already suffixes every header with a CRLF. The result is that the extension headers are followed by 2 CRLFs, introducing empty lines inside the header segment. This appears to be unintended, since none of the other headers have a terminating CRLF in their production rules, only the ext-header.

line, and a flag character. If a body is present, the end-line MUST
be preceded by a CRLF that is not part of the body. If the chunk
represents the data that forms the end of the complete message, the
flag value MUST be a "$". If the sender is aborting an incomplete
message, and intends to send no further chunks in that message, the
flag MUST be a "#". Otherwise, the flag MUST be a "+".
If the request contains a body, the sender MUST ensure that the end-
line (seven hyphens, the transaction identifier, and a continuation
flag) is not present in the body. If the end-line is present in the

It should say:

line, and a flag character. If a body is present, the end-line MUST
be preceded by a CRLF that is not part of the body. If the chunk
represents the data that forms the end of the complete message, the
flag value MUST be a "$". If the sender is aborting an incomplete
message, and intends to send no further chunks in that message, the
flag MUST be a "#". Otherwise, the flag MUST be a "+".
If the request contains a body, the sender MUST ensure that the end-
line (seven hyphens, the transaction identifier, and a continuation
flag) is not present in the body. A receiver detecting an end-line
present in the body preceded by a non-empty sequence other than CRLF
SHOULD terminate the session. If the end-line is present in the

Notes:

The way the text is written leaves unspecified how a receiver should handle the situation where it encounters an end-line within the body that's preceded by something OTHER than CRLF.

Obviously, this indicates the sender is not complying with this RFC, but what should the receiver do?

Should the receiver terminate the connection? Or just proceed giving no special interpretation to the end-line, which would actually work just fine?

The suggested change reflects the first choice. If the second choice were made, the change could be:

If the request contains a body, the sender MUST ensure that the
end-line (seven hyphens, the transaction identifier, and a continuation
flag) neither appears at the beginning of the body nor is not present
in the body preceded by CRLF. An end-line MAY appear in the body if
preceded in the body by any non-empty sequence other than CRLF.

This would force the interpretation that an end-line not preceded by CRLF has no special significance.

Note on Terminology:
To help avoid the terminological issues observed in the companion
document, RFC 4976, and reduce the likelihood of similar issues in
future derived work, it would perhaps have been useful to subtly
change the ABNF in Section 9 (and all related references in the prose),
replacing three rule names:
<headers> --> <hfields>
<header> --> <hfield>
<ext-header> --> <ext-hfield>

<<< at the end of the (indented) second paragraph >>
[...] For example, an endpoint could concatenate an instance
identifier such as a MAC address, its idea of the number of
seconds since the epoch, a process ID, and a monotonically
increasing 16-bit integer, all base-64 encoded. Alternately, an
endpoint without an on-board clock could simply use a 64-bit
random number.

It should say:

[...] For example, an endpoint could concatenate an instance
identifier such as a MAC address, its idea of the number of
seconds since the epoch, a process ID, and a monotonically
increasing 16-bit integer, all base-64 encoded. Alternately, an
endpoint without an on-board clock could simply use a 64-bit
| random number and base-64 encode it.

Notes:

Clarification; otherwise, "Alternately" could be grossly misunderstood
to indicate a direct alternative for the header field value.

| This specification establishes the header field-Field sub-registry
under MSRP Parameters. New parameters in this sub-registry must be
published in an RFC (either as an IETF submission or RFC Editor
submission). [...]

It should say:

| This specification establishes the Header Field sub-registry under
MSRP Parameters. New parameters in this sub-registry must be
published in an RFC (either as an IETF submission or RFC Editor
submission). [...]