SASLprep200x

[Paul Hoffman]

At 7:05 PM -0500 1/4/07, John C Klensin wrote:
>While I agree, I really don't see a problem here and, to the
>extent to which there is an issue, I think Simon has identified
>the way out.  At the moment, we have a base list of rules from
>which to select in Stringprep.  One of our goals, IMO a
>necessary one, is to make Stringprep as nearly as possible
>Unicode-version-agnostic.  But doing that doesn't have any
>inherent impact on either IDNA or SASL or even on what
>Stringprep does and does not permit (at least within the Unicode
>3.2 context and conceptually more generally).

Strongly disagree. What Simon is asking for (as few character 
prohibitions as possible to aid SASLprep) is inherently against the 
basis of the -bis effort, which is to start with a more limited 
defensible set. If StringprepBis has a significantly larger set of 
characters than NamePrepBis, NamePrepBis will become a convoluted set 
of subsetting rules. That does not serve the DNS community in the 
least.

>  >From my point of view, both Paul and Simon are correct, even
>though they seem to be disagreeing with each other.  We should
>have, if at all possible, a common character-interpretation
>framework that applies to both (and, ideally, to more general
>use of Unicode strings, as represented in the still-on-hold
>Net-Unicode draft).

I certainly disagree with "if at all possible". Just because it is 
possible does not mean that the outcome would be worthwhile for the 
DNS community.

So far, no one has shown that the greater character restrictions we 
want to bring to IDNs would have any appreciable effect on passwords 
under SASLprep. Instead of us breaking our backs for them, I propose 
that we move forward with our current thinking and, if the SASL 
community feels too restricted by our output, they can make a very 
simple fork of SASLprep that says "for passwords, what they said, 
plus the following characters".