[Errata Held for Document Update] RFC5890 (4823)

[John C Klensin]

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