Re: [DNSOP] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

Implementing the encoder isn’t hard but it needs to be clearer that there are specific encodings. It is easy to miss this. I did initially.

-- 
Mark Andrews

> On 26 Sep 2019, at 20:41, Vladimír Čunát <vladimir.cunat+ietf@nic.cz> wrote:
> 
> 
>> On 9/26/19 12:30 PM, Jan Včelák wrote:
>>> The current draft attempts to minimize complexity for implementers by offering a fully generic encoding for unknown key types.  For example, "alpn=h3" can also be expressed as "key1=h3", and "port=8003" can also be expressed as "key2=\031\067".  This encoding may not be convenient, but hopefully it will reduce the burden of supporting new parameter types.
>> I agree we need generic encoding. There is a way to express unknown
>> record types (https://tools.ietf.org/html/rfc3597#section-5) and the
>> syntax used there is more compact than what you propose. It uses hex
>> strings instead of escaped decimal values. However its clumsy to work
>> with records in that syntax and you proposal is better in that sense.
> I'm curious, Is there much motivation for a bit more compactness of the *presentation* format?  I consider its design primarily meant for humans.
> 
> 
>> I think this may become the most complex record type we have in DNS so
>> far. None of the existing registered record types contain a list of
>> key-value pairs of arbitrary length. Given that there is also a
>> registry for key types involved it will be fun to implement the
>> encoder/decoder. But we will have to deal with it. I'm interested in
>> what others in this working group think.
> I think we should get "implementation experience" from multiple parties at least before publishing the RFC (though that's a point far ahead, I suppose).
> 
> --Vladimir
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop