SASLprep200x

Paul Hoffman phoffman at imc.org
Fri Jan 5 21:52:23 CET 2007


At 2:36 PM -0500 1/5/07, John C Klensin wrote:
>Now I am suitably confused.
>
>The abstract of Stringprep (RFC3454) says:
>
>#  This document describes a framework for preparing Unicode
>#  text strings in order to increase the likelihood that string
>#  input and string comparison work in ways that make sense for
>#  typical users throughout the world.  The stringprep protocol
>#  is useful for protocol identifier values, company and
>#  personal names, internationalized domain names, and other
>#  text strings.
>
>#  This document does not specify how protocols should prepare
>#  text strings.  Protocols must create profiles of stringprep in
>#  order to fully specify the processing options.
>
>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.

>To the extent to which we propose to change Stringprep,

I thought we were creating StringPrepBis, not changing the current 
StringPrep. That is a huge difference because...

>I
>think it is incumbent upon us to not make changes that adversely
>and unintentionally impact other Stringprep-user protocols, at
>least without being confident that someone is worrying about the
>issues. I don't believe we can retroactively say "the text
>quoted above it irrelevant -- Stringprep belongs to IDNA and, if
>anything else decides to use it, good for them... but at their
>risk".

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.

>"We" --and perhaps it is the vagueness of that reference that is
>causing some of the problem-- do not need to do that work as
>part of the IDNAbis effort, but we must, IMO, take some
>responsibility for being sure that _someone_ does it.  If it is
>not done, then a revision to Stringprep will certainly not
>survive IETF Last Call... and should not do so.

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

>The "end result" I was referring to above as needing to reflect
>the needs of several protocols and uses was such a hypothetical
>revision of Stringprep.   I do not see any need --or
>desirability-- to change what is permitted in IDNA one bit to
>accommodate the perceived needs of other protocols (and thought
>I had been saying that).

We agree with that endpoint, but we disagree on how to get there.

>But, ultimately, we have three options:
>
>	(1) We cut Nameprep loose from Stringprep and make it a
>	stand-alone specification rather than a profile.
>
>	(2) We develop a new Nameprep profile that relies on the
>	current Stringprep.  I don't see any way to do that
>	which does not result in a set of rules more convoluted
>	(to use your description) than I can imagine being
>	implementable.
>
>	(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.


More information about the Idna-update mailing list