Subject: RE: [idn] Re: stringprep and unassigned code points

From: Yves Arrouye <[email-masked]>
Date: Thu, 25 Oct 2001 00:01:41 -0700

> > >  4) If we finalize IDN before TAGALOG is added, there is 
> no way to support
> > >   seamlessly support of TAGALOG input in older nameprep 
> applications
> > >   but for users to upgrade their s/w.
> >
> >I would like to rephrase this. Your wording is very drastic.
> >
> 
> [...]
> 
> The way I was understanding things is that the server side where the
> new name is registered has to be upgraded to the new version including
> Tagalog (and this may be done by a new table, or whatever). 
> The client,
> and in particular the stringprep/nameprep/ace part of it, won't need
> any upgrades. Of course, there may be a need for installing a Tagalog
> keyboard driver or other components to input Tagalog, but that's
> a separate problem.

I have the same understanding you do re: when unassigned code points may be
generated (by an application that gets code points from a version of Unicode
that was released after the version of Nameprep it uses). Now let's suppose
Unicode encodes something new, for which a new Nameprep is released (because
some additions to the mapping table are needed). At this point, the DNS
servers may contain the ACE(Nameprep(names in this new thing)). And
applications get these new codepoints, but because they do not have the
appropriate mapping table, they will pass ACE(Old Nameprep(names in this new
thing)) which will sometimes match the new labels, and sometimes not. Am I
right in thinking that applications do not need to be updated only if
Nameprep does not change for the new code points (looks like common sense
anyway)?

YA

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 25 Oct 2001 11:10:58 +0200

--On 01-10-25 00.01 -0700 Yves Arrouye <[email-masked]> wrote:

> I have the same understanding you do re: when unassigned code points may
> be generated (by an application that gets code points from a version of
> Unicode that was released after the version of Nameprep it uses).

I must be extremely bad at expressing myself. This is now the third time
since monday I explain how things work.

> Now
> let's suppose Unicode encodes something new, for which a new Nameprep is
> released (because some additions to the mapping table are needed).

A mapping can only be from an earlier unassigned codepoint.

> At
> this point, the DNS servers may contain the ACE(Nameprep(names in this
> new thing)).

ACE have absolutely nothing to do with this. This is a stringprep issue.

Only nameservers which do understand the new version of stringprep can have
these names.

> And applications get these new codepoints,

What do you mean by "get these new codepoints"?

> but because they
> do not have the appropriate mapping table, they will pass ACE(Old
> Nameprep(names in this new thing))

No, because the codepoint is unassigned in old version of stringsprep, and
because of that MUST NOT be used.

> which will sometimes match the new
> labels, and sometimes not. Am I right in thinking that applications do
> not need to be updated only if Nameprep does not change for the new code
> points (looks like common sense anyway)?

You are wrong.

Summary (once again):

If a new version of Unicode comes out, which have a newly assigned
codepoint (X), and a mapping from X to Y, the following is true:

- X can not be part of the result of a nameprep which an old application
  creates. If an old application get X as input, the codepoint is unassigned
  and therefore illegal.
- If Y is an earlier assigned codepoint, an application understanding the
  new version of nameprep will when getting X map that to Y.
- If Y is a newly assigned codepoint, an application understanding the
  new version of nameprep will when getting X map that to Y.
- In neither case (old application or new application) X will be part of
  the output of the stringprep process.

         paf

---

From: YangWoo Ko <[email-masked]>
Date: Fri, 26 Oct 2001 00:02:12 +0900

Dear Patrik Falstrom,

Thank you for your clear summary. Exeucuse me but would you do the
summary again for the following case ? This is really helpful when
we talk about Traditional Chinese / Simplified Chinese issue.

If a new version of Unicode comese out, which have a newly defined
rule to map codepoint (X) to codepoint (Y), where codepoint (X)
and (Y) was already defined in the previous version of Unicode and
there no rule for mapping or NF?C for either codepoint(X) or
codepoint(Y), the following is true:

...

-- 
/*------------------------------------------------
YangWoo Ko : [email-masked]
We Invent Enterprise Software Solutions
and Make You Secure & Powerful.
------------------------------------------------*/

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 26 Oct 2001 09:45:40 +0200

> codepoint(Y), the following is true:

If you have an alreday assigned codepoint, a mapping will _NOT_ be added in
later versions of Nameprep.

So, what you ask for will never happen.

  paf

>>   creates. If an old application get X as input, the codepoint is
>>   unassigned and therefore illegal.

Patrik Fältström <[email-masked]>                         Cisco Systems
Consulting Engineer                                  Office of the CSO
Phone: (Stockholm) +46-8-6859131            (San Jose) +1-408-525-8509
        PGP: 2DFC AAF6 16F0 F276 7843  2DC1 BC79 51D9 7D25 B8DC