[Errata Held for Document Update] RFC5890 (4823)
John C Klensin
john-ietf at jck.com
Fri Oct 7 23:18:19 CEST 2016
For whatever it is worth, I agree with Markus. This whole
discussion indicates to me that I/we said rather too much in
5890 and that the correct solution is to talk about code points
and then stop. In that context, the proposed "corrected text"
below could be further improved by saying what we mean, which
is, more or less,
"DNS labels are limited to a maximum length of 63 octets
[RFC 1034] which, if only traditional ASCII characters
are involved, becomes a 63 character limit. The
symmetric relationship between U-labels and A-labels and
properties of the Punyocde encoding used in the latter
effectively impose a smaller limit of no more than 59
Unicode code points".
That should be all we need to say and, incidentally, we should
only need to say it once.
This is useful to resolve now because there is a document being
developed that is likely to be posted as an I-D fairly soon.
That document, for other reasons, will update 5890. So, unlike
the usual situation in which "Hold for Document Update" implies
a really long time, drafts for that update could be only weeks
in the future. Resolving what the community wants now could
save some time and repeating the pain this issue and erratum has
caused already.
john
--On Friday, October 07, 2016 13:16 -0700 Markus Scherer
<markus.icu at gmail.com> wrote:
> On Fri, Oct 7, 2016 at 12:58 PM, RFC Errata System <
> rfc-editor at rfc-editor.org> wrote:
>
>> Corrected Text
>> --------------
>> expansion of the A-label form to a U-label may produce
>> strings that are much longer than the normal 63 octet DNS
>> limit (potentially up to 59 Unicode code points or 236 octets)
>>
>
> The "or 236 octets" is rather confusing, and irrelevant:
> Anyone dealing with Unicode strings has an idea how they store
> them. It would be better to drop this part.
>
> If there is a desire to keep something like it, I suggest
> "potentially up to 59 Unicode code points which in turn could
> be represented by up to 236 octets in any of the standard UTF
> encoding forms"
>
> That would be pretty clear, but my preference is simply
> "potentially up to 59 Unicode code points" and be done with it.
>
> Best regards,
> markus
More information about the Idna-update
mailing list