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
