Subject: [sasl] [Fwd: Re: Brainstorming SASLPrep/StringPrep update/replacement requirements]

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Nov 2009 22:18:41 +0900

In order to help drive the StringPrep/SASLPrep discussion tomorrow, I am 
forwarding some requirements/thoughts from Nico and Joe.

Subject: Re: Brainstorming SASLPrep/StringPrep update/replacement requirements
From: Joe Hildebrand <[email-masked]>
To: Nicolas Williams <[email-masked]>, Alexey Melnikov <[email-masked]>
Cc: Peter Saint-Andre <[email-masked]>, John C Klensin <[email-masked]>, Pete Resnick <[email-masked]>, Tom Yu <[email-masked]>, "Kurt D. Zeilenga" <[email-masked]>, Simon Josefsson <[email-masked]>, Chris Newman <[email-masked]>
Date: Fri, 30 Oct 2009 17:36:04 -0600

Adding a couple more:

- Where implementers have already implemented NFKC, moving to NFC or NFD is
not a win (for the developer).  The win for users would have to be somewhat
compelling to get them to implement another NF.

- Unicode version independence is a goal.  Failing that, a mechanism to
update to new Unicode versions with a relatively small amount of standards
and implementation work would be nice.  Failing that, we need to at least
level up to the current version from 3.2.

On 10/30/09 3:36 PM, "Nicolas Williams" <[email-masked]> wrote:

> Also, please document what are the problems with SASLPrep/StringPrep,
> and what kinds of changes you're looking for.  I see two kinds of
> changes:
> 
>  - backwards compatible ones
>  - new profiles that are to be used...
>     - ...in new contexts (new SASL mechs, existing mechs with new names,
>       ...)
>     - or when negotiated
> 
> I'll start:
> 
>  - query strings should be unnormalized (it's nice, perhaps, if they are
>    normalized, but should that not be required)
> 
>  - comparisons to storage strings should be normalization-insensitive
> 
>  - profiles should specify whether to normalize on object creation, and
>    optionally should specify a NF
> 
>  - obviously, when strings are hashed, they should be normalized first;
>    whether the NF must be specified by the profile depends on what
>    components of the system will access the hashed strings.
> 
>     - in the case of passwords, and any other strings where two peers
>       separately hash the same string and ultimately compare, of course,
>       the NF has to be specified by the profile or must be negotiated
> 
>  - NF negotiation is nice, but, really, expecting implementations to do
>    all of them is annoying
> 
>     - the most basic NF is NFD; therefore we should prefer NFD
>        - sadly most input methods produce NFC by nature, so that
>          requiring NFD typically requires more work than requiring NFC
>          (for implementors that hope their input methods get them
>          through any NFC requirements)
>           - of course, implementors SHOULD NOT/MUST NOT rely on input
>             methods to produce strings in the right NF, so, IMO, NFD
>             should be the preferred NF
> 
> Cheers,
> 
> Nico
> --

-- 
Joe Hildebrand