[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] stringprep comment 1


> surely do comparisons on them  later time silently
 
When stringprep is used correctly, loose vs loose comparisons alone will never happen. If loose vs loose comparisons must be used; one needs to also transmit additional information in order to make a valid comparison. Let's restate the obvious:
 
1. Stringprep is appropriate in certain environments.
2. Stringprep is not appropriate in other environments,
 
Simply stating that there could be cases where stringprep may cause problems is just reiterating (2), and adds no useful information to the discussion.
 
Mark
—————
 
Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]
 
http://www.macchiato.com
----- Original Message -----
From: Soobok Lee
Sent: Friday, February 01, 2002 16:21
Subject: Re: [idn] stringprep comment 1

 
----- Original Message -----
From: Mark Davis
Sent: Saturday, February 02, 2002 7:55 AM
Subject: Re: [idn] stringprep comment 1

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.
Some applications  in the end of transmission surely do comparisons on them  later time silently .
The intermediate/final applications may not give back the negative answers to the
originating end users immediately or finally or both. eg) sending emails or enlisting in the online white page.
 
Their failure is as silent as anthrax threat. and
That' like a lost land mine which some civil children  may step on .
The soldiers don't know what  happens until they get report that someone lost  their feet by the lost mine.
 
Soobok Lee
 
 
Mark
—————
 
Πόλλ’ ἠπίστατο ἔργα, κακῶς δ’ ἠπίστατο πάντα — Ὁμήρου Μαργίτῃ
[For transliteration, see http://oss.software.ibm.com/cgi-bin/icu/tr]
 
----- Original Message -----
From: Soobok Lee
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
> >
> >
> >
> >
>