The Message Session Relay Protocol (MSRP)
RFC 4975

Note: This ballot was opened for revision 19 and is now closed.

(Jon Peterson) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Brian Carpenter) No Objection

(Lisa Dusseault) (was Discuss) No Objection

(Lars Eggert) No Objection

Comment (2006-08-28 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

Section 2048, paragraph 0:
>    To ensure fairness over a connection, senders MUST NOT send chunks
>    with a body larger than 2048 octets unless they are prepared to
>    interrupt them (meaning that any chunk with a body of greater than
>    2048 octets will have a "*" character in the range-end field).  A
>    sender can use one of the following two strategies to satisfy this
>    requirement.  The sender is STRONGLY RECOMMENDED to send messages
>    larger than 2048 octets using as few chunks as possible, interrupting
>    chunks (at least 2048 octets long) only when other traffic is waiting
>    to use the same connection.  Alternatively, the sender MAY simply
>    send chunks in 2048 octet increments until the final chunk.  Note
>    that the former strategy results in markedly more efficient use of
>    the connection.  All MSRP nodes MUST be able to receive chunks of any
>    size from zero octets to the maximum number of octets they can
>    receive for a complete message.  Senders SHOULD NOT break messages
>    into chunks smaller than 2048 octets, except for the final chunk of a
>    complete message.

  Does anyone know whether SIP stacks usually leave the TCP Nagle
  algorithm enabled? I'd hope that they do, but some apps turn Nagle
  off. With Nagle off, specific message sizes and path MTUs can lead to
  many small packets being sent, which is inefficient.

Section 8.5., paragraph 0:
>    8.5.  Connection Negotiation

  Remove before publication?

Section 9., paragraph 0:
>    9.  Formal Syntax

  BNF doesn't validate (


Section 2., paragraph 1:
>    There are a number of scenarios in which using a separate protocol
>    for bulk messaging is desirable.  In particular, their is a need to

  Nit: s/their/there/

Section 3., paragraph 4:
>    All other requests are sent end-to-end.

  s/are sent end-to-end/are acknowledged end-to-end/?

Section 6.3, paragraph 6:
>    The URL MUST contain at least 64 bits of crypto random material so that it is not

  Nit: s/crypto random/random/?

Section 7., paragraph 0:
>    7.  Formal Syntax

  Nit: Validates, but could be made canonical (

Appendix A., paragraph 4:
>    When a relay starts up it could pick a crypto random 128 bit password (K) and 128

  Nit: s/crypto random/random/?

(Bill Fenner) No Objection

Comment (2006-08-30 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
RFC 3629 eliminated the two longest UTF-8 encodings; I don't know if it's appropriate to just remove them from UTF8-NONASCII, to use the RFC 3629 ABNF (or refer to it), or what.

While it's legal to define a rule with one case and use it with another, it's confusing; I suggest change the "alphanum" references to "ALPHANUM"?

[I don't know what Lars thinks doesn't validate]

I *do not* recommend that anyone change ABNF to match 'Bill's "canonical" output' unless their sense of style matches mine.  "canonical" is in quotes because I just flat out made it up as I went along...

(Ted Hardie) (was Discuss) No Objection

(Sam Hartman) No Objection

Comment (2006-08-29 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I really appreciate all the work that has gone into improving thesen
documents over the years.

(Russ Housley) (was Discuss) No Objection

Comment (2006-08-30)
No email
send info

  s/hop by hop/hop-by-hop/

  s/encrypt and sign/sign and encrypt/

  s/encrypted and signed/signed and encrypted/

  s/Peer to Peer Mode/Peer-to-Peer Mode/


  s/peer to peer/peer-to-peer/

  s/crypto/cryptographic mechanisms/

(David Kessens) No Objection

(Dan Romascanu) No Objection

Comment (2006-08-30 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
There is no referece in any of the two documents to manageability or operational considerations. It would be useful to mention or refer to other documents that show how MSRP will be configured and deployed, if there are any specific status or monitoring information that need to be watched by a network operator, and if the deployment of this technology has any impact on the behavior of the existing network running SIP or SIP entities.

(Mark Townsley) No Objection

Magnus Westerlund (was Discuss) No Objection

Comment (2006-10-30)
No email
send info
Base spec:

I think this document is hard to understand. For example the overview totally skips to explain how relays are tied into the SIP and SDP signalling. Thus leaving me confused until I arrived at the end of the document. I wished it was much clearer written in this regards. However it is possible to figure out so thus no discuss.

Discusses I will not insist one but is worth considering in the future when doing updates or extensions:

The addition of a header containing a hash or checksum over the complete object transfered using one or more SEND. The motivation I see for actually having such a feature is two fold. First protect against errors that escape being detected by the TCP checksum. We all know that the Internet checksum is quite weak and certain error patterns very hard to detect. The second one is the fragmentation mechanism built into MSRP. There is no way for the receiver to check that the object has been correctly received and reassembled. Having a strong checksum/hash over the complete transfered object would allow for detection by the receiving end of any of these cases. 

Has this been discussed in the WG? I know this is late for adding such a feature, but it seems to be a real weakness of MSRP.

(Cullen Jennings) Recuse