Subject: Re: [idn] nameprep vs. stringprep

From: Erik Nordmark <[email-masked]>
Date: Thu, 2 May 2002 09:13:37 +0200 (CEST)

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

Eric,

The above is not the intent.

The intent is that stringprep define a bunch of tables and the stringprep
profile then selects which table(s) of prohibited characters and mappings
it want to use from stringprep. And if need be a stringprep profile can
also add its own prohibitions and mappings although.

Hence we get easier reuse of the tables of code points - nothing more
and nothing less.

  Erik

---

From: "Edmon Chung" <[email-masked]>
Date: Thu, 2 May 2002 07:27:59 -0400

----- Original Message -----
From: "Erik Nordmark" <[email-masked]>
> Hence we get easier reuse of the tables of code points - nothing more

So you mean Stringprep will actually contain all the tables and then
Nameprep would be a profile that chooses which table to use?  So
essentially, stringprep will be sort of like a general framework plus a
mapping table repository.  I think this makes sense.

If this is so, why dont we also put in the mapping tables created by the CJK
communities respectively on their particular issues (including jpchar
hangulchar and tsconv) into the Stringprep respository?  Nameprep will not
need to choose these tables, while people can get the information from those
valuable discussions at a common place and decide whether to implement it
themselves.

Thoughts?

Edmon

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 2 May 2002 15:53:16 +0200 (CEST)

> valuable discussions at a common place and decide whether to implement it

The tables currently in stringprep are only those that are going 
be used by an IETF standard. Thus as more IETF standards do I18N
and need more stringprep profiles, stringprep might need additional
tables.

But adding tables to stringprep before there is an intended use for them
seems problematic - the IETF would have no criteria for what tables would
or would not go into stringprep.

   Erik

---

From: "Edmon Chung" <[email-masked]>
Date: Thu, 2 May 2002 11:07:59 -0400

Agreed... but not convinced that the CJK tables do not have an "intended"
use.  At least the T/SC table is already actively being used by a couple of
domain operators.

Edmon

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 02 May 2002 10:21:54 -0500

> also add its own prohibitions and mappings although.

Thanks for the clarification

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

---

From: "Doug Ewell" <[email-masked]>
Date: Thu, 2 May 2002 08:41:16 -0700

> use.  At least the T/SC table is already actively being used by a
couple of

Ah, see, I knew that was the intent all along.  This is another attempt
to force IDN to perform 1-to-1 TC/SC mapping by having IETF "publish"
the proposed table in the stringprep document and then insisting that
IDN implement the conversions specified in the "official" table.

TC/SC equivalence is not 1-to-1.  Implementations that pretend that it
is will confuse and mislead Chinese speakers who expect true,
context-based equivalence.  Domain operators who implement 1-to-1 TC/SC
mapping tables are out of conformance with the IDN proposal.

-Doug Ewell
 Fullerton, California

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 2 May 2002 09:51:29 -0700

And, as folks can see on the list, the drafts with the tables moved 
have been published.

As far as we know, there is literally no change for the IDN WG with 
these new drafts from the previous ones. The exact same characters 
are mapped and prohibited. If we made a mistake in this, by all means 
let us know.

The only significant change that will affect other WGs that use 
stringprep is that only Unicode normalization form KC is specified. 
Our thinking is that if we specified both NFC and NFKC, we would need 
many more tables and there is a much higher chance of error. No one 
has given a strong argument for using NFC, other than objections to 
some of the mappings in NFKC, which cannot be changed by the Unicode 
Consortium without breaking a lot of deployed software. If other 
working groups want us to allow NFC and create and check the 
additional tables, we will probably hear about it during IETF last 
call.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Edmon Chung" <[email-masked]>
Date: Thu, 2 May 2002 22:18:40 -0400

I dont think this is an intent to "force" TC/SC mapping, I just think that
it would be a good repository for work done that is meaningful for the
community.
Edmon

----- Original Message -----
From: "Doug Ewell" <[email-masked]>
To: "Edmon Chung" <[email-masked]>; "Erik Nordmark"
<[email-masked]>
Cc: "Eric A. Hall" <[email-masked]>; <[email-masked]>
Sent: Thursday, May 02, 2002 11:41 AM
Subject: Re: [idn] nameprep vs. stringprep