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

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

on 7/3/2002 3:28 AM Erik Nordmark wrote:
>> |  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

> What is the problem?

Anal types like me see StudlyCapped functions and flags and expect to find
them documented. Other than that, none I suppose.

>> 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, [...]

There are already profiles described for iSCSI names and Kerberos realms.

> 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.

Requiring new codecs for new profiles is all cost and zero benefit. What
possible value is there in forcing applications to define new codecs with
different outputs for their alternative names?

> 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.

Being "compliant" with IDNA is a matter of surviving a trip through
ToASCII and back. As far as I can tell, any standards-track stringprep
profile which uses label sequences can meet this requirement.

> That would lead to non-interoperability as far as I can tell.

If an organization starts using kerberos-prep for zone delegation or
addressing purposes then yes, there would be interoperability problems
with the applications that decode the sequences. In fact there would be so
many problems that one is left to wonder how anybody would willfully do
something that stupid.

On the other hand, requiring new profiles to develop new codecs imposes
its own interoperability problems. EG, all forms of network data are
guaranteed to be opaque to everybody until all of the codecs have been
installed on every machine on the planet. You can't encode/decode Kerberos
names into a local text file until you've got the codec...

This would be a significant negative development towards the notion of
transparency. One codec for all domain name-like profiles of stringprep
should be enough.

I thought we had settled this argument a couple of weeks ago.

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