[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] stringprep comment 1
----- Original Message -----
From: "Paul Hoffman / IMC"
To: "Yves Arrouye" ;
Sent: Saturday, February 02, 2002 7:35 AM
Subject: RE: [idn] stringprep comment 1
> At 2:26 PM -0800 2/1/02, Yves Arrouye wrote:
> > > 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 :)
> 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.
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
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.
> --Paul Hoffman, Director
> --Internet Mail Consortium