Clarify cardinality via the use of the (non-redudant:-) length field

[sftcd]

The goal here is really to provide more clarify about cardinality, if there's a better way or place to do that, that'd be fine.

[ekr]

I don't believe this is necessary. This idiom is well understood in TLS and this just appears to be excess verbiage.

[sftcd]

Hiya,

(As with all these PRs, I'm ok if they're not accepted...)

On 05/08/2021 22:48, Christopher Wood wrote:

@chris-wood approved this pull request.

+: The length, in bytes, of the next field. One primary method of +distributing ECHConfig values is via the DNS +{{!HTTPS-RR=I-D.ietf-dnsop-svcb-https}} where they may be found in HTTPS or +SVCB records that can (and will commonly) contain a list of ECHConfig values +using the ECHConfigList syntax defined below. This length field allows +implementations to skip over the elements in such a list where they cannot +parse the specific version of ECHConfig.

: The length, in bytes, of the next field. This length field allows
implementations to skip over the elements in such a list where they cannot
parse the specific version of ECHConfig.

For me, that is better than the original, but I do think we ought state the expected cardinality that implementers need to handle somewhere. I reckon it's better to not assume implementers are very familiar with SVCB as for libraries at least, the DNS stuff happens elsewhere. They will have to figure that out eventually, but better to say it somewhere explicitly I think, or we may face some important code base that doesn't handle >1 public key when it ought.

Cheers, S.