> 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 > <mailto: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. > > Thank you for the details on how your client uses the wire format and the way > those impact the end client systems. Absolutely! Happy to answer any further questions as well. Best, Tommy > > Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop