[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] stringprep comment 2
----- Original Message -----
From: "Adam M. Costello"
Sent: Wednesday, January 30, 2002 1:09 PM
Subject: Re: [idn] stringprep comment 2
> Soobok Lee wrote:
> > 6. Unassigned Code Points in Stringprep Profiles
> > This section describes two different types of strings in typical
> > protocols where internationalized strings are used: "stored strings"
> > and "queries".
> > Is this classification from over-simplifications ? only two types? Is
> > there any 3rd type possible?
> I think what this section really depends on is that whenever two strings
> are compared, at least one of the strings must have been prepared using
> strict stringprep (no unassigned code points allowed), while the other
> may have been prepared using loose stringprep (unassigned code points
> allowed). This allows false negatives (where the strings don't match
> even though you wish they did), but prevents false positives (where the
> strings match even though they shouldn't).
> Applications and protocols need to do whatever is necessary to guarantee
> that whenever two strings are compared, at least one was prepared using
> strict stringprep. Typically they would satisfy that requirement by
> classifying strings into "stored strings" and "query strings", using
> strict stringprep on the stored strings, and never comparing two query
> strings. But it's up to each application/protocol to define that
> classification for its own strings.
> Perhaps the document should say something like that.
In many cases, label strings are imported or transmitted from other applicationss,
not generated by the application itself. that makes it difficult to classify them.
For example, let's think about IRC servers using email addresses as nicknames.
One IRC participator announces him as user@A.com using old iDNA-aware IRC client,
and his partner invites him as 'user@B.com' using new client,
while A == B modulo new stringprep ,but A != B modulo old stringprep.
The similar situations come with other applications using email addresses as
such session/user identifiers, which are not necessariliy permanent identifiers.
In such cases, comparing two "query strings" are inevitable and make troubles.
In composing email messages, senders' email addresses are "stored strings" or "queries"??
the recipients addresses can be classified as the same or not ?
the email addresses in the addressbook?
It seems very subtle question.