<font face="georgia,serif">Thanks. I agree that it isn't relevant to U-Labels.</font><div><font face="georgia,serif"><br clear="all"></font><font face="georgia, serif">Mark<br><br><i>— Il meglio è l’inimico del bene —</i></font><br>

<br><br><div class="gmail_quote">On Wed, Sep 29, 2010 at 19:49, John C Klensin <span dir="ltr"><<a href="mailto:klensin@jck.com">klensin@jck.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
--On Wednesday, September 29, 2010 18:31 -0700 Mark Davis ☕<br>
<div class="im"><<a href="mailto:mark@macchiato.com">mark@macchiato.com</a>> wrote:<br>
<br>
> Ken is right about the maximal source label length being at<br>
> least 252 in the absence of mapping.<br>
><br>
> With the use of mapping, however, it could be substantially<br>
> longer. This can happen a series of characters in the source<br>
> can map to a single character, and then are mapped to a single<br>
> byte in Punycode. That can happen with IDNA2008, or with UTS46<br>
> (or any other mapping preprocessing for IDNA2008).<br>
><br>
> So it is best to just avoid a mention of a limit like 252;<br>
> either that or explain the situation in more detail.<br>
</div>>...<br>
<br>
Mark,<br>
<br>
Thanks for the explanation and illustration.  Do note two things:<br>
<br>
(1) We aren't discussing a document that is still in development<br>
here, but a published RFC.  While I can imagine the document<br>
being "updated" (really replaced by a new version) at some<br>
point, I doubt that it will be any time soon unless we discover<br>
a really severe problem.   Because the present comment was more<br>
or less an aside, it would be hard to claim it is that severe.<br>
So the most that it is possible to do at this stage is to file<br>
an erratum.  Not only do few people look at those in practice,<br>
but, for something like this, the most likely status for it is,<br>
more or less, "note to be considered when the document is next<br>
revised".<br>
<br>
(2) The text of RFC 5890 at that point is, unless my memory has<br>
gone seriously bad, strictly discussing U-labels and A-labels.<br>
A U-label involves absolutely no mapping: it is required to be<br>
in NFC form, but there isn't even mapping _to_ NFC form.    So,<br>
using your example,  consider<br>
<div class="im"><br>
> 00 00 00 41 00 00 03 08 00 00 03 04<br>
><br>
> That sequence, when normalized to NFC, yields<br>
><br>
> U+01DE ( Ǟ ) LATIN CAPITAL LETTER A WITH DIAERESIS AND<br>
> MACRON, one character.<br>
<br>
</div>Yes.  But, because that sequence is not in NFC form, it isn't a<br>
valid U-label.  So the example is interesting --and very<br>
important to mapping approaches like those outlined in RFC 5895<br>
or UTR 46-- but it is irrelevant to RFC 5890.<br>
<br>
     john<br>
<br>
_______________________________________________<br>
<div><div></div><div class="h5">Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</div></div></blockquote></div><br></div>