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

From: Elisabeth Blanconil <[email-masked]>
Date: Mon, 31 Aug 2009 00:35:09 +0200

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

---

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Mon, 31 Aug 2009 02:15:07 +0200

Elisabeth,
you only consider the formal aspects. Technically,

2009/8/31 Elisabeth Blanconil <[email-masked]>

> -> this is now what you propose.

this is something we could support if it helped majuscules support.

> -> you now propose a change from "xn--" to "$$--"

this is something wich is not Internet specific and we need to see organised
at a multilingual digital ecosystem adminance level (ISO?).

> of character mapping in the protocol)"

we said we did not object that change. If independence (i.e. net neutrality)
remains the ultimate objective.

Portzemparc
an IETF user

---

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Mon, 31 Aug 2009 04:51:16 +0200

2009/8/31 Paul Hoffman <[email-masked]>

> At 4:08 AM +0200 8/31/09, jean-michel bernier de portzamparc wrote:
> >I think I would support your proposition, but I am not sure I understand
>  "A pair of A-labels MUST be compared using a case-preserving comparison.".
>
> A comparison between xn--Axdf and xn--axdf would yield "not matched".
>

Here is where I dont understand. This violates the DNS context. DNS
comparison rules MUST apply because A-labels are whole ASCII labels.

>  >Moreover, the way you phrase it seems to integrate the case-preservation
> in the protocol, i.e. in the ACE and not to keep it as a part of its use?
>
> Uppercase characters are not allowed in the U-labels anyway, so there is no
> reason to keep them in the A-labels.
>

Uppercase characters are supported but not used by ASCII Domain Name. Once
ASCII I do not see why there would be a difference based upon the origin
(how do a non-IDNA aware system would know it?).

>  >The rule proposed by Andrew Sullivan seems quite systematic and clear?
> >
> >1. The encoding of A-label1 according to [RFC3492] results in U-label1.
> >2. The decoding of U-label2 according to [RFC3492] results in A-label2.
> >3. A-label1 is equivalent to A-label2 according to DNS matching rules for
> labels.
> >4. U-label1 is bistring equivalent to U-label2.
>
> Well, no one spoke up for it. Personally, I find the introduction of
> A-label2 and U-label2 out of thin air to be confusing.
>

Well, it is the same as the present text, but clearer. It appeals to me by
its usual scientific approach.  The point is that you seem to disagree with
the rule 3. I did not realise that before using that presentation. It shows
it well.

 >We felt it addressed our point "References to the lower/uppercase image
> can be understood by DNS old-timers, but is confusing to newcomers, as it
> does not reflect the same functionality and because U-label/A-label
> lower/uppercase treatment is not the same." since everyone knows that
> punycode is case preserving.
>
> I figure it is easier to remove the comparisons to regular-style DNS
> mapping than to try to show the differences.
>

This is not where we saw the problem. We saw it in an explanation using a
non yet fully accepted image by a non-specialist. And a confusion between
upper-cases in Ascii and Unicode. We are users, not much interested in the
black-magic if we can. We just want:

(1) in real life use no more constraint IRT upper-cases than in ASCII
English.
(2) IDNA2008 is case insenstive, but we need to have it majuscule sensitive.

We have no real problem with these needs if the ASCII rule is the same in
every case, i.e. XN--ABC-DEF is the same as xn--abc-def. This is what we
understand as the protocol (on the wire) part. What the applications can do
("IDNA2008 should prohibit upper-case characters as input even though user
interfaces to applications should probably map those characters"), i.e.
"post-wire" is another different non-ACE but ACE-use story.

Or did I misunderstand the whole thing?

Portzamparc
an IETF user