[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] ietf london idn wg meeting minutes
At/À 14:25 2001-08-26 +0200, Dan Oscarsson you wrote/vous écriviez:
> >included is the first version of the idn wg meeting minutes.
>
>Thanks. Reading through it I have several questions and see
>incorrect statements.
to my knowledge you were not present at the wg session, so when you say:
"incorrect statements", you mean that you disagree with what was said
during the meeting, but you are not saying that this is incorrect minutes.
>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?
While any useful information for the discussion of the wg is always
welcome, here again, these activities outside the idn session would not be
included in the meeting minutes.
> >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.
that is not what we heard from most implementors. Maybe there is an
understanding problem with the statement. I try to explain: the ACE cpu
processing is much much less than the Nameprep cpu processing.
> >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.
none. just making sure that we agree on a pre-processing step. The actual
details of the step was discussed after.
>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".
it was said that the current nameprep authors (Paul and I) were already
working on a stringprep document which will discuss about i18n string
preparation. But this would be a generalized nameprep that could be used by
other apps/protocols. But the stringprep work is outside of the wg charter.
> >================================================================
> >
> >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,
AAAA records are in bind since 4.9.5 and this was documented in RFC 1886,
December 1995.
A6, bitlabels and dname have recently been moved to experimental.
> never be able to use new record
>types like SRV or DNAME.
some dns records can be used without a full and complete deployment.
>I cannot understand the resistance
it is not "resistance". it is a compromise. no proposal on the table is
perfect. all have pros and cons.
>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,
me too: draft-ietf-idn-idne-xx.txt
>just like DNSSEC and others. And I have for a long time felt that many
>do not want to go there.
hopefully all wg participants are openminded...
>Should we move the UDNS and other protocol
>changing drafts over to DNSEXT and leave the non-DNS-protocol IDNA here?
it is sure that any proposal that changes the DNS would have to be
discussed in the DNSext wg.
>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.
for me idna is not a perfect solution, but has the best support in the wg
among all proposals.
> Dan
Marc.