UTF-8

[Nicolas Williams]

On Sat, Jun 19, 2010 at 10:22:36AM +0200, jean-michel bernier de portzamparc wrote:
> The points you raise from your perspective are those we raise from our
> Internet Users' perspective. I am not familiar with your area but for two
> years we met the same problem we analysed in terms of "IS/ARE, MUST, SHOULD,
> MAY" interoperation. The major IDNA2008 is the switch of the MUST from the
> Internet system, to the internet use interface (we named "internet peritem"
> to get a clear difference) that itself is related to the User Inteface of
> applications of the present/future "internet exotem".
> 
> You join us in calling for "MUST"s that permit interoperability and you call
> for someone issuing these MUSTs. There is no MUST in IDNA2008, there only
> are "IS/ARE". IDNA2008 says the way the Internet System is (DNS), period
> (IS/ARE). Now, we need someone to tell/some place to discuss how we MUST

Well, a quick check of draft-ietf-idnabis-protocol-18 shows plenty of
normative language in use:

"
3.1. Requirements

   IDNA makes the following requirements:

   1.  Whenever a domain name is put into an IDN-unaware domain name
       slot (see Section 2 and [IDNA2008-Defs]), it MUST contain only
       ASCII characters (i.e., its labels must be either A-labels or NR-
       LDH-labels), unless the DNS application is not subject to
       historical recommendations for "hostname"-style names (see
       [RFC1034] and Section 3.2.1).
"

There are five more MUSTs just in that section (3.1).

I count 28 (28!) MUSTs and MUST NOTs altogether in that one I-D.

And by my reading these are very strong normative requirements.  That
very first one requirement that I quote above is the most important one.
It captures the essense of IDNA.

Now, what isn't specified in as much detail is: just what is an
"IDN-unaware domain name slot".  Yes, a definition is given in
draft-ietf-idnabis-defs-13, but there is no exhaustive list.  If anyone
is going to complain about lack of normative language in IDNA2008, they
should complain about the lack of an exhaustive list of IDN-aware and
-unaware domainname slots.  Of course, there's a reason such a list is
missing: we need to consider all domainname slots on a case-by-cases
basis, and the IDNAbis WG couldn't have tackled that job.

I think the lack of an even of small subset of these slots is a problem
-- not a huge problem, but it is a problem.  I also think that more
guidance to protocol designers, and to developers, would be nice -- if
it weren't so late, I might insist on it.  However, I think there's
enough for us to get by, and any guidance that could be given couldn't
be normative.

For example, in the NFSv4 WG we're discussing what to do about NFSv4's
domainname slots.  First we need to establish how they are handled by
existing implementations.  For at least some, if not all
implementations, NFSv4's domainname slots are handled in an IDN-unaware
fashion right now.  But that's not entirely dispositive: we could
consider a) the cost and likelihood of fixing the deployed base, and b)
interoperability options when "legacy" deployments exist, and we could
conclude that we'd rather have these slots be declared IDN-aware in
spite of their current treatment.  (We're still working this out in the
NFSv4 WG; we've not made any decisions yet.)

> I have initiated the workon at idna2010.org mailing list to discuss that
> "MUST"s and their relations with IDNA2008 "IS/ARE"s, and we reserved

Your claims regarding IDNA2008 and lack of normative language in it are
clearly incorrect.  Your invitation to join yet-another mailing list
isn't exactly winning me over.

Nico
--