Re: [idn] nameprep vs. stringprep

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

Erik Nordmark wrote:

> But there is one high-level comment which might seem like a significant
> change but in fact should be just a case of moving text around. This
> has to do with the split between what goes in the nameprep vs.
> stringprep document. Currently the code point tables are in nameprep.
> This means that when non-IDN WG protocols want to define a stringprep
> profile they are likely to end up copying most of those tables (e.g.
> the large tables with casefold+NFKC). Thus we will avoid a lot of
> redundant tables in RFCs if those tables are placed in the stringprep
> document instead of in nameprep.

I've been waiting for the changes before releasing the IDN-DM-01 draft.

I'll have to wait to see what the impact of this change is, but on the
surface, the immediate affect will be that this draft will no longer be
able to encourage the creation of stringprep profiles for specific
resource record owner names and RR data. Until now, domain names which
require syntaxes that were not compatible with nameprep could create their
own stringprep profiles, but if the prohibitions go into stringprep, then
these domain names will have to be defined separately from the stringprep
family altogether. At that point, I'm not sure what value stringprep has
over just going back to a monolithic nameprep.

Examples of these domain names are NetBIOS names and IPX SAP entries, both
of which can contain things like spaces and punctuation, and which are
legal in the STD13 namespace. Kerberos realms are normally uppercased, so
an i18n equivalent of those may have needed a separate stringprep profile
as well. As stated above, it will not be possible to define exceptions as
stringprep profiles if stringprep prohibits it, and at that point why not
just go back to a monolithic nameprep.

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