Peter Saint-Andre - &yet <peter(_at_)andyet(_dot_)net> writes:
SASLprep and the several profiles defined by this document give
different outputs for some inputs. This new protocol can also give
different outputs depending on which Unicode version the implementation
uses.
Do you think that more text is needed on those points?
I don't think text will help. I believe this design property will lead
to slow migration and frustration from implementers. Compare the state
of IDNA2008. So, I don't see how more text would make a difference.
Combined, these
aspects may lead to interoperability and security issues if migration is
not coordinated among protocols and implementations.
I am not sure if migration needs to be coordinated across protocols
(e.g., does XMPP need to be in sync with STUN?).
Agreed. I didn't intend that and agree my wording could be interpreted
the wrong way. I meant coordination among implementation of a
particular protocol. It would be bad if, for two implementations of one
protocol, for one of the implementations to migrate from SASLprep to
SASLprepbis on its own.
I do think that some rough coordination across implementations of a
given protocol is desirable, and those implementation communities
would do well to pursue such coordination through the normal standards
processes. See below.
Agreed.
Essentially, what does it mean for this document to obsolete RFC 4013
for an implementation implements a protocol that normatively reference
RFC 4013? When are implementations supposed to be updated to use this
document? Now, or when the respective RFC is updated to point towards
this new document?
The latter.
Good! I wasn't confident in this interpretation.
Here is further proposed text:
This document does not modify the handling of internationalized
strings in usernames and passwords as prescribed by existing
application protocols that use SASLprep. If the community that uses
such an application protocol wishes to modernize its handling of
internationalized strings to use PRECIS instead of stringprep, it
needs to explicitly update the existing application protocol
definition (one example is [I-D.ietf-xmpp-6122bis], which obsoletes
[RFC6122]). Non-coordinated updates to protocol implementations are
discouraged because they can have a negative impact on
interoperability and security.
Does that address your concern?
Awesome, thank you!
/Simon
signature.asc
Description: PGP signature