Re: Proposed SASL WG charter description

Kurt Zeilenga <[EMAIL PROTECTED]> writes:

> On Sep 8, 2008, at 4:26 AM, Simon Josefsson wrote:
>
>>
>> Alexey Melnikov <[EMAIL PROTECTED]> writes:
>>
>>> Frank Ellermann wrote:
>>>
>>>> Kurt Zeilenga wrote:
>>>>
>>>>
>>>>> This group will produce a document revising SASLprep [RFC4013]
>>>>> to improve Unicode version agility while maintaining RFC 4013
>>>>> behavior when used with RFC 4013 mandated version of Unicode.
>>>>> The outcome of this work will be a Standards Track RFC replacing
>>>>> RFC 4013.
>>>>>
>>>>>
>>>> Does that allow for "abandon SASLprep in favour of net-UTF8" ?
>>>>
>>>>
>>> A very good question indeed.
>>
>> Given that few have implemented RFC 4013 I'm not sure that backwards
>> compatibility with it has to be an absolute mandate in the SASL WG
>> charter.
>
> My view is that it's not an "absolute mandate".  As I noted in my
> response to Frank's comments, my intent was to keep a narrow focus on
> the work.  I specially don't want to revisit discussions such as
> "Should character X be excluded?".   I want to limit the work to
> replacing stringprep tables with Unicode properties.  SASLprepbis(x)
> == SASLprep(x) for all x (where x is well formed Unicode 3.2 text).

Limiting the work would preclude considering Net-UTF8, as far as I can
tell.

>> Given the PR-29 problem (NFKC output has been altered for some code
>> points in later Unicode versions), perfect backwards compatibility may
>> not be something to strive for anyway.
>
> How about "backwards compatibility for characters used in practice"?
> PR-29 issues were limited to characters which do not occur in practice.

That would work.

>> Even though NFKC was
>> used by StringPrep for domain names, I'm not convinced it is the best
>> choice for passwords.
>
> I note that SASLprep is also used for user names.  Decisions need to
> be made not just based on "best choice for passwords" but "best choice
> for user names and passwords".

One could also use Net-UTF8 for usernames and SASLprep for passwords.

/Simon