"rationale" -04, section 7.1.2
Edward Lewis
Ed.Lewis at neustar.biz
Tue Nov 18 15:59:02 CET 2008
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.
http://www.ietf.org/internet-drafts/draft-ietf-idnabis-rationale-04.txt
# 7.1.2. Labels in Registration
#
# Anyone entering a label into a DNS zone must properly validate that
# label ... In particular, for
# such zones:
#
# o Any label that appears to be an A-label, i.e., any label that
# starts in "xn--", MUST be IDNA-valid, i.e., they MUST be valid
# A-labels, as discussed in Section 2 above.
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.
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.)
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)?
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")?
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.
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.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-571-434-5468
NeuStar
Never confuse activity with progress. Activity pays more.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081118/b6c2bce0/attachment.htm
More information about the Idna-update
mailing list