vint at google.com
Tue Dec 22 02:32:15 CET 2009
the mappings document was deliberately not normative. It outlined a
set of mappings that the authors and others saw as meeting user
expectations created in part by the case insensitivity of the ASCII
DNS, for example. It does not promote the more extensive mapping found
in TR46. Despite the backward compatibility arguments, at least some
of us worry that the TR46 mappings may tend to create defacto "PVALID"
behaviors in IDN domain name labels by characters that aren't, in fact
PVALID. At least that's how I have been interpreting the distinction.
They also create a kind of conflict with the canonical A-Label/U-label
commutation of IDN2008.
On Dec 21, 2009, at 8:20 PM, Shawn Steele wrote:
> There is very little consensus for the mapping document. The
> mapping document was created as a minimal mapping which was pretty
> much ignored by those in favor of a more UTR-46 style mapping when
> it became clear that "more" mapping wouldn't happen in the WG.
> The big difference seems to be the "why do we need these?" view vs.
> "what harm are they and they won't break stuff if we keep them in"
> From: idna-update-bounces at alvestrand.no [idna-update-bounces at alvestrand.no
> ] on behalf of Vint Cerf [vint at google.com]
> Sent: Saturday, December 19, 2009 4:57 PM
> To: Michel SUIGNARD
> Cc: idna-update at alvestrand.no
> Subject: Re: idna-mapping update
> Two things strike me about your line of reasoning. First, the IDNABIS
> WG spent considerable time crafting the mapping document - we achieved
> a delicate consensus on this non-normative contribution. Re-opening
> this within the IDNABIS WG does not strike me as fruitful. At least
> the IDN Guidelines group is starting with a relatively open agenda if
> I have understood correctly. Second, the assumption that "most of us
> have no say" may be an overstatement or perhaps mistaken. Cary Karp
> can probably speak to this more accurately than I can but I see no
> reason why a competent contribution would be turned away. I feel
> strongly motivated to complete the technical work of IDNABIS, which I
> believe was accomplished with the normative documents; the rationale
> and mappings documents illustrate significant issues in the design and
> implementation of IDNA2008. One might even argue that forwarding the
> present documents to IESG and gaining their imprimatur would provide a
> good foundation for the discussions to be undertaken in the Guidelines
> On Dec 19, 2009, at 6:16 PM, Michel SUIGNARD wrote:
>>> From Vint Cerf
>>> Another way to think about this, Michel, is that the IDNABIS
>>> working group simply does not make a normative recommendation
>>> on mapping. It has been consistent about no mapping for
>>> registration (in other words, you register only PVALID
>>> characters and the registry does not map for the registrant).
>>> With regard to lookup, there isn't consensus within the IDNABIS
>>> WG on either the nature of mappings or even the advisability.
>> No disagreement here, my message was aiming at making the mapping
>> process consistent between idna-mappings and Unicode TR 46, to avoid
>> confusion among implementers. The fact that idna-mappings is out
>> there in the idna-bis web page is still an implied indication that
>> there is support for it. If it gets published either as an optional
>> part of idna 2008 or separately, it would still be a good idea to
>> converge with what was suggested in Unicode TR46.
>>> It has been suggested that a better forum in which to deal with
>>> IDNA2003 and IDNA2008 incompatibility is the ICANN IDN Guidelines
>>> Committee. That may be a better forum with broader participation
>>> than the IDNABIS working group in which the TR46 proposal or other
>>> proposals may be discussed. If we adopt Cary Karp's offer, your
>>> observations, below, would be input into the Guidelines committee
>> Compatibility issues are only part of the problem. Having a well
>> recognized mapping is also important. Combining both as done in the
>> proposal I am advocating is probably the best solution. Finally I am
>> not sure to see how the Guidelines committee process will create
>> broader participation if we are limited to discretionary input into
>> a committee where most of us have no say.
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update