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