Subject: Re: [iucg] Comments on draft-ietf-idnabis-defs-10

From: Vint Cerf <[email-masked]>
Date: Sun, 30 Aug 2009 23:37:55 -0400

No I did not propose a change. I used these characters to mean that anything
with "--" in the third and fourth character positions on the wire are
reserved strings. V

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Wil Tan <[email-masked]>
Cc: Andrew Sullivan <[email-masked]>; [email-masked]
<[email-masked]>; John C Klensin <[email-masked]>; internet
users contributing group <[email-masked]>; lisa Dusseault
<[email-masked]>
Sent: Sun Aug 30 18:35:09 2009
Subject: Re: Comments on draft-ietf-idnabis-defs-10

Dear Wil,
thank you for reading the interplus provisional documents and spotting
how IUCG user members trust the WG Charter when it states :

"The WG will stop work and recommend that a new charter be generated
if it concludes that any of the following are necessary to meet its
goals:

"(i) A change to the "punycode" algorithm or to the ACE approach to
encoding names  in the DNS."
-> this is now what you propose.

"(ii) A change to the ACE prefix from "xn--"
-> you now propose a change from "xn--" to "$$--"

"(iii) A change to the basic approach taken in the design team
documents (Namely: independence from Unicode version and elimination
of character mapping in the protocol)"
-> Vint already proposed the change of the last sub-point.Yet the WG
has not stopped work as the Chair confirmed it when I asked if it was
necessary for an I_D concerning and quoting the WG to be published as
a WG Draft or if IUCG could submit it.

As we expected it, at this stage of the document set production, a few
hours before the end of the WG/LC, you question the worked out rough
consensus. Since we obviously expected your requests, we have
considered at length how they could be best addressed. Our consensus
is:

1. either the Chair calls for a stop on the WG work, and a debate on
Charter changes to be proposed.
2. either the Charter (modified or not?) is respected and we make (i),
(ii) and (iii) an issue for the IETF/LC.
3. or we face an IETF process and architectural conflict that will
probably resolve at network clients level.

It would be better to avoid (3). (1) and (2) seem technically
equivalent at this stage. The real issue is the impact of the
resulting further delays in implementing IDNA2008, on Fast Track and
IDNccTLDs, etc. and their FLOSS strategic equivalents: Project.FRA,
Multilinc, etc. FYI, since FLOSS have no financial nor political
dependency, AFAIK they seem to be on track.

Best regards.
Elisabeth Blanconil

2009/8/30 Wil Tan <[email-masked]>:
>
>
> On Sat, Aug 29, 2009 at 5:17 PM, John C Klensin <[email-masked]> wrote:
>>
>> --On Monday, August 24, 2009 23:24 -0400 Andrew Sullivan
>> <[email-masked]> wrote:
>>
>> >
>> > In a previous comment (see
>> > http://www.alvestrand.no/pipermail/idna-update/2009-July/00497
>> > 0.html), I made a vague remark about something I find
>> > worrisome in this text in §2.3.2.1:
>> >...
>>
>> These changes, with Paul's suggested modifications, have been
>> tentatively accepted and incorporated in the document.  Anyone
>> who objects should say so quickly.
>>
>
> I posted a comment related to the definition of A-label some time ago, but
> the thread was
> digressed:
> http://www.alvestrand.no/pipermail/idna-update/2009-June/004558.html
> The issue is with case variants of A-labels. By DNS rules, as mentioned in
> several places in the idnabis-defs draft, A-labels are to be compared in a
> case independent manner. However, if certain characters in an A-label have
> been uppercased, the Punycode decoding algorithm (due to its mixed-case
> annotation feature) may produce invalid U-label because the ASCII
> characters
> will be in capital letter form.
> =wil
> _______________________________________________
> Idna-update mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
_______________________________________________
Idna-update mailing list
[email-masked]
http://www.alvestrand.no/mailman/listinfo/idna-update

---

From: Elisabeth Blanconil <[email-masked]>
Date: Mon, 31 Aug 2009 11:52:20 +0200

> with "--" in the third and fourth character positions on the wire are

Dear Vint,
Sorry, but obviously you did.

Elliptic or not:

