<div dir="ltr">I had a chance to review the documents again, and here are my comments.<br><div><br></div><div>1. First, and most importantly, the normative definitions really have to be moved out of the rationale document and into the protocol document. One could argue that disentangling them is difficult for the editor, but as it stands the documents are simply too difficult to understand in terms of the normative implications. And if it is difficult for the editor to disentangle, it will be far, far, more difficult for users of the specifications to disentangle.</div>
<div><br></div><div>Concretely, I suggest that this would be done by moving the following sections into the protocol document.</div><div><br></div><div>1.5.2 - 1.5.4</div><div>4</div><div>5, 5.1, 5.2</div><div>9.1</div><div>
<br></div><div>Most of the above moves into the terminology section in protocol; 9.1 (describing differences from IDNA2003) could come either near the start or at the end.</div><div><br></div><div>With these changes, I think protocol would be in pretty good shape. Rationale would need a lot more work, but if the normative sections are moved to protocol, then it is much less of a problem for a timely release.</div>
<div><br></div><br>Other comments on protocol.<br><br>> IDNA. Note that IDNs occupying domain name slots in those older<br>> protocols MUST be in A-label form until and unless those protocols<br>> and implementations of them are upgraded.<br>
<br>upgraded to what? It is unclear what the referent is.<div><br></div><div><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> be Unicode). The registry MAY permit submission of labels in A-label</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> form. If it does so, it SHOULD perform a conversion to a U-label,</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> perform the steps and tests described below, and verify that the</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> A-label produced by the step in Section 4.5 matches the one provided</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> as input. If, for some reason, it does not, the registration MUST be</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> rejected.</p><div><br></div><div>The first SHOULD has to be a MUST; otherwise the registry can register an invalid name.</div><div><br></div><div><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">
> 4.2. Conversion to Unicode and Normalization</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> ... That string MUST be in Unicode Normalization</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> Form C (NFC [Unicode-UAX15]).</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">
This constraint needs to be moved to Permitted Character and Label Validation, for clarity, since it can otherwise be misleading (we've seen too many people confuse these issues). I'd suggest 4.3.1 and then renumbering the ones after. (I think this should be uncontroversial after you look at this section, but if not let me know and I'll supply some more reasoning)</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> As a local implementation choice, the implementation MAY choose to</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> map some forbidden characters to permitted characters (for instance</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> mapping uppercase characters to lowercase ones), displaying the</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> result to the user, and allowing processing to continue. However, it</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> is strongly recommended that, to avoid any possible ambiguity,</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> entities responsible for zone files ("registries") accept</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> registrations only for A-labels (to be converted to U-labels by the</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> registry) or U-labels actually produced from A-labels, not forms</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> expected to be converted by some other process.</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">
I really think this is a bad idea. One of the reasons for a clear separation of A-Label and U-Label is to make it very clear what is being registered. The above muddies it again. So I would drop the first sentence, and make the second two be MUSTs, and make it clear that even if the registration process takes a U-Label, what is being registered is the A-Label.</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> The Unicode string is checked to verify that no characters that IDNA</p>
<div>... </div><div>(later section)</div><div>...</div><div><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> The proposed label (in the form of a Unicode string, i.e., a putative</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> U-label) is then examined, performing tests that require examination</p><div><br></div><div>For clarity, the terminology needs to be a bit more consistent. I would suggest using "putative U-Label" (or something similar) uniformly throughout the different steps, both here and in the lookup sections.</div>
<div><br></div><div><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> there SHOULD be policies. Even a trivial policy (e.g., "anything can</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> be registered in this zone that can be represented as an A-label -</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> U-label pair") has value because it provides notice to users and</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> applications implementers that the registry cannot be relied upon to</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> provide even minimal user-protection restrictions. These per-</p><div><br></div><div>It is really an open issue as to where the best place for restrictions or notifications of possible spoofing is in the registry or in the client software. Given that, I think this section is best left out, or moved to rationale and made non-normative. This is especially the case given that it applies to registries at *all* levels, and because of the text about notice ("it provides notice to users and applications implementers") so it imposes a SHOULD on, say, Google to provide notice to users about policies for <a href="http://xxx.google.com">xxx.google.com</a> and <a href="http://yyy.xxx.google.com">yyy.xxx.google.com</a>, and so on.</div>
</div></div><p></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> The string produced by the above steps is checked and processed as</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> appropriate to local registry restrictions. Application of those</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> registry restrictions may result in the rejection of some labels or</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> the application of special restrictions to others.</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">
This paragraph is not very clear, and here would be a good point to have a brief statement about the common techniques of "bundling" vs "blocking". Suggested replacement:</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">
<br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">The string produced by the above steps thus may be examined as appropriate for consistency to local registry policies. Where characters are disallowed according to those local policies, the string would be rejected. The string may also be overly similar to an existing registration, such as where Chinese string with a traditional character versus a simplified one, or a Romanian word with S with cedilla versus S with comma below. In such cases, there are two common techniques for local registries. With blocking, the string is rejected. With bundling, the original registrant automatically gets the variants of a registered name.</p>
<p></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><br></p><p></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> ... the lookup application MAY attempt to convert it</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> to a U-label and apply the tests of Section 5.5 and, of course, the</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> conversion of Section 5.6 to that form. If the label is converted to</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> Unicode (i.e., to U-label form) using the Punycode decoding</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> algorithm, then the processing specified in those two sections MUST</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> be performed, and the label MUST be rejected if the resulting label</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> is not identical to the original. See also Section 6.1.</p><p></p><p></p><div><br></div><div>I'm not sure how this would play out in practice. Suppose I have a program accepts an A-Label and routes it two internal, independent modules. One module may process the A-Label into a U-Label, while the other just send the A-Label on to another program. This conformance clause would seem to require that if module #1 happens to find a problem, the program as a whole MUST reject the label. That would require that we MUST rearchitect the program to have module 1 be able to communicate with module 2 AND that module 2 can't send the name on without waiting on module 1. I think we have to change this to ...MAY... SHOULD, and not ... MAY ... MUST.</div>
<div><br></div><div><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> the lookup-side tests are more permissive and rely</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> heavily on the assumption that names that are present in the DNS are</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> valid.</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">As far as I can tell, the only difference in the processing is that BIDI is a SHOULD not a MUST. If that is the case, then "more permissive and rely heavily" is overstating the differences. And either way, we really need to have a much crisper description of the differences.</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">That is, paedigogically, the structure now is something like</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">
<br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">Registry</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">(registry specific stuff)</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">Do A</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">Do B</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">Do C</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">
Do D</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">Do E</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">...</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">Do H</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">
(registry specific stuff)<br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">Lookup</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">
<br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">(lookup specific stuff)</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">Do A</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">
Do B</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">Do C</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><span class="Apple-style-span" style="font-family: arial; "></span></p><p style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Arial; ">
Do D</p><p style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Arial; ">Do E</p><p style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal normal normal 13px/normal Arial; ">
...</p><p></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">SHOULD do H</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">(registry specific stuff)<br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">
<br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">That forces the user who needs to determine the differences to do his own DIFF between them, and gives implementers of libraries who will supply parameterized software that does both plenty of chances to screw it up. It would be less error prone, if possible, to structure the text so as to distinguish the core processing (A-H above), and say that Lookup follows exactly the same process for that core except that H is optional.</p>
<div><br></div></div></div><div><br></div><div><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> The Unicode string MAY then be processed to prevent confounding of</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> user expectations. </p><div>...</div><div><br></div><div><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> Preprocessing MUST NOT map a character</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> that is valid in a label (i.e., one that is PROTOCOL-VALID or</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> permitted in any context) into another character.</p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">
These two statements must be very closely associated - the second is a strong restriction on the first, but they are separated by gobs of text. The second needs to be moved up to be directly after the first, eg. "Such preprocessing MUST NOT ..."</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"><br></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial"></p><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">
> 6.3. Root and other DNS Server Considerations</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">></p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> IDNs in A-label form will generally be somewhat longer than current</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> domain names, so the bandwidth needed by the root servers is likely</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> to go up by a small amount. Also, queries and responses for IDNs</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> will probably be somewhat longer than typical queries historically,</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> so EDNS0 [RFC2671] support may be more important (otherwise, queries</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> and responses may be forced to go to TCP instead of UDP).</p><div><br></div><div>The first sentence looks like a hold-over. It is untrue, since IDNA2003 has been deployed for some time now, and so IDNs in A-Label from are already "current". The wording also looks like it is going to contrast "IDNs in A-Label form" with some other IDNs (U-Label). Following is suggested wording.</div>
<div><br></div><p></p></div></div></div><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><span class="Apple-style-span" style="font-family: Arial; ">IDNs (the A-label form) are generally somewhat longer than other domain names, so as they have increasing deployment the bandwidth needed by the root servers is likely ...<br>
<br><br></span></blockquote><div><div><p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> This memo describes procedures for registering and looking up labels</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> that are not compatible with the preferred syntax described in the</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> base DNS specifications (STD13 [RFC1034] [RFC1035] and Host</p>
<p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 13.0px Arial">> Requirements [RFC1123]) because they contain non-ASCII characters.</p><div><br></div><div>The wording here also seems odd, given that IDN2003 has been out for some 5 years. Maybe just adding wording referencing the IDNA2003 specs at an appropriate point?</div>
<div><br></div><div><br></div></div></div></div>