Pete Resnick <presnick(_at_)qualcomm(_dot_)com> writes:
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.
Thanks for clarifying.
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".
Sure. RFC 5892 is part of the IDNA2008 set and primarily RFC 5891
describe the conversion. RFC 5891 uses the properties defined in RFC
5892.
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.
Right.
If what you mean above is that your implementation intends to raise an
error for DISALLOWED code points and would,
That is required by RFC 5891 section 4.2.2:
4.2.2. Rejection of Characters That Are Not Permitted
The candidate Unicode string MUST NOT contain characters that appear
in the "DISALLOWED" and "UNASSIGNED" lists specified in the Tables
document [RFC5892].
and section 5.4:
Putative U-labels with any of the
following characteristics MUST be rejected prior to DNS lookup:
o Labels containing prohibited code points, i.e., those that are
assigned to the "DISALLOWED" category of the Tables document
[RFC5892].
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.
I don't see how.
My code uses the tables from RFC 5892 which were generated in an Unicode
5.2 environment. My IDNA2008 code may eventually run in an Unicode 6.0
environment, or any other future version of Unicode. I can't control
the Unicode version used, and from what I understand this is one of the
features of IDNA2008. Implementations need not lock down the Unicode
version to a single Unicode version, as they had to do for IDNA2003.
If this model is not permitted, I believe there are bigger problems.
To avoid doubt, and to back up your assertment that my implementation is
non-compliant, please point to the "MUST" or "SHOULD" in RFC 5892 that
forbis this, to me, logical implementation approach.
/Simon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf