On Tue, Mar 15, 2016 at 11:32:24PM -0400, Rob Austein wrote:
> RFC 882, page 10; RFC 1034, page 13.
Well, duh. I've read that at least a dozen times in the past couple
months, and still got it wrong, so I'm a moron (as though we needed
more evidence).
This does suggest a worse structural problem in the IANA registry,
however, because here's what the registry says (comma-separated):
TYPE,Value,Meaning,Reference,Template,Registration Date
A,1,a host address,[RFC1035],,
Since 1034 says that A in CH is "a domain name followed by a 16 bit
octal Chaos address," but 882 sais "it might have the phone number of
the host" (and gives the example
+----------+--------+--------+----------------------------+
|F.ISI.ARPA| A | CS | 213-822-2112 |
+----------+--------+--------+----------------------------+
) I'm not sure what to think. It isn't at all obvious that the RRTYPE
registry is correct. I think this is _yet another_ reason to
deprecate non-IN classes and just specify that new things are
class-independent, period. Alternatively, we could make the RRTYPE
registry clearer about the definition of a given type by class; but
since the other classes don't work for the other reasons discussed,
that would be complicating the registry to no benefit.
Thoughts?
A
--
Andrew Sullivan
[email protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
