> > My message to the WG is in essence to be sparing in defining RRTYPEs > > with extensible field subtypes. > > I thought this WG decided a long time ago that subtyping was bad. > It didn't get written up as an RFC though.
This seems to be an instance of a universal problem in protocol design: keeping the protocol simple may lead to a popular protocol that cannot be extended without hacks. Making the protocol extensible may lead to a protocol that is overly complex. I doubt we can say much in general. In needs to be decided on a case by case basis. In the context of DNS, I don't really see the problem because we already have many instances of extensible fields. The oldest is of course the introduction of new RRtypes. Any library that deals with DNS as a whole needs to be able handle unknown RRtypes. With EDNS(0) came unknown options. Again, something software has to deal with. Anything that deals with security has algorithm fields that are open-ended. Though in libraries those are usually left as bit strings. An exercise for the reader would be to express the semantics of SVCB as a collection of RRtypes that cannot be extended. I'm sure it can be done, but I doubt the end result will be less complex than what we have in SVCB. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
