On 11 March 2016 at 17:47, Robert Edmonds <edmo...@mycre.ws> wrote: > Dick Franks wrote: > > There is no need to resort to doctrinal arguments about MUST/SHOULD, or > > imagine that the RFC6844 tail can wag the RFC1035 dog. > > > > Mark A's objection really points a fundamental contradiction in RFC6844 > > itself. > > Hi, Dick: > > Are you implying that 6844 violates 1035 in some way?
6844 5.1.1 defines the tag field in a way which forbids the (arbitrary) characters which MAY (but SHOULD NOT) be present according to the text in 5.1. This conflicts with the 1035 notion that master files contain text representation of RRs. I understand the > reasoning in the erratum rejection: > > [...] > > The author believes SHOULD is correct here. The protocol on the wire > will work just fine if someone breaks this advice. > > Yes, it might well break some zone file parsers. But those aren't on > the wire and that type of incompatibility is exactly what I would > expect from violating a SHOULD. > > [...] > > to be asserting that a valid wire format RR can have no valid canonical > presentation format. But CAA _does_ have a canonical presentation format, defined at 5.1.1. The closest requirement I can find in 1035 is this: > > 5. MASTER FILES > > Master files are text files that contain RRs in text form. Since the > contents of a zone can be expressed in the form of a list of RRs a > master file is most often used to define a zone, though it can be used > to list a cache's contents. > So are you really suggesting flipping between canonical 6844 format and 3597 \# format merely because the tag field happens to contain some non-alphanumeric character or upper case letter? > RFC6844 offers no justification for case folding, so > > specifying exact matching would make the whole issue go away. > > I would hazard a guess that the "Matching of tag values is case > insensitive" sentence is a requirement on applications that consume the > RR, and not to DNS protocol comparisons like RRset data equality or > DNSSEC canonical form. (Note the sentence "Applications that interpret > CAA records..." a few lines up.) > An unnecessary complication in my view, but maybe that is off-topic here. -- Dick Franks
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
