On Mon, Oct 20, 2025 at 10:16 AM Michael Richardson <[email protected]> wrote: > > > Paul Hoffman <[email protected]> wrote: > > SVCB/HTTPS, and the future DELEG/DELEGI, use subtypes for more than > > just reducing the number of new RRtypes: they use them for grouping > > subtyped data into a logical record. Saying "you can't do that" puts a > > limit on designs where one qname might have sets of related data. It > > feels inappropriate for DNSOP to say "you can't do that in the DNS" > > just to make life easier for API developers. > > I think, but I hope Viktor will confirm, that the problem isn't so much the > subtyping itself, but rather the syntax of the value side of things. > SVCB/HTTPS (DELEG) are maps with keys and values. > > If the values have wide-open to-be-defined-by-extension formats, then it > becomes hard. If they degenerate to "some sequences of bytes" (some of them > DNS QNAME restricted strings, some UTF-8, some 16-octet v6-addresses, ...) > then life becomes hard for API writers. > If they are restricted to some clear set of value-types, then it's better. > That might be a good middle ground: the RR type RFC needs to define valid > formats for values, and any extension requires a new RR-type.
I disagree to a point. An API that exposes the fields it knows about, while also exposing unknown extensions is possible while also giving raw access to all when needed. This is fairly well established in dealing with X509. It's true that if there's a format restriction that the library/ecosystem doesn't have a way to support, application writers have a more difficult time, but there's no working around that even with a new RR type. > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Astra mortemque praestare gradatim _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
