The text in question was <font size="2"><i>"(something that is now recognized as a considerable source of risk)".<br><br></i></font>As the high bit, we could fix this textual problem with a few lines in Rationale that summarized your argument, in a Section X, and then instead of the above text, we could have "(something that may be a source of risk - see Section X)". That would address the dangling reference for "now recognized", and give people some concrete reasoning.<br>
<br>==<br><br>As the second-order bit, however, I think the argument you convey is inconsistent with actual statements in Protocol.<br><br>1. If you say that the registries cannot be depended on, then we need to remove the text that IDNA2008 relies on "the assumption that the names present in the DNS are valid". See below.<br>
<br><a href="http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#section-5.1">http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#section-5.1</a><br><pre class="newpage"> Although some validity checks are<br>
necessary to avoid serious problems with the protocol (see<br> <a href="http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#section-5.5">Section 5.5</a>ff.), the lookup-side tests are more permissive and rely<br>
on the assumption that names that are present in the DNS are valid.<br></pre>2. Since the onus is on lookup, then we also would need to tighten the lookup requirements so that they are as strong as the registry requirements. This would imply that:<br>
<br>a. lookup would be required to test for CONTEXT and BIDI rules.<br>b. lookup would be required to test A-Labels, rather than allow them to sail through unchallenged.<br><br><a href="http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#section-5.4">http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#section-5.4</a><br>
<pre class="newpage"> If the input to this procedure appears to be an A-label (i.e., it<br> starts in "xn--"), the lookup application MAY <i>[test it].</i></pre><div style="margin-left: 40px;">For example, the A-Label <a href="http://xn--iny-zx5a.com/">xn--iny-zx5a.com</a> (the pernicious I♥NY.com) could go sailing through without any checks, even through one of the characters is DISALLOWED (not just UNASSIGNED). So in particular, suppose I have a process P1 that takes in IRIs and transforms them to A-Label form. It is not doing a lookup, so it is not subject to the requirements of Protocol. It passes that off to a second process P2 that does a lookup. P2 is handed an A-Label, so it is not required to do any tests.<br>
<br>Or P2 could just be picking up IRIs from web pages, XML documents, or any other sources, where the real originator of the A-Label is obscured, and may have been an IDNA2003 process, which allows for UNASSIGNED code points in lookup.<br>
</div><br> ===<br><br>And yet I don't want to argue that we have to do #1 and #2. What we all really would like to do is block an IRI that uses codepoints that are UNASSIGNED as of the current, latest, version of Unicode, but let through IRIs that use codepoints that have been tested by a process that supports a later version of Unicode. But there doesn't appear to be a feasible way to do that.<br>
<br>[The more I think about the application of these constraints in real-live implementions -- who has to do what, and how we are going to make this work -- the more my head swims! See the implementation questions note that I filed yesterday (<a href="http://www.alvestrand.no/pipermail/idna-update/2008-December/003287.html)">http://www.alvestrand.no/pipermail/idna-update/2008-December/003287.html)</a>.]<br>
<br>Mark<br><br>PS.<br><br><div style="margin-left: 40px;">John: I noticed an orthogonal textual problem in the statement in #1. The "(see <a href="http://tools.ietf.org/html/draft-ietf-idnabis-protocol-08#section-5.5">Section 5.5</a>ff.)"
note sets the reader's expectations that 5.5 will explain what the
"serious problems" are. But it just lists the requirements, not the
"serious problems". Maybe that could be addressed by moving that parenthetical to after "the lookup-side tests".<br></div><br><div class="gmail_quote">On Sun, Dec 21, 2008 at 03:43, Vint Cerf <span dir="ltr"><<a href="mailto:vint@google.com">vint@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
<br>
Mark,<br>
<br>
the simplest reason I see for NOT permitting UNASSIGNED<br>
characters to be included in lookup has to do with our<br>
inability to assure compliance especially at lower levels of<br>
the domain name space. Unscrupulous or merely incompetent or<br>
inattentive registrars (by this I do not mean the ICANN<br>
definition of "registrar" but rather any entity that places<br>
domain names into zone files at any level in the system) might<br>
use (ie register domain names with) unassigned characters in<br>
an attempt to cause confusion or to use misleading<br>
registrations for abusive purposes. By prohibiting the lookup<br>
of UNASSIGNED characters, such abuses are blocked.<br>
<br>
Since the complete property list for an unassigned code point is<br>
unknown, and<br>
remains unknown until the code point is assigned, we can't know<br>
whether that code point will<br>
<br>
-- turn out to be DISALLOWED (presumably because it is<br>
assigned to a symbol, punctuation, or a letter that<br>
decomposes under NFC to some other character)<br>
<br>
-- turn out to be something that requires contextual<br>
treatment (i.e., CONTEXTO or CONTEXTJ and which one),<br>
much less what the relevant rules would be.<br>
<br>
-- turn out to be PVALID.<br>
<br>
In essence, permitting it to be looked up establishes a "PVALID<br>
until proven otherwise" status, which therefore raises most (but<br>
not quite all) of the issues associated with changing the status<br>
of a character from PVALID to DISALLOWED. Something I think<br>
most of us would not want to facilitate.<br>
<br>
<br>
Vint Cerf<br>
Google<br>
1818 Library Street, Suite 400<br>
Reston, VA 20190<br>
202-370-5637<br>
<a href="mailto:vint@google.com">vint@google.com</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
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>
</blockquote></div><br>