> On 11 Feb 2020, at 11:16, 神明達哉 <[email protected]> wrote: > > At Sun, 9 Feb 2020 04:28:14 -0500, > Viktor Dukhovni <[email protected]> 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.
I would submit a bug report. The intention of RFC3597 is to allow servers to load records regardless of whether they know the record’s presentation format or not. Mark > -- > JINMEI, Tatuya > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
