On 5/26/11 6:19 AM, Simon Josefsson wrote:
Dear IESG, Is the intention that this document will update RFC 5892 or not? The document does not contain a "Updates:" header but the draft name suggests otherwise to me, hence my question.
The IESG has not yet discussed this topic, and I will be bringing it to their attention. We may decide to include "Updates: RFC 5892"; we may not.
If the document does not update RFC 5892 (or some other document), I support publishing this document because it will not affect my implementation of RFC 5892. If the document updates RFC 5892, in order to remain compliant with the RFCs I would have to modify my implementation and make a backwards incompatible change. Today U+19DA converts to xn--pkf. With this document, I would have to raise an error for that input instead.
My understanding is that the above statements are, if not false, at least incomplete. It is not true, at least with regard to RFC 5892, that "today U+19DA converts to xn-pkf" because RFC 5892 doesn't do any "converting". It *is* true that the code point U+19DA is PROTOCOL VALID using the algorithm in RFC 5892 as applied to Unicode 5.2, and is DISALLOWED using the algorithm in RFC 5892 as applied to Unicode 6.0. If what you mean above is that your implementation intends to raise an error for DISALLOWED code points and would, in a Unicode 6.0 environment, evaluate U+19DA as PVALID and therefore not raise that error, then it is not "compliant" with RFC 5892, irrelevant of the "Updates" status of the present document.
pr -- Pete Resnick<http://www.qualcomm.com/~presnick/> Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf