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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
