headers
Erik Nordmark | 2 May 09:13
Picon

Re: nameprep vs. stringprep

> 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
Permalink | Reply |
headers
Eric A. Hall | 2 May 17:21

Re: nameprep vs. stringprep


Erik Nordmark wrote:

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

Thanks for the clarification

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
Permalink | Reply |
headers
Paul Hoffman / IMC | 2 May 18:51
Picon

Re: nameprep vs. stringprep

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
Permalink | Reply |
headers
Edmon Chung | 2 May 13:27

Re: nameprep vs. stringprep

----- Original Message -----
From: "Erik Nordmark" <Erik.Nordmark <at> sun.com>
> 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.

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
Permalink | Reply |
headers
Erik Nordmark | 2 May 15:53
Picon

Re: nameprep vs. stringprep

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

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
Permalink | Reply |
headers
Edmon Chung | 2 May 17:07

Re: nameprep vs. stringprep

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

----- Original Message -----
From: "Erik Nordmark" <Erik.Nordmark <at> sun.com>
To: "Edmon Chung" <edmon <at> neteka.com>
> > 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.
>
> 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
(Continue reading)

Permalink | Reply |
headers
Doug Ewell | 2 May 17:41
Picon

Re: nameprep vs. stringprep

Edmon Chung <edmon <at> neteka.com> wrote:

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

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
Permalink | Reply |
headers
Edmon Chung | 3 May 04:18

Re: nameprep vs. stringprep

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" <dewell <at> adelphia.net>
To: "Edmon Chung" <edmon <at> neteka.com>; "Erik Nordmark"
<Erik.Nordmark <at> sun.com>
Cc: "Eric A. Hall" <ehall <at> ehsco.com>; <idn <at> ops.ietf.org>
Sent: Thursday, May 02, 2002 11:41 AM
Subject: Re: [idn] nameprep vs. stringprep

> Edmon Chung <edmon <at> neteka.com> wrote:
>
> > 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.
>
> 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.
(Continue reading)

Permalink | Reply |

Gmane