Consensus Call on Latin Sharp S and Greek Final Sigma

[Lisa Dusseault]

I don't believe we know what the WG consensus position is around how
strongly pre-lookup mappings are recommended and in what use cases,
and how compatible optional pre-lookup mappings are with IDNA2003
in-protocol mapping.

Agreeing with you to a large extent Vint, I believe there is a strong
consensus in the WG that mappings "aren't part of the protocol",
meaning mapping shouldn't be required in all cases. Certainly,
registries shouldn't be required to automatically map any character
into any other character before registering the mapped domain name:
better to make the domain name holder be explicit about the exact
domain name they are registering.  We have also referred to use cases
involving client software doing lookup of domains that are already
supposed to be valid, in which context an invalid character would
simply be a software error rather than a situation that required
mapping. In this matter, we have consensus to do something different
in IDNA2008 vs IDNA2003.

I believe we also do have consensus in the equivalence of A-label and
U-label forms and transformation in either direction.

After that it gets confusingly nuanced.  We even discussed having a
different term for optional, pre-lookup mapping of user-typed-in
domain names, including links found in HTML typed in by the HTML
author.  I believe we do have consensus in the WG that this type of
helpful mapping is going to be implemented, for example in Web
browsers, as being a user experience that is preferred over a dialog
interruption or error.

So that leaves us with a great deal of progress in IDNA2008, and a lot
that is decided by WG consensus, but still with a gap in our total
consensus.  Some people would prefer that optional, pre-lookup mapping
be wide open.  Others would prefer would that although pre-lookup
mapping should be optional, IF it is done, it MUST be done one way.
There's even room for a middle ground where there might be more than
one recommended standard set of mappings, but they should be done as a
matter of standardization and not as a matter of full implementer
discretion, if at all possible.  There is room for splitting the
mappings territory up per-application: perhaps domains in HTTP URLs
and browser address bars should be mapped one way, but other types of
URLs could follow "no mappings allowed" rules.

Finally, we have the options around transition strategies (such as
bundling recommendations) that might allow us to come to consensus
regarding these optional pre-lookup mapping questions.

I appreciate all the discussion that is leading us to a better
understanding of the issues around those last issues, and developing
consensus regarding those last options.

Lisa

On Mon, Nov 30, 2009 at 8:19 PM, Vint Cerf <vint at google.com> wrote:
> We had long since concluded that there should be no mappings within
> protocol, either within the lookup procedure or the registration procedure.
>
> We agreed to preserve the equivalence of A-label and U-label forms via
> punycode transformation/encoding.
>
> We added a non-normative document about mapping for User Interface purposes.
> Implicit in that was awareness that context might make a difference as to
> choice of mapping.
>
> Re-introduction of mandatory/normative mapping strikes me as old territory
> that had been settled.
>
> Vint
>
>
> On Nov 30, 2009, at 9:02 PM, Shawn Steele wrote:
>
>> On 2009/11/30 16:45, Shawn Steele wrote:
>>>>
>>>> I agree with Mark that this is very badly worded.
>>
>>> Can you propose (in your eyes) better wording?
>>
>> It's easier to say it is badly worded :)  I'll try:
>>
>> (1) Both characters should be PVALID, the 2003 mappings will break.
>> (2) The 2003 mappings MUST be applied to both characters, and both
>> characters should be DISALLOWED.
>> (3) The 2003 mapping for Greek Small Letter Final Sigma MUST be applied,
>> but not the Latin Small Letter Sharp S mapping.  The Latin Small Letter
>> Sharp S should be PVALID.
>> (4) The 2003 mappings for Latin Small Letter Sharp S MUST be applied, but
>> not the Greek Small Letter Final Sigma mapping.  The Greek Small Letter
>> Final Sigma should be PVALID.
>>
>> There's a fundamental problem with my wording; it presumes we have to have
>> mappings, which opens a different set of problems.  Perhaps we should start
>> with a consensus call on mappings first:
>>
>> (A) No mappings are permitted.
>> (B) Only ASCII case mappings are permitted.
>> (C) Any mapping MAY be used.
>> (D) Only IDNA standard mappings MAY be used, other mappings are
>> disallowed.
>> (E) IDNA standard mappings SHOULD be used, other mappings are disallowed.
>> (F) IDNA standard mappings MUST be used, other mappings are disallowed.
>>
>> That leaves open what an "IDNA standard mapping" is, however I would
>> suggest that it be as close to IDNA2003 as possible, eg: UTR46.  Presumably
>> if we knew mappings MUST NOT, MAY, SHOULD, or MUST be used, then we could
>> better agree on what exactly those mappings should be.
>>
>> As everyone knows already, I would prefer (F) or (E), or reluctantly (D).
>>  IMO (A) is not practical, (B) is not internationalized, & (C) is chaos.
>>
>> -Shawn
>
>