Make options a list again

[miri64]

TBD28259 (see section Name Compression) put the final death nail into the idea of the EDNS(0) options being a map.

[miri64]

In the interest of consistency it probably makes sense to encode the list of options in the same manner as we do SvcParams (a flat list with interleaving optnum-optval-pairs). We do that their, because SvcParams MUST have a predetermined order, but does not hurt to do it here as well. Will do!

[nuclight]

I support making it array (so that everything structured is array which allows for subset coding in CBAPT, but this I'll write more detailed later in #12), however did not quite understand why name compression was that nail.

The only possible thing I may be suggesting here is to add a phrase that order of key-value pairs is, like in original DNS, not important (behaves like map) - for those fearless who could try to add determinism here in future...

[miri64]

..., however did not quite understand why name compression was that nail.

Because the order, strings appear within the object, is important with name compression. Unless when using deterministic encoding (or more specific just what used to be called lexicographic-map-sorting encoding constrained) there is no given order to maps in CBOR. So unless we enforce the encoding constraint we can't use maps within TBD28259. However, given that we don't have strings here in the keys, but unsigned ints, and those ints are to be in numerical order for SvcParamKeys, I'd rather avoid confusion and don't use such encoding constraints and just provide an order with the list encoding.

[nuclight]

Ah, so we could get different compressed size depending on order of strings within maps. Got it.
Where's the approve button here...

[miri64]

Ah, so we could get different compressed size depending on order of strings within maps. Got it.
Where's the approve button here...

Not a different size. Depending on how you write and in which programming language your encoder, e.g., use an in-memory representation of a hash map of objects first, and then convert to binary. This can actually completely mess up your references, as strings might not be in the same order in the binary as they were in your in-memory representation.

[miri64]

Where's the approve button here...

Under the "Files changed" tab.

[miri64]

Not a different size. Depending on how you write and in which programming language your encoder, e.g., use an in-memory representation of a hash map of objects first, and then convert to binary. This can actually completely mess up your references, as strings might not be in the same order in the binary as they were in your in-memory representation.

And sure, a smart programmer will not make such a mistake, but let's try to prevent potentials for programmers to shoot themselves in the foot directly here.

[miri64]

The only possible thing I may be suggesting here is to add a phrase that order of key-value pairs is, like in original DNS, not important (behaves like map) - for those fearless who could try to add determinism here in future...

Thought I amended something for that, but apparently, I forgot. Please wait with the merge until tomorrow when I can check my work machine.

[nuclight]

Ah, so we could get different compressed size depending on order of strings within maps. Got it.
Where's the approve button here...

Not a different size. Depending on how you write and in which programming language your encoder, e.g., use an in-memory representation of a hash map of objects first, and then convert to binary. This can actually completely mess up your references, as strings might not be in the same order in the binary as they were in your in-memory representation.

Ah, not thought about it. So I am not so smart programmer :) let's prevent foot guns directly.

Under the "Files changed" tab.

Don't see it here either, but OK, let's wait.

[miri64]

Thought I amended something for that, but apparently, I forgot. Please wait with the merge until tomorrow when I can check my work machine.

Done.