Re: CONSENSUS CALL: draft-zeilenga-sasl-rfc2222bis as WG item

[Simon Josefsson <[e-mail]>]

Tom Yu <[e-mail]> writes:

> If you support the working group adopting
> draft-zeilenga-sasl-rfc2222bis as a replacement to
> draft-ietf-sasl-rfc2222bis, please reply indicating this support.

I read these two documents side by side today, and I didn't find any
major problems with Kurt's rewrite.  Actually, I found Kurt's version
more precise and generally easier to read.  Good work!

> If you have other comments, please send them as well.

I note that there is almost no SASLprep discussion in the new
document.

SASLprep is only mentioned once, and only in the context of
mechanisms:

  For simple user names and/or passwords in authentication credentials,
  SASLprep [RFC4013] (a profile of the StringPrep [RFC3454] preparation
  algorithm), SHOULD be specified as the preparation algorithm.

Removing SASLprep discussions from the core document may be a good
thing.  Doing so will force the SASLprep discussions down into the
mechanism specification (for authid) and the protocol profile
specification (for authzid), where it may be easier to specify the
details.

On the other hand, removing SASLprep guidance from the core document
may lead to poorer SASLprep discussions in mechanism/profile
documents.  That is because the SASLprep discussion would have to be
duplicated and re-thought for each mechanism/profile.  At worst,
without proper co-ordination, some decisions made in one mechanism (or
profile) could become in conflict with decisions made in some profile
(or mechanism).

Generally, it seems that with this new document, authors of
mechanism/profile documents will have little guidance on how to use
SASLprep correctly within the SASL framework.

Finally, if the intention was to remove SASLprep discussions from the
core document, I think SASLprep could be removed completely.  I.e.,
rewrite the SHOULD paragraph, turning it into a suggestion, and make
SASLprep an informational reference.  That would make it possible to
make mechanisms use a future SASLprep2 without having to revise the
core document.

Regards,
Simon