Subject: Re: [mile] IDN issue

From: <[email-masked]>
Date: Wed, 25 Jan 2012 17:06:58 -0500

Hello Pete, Peter, and Sean,

The working group provided a few comments, they agree with internationalization support, but would prefer to keep the RID message in UTF-8.  They would prefer any translation to punycode happen by the DNS supporting the RID application.  Are you OK with changing the text as follows:

11. Internationalization Considerations

   The Node class identifies a host or network device.  This document
   re-uses the definition of Node from the IODEF specification
   [RFC5070], Section 3.16.  However, that document did not clearly
   specify whether a NodeName could be an Internationalized Domain Name
   (IDN).  RID systems MUST treat the NodeName class as a domain name
   slot [RFC5890].  RID systems SHOULD support IDNs in the NodeName
   class;  if they do so, the UTF-8 representation of the domain name MUST
   be used, i.e., all of the domain name's labels MUST be U-labels
   expressed in UTF-8 or NR-LDH labels [RFC 5980]; A-labels
   MUST NOT be used.  A RID system can convert between A-labels
   and U-labels by using the Punycode encoding [RFC3492] for A-labels
   as described in the protocol specification for Internationalized
   Domain Names in Applications [RFC5891].

From:
>> 11. Internationalization Considerations
>>
>> The Node class identifies a host or network device. This document
>> re-uses the definition of Node from the IODEF specification
>> [RFC5070], Section 3.16. However, that document did not clearly
>> specify whether a NodeName could be an Internationalized Domain Name
>> (IDN). RID systems MUST treat the NodeName class as a domain name
>> slot [RFC5890]. RID systems SHOULD support IDNs in the NodeName
>> class; if they do so, they MUST ensure that the domain name is
>> represented only using ASCII characters, i.e., all of its labels
>> MUST be either A-labels or NR-LDH labels [RFC5890] and
>> internationalized labels MUST be encoded as A-labels using the
>> Punycode encoding [RFC3492] as described in the protocol
>> specification for Internationalized Domain Names in Applications
>> [RFC5891].
>>

Thank you,
Kathleen (as author)

---

From: Brian Trammell <[email-masked]>
Date: Wed, 25 Jan 2012 23:18:02 +0100

Greetings, all,

It appears that WG discussion on this last issue is closed, at least; from my point of view, the draft is ready for submission of the next (and hopefully final :) ) revision.

Cheers,

Brian (as WG chair)

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 25 Jan 2012 15:38:34 -0700

> Hello Pete, Peter, and Sean,

Howdy. :)

> The working group provided a few comments, they agree with
> internationalization support, but would prefer to keep the RID
> message in UTF-8. 

UTF-8 is a character encoding scheme (RFC 6365). The data of a RID
document could contain A-labels (or other text with characters only from
the ASCII range) yet still be encoded in UTF-8. So the choice of UTF-8
encoding for the RID document is somewhat orthogonal to the question of
whether to use A-labels or U-labels in the domain name slot of the
NodeName class.

> They would prefer any translation to punycode
> happen by the DNS supporting the RID application. 

That is one option, yes.

> Are you OK with
> changing the text as follows:
> 
> class;  if they do so, the UTF-8 representation of the domain name
> MUST be used, i.e., all of the domain name's labels MUST be U-labels 
> expressed in UTF-8 or NR-LDH labels [RFC 5980]; A-labels MUST NOT be
> used.  A RID system can convert between A-labels and U-labels by
> using the Punycode encoding [RFC3492] for A-labels as described in
> the protocol specification for Internationalized Domain Names in
> Applications [RFC5891].

Well, it's important to understand what you're signing up for when you
say that you want to use U-labels instead of A-labels. Please consider
the definition of U-label from RFC 5890:

   o  A "U-label" is an IDNA-valid string of Unicode characters, in
      Normalization Form C (NFC) and including at least one non-ASCII
      character, expressed in a standard Unicode Encoding Form (such as
      UTF-8).  It is also subject to the constraints about permitted
      characters that are specified in Section 4.2 of the Protocol
      document and the rules in the Sections 2 and 3 of the Tables
      document, the Bidi constraints in that document if it contains any
      character from scripts that are written right to left, and the
      symmetry constraint described immediately below.  Conversions
      between U-labels and A-labels are performed according to the
      "Punycode" specification [RFC3492], adding or removing the ACE
      prefix as needed.

Notice what's entailed here...

1. Unicode Normalization Form C (NFC):

   http://www.unicode.org/reports/tr15/tr15-31.html

2. Constraints on permitted characters from RFC 5891:

   http://tools.ietf.org/html/rfc5891#section-4.2

3. The property rules from RFC 5892:

   http://tools.ietf.org/html/rfc5892#section-2
   http://tools.ietf.org/html/rfc5892#section-3

4. The bidi constraints from RFC 5892, see also RFC 5893:

   http://tools.ietf.org/html/rfc5893

Do IODEF/RID implementations want to sign up for all that?

Furthermore, if we start accepting input strings then we might well need
to specify mappings of the kind that are explained in RFC 5895. Notice
the very helpful Section 3 in the latter specification:

   If you are implementing a mapping for an application or operating
   system by using exactly the four steps in Section 2, the authors of
   this document have a request: please don't.  We mean it.  Section 2
   does not describe a universal mapping algorithm because, as we said,
   there is no universally-applicable mapping algorithm.

   If you read the material in Section 2 without reading Section 1, go
   back and carefully read all of Section 1; in many ways, Section 1 is
   more important than Section 2.  Further, you can probably think of
   user interface considerations that we did not list in Section 1.  If
   you did read Section 1 but somehow decided that the algorithm in
   Section 2 is completely correct for the intended users of your
   application or operating system, you are probably not thinking hard
   enough about your intended users.

In short, there be dragons.

Your life will be simpler if you say "we might get some IDNs out of the
DNS or from somewhere else, and for our purposes we're going to assume
that they're all A-labels because we don't want to deal directly with
all that i18n madness, since it's just not a critical feature for RID
itself and we're just a consumer of DNS names".

Just my centigram of silver. :)

Peter

--
Peter Saint-Andre
https://stpeter.im/