Peter Saint-Andre - &yet <peter@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature