Subject: RE: [idn] stringprep comment 1

From: Yves Arrouye <[email-masked]>
Date: Thu, 31 Jan 2002 22:51:31 -0800

> 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

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 1 Feb 2002 08:19:25 -0800

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.

Mark
—————

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

http://www.macchiato.com

----- Original Message -----
From: "Yves Arrouye" <[email-masked]>
To: "'Michel Suignard'" <[email-masked]>; "Paul Hoffman / IMC"
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 31, 2002 22:51
Subject: RE: [idn] stringprep comment 1

---

From: "Soobok Lee" <[email-masked]>
Date: Sat, 2 Feb 2002 02:07:47 +0900

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

> the server. Everything works. It even works if client B re-namepreps

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

> From: "Yves Arrouye"
> To: "'Michel Suignard'" ; "Paul Hoffman / IMC"
>
> Cc:

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 1 Feb 2002 09:02:38 -0800

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

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 1 Feb 2002 14:55:56 -0800

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

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

Soobok Lee

---

From: "Soobok Lee" <[email-masked]>
Date: Sat, 2 Feb 2002 09:21:25 +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

Soobok Lee

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 1 Feb 2002 16:40:10 -0800

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

http://www.macchiato.com

  ----- Original Message -----
  From: Soobok Lee
  To: Mark Davis ; [email-masked]
  Sent: Friday, February 01, 2002 16:21
  Subject: Re: [idn] stringprep comment 1

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

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

    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

Soobok Lee

---

From: "Adam M. Costello" <[email-masked]>
Date: Sat, 2 Feb 2002 07:19:45 +0000

Mark Davis <[email-masked]> wrote:

> When stringprep is used correctly, loose vs loose comparisons alone
> will never happen.

At the very least, we need to spell that out in the stringprep spec.  We
need to say that the ultimate purpose of the guidelines about "stored
strings" and "query strings" is to make sure that two loosely prepared
strings are never compared.  That will at least give people a better
chance of figuring out when they can safely use loose stringprep.

I also suggest adding an explicit requirement that applications must
use strict stringprep whenever there is doubt.  They may use loose
stringprep only when they know that the string will not be compared with
another loosely prepared string (for example, when they are putting
the string into a protocol slot that is used only for comparisons with
strictly prepared strings; DNS queries qualify if we add a requirement
to IDNA prohibiting DNS servers from serving loosely-prepared names).

I think that's the least we should do.  We could go even further and
always prohibit unassigned code points.  That would occasionally
inconvenience people (who would have to upgrade their software), but
would be a lot simpler and would avoid confusing people when new
characters silently fail to match.

AMC