At Sun, 9 Feb 2020 04:28:14 -0500, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> ---> 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. > > In particular the middle paragraph's *MAY* could appear to suggest that > the choice is not just one of output format, but that *on input* parsers > don't need to support the generic "\# <len> <hex nibbles>" form for > *known* types. > > I don't read it that way, rather my reading is that the generic RDATA > format MAY be selected on *output* for portability reasons, but *should* > MUST be supported for all types, whether known or unknown, on input. It would be nice if we could clarify the meaning of this "MAY". I've also encountered an implementation (not BIND 9) that rejects the RFC3597 form of RDATA for types that the implementation already explicitly supports (e.g., type AAAA). I was about to submit a bug report but on re-reading the RFC and found this "MAY", and wondered whether this allows such an implementation to still claim to be compliant. I personally agree with your interpretation, but the text could actually be clearer. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
