format specific to the SvcParamKey. Their definition should specify
both their presentation format and wire encoding (e.g., domain names,
binary data, or numeric values). The initial SvcParamKeys and
FP: I have the feeling "should" is not the right term here, I suggest to change
to "must" or "is required to". Also, it would have been useful to me to add a
pointer to RFC 8499 in the terminology about "presentation format".
The value is then
validated and converted into wire-format in a manner specific to each
key.
FP: Section 15.4 states
registration policy ([RFC8126], Section 4.4). The Format Reference
MUST specify how to convert the SvcParamValue's presentation format
to wire format and MAY detail its intended meaning and use. An entry
This covers the conversion, but does not cover the validation mentioned above.
length prefix. In presentation format, the value is a single
ECHConfigList encoded in Base64 [base64]. Base64 is used here to
FP: Please clarify that "Base 64 Encoding" (Section 4) is used (rather than
"Base 64 Encoding with URL and Filename Safe Alphabet" (Section 5))
FP: According to 8126, the registry "Service Parameter Keys (SvcParamKeys)"
should include a change controller field.
But that is not specified in the text above, that only talks about first come
first serve registration policy. That should be made consistent.
Nits and Editorials
When the "=" is omitted, the value is interpreted as empty.
FP: When the optional "=" SvcParamValue is omitted
All protocols employing "http://" or "https://" URLs SHOULD respect
HTTPS RRs. For example, clients that support HTTPS RRs and implement
FP: I am not sure how the first sentence is supposed to be implemented, hence
why BCP 14 SHOULD is used here. I also think "respect HTTPS RRs" might not be
the clearest wording.
format specific to the SvcParamKey. Their definition should specify both their presentation format and wire encoding (e.g., domain names, binary data, or numeric values). The initial SvcParamKeys and
FP: I have the feeling "should" is not the right term here, I suggest to change to "must" or "is required to". Also, it would have been useful to me to add a pointer to RFC 8499 in the terminology about "presentation format".
The value is then validated and converted into wire-format in a manner specific to each key.
FP: Section 15.4 states
registration policy ([RFC8126], Section 4.4). The Format Reference MUST specify how to convert the SvcParamValue's presentation format to wire format and MAY detail its intended meaning and use. An entry
This covers the conversion, but does not cover the validation mentioned above.
length prefix. In presentation format, the value is a single ECHConfigList encoded in Base64 [base64]. Base64 is used here to
FP: Please clarify that "Base 64 Encoding" (Section 4) is used (rather than "Base 64 Encoding with URL and Filename Safe Alphabet" (Section 5))
FP: According to 8126, the registry "Service Parameter Keys (SvcParamKeys)" should include a change controller field.
Table 1
FP: The table reports that
| 65280-65534 | N/A | Private Use | (This document) |
But that is not specified in the text above, that only talks about first come first serve registration policy. That should be made consistent.
Nits and Editorials
When the "=" is omitted, the value is interpreted as empty.
FP: When the optional "=" SvcParamValue is omitted
All protocols employing "http://" or "https://" URLs SHOULD respect HTTPS RRs. For example, clients that support HTTPS RRs and implement
FP: I am not sure how the first sentence is supposed to be implemented, hence why BCP 14 SHOULD is used here. I also think "respect HTTPS RRs" might not be the clearest wording.