<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--></style><title>"rationale" -04, section
7.1.2</title></head><body>
<div>I understand that the RFC 2119 "MUST"s have been
removed but in case that was the only change, the following passage
needs to be improved.</div>
<div><br></div>
<div
>http://www.ietf.org/internet-drafts/draft-ietf-idnabis-rationale-04.<span
></span>txt</div>
<div><br></div>
<div># 7.1.2. Labels in Registration<br>
#<br>
# Anyone entering a label into a DNS zone must properly
validate that</div>
<div># label ... In particular, for</div>
<div># such zones:<br>
#<br>
# o Any label that appears to be an A-label, i.e.,
any label that<br>
# starts in "xn--", MUST be
IDNA-valid, i.e., they MUST be valid<br>
# A-labels, as discussed in Section 2
above.<br>
</div>
<div>From what I understand this is not a requirement placed on the
DNS protocol (name servers do not have to perform this check) and that
this is a requirement on the registration system.</div>
<div><br></div>
<div>I know I should send text to fix this, but after consulting a few
other folks, I don't know what the fix should be. That is, I
don't know what the intent of the passage is supposed to be.
(Hence, why there is confusion in reading it.)</div>
<div><br></div>
<div>If this is not a requirement placed on the DNS, then it is a
requirement placed on, hmm, the registry database, the registration
customer interface (provisioning, or where some use EPP)?</div>
<div><br></div>
<div>Is the intent of this requirement to only make sure the DNS does
not get messed-up A-labels? Is this a requirement that impacts
bundling? Or is this requirement meant to restrict what a
registry puts into A-labels ("don't invent new ones")?</div>
<div><br></div>
<div>One of the problems I see in trying to rewrite this is that it is
protocol-valid to enter a label that fails the stated requirement.
This is possible because not all DNS zones will be striving to meet
the requirements of IDNAbis. Because A-label-looking
labels that are not IDNA valid may be seen in the DNS, the consumers
of the labels (those relying on the output of IDNAbis-complying
registries) might run across a poorly (to them) formatted label and
have to be prepared to not choke - they need to have error handling
code for it.</div>
<div><br></div>
<div>Part of my sensitivity here is rooted in DNS discussions
concerning what do we mean by "bad names" or "bad
data", etc., and how do we shut it down. It's a sticky
issue in the DNS specification.</div>
<div><br></div>
<x-sigsep><pre>--
</pre></x-sigsep>
<div
>-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<span
></span>-=-=-=-<br>
Edward
Lewis <span
></span
> <span
></span
> <span
></span
> <span
></span> +1-571-434-5468<br>
NeuStar</div>
<div><br></div>
<div>Never confuse activity with progress. Activity pays
more.</div>
</body>
</html>