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? 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. 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.
I.e., cacheable RRTYPEs (non- meta TYPEs) must be representable in
master files. At the time 1035 was written, this would have implied a
requirement that valid wire format RRs must have a valid canonical
presentation format. But 3597 defined the generic "\#" encoding for
RDATA appearing in master files, and explicitly allowed its use for
representing known RRTYPEs:
An implementation MAY also choose to represent some RRs of known type
using the above generic representations for the type, class and/or
RDATA, which carries the benefit of making the resulting master file
portable to servers where these types are unknown. Using the generic
representation for the RDATA of an RR of known type can also be
useful in the case of an RR type where the text format varies
depending on a version, protocol, or similar field (or several)
embedded in the RDATA when such a field has a value for which no text
format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
0.
Even though an RR of known type represented in the \# format is
effectively treated as an unknown type for the purpose of parsing the
RDATA text representation, all further processing by the server MUST
treat it as a known type and take into account any applicable type-
specific rules regarding compression, canonicalization, etc.
> RFC6844:
>
> 5.1.1. Canonical Presentation Format
>
> The canonical presentation format of the CAA record is:
> [snip]
>
> Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower
> case.
>
> [I assume "non-zero" really means "non-empty"]
>
>
> is incompatible with the text in 5.1:
>
> Tag: The property identifier, a sequence of US-ASCII characters.
>
> Tag values MAY contain US-ASCII characters 'a' through 'z', 'A'
> through 'Z', and the numbers 0 through 9. Tag values SHOULD NOT
> contain any other characters. Matching of tag values is case
> insensitive.
>
> Tag values submitted for registration by IANA MUST NOT contain any
> characters other than the (lowercase) US-ASCII characters 'a'
> through 'z' and the numbers 0 through 9.
>
>
> which not only appears to imply the existence of two distinct species of
> tag identifiers, but has the bizarre consequence that not all tag
> identifiers are exactly representable using the canonical format prescribed
> by section 5.1.1
>
> The same form of words, or at least compatible words, should be used in
> both places. 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.)
--
Robert Edmonds
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
