[Errata Held for Document Update] RFC5890 (4823)

[Martin J. Dürst]

Hello Markus, John,

I would be fine either way, but I'd at least keep the current wording 
for the errata for the following (partially overlapping) reasons:

- The main point of an erratum (in my view at least) is to fix a clear
   problem, not to engage in detailed wordsmithing.
- The errata review process isn't at the same level as a WG process,
   so trying to find a final wording on the erratum sounds slightly
   premature.
- I don't think "held for document update" does in any way imply
   that the update has to use the exact wording.
- The current RFCs have counts like 236. The explanations that were
   just approved as errata help see where this number came from.
   This is (somewhat) more important in an erratum (which is approved
   just on the level of AD) than in a new document (which is approved
   by IETF consensus).
- The error was not just a calculation error; I think there was indeed
   an intent in the WG to warn implementers about the expansion problem).

Also, Markus said: "Anyone dealing with Unicode strings has an idea how 
they store them.". I'd say: "We'd better hope so!". But implementers in 
the DNS area are not necessarily familiar with Unicode strings. So a 
hint can help, and shouldn't hurt.

Regards,    Martin.

On 2016/10/08 06:18, John C Klensin wrote:
> 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
>
>
>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>

-- 
Martin J. Dürst
Department of Intelligent Information Technology
Collegue of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan