[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] ietf london idn wg meeting minutes
>included is the first version of the idn wg meeting minutes.
Thanks. Reading through it I have several questions and see
incorrect statements. They are in the text below.
Does any of you who were at the meeting have any comments on
what happened related to IDN outside the session?
>ACE EVALUATION WITH IDNs ALREADY REGISTERED, Yoshiro Yoneya
>
>- Most important evaluation criterion to study is to maximize number
> of characters, raw speed is less important because nameprep is the
> slow stage.
This is not correct in general. At my site which uses the Latin-1 subset
of UCS, most ACE encodings are a very expensive step compared to nameprep.
>MATCHING (NAMEPREP)
>
>- Need for a standardized pre-processing step regardless of what IDN
> protocol we choose?
> Yes lot of hands
> No one hand
>
I am not sure what you discussed to do in the pre-processing step.
The minimum mandatory pre-processing step should be normalisation
to Uncode form C.
To match two labels in DNS you should do:
1) Start with the normalised name.
2) Form-fold the name
3) Binary compare.
Form-folding may not remove any character that is suitable in a name
(any name includeing host names). Only an application may reject a name due to
unsuitable characters for the specific type of name.
In the context of nameprep some talk about canonicalisation.
What is a canonical name?
In RFC 1035 a CNAME record defines the canonical name for an alias.
From this I get that the canonical name is not the same as the
form-folded name. A canonical name may include mixed case and other
forms not significant in matching.
>Other comments:
>
>Patrik Faltstrom: Doesn't preclude other pre-processing before it,
>which some people have worried it would. But even so, IETF really
>needs to have one standard way of processing Unicode.
Is DNS going to use the standard IETF way of handling UCS or a special
type? Nameprep as it is defined to day is not fit to be used for
other places except matching of "host names".
>================================================================
>
>PROTOCOL PROPOSALS, Dave Crocker
>
>
>Encoding efficiency:
>- ACE is an encoding scheme
It is much more. UTF-8 is a character encoding scheme. Most ACE today
is a character compression scheme followed by a binary data to ASCII
encoding scheme.
> - longer mapping mean shorter names
Not really. Just use a long label type in DNS.
>
>ACE has an extraordinarily minimal amount of change necessary to make
>an IDN useful, just two applications. This is about as good a
>transition scheme as you can possibly get.
Well, using plain UTF-8 you also only need two applications. So it is just
as good in that sense.
>
>UTF-8 is an extreme in the opposite direction, it requires that
>everything work end-to-end.
Not at all! A very simple UTF-8 with every thing form-folded is just like
ACE. A more well working solution with support for ACE when needed and
less requirement of the applications, only need support in two applications
and the authorative DNS servers for the domain queried.
>
>1. ACE only four pluses good
>2. UTF-8 only five minuses bad
No, UTF-8 is about the same as ACE. ACE as used in IDNA also has the
negative aspect that it requires form-folded names.
>
>Transition Interactions:
>-------------------------------------------------------------------------
>-------------------------------------------------------------------------
> Client-> Server-> ACE UTF-8
> Server Client
>-------------------------------------------------------------------------
>1. old client old dn new dn transparent UTF-8 and ACE
> new server maybe break client
>-------------------------------------------------------------------------
>2. new client, new dn old dn transparent break server?
> old server
>-------------------------------------------------------------------------
>-------------------------------------------------------------------------
UTF-8 will not break server or client, if combined with ACE. Without ACE
it will break some clients.
>
>Specification comparison:
>-------------------------------------------------------------------------
> Efficiency Transition Risk/Operational
> Expense
>-------------------------------------------------------------------------
>IDNA (ACE) bad(data) automatic none
>-------------------------------------------------------------------------
> how to detect
>uDNS (UTF-8) poor(data) when to use ACE? high
> (poorly defined
> and not realistic)
>-------------------------------------------------------------------------
I do not understand the comment about UDNS above. To me, who has
a deep technical background, there is low or none in operational risk
and there are no problems to detect when to use ACE.
When many compares IDNA (ACE) with UDNS they think it is very bad that
UDNS requires modifications in the DNS protocol and DNS server.
Why?
If you do not want to change the DNS protocol/DNS servers you will never
get DNSSEC, never be able to use IPv6, never be able to use new record
types like SRV or DNAME.
I cannot understand the resistance against updating the DNS protocol to
support non-ASCII in a complete and consisten way. Instead some want to
add non-ASCII support by just do it for "host names" and do it by adding
an additional layer on top of the DNS protocol.
I have since the start of the IDN discussions worked for an update of DNS,
just like DNSSEC and others. And I have for a long time felt that many
do not want to go there. Should we move the UDNS and other protocol
changing drafts over to DNSEXT and leave the non-DNS-protocol IDNA here?
For me the IDNA way will always be an incomplete solution and impossible
for me to support in a good way without changing my DNS servers.
Dan