Re: [idn] stringprep comment 1

["Mark Davis" <mark@macchiato.com>]



As discussed before, comparisons only work if you are matching

 

loose vs strict // where the strict is authoritative

strict vs strict

 

Simple transmission or store and transmission is not an issue, as long as no comparison is made.

 

Mark

—————

 

Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]

 

http://www.macchiato.com

----- Original Message -----

From: Soobok Lee

To: idn@ops.ietf.org

Sent: Friday, February 01, 2002 09:07

Subject: Re: [idn] stringprep comment 1

----- Original Message -----
From: "Mark Davis" 
To: "Yves Arrouye" ; "'Michel Suignard'" ; "Paul Hoffman / IMC" 
Cc: 
Sent: Saturday, February 02, 2002 1:19 AM
Subject: Re: [idn] stringprep comment 1


> Stringprep keeps its own tables. What any implementation of Unicode
> needs to do if they want to maintain strict backwards compatibility
> for case folding is to only *add* to tables in the future, not change
> the values of characters that are already in the tables.
>
> While it is extremely unlikely that Unicode will make a change that
> causes problems for nameprep, using the above strategy guarantees
> backwards compatibility.
>
> To repeat, the loose vs strict approach works as follows:
>
> Suppose the client is Unicode 3.1 and the server is Unicode 4.0. As
> long as the client produces names that are only 3.1, no problem.
> Stringprep on the client will produce results that the server accepts.
>
> Suppose the user has characters that are unassigned in 3.1 (but are in
> 4.0). As long as the user (manually) picks lowercase characters (in
> the right canonical form), those names will be accepted by the 4.0
> server. While it is not as easy as when the software does it for the
> user, it will work for any new characters.
>
> This is important for another scenario. Client A is on Unicode 4.0,
> client B is on Unicode 3.1, and the server is on Unicode 4.0. Client A
> namepreps a string, sends to client B. Client B sends the string on to
> the server. Everything works. It even works if client B re-namepreps
> the string.

Would you clarify your assertion for peer-to-peer transactions ?

Even in some client to server transactions, server sides may have
no persistant/stored strings (not-authoritative)  to compare against the queries, but
just store and trust or transmit without giving back no negative response..

Soobok Lee

>
> Mark
> —————
>
> Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
> [For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]
>
> http://www.macchiato.com
>
> ----- Original Message -----
> From: "Yves Arrouye" 
> To: "'Michel Suignard'" ; "Paul Hoffman / IMC"
> 
> Cc: 
> Sent: Thursday, January 31, 2002 22:51
> Subject: RE: [idn] stringprep comment 1
>
>
> > > Not a chance. Unicode and ISO 10646 collect in fact some unneeded
> crumbs
> > > that way. Once a character is officially approved for inclusion it
> is
> > > there forever, whatever we don't like it or not. Characters get
> > > deprecated (i.e. usage discouraged) but never removed. This is the
> price
> > > you have to pay for stability and usage by other specification
> (like
> > > IDN).
> >
> > Sorry, I did not mean removed from Unicode (I am aware of the rule
> there,
> > which makes sense), I meant one character that is added to Unicode
> but that
> > a given Stringprep profile would think desirable to remove.
> >
> > As for case folding, as soon as one adds a new case mapping in the
> Nameprep
> > profile, one needs to upgrade clients at the same time as servers.
> Oops.
> > Encoding the Nameprep version in queries would solve that, but
> obviously at
> > the cost of some other meaningful info in the label, thus reducing
> the
> > length of IDN names.
> >
> > YA
> >
> >
> >
> >
>