> On May 19, 2021, at 2:37 PM, Erik Nygren <erik+i...@nygren.org> wrote: > > > > >> On Wed, May 19, 2021 at 5:12 PM Tommy Pauly <tpa...@apple.com> wrote: >> >> >>> On May 19, 2021, at 1:34 PM, Brian Dickson <brian.peter.dick...@gmail.com> >>> wrote: >>> >>> >>> >>> On Wed, May 19, 2021 at 7:49 AM Tommy Pauly <tpa...@apple.com> wrote: >>>> I wanted to chime in on this discussion as a client-side implementor who >>>> has already widely deployed support for SVCB/HTTPS. >>>> >>>> The current format, where the parameters are structured as a list within a >>>> single RR, is certainly simpler and less error prone for processing. Much >>>> of the information contained as parameters within the SVCB RR are useful >>>> for higher-level “application” logic. Within our deployment, the DNS stub >>>> resolver daemon receives the RR and does the parsing, and passes up the >>>> parameters bundle as a blob that is more or less opaque, to the layer that >>>> handles actual connection processing (doing happy eyeballs, protocol >>>> selection). >>>> >>>> Processing the content of SVCB parameters must be handled atomically: the >>>> ALPN, ECH config, and any other information must be handled clearly as a >>>> unit and not have any chance of being broken up. Lots of code is already >>>> based on processing RRs as chunks of data, and requiring anyone looking at >>>> the information to stitch the parameter list back together based on >>>> multiple RRs that must be in a particular order adds complexity and >>>> invites in bugs and errors. >>>> >>>> I’d strongly encourage sticking with the wire image we’ve already been >>>> using and deploying. >>> >>> Would it be accurate to say that as long as the wire format of both SVCB >>> and HTTPS do not change, your client implementation(s) would not be >>> impacted by any changes to zone file format? >>> >>> I.e. you don't implement any server code, so what the zone format is does >>> not affect you, and how the wire format gets produced from the zone format >>> is not relevant to you? >> >> That’s correct. My main concern here is keeping the wire format consistent >> and simple. How the zone format file works is indeed something separate, and >> not something I have strong opinions on. Anything we can do to make the >> processing simple for both sides is great. >> > > Also as I understand it, changes that substantially change the semantics of > the records but preserving > the presentation format and wire format would also affect you? In > particular, any shift from > a RR-per-service-binding to having service bindings span RRs in the RRset > would add significant > complexity to your client implementation as you've described?
Correct. I’m saying that the wire format should remain as defined, as well as the contents and semantics—the single RR containing the various parameters needed to interpret a single service instance, with ALPN/ECH/Hints all together. Changing the way this service is spelled, such as breaking it into separate RRs, effectively breaks the wire format (since it is no longer intelligible as a single service). > > Separately I've opened https://github.com/MikeBishop/dns-alt-svc/issues/324 > to explore if there are ways we can simplify through character set > constraints. > In-particular, if we could get ALPN constrained to a set of token characters > (and similarly constrain future SvcParams that want to be value lists to use > a limited subset of characters) then some of the parsing concerns get > simpler. > I've mailed the TLS WG as they may not be willing to change how ALPN registry > entries are handled in which case we'd still need a solution here. > > Best, Erik >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
