Re: [idn] I-D ACTION:draft-ietf-idn-idna-10.txt

[Erik Nordmark <Erik.Nordmark@sun.com>]

>  |  2. Perform the steps specified in [NAMEPREP] and fail if there is
>  |     an error. The AllowUnassigned flag is used in [NAMEPREP].
> 
> "allowunassigned" does not appear in draft-ietf-idn-nameprep-11.txt

Searching for "unassigned" in nameprep-11 results in:
	7. Unassigned Code Points in Internationalized Domain Names

	If the processing in [IDNA] specifies that a list of unassigned code
	npoints be used, the system uses table A.1 from [STRINGPREP] as its list
	of unassigned code points.

What is the problem?

> Is this the intended mechanism for allowing alternative profiles to be
> encoded in IDNA? I see that section 1.1 says that nameprep is mandatory:
> 
>  | IDNA requires that implementations process input strings with
>  | Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP],
>  | and then with Punycode [PUNYCODE]. Implementations of IDNA MUST
>  | fully implement Nameprep and Punycode; neither Nameprep nor Punycode
>  | are optional.
> 
> Collectively this means that nameprep is still the gatekeeper, and that
> profiles other than nameprep cannot be encoded with IDNA.

When there are additional profiles for domain names, it might 
makes sense to have a standards track RFC that either updates the IDNA RFC
to say when the new profile can be used, or (depending on how different
things would be for the new usage) it might make sense to
have a standards track RFC which uses "newprep" plus punycode.
But such a future doesn't mean that IDNA can bypass the requirement that
nameprep applies today - removing that requirement might lead folks to believe
they can do non-standard prep and still be compliant with IDNA. That would lead
to non-interoperability as far as I can tell.

  Erik