SASLprep200x

[Paul Hoffman]

At 4:41 PM -0500 1/5/07, John C Klensin wrote:
>  > 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.

That works for me; hopefully it works for Simon as well.

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

We do not need to say "not our problem" if we say StringPrepBis does 
not obsolete or update StringPrep. They are unrelated.

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

Those can be tamed with enough force. :-) Seriously, StringPrep is 
not a protocol in any sense of the word: it is a set of rules that 
people can subset or expand. We can / should make a different set of 
rules.

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

I see it slightly differently. I think we can make StringPrepBis and 
NamePrepBis where the latter is a very simple profile of the former; 
just like for the 2003 versions. The difference between what Simon 
asked for (and others will surely ask for) and what I want is that we 
don't spend much time trying to make them happy. If there are some 
easy things that need a profile, we do them; if there are not, then 
we revisit the single-document idea. Remember, we vacillated on this 
the first time around as well.

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

I am not active in any of the groups that also did StringPrep 
profiles, so I don't know how happy or unhappy they are, particularly 
with the lock-in to 3.2. If they are not unhappy, or only become 
unhappy when prompted to be, then the decoupling should not cause 
anyone sleep loss.