Subject: [idn] nameprep vs. stringprep

From: Erik Nordmark <[email-masked]>
Date: Mon, 29 Apr 2002 16:45:58 +0200 (CEST)

Folks,

Finally the AD has completed the review of the 4 documents.
There are some comments from this review that I will send to
the mailing list shortly (I have to finish typing them up).

Once these comments (mostly editorial clarifications) are resolved
one way or another I think we will be ready for the IETF-wide last call.

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.
Then such profiles could just reference those tables.
This should not have any impact on the IDN solution/protocol.
(But I have't personally verified that it is just a movement of text between
the drafts.)

So Paul will submit updated nameprep and stringprep documents to the I-D
directory so that you all can verify that this didn't change anything.

  Erik

---

From: "Eric A. Hall" <[email-masked]>
Date: Tue, 30 Apr 2002 12:20:36 -0500

Erik Nordmark wrote:

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

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 30 Apr 2002 22:56:20 +0200

--On 2002-04-30 12.20 -0500 "Eric A. Hall" <[email-masked]> wrote:

> Kerberos realms are normally uppercased, so
> as well.

The change is to make sure that a profile choose whether it should produce
case sensitive or not case sensitive matchings. Not how the case folding is
happening. I.e. I (as area director this time) can say that IESG have been
nervous if it was possible for different profiles to create different case
folding algorithms. It is enough for a profile to say whether case folding
was to happen or not.

Regarding Kerberos, it is interesting you bring it up.

Kerberos realms are case sensitive, but mostly only uppercase letters are
used. When trying to locate the kerberos server for a realm, the name of
the realm was used together with SRV records (or some other similar
algorithms).

This means that the current specification of kerberos says we can have two
realms which are "foo" and "FOO", but the algorithm used to find the server
in DNS can not handle it.

This is on its way to be resolved thanks to the creation of a profile of
stringprep, and one question we got in IESG from the kerberos people was
why they have to create the table to use when talking about case folding.

   paf