Section 4, page 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.
There are probably 5 typos, and I wonder how can I suggest an update? Registration is not available as it is, because your account at ietf.org should be reviewed by... so-called administrator.
P. S. I know, RFC shouldn't be updated often, and these "issues" are not crucial, but again, this is a fundamental thing. It should be as ideal as possible.
It's been noticed before and reported, the response was
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).
Arse it indeed.