danmarg
commented
6 years ago §5.4:
Alternately, if a receiving system offers "Accept-Encoding" value of "gzip"...
Offers it where?
I'm confused by this. Accept-Encoding is a request header, not a response header, so there's no way for servers to use it to indicate to clients that they accept GZIP. It seems like clients would have to just try GZIP and see if they get a 200 or a 415 response code (415 = unsupported media type).
For now I'm just removing this paragraph, but I'm happy to take suggestions on how this should work.
abrotman
COMMENT:
Thanks to everyone who worked on this document. The mechanism seems useful, and I hope it aids in the deployment of TLS-secured email transfer. I have a mix of editoral and substantive comments.
§1.1:
This document also uses lowercase forms of these words. Consider using the boilerplate from RFC 8174.
§3:
This seems tautological. If this is intended to restrict some action that is not impossible by its own nature, then it needs rephrasing. Otherwise, it should probably just be removed.
§4.4:
Although these use the word "number," its use seems to be colloquial rather than technical. It is probably worthwhile, for avoidance of doubt (and to prevent errant string encodings), to add ", encoded as a JSON number" to the end of each of these.
§4.4:
Presumably, this is ANBF? Please indicate that. Also, in ABNF, comments start with a semicolon and continue to the end of the line, which makes this production syntactically invalid.
I beleive you want the following instead:
dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255
§4.5:
This isn't a sentence. Perhaps insert "this is" before "an array"?
§5.2:
This "SHOULD" makes it necessary to include GZIP as a normative reference. I believe the correct reference here is RFC 1952. While it is Informational, it is already in the downref registry, which saves us a lot of headache.
§5.4:
Offers it where?
§6.4:
Please also cite RFC 6713 Section 4.
Please replace "n/a" with "first two bytes are 0x1f, 0x8b."
§6.5:
This table omits a column for the defining document and/or party to contact, which is usually present for "Expert Review" registries. Is that intentional?
Appendix B:
Please use IPv6 or a mix of IPv4 and IPv6 in your example. See https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for further guidance.
Please select addresses from the ranges reserved by RFC 3849 (and RFC 5737, if necessary), rather than the allocated addresses (owned by Yahoo, Alisoft, and Windstream) and private-use addresses currently in the example.