Re: [idn] One profile for domain names, or many?

["Eric A. Hall" <ehall@ehsco.com>]

on 6/13/2002 6:54 PM Adam M. Costello wrote:

> It would be great to have that fixed, but when will it happen?

WILL it happen is the question since it would have to be done by DNSEXT.
Between John, Erik and myself I think a compelling argument can be made
for it. Other WGs need this too (the CRISP WG needs BNF for the RRs so
that ASN.1 syntaxes can be defined so that WHOIS-like information can be
specified for storage in LDAP, for example).

> Can IDNA afford to wait for it?  If not, should IDNA go ahead and limit
> the applicability of Nameprep to the still-vague concepts of "host name
> label" and "mail domain name label" in the hopes that those terms will
> become rigorous?

I don't know how to answer that. It would seem that a standalone codec
doesn't need to specify anything other than the inputs and outputs, and
without imposing on other standards and WGs. I would also think that
nameprep can say that it provides one method for mapping UCS character
sequences into strings which are usable as LDH labels (and vice-versa)
without imposing on other standards and WGs. Otherwise I'll leave this to
people who are more knowledgable in these matters. I'll say no more on
this subject.

> We bundle Stringprep and Punycode and the prefix into a single operation
> for convenience of description, so we can say something simple like
> "for any text label X, ToASCII(X) is an equivalent ASCII label".  We
> needed ToASCII and ToUnicode to serve as definitions of the correct
> results for *any* input, not just already-prepared input.  If you have
> already-prepared input, you can optimize the Stringprep step down to
> nothing.
> 
> IDNA never says that ToASCII needs to be performed all at once by a
> single entity.  For example, an IDN-aware interface can require its
> non-ASCII input to be already prepared, in which case when it performs
> ToASCII the Stringprep step has no effect and can be optimized away.
> The thing calling the interface then has the burden of performing
> Stringprep, but not the rest of ToASCII.  In this scenario the work of
> ToASCII has effectively been split across two entities.
> 

How about mixing the two models? You can pass a stringprep profile to
ToASCII as a parameter, but an empty parameter value (or some other flag)
means that the string has already been prepared and that steps(N) are to
be skipped. Would that work?

>>The resolver doesn't have to keep track of this
> 
> Sure it does.  If I pass an 8-bit label to a new-resolver, the resolver
> needs to know whether the 80..FF values are UTF-8 text or opaque bytes

Clarification, the resolver doesn't "need" a flag because it already has
access to a flag. On the application side, this would be the Wide API
versus the legacy API, while on the wire side this would be the STD13
versus EDNS label formats. In either case, if the legacy API/label is used
and the label does not contain zz-- then it is not ACE and it certainly
isn't UTF-8.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/