是否可以建议对 RFC 进行更新？
Is it possible to suggest an update to RFC?
第 4 节，第 34 页：
If the message uses the media type "multipart/byteranges", and the
ransfer-length is not otherwise specified, then this self-
^
should be transfer instead?
elimiting media type defines the transfer-length. This media type
UST NOT be used unless the sender knows that the recipient can arse
^ ^
should be MUST? should be parse? arse means ass as far as I know
it; the presence in a request of a Range header with ultiple byte-
^
should be multiple?
range specifiers from a 1.1 client implies that the lient can parse
^
should be client?
multipart/byteranges responses.
可能有 5 个错别字，我想知道如何建议更新？无法按原样进行注册，因为您在 ietf.org 的帐户应该由... 所谓的管理员审核。
P. S. 我知道，RFC 不应该经常更新，这些 "issues" 并不重要，但同样，这是一个基本的东西。越理想越好。
是 been noticed before and reported，响应是
Unfortunately, we can't update the document, as published RFCs don't
change. This was already reported and verified as an error
(http://www.rfc-editor.org/errata_search.php?rfc=2616&eid=652).
确实是这样。
rfc-editor.org 上的常见问题解答有 an entry for "How can I correct an error in a published RFC?":
You cannot! Once an RFC is published, it cannot be changed. The RFCs form an archival series. If the bug represents a change of content, a revised RFC can be written that obsoletes the one in error. For both technical and editorial errors, the RFC Editor provides a list of errata for published RFCs. Use the RFC Errata page to look up errata by RFC number or view the complete list. Also, search results from the RFC search page include hyperlinks to any corresponding errata entries. To report an error in an RFC, please use the form available from the RFC Errata page (see How to Report Errata for details).
通常，像这样的印刷错误被列为勘误表，并在下次因其他原因重写 RFC 时得到更正。在这种情况下 两者 都已经发生了：
- The Errata page for RFC 2616 包含此 "Editorial" 更正。
- RFC 已被从 RFC 7230 开始的一系列更详细的 RFC 淘汰。从简短的搜索来看，似乎没有与该段落直接对应的部分，但如果有，无疑会更正拼写错误。
第 4 节，第 34 页：
If the message uses the media type "multipart/byteranges", and the
ransfer-length is not otherwise specified, then this self-
^
should be transfer instead?
elimiting media type defines the transfer-length. This media type
UST NOT be used unless the sender knows that the recipient can arse
^ ^
should be MUST? should be parse? arse means ass as far as I know
it; the presence in a request of a Range header with ultiple byte-
^
should be multiple?
range specifiers from a 1.1 client implies that the lient can parse
^
should be client?
multipart/byteranges responses.
可能有 5 个错别字，我想知道如何建议更新？无法按原样进行注册，因为您在 ietf.org 的帐户应该由... 所谓的管理员审核。
P. S. 我知道，RFC 不应该经常更新，这些 "issues" 并不重要，但同样，这是一个基本的东西。越理想越好。
是 been noticed before and reported，响应是
Unfortunately, we can't update the document, as published RFCs don't change. This was already reported and verified as an error (http://www.rfc-editor.org/errata_search.php?rfc=2616&eid=652).
确实是这样。
rfc-editor.org 上的常见问题解答有 an entry for "How can I correct an error in a published RFC?":
You cannot! Once an RFC is published, it cannot be changed. The RFCs form an archival series. If the bug represents a change of content, a revised RFC can be written that obsoletes the one in error. For both technical and editorial errors, the RFC Editor provides a list of errata for published RFCs. Use the RFC Errata page to look up errata by RFC number or view the complete list. Also, search results from the RFC search page include hyperlinks to any corresponding errata entries. To report an error in an RFC, please use the form available from the RFC Errata page (see How to Report Errata for details).
通常，像这样的印刷错误被列为勘误表，并在下次因其他原因重写 RFC 时得到更正。在这种情况下 两者 都已经发生了：
- The Errata page for RFC 2616 包含此 "Editorial" 更正。
- RFC 已被从 RFC 7230 开始的一系列更详细的 RFC 淘汰。从简短的搜索来看，似乎没有与该段落直接对应的部分，但如果有，无疑会更正拼写错误。