SASLprep200x

Fri Jan 5 23:10:10 CET 2007

Simplicity is highly desirable. Single choices rather than options have
served the Internet well. However, in my naïve way, I am coming to believe
that the UNICODE system, developed for expressive purposes not associated
with: IDNs, passwords, other applications, is not structured in such a way
as to support the elusive GUTICH particle John referenced below. On that
assumption, I would suggest that we may as well assign STRINGPREPbis the
role of IDNAPREP alone, be up front about this, and proceed. I come to this
conclusion with some reluctance but would much rather have an IDNAPREP that
is UNICODE version insensitive than to have a STRINGPREP that still requires
various profiles to work in various contexts. Confusion over which profile
is appropriate for which application could become a serious interoperability
hurdle. A fixed IDNAPREP might serve the IDN application better.

Vint

Vinton G Cerf
Chief Internet Evangelist
Google
Regus Suite 384
13800 Coppermine Road
Herndon, VA 20171

+1 703 234-1823
+1 703-234-5822 (f)

vint at google.com
www.google.com

-----Original Message-----
From: idna-update-bounces at alvestrand.no
[mailto:idna-update-bounces at alvestrand.no] On Behalf Of John C Klensin
Sent: Friday, January 05, 2007 4:41 PM
To: Paul Hoffman; idna-update at alvestrand.no
Subject: RE: SASLprep200x

--On Friday, 05 January, 2007 12:52 -0800 Paul Hoffman <phoffman at imc.org>
wrote:

> At 2:36 PM -0500 1/5/07, John C Klensin wrote:
>> Now I am suitably confused.
>...

>> I infer from this that Stringprep is intended to serve several 
>> protocols, not just IDNA.
> 
> ...as long as they want to do things the way we do them and don't want 
> to do it yourself. That is, everyone who saw how hard it was for the 
> IDN WG to get consensus on the character choice part could pick 
> StringPrep instead of "do it yourself".
> That worked for some, and probably worked against others.
> 
>> I cannot read the text in any other way.
> 
> Sure you can: you can read it as less-than-fully-honest advertising. 
> It was the position we were put in by everyone who didn't want to do 
> the hard work themselves.

Ok.  If one is willing to accept that, then things get a lot easier.  I've
received some proactive feedback from an AD or two that we should not assume
a "make a new one and leave the old one behind" strategy, but we can cross
that bridge when we get to it.

>...
> Agree about not changing StringPrep. Disagree that our output  *of 
>this work* needs to be useful to anyone other than us and  the people 
>who use domain names.

Ok.  I think we agree about that too, actually.  I do not have any
expectation that our work needs to be useful to anyone but the two groups
listed above.  I have been assuming that we needed to avoid fouling the
others up, or making version-migration unnecessarily hard, but maybe that
assumption is wrong.  See below.

>...
> Why not? (Serious question.) As long as we don't break any  existing 
>uses of the current StringPrep, why should it matter  if the SASL folks 
>aren't affected? Of course, they can look at  our deltas and decide 
>which would be useful to them (such as  starting from 5.0 instead of 
>3.2), and which would not  (restricting a lot more characters).

Hmm...   One answer is that StringPrep200X is either an
independent piece of protocol for IDNA use only (see below) or it presumably
needs to "obsolete" or at least "update"
StringPrep2003.  As soon as "we" do either of those things, then other
protocols that use StringPrep2003 are in trouble and need
to make some adjustments, at least formally.   One could
reasonably say "not our problem", but...

>> But, ultimately, we have three options:
>> 
>>	(1) We cut Nameprep loose from Stringprep and make it a
>>	stand-alone specification rather than a profile.
>...
>>	(3) We change Stringprep.  We might do that by adding
>>	one or more new tables and have Nameprep reference them,
>>	leaving everything else unaffected.  Or we might make
>>	other changes, in which case we need to be aware --or be
>>	sure that someone is aware and deals with-- their
>>	implications to anything else that references
>>	Stringprep.  As one variation on this, we move IDNA to
>>	some hypothetical and drastically different
>>	Stringprep200X but leave SASL and other Stringprep users
>>	at Stringprep2003 for as long as it takes, essentially
>>	forking the specification.  I don't think that would be
>>	an especially good outcome for the community --it would
>>	certainly violate the multi-protocol principle that
>>	motivated Stringprep and the above quoted text-- but it
>>	is a plausible outcome.
> 
> (4) We create StringPrepBis and a NamePrepBis profile of it.
> This seems the easiest and cleanest way of doing things.

No, actually not, and maybe this is where we are getting hung
up.   If StringPrepBis is intended to serve IDNA only, and we
are willing to be explicit about that rather than engaging in
"less-than-fully-honest advertising", then my instincts as a hater of
profiling in protocols take over.  Less abstractly, if StringPrepBis is to
be designed _only_ to deal with IDNA, then constructing it and then
constructing a profile for how to use it is a waste of time and a source of
unnecessary complexity: we should simply produce an "IDNAprep" that is
self-contained and that has no pretense of serving anything but IDNA,
obsolete
NamePrep2003 (since this has always been about label strings and not about
names, as you indirectly pointed out earlier), and
ignore StringPrep2003 entirely.    Note that, except for
terminology, this is no different from the "cut Nameprep loose"
model of (1) above.

As an aside, it is possible that one of the things we have learned in the
last several years --and of which this work and the Unicode "identifier" and
"confusables" work are symptoms-- is that the assumption/dream that underlay
StringPrep2003 was just wrong.  That assumption was that, advertising aside,
it was possible to construct a single protocol specification that would
support, modulo profiling, all contexts in which non-ASCII characters were
to be used on the network. Maybe we have found out that, just as UTC
discovered that each of NFC, NFKC, NFD, and NFKD (and their "stable"
variants and maybe some others) have roles to play in difficult
circumstances, there is no "grand unified theory of international character
handing"
(GUTICH) which can be captured in something like Stringprep.
If that were to be our conclusion, then the IETF ought to be decoupling
everything, if not from Stringprep, than at least from the assumption that
Stringprep, or even StringPrepBis, is the solution to any broad range of
problems.  That would be too bad in some respects but I, for one, wouldn't
lose a lot of sleep over it.

     john

_______________________________________________
Idna-update mailing list
Idna-update at alvestrand.no
http://www.alvestrand.no/mailman/listinfo/idna-update