Subject: RE: [idn] stringprep comment 1

From: Yves Arrouye <[email-masked]>
Date: Fri, 1 Feb 2002 14:10:23 -0800

> At 10:51 PM -0800 1/31/02, Yves Arrouye wrote:
> >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.
> 
> Could you give an example of this? Why would we ever want to add a
> new casefolding rule for a current character? Adding a casefolding
> rule for a *new* character should not make a difference because the
> new character is not yet stored in domain names.

Sure. I'll use the same example I just used and used before.

Server S runs Nameprep-08. It *does* have names that use this new character,
and it has been case folded since Nameprep-08 has a case mapping for it.

Client A has an email client using Nameprep-07. At the same time, this email
client runs on the latest and greatest <your favorite OS here> which has
support for the version of Unicode that is used in Nameprep-08 (and has this
new character in both upper and lower case--I am speaking of the Unicode
version here). Now, this character (the uppercase one) is typed by the user
(since the OS supports it). The email client sees it as being unassigned as
far as its Nameprep-07 tables go, and thus pass it unchanged to the server.
On the server, there is no match, because the registered string was case
folded (since the server uses Nameprep-08).

But since you said that DNS makes no guarantee of case mapping (and I guess
it's fair to say that if IDNA does not make any guarantee, it doesn't matter
what DNS for ASCII did) I guess it's okay. It's just going to be fun when
the user registers his IDN with uppercase but cannot use it from his own
email client :) It's all about user education... (And fortunately, most
people type these things all-lowercase anyway.)

YA

---

From: "Postel Services, Inc" <[email-masked]>
Date: Sat, 2 Feb 2002 09:17:36 +0900

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

From: Mark Davis

To: [email-masked] ; Soobok Lee

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]

http://www.macchiato.com

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

From:
Soobok Lee

To: [email-masked]

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