- This WG is chartered to deal with "xn--". Dealing with "00--" to
"zz--", is a change indeed.
- The same as imposing lowercases to punycode is a change in the
punycode algorithm and/or ACE (impact on UTF-8 conversion?).
- The same as declaring invalid some domain names because of the way
they are written is a change in the ACE and DNS
- The same as mapping some characters (unicodepoints?) requires the
charter change you requested.

Wil is right: the whole thing does not stand well. We all know that.
We can be incremental, disruptive, messy or smart about it. We should
stay on our incremental tack. And be smart further on (interplus).
Disruptive changes on this last working minutes is messy. There are
plenty of pending issues which have not been addressed yet (except by
Harald) at http://wikidna.org/index.php?title=WG-IDNA_LC. I wish we
are done with IDNA2008 and get it published in 2010, before I am a
grand-mother.

Elisabeth Blanconil

---

From: John C Klensin <[email-masked]>
Date: Mon, 31 Aug 2009 06:01:47 -0400

--On Monday, August 31, 2009 11:52 +0200 Elisabeth Blanconil
<[email-masked]> wrote:

>...
> Elliptic or not:
> 
> - This WG is chartered to deal with "xn--". Dealing with
> "00--" to "zz--", is a change indeed.

No, the WG is chartered to deal with IDNA.  We are not proposing
to use those prefixes, only to impose a condition on their use
for IDNA-aware applications.  That condition (or some very small
variation on it) has been in the documents since almost the time
the WG started.

> - The same as imposing lowercases to punycode is a change in
> the punycode algorithm and/or ACE (impact on UTF-8
> conversion?). 

No one has proposed changing Punycode, although it has been
tempting.  As I noted, both the ToASCII operation of IDNA2003
and the operations of IDNA2008 produce lower-case from the
Punycode algorithm.   Under IDNA2003, if someone later mixes the
cases, the internal Stringprep processing causes the anomaly now
under discussion to be eliminated.  The question is how to
prevent the anomaly under some edge cases in IDNA2008 and
preserve the existing behavior.

- The same as declaring invalid some domain
> names because of the way they are written is a change in the
> ACE and DNS

Unless you are referring to a case I can't think of right now,
this is not being done.  

> - The same as mapping some characters (unicodepoints?)
> requires the charter change you requested.
 
> Wil is right: the whole thing does not stand well. We all know
> that. We can be incremental, disruptive, messy or smart about
> it. We should stay on our incremental tack. And be smart
> further on (interplus). Disruptive changes on this last
> working minutes is messy. There are plenty of pending issues
> which have not been addressed yet (except by Harald) at
> http://wikidna.org/index.php?title=WG-IDNA_LC. I wish we are
> done with IDNA2008 and get it published in 2010, before I am a
> grand-mother.

Regardless of your intentions, your behavior pattern is not
advancing things.

    john

---

From: jefsey <[email-masked]>
Date: Mon, 31 Aug 2009 17:56:55 +0200

Dear all,
we are now a few hours before the closing of the WG-IDNABIS/LC. We 
known that the current confusion attempt would be tried by Wil Tan, 
and for which reasons. I certainly support what you have said so far 
on the WG list. However, I urge you not to increase the confusion. 
This is pure tactics. We all know by who and why (Wikipedia speaks 
up!), for many years.

We have, from the very begining, only one question we first asked 
Vint: what are the Chair's real targets? He initially sided with the 
answers prompted by James Seng, what dismayed some people. Today he 
has to formaly take side in forwarding a document set violating the 
Charter or not (sorry, John, but it might as we [or big others] may 
ask the IESG and IAB to confirm). We decided to support the current 
version of the document set, because of the reasonable technical 
positions of people in copy. For that reason I asked you to delay the 
interplus documentation so we could possibly amalgamate/build upon 
IDNA what is our ultimate target for the Intersem. We will review 
this next week (I might be back in Versailles only on Tuesday).

Decision rests with the Chair.
Have a good interesting day.
jefsey

PS. For information of some people in CC who may ignore it: I think 
that DNS LDH is a blessing for 
internationalization/multilingualization robustness. I have no 
problem at all with Vixie's proposition as I think it would definitly 
protect us from upper/lowercase/majuscule confusion in making clear 
they are two different and orthogonal issues (this was not my initial 
position).