> On Oct 20, 2025, at 10:13, 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.
That proposal sounds fine to me, but that's not how I read Viktor's request. (And I'm not sure how that restriction could be made in a way that future creators of new RRtypes would find it, which would make this effort moot.) --Paul Hoffman _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
