Subject: Re: [idn] ietf london idn wg meeting minutes

From: Dan Oscarsson <[email-masked]>
Date: Sun, 26 Aug 2001 14:25:00 +0200 (MEST)

>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

---

From: "James Seng/Personal" <[email-masked]>
Date: Sun, 26 Aug 2001 21:54:39 +0800

> of UCS, most ACE encodings are a very expensive step compared to
nameprep.

I am curious about this statement. Do you have any numbers for this?

You see, all datas from other sources, from Verisign, i-DNS.net, JPNIC
etc who have done Nameprep-ACE/UTF-8 have clearly shown that Nameprep ~=
10xACE in terms of CPU time.

http://www.i-d-n.net/ietf50/idn-minneapolis-implementors-zhuyu.ppt
http://www.i-d-n.net/ietf50/idn-implementors-colosi.ppt

ps: Sorry, only PPT since that is the presentation material given to us
by the presenter.

-James Seng

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 26 Aug 2001 10:35:01 -0400

Morning Dan,

> what happened related to IDN outside the session?

Hmm. Broad question. Could you be more specific?

> In the context of nameprep some talk about canonicalisation.

I don't think the reference is to CNAMEs.

>> [Patrik's comment, the general apps requirement (IMO under-specified)
>> and the idn requirement (IMO over-specified), harmonized.]
>

This was the subject of some jack-in-the-box back-and-forth to the mic on
my part. There is the "uniprep" problem, and layered on top that is the
"nameprep" problem.

In Marc's notes this was captured as "unichar" and the note about the tscconv
and similar range-specific drafts.

>                      ... Should we move the UDNS and other protocol

Erik Nordmark asked me to copy our eventual (sorry, I've got provreg, whois,
some related work a bunch of icann stuff, and a registry to take "live" to do
also) utf draft to this WG. 

We've set up a utf list, implementors welcome, just drop me a line.

Eric

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 26 Aug 2001 15:31:54 -0400

At/À 14:25 2001-08-26 +0200, Dan Oscarsson you wrote/vous écriviez:

>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.
>

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.

>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.

>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.

>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.

>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

me too: draft-ietf-idn-idne-xx.txt

>do not want to go there.

hopefully all wg participants are openminded...

>Should we move the UDNS and other protocol

it is sure that any proposal that changes the DNS would have to be 
discussed in the DNSext wg.

>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.