"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