Re: IDNA reference

--On Tuesday, September 07, 2010 10:14 PM +1000 Wil Tan
<wil@dready.org> wrote:

> On Tue, Sep 7, 2010 at 7:41 PM, Julian Reschke
> <julian.reschke@gmx.de>wrote:
> 
>> Hi,
>> 
>> <http://tools.ietf.org/html/draft-ietf-iri-3987bis-01#section
>> -3.4>:
>> 
>>   Replace the ireg-name part of the IRI by the part converted
>>   using the ToASCII operation specified in Section 4.1 of
>>   [RFC3490] on each dot- separated label, and by using U+002E
>>   (FULL STOP) as a label separator, with the flag
>>   UseSTD3ASCIIRules set to FALSE, and with the flag
>>   AllowUnassigned set to FALSE.  The ToASCII operation may
>>   fail, but this would mean that the IRI cannot be resolved.
>>   In such cases, if the domain name conversion fails, then
>>   the entire IRI conversion fails.  Processors that have no
>>   mechanism for signalling a failure MAY instead substitute
>>   an otherwise invalid host name, although such processing
>>   SHOULD be avoided.
>> 
>> In August, RFC 3490 has been obsoleted by RFC 5890/91.

And there is no "ToASCII" operation any more, so any such
sentence will need rewriting, not just an updated reference.
"Producing A-labels" (below) is better terminology.

Actually, 5890/91/92/93 and arguably the still unpublished RFC
5895.  RFC 5894 is not normative, but contains the explanations
that might be more useful to some people as well as a discussion
of the transition issues.

>> What's the right reference for ToASCII now?

> The closest thing would be sections 5.1 to 5.5 of RFC 5891,
> but simply referencing them will lead to incompatibility (e.g.
> producing different A-labels from the IDNA2003 version.)

We have been recommending saying something like "... IDNA as
described in RFC 5890 and the companion documents to which it
points".

> http://unicode.org/reports/tr46/ details a good transition
> strategy, but I wonder how one could work that into iri-bis.

TR46 (which is not yet a stable reference since the text is
still under review and may change yet again), details a
transition strategy.  But it is one that does not have IETF
consensus, partially because it posits a much slower transition
to allow for circumstances that are either very low frequency or
that represented abuses even under pre-IDNA2008 standards and
best practices.   Let's not make things more confusing by trying
to reference it as if it were the only reasonable approach to
the situation.

     john

Received on Tuesday, 7 September 2010 15:06:43 UTC