SASLprep200x

[John C Klensin]

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