Subject: RE: [idn] stringprep comment 1

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

> Client A sends out a character that will never match something that
> could be stored in a name server under -07 (because it is unassigned)
> or under -08 or later (because it is mapped to nothing). Why would
> you expect the server to ever match it? What is the problem here that
> you see and that I don't?

No I don't expect the server to match it, since it is deleted. All I am
saying is that the assumption that has been stated here many times that "an
application that uses a former version of Nameprep to speak to a server
using a later one has nothing to worry about because it just passes all
unassigned codepoints (from its former Nameprep perspective) to the server"
is not true. If that assumption is old / has been revised then I am just
wasting your bandwidth :)

YA

---

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

>wasting your bandwidth :)

I think so. :-) "Nothing to worry about" means "the server won't 
falsely give a positive result when it should have been negative". 
You should worry if the protocol had a state where the client was 
asking for something that would never exist but the server could 
mistakenly give a positive answer.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: "Soobok Lee" <[email-masked]>
Date: Sat, 2 Feb 2002 10:06:22 +0900

----- Original Message -----
From: "Paul Hoffman / IMC"
To: "Yves Arrouye" ;
Sent: Saturday, February 02, 2002 7:35 AM
Subject: RE: [idn] stringprep comment 1

> mistakenly give a positive answer.

There are many applications that don't give back immediate negative
answers to end users , regarded as implicitly positive answer.
The end users may believe their transactions
were successful and leave their PC and go vacation! :-)

My half-baked suggestion :

2rd type: queries that *is* compared against stored strings
immediately.

3rd type: queries that is *not* compared against stored strings
immediately and may or may not give answers.

4th type: queries that are postentially going to be compared
with at least another query on applications servers which do not
refer to the authoritative IDN data for comparisons.

But this distinction may not clear to implementors, since
those types may overlap to one another.
Queries that have 3rd and 4th types require strong nameprep.

Soobok Lee

---

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

>were successful and leave their PC and go vacation! :-)

So, how is this different than today's DNS?

You keep bringing up vague comparisons with no concrete examples. It 
sounds like you really believe what you are saying, but the rest of 
us cannot figure out if what you are saying has any merit to it 
unless you get much more specific.

--Paul Hoffman, Director

---

From: "Soobok Lee" <[email-masked]>
Date: Tue, 5 Feb 2002 06:36:58 +0900

----- Original Message ----- 
From: "Paul Hoffman / IMC" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, February 02, 2002 12:06 PM
Subject: Re: [idn] stringprep comment 1

> unless you get much more specific.

You may have missed my specific examples listed in my previous postings.
Still, i think the categorization of applications IDN behaviours into 2 types is 
from oversimplification.

Many applications defer its validation of native IDN labels against
authoritative stored strings  toward later time, and make later failures
silently and that gives no immediate feedback to users.

Think about uppercased new-script IDN email addresses submitted for job applications forms.
What if job applications server is using old nameprep and defer its ACE encoding until
the employer will try to reply them with acceptance notices after finishing reviews, 
while the applicants are using new nameprep and confident in the success of their uppercased native
labels, waiting for never-coming acceptance emails from the employer.

Soobok Lee