The Message Session Relay Protocol (MSRP)
draft-ietf-simple-message-sessions-19

[Ballot discuss]
draft-ietf-simple-msrp-relays-08:

  Section 3 includes a discussion of TLS, and it points to section 9.2
  for many TLS processing details.  The relay is acting as the TLS
  server, and it always has a certificate.  Will the TLS client ever
  have a certificate for TLS client authentication?  The document
  does not seem to prohibit it.  Therefore, I expected section 9.2 to
  tell the relay what name to expect in the certificate.

[Ballot discuss]
MSRP-relays:

Section 8, second paragraph. I think this paragraph and the possibility to not use port numbers in the URI is a direct violation of the base specification which states that port number always will be included. This seems to have potential for creating interoperability issues.

[Ballot discuss]
draft-ietf-simple-msrp-relays-08:

  Section 3 includes a discussion of TLS.  What name matching is
  performed on the relay's certificate?  When client authentication
  is used, what name matching is performed on the client's certificate?
  This could be done with a pointer to section 9.2 if that text is
  expanded to handle optional mutual authentication.

  The discussion in section 3 or the discussion in section 9.2 (or
  both) need to include a normative reference to RFC 3280 regarding
  certificate validation.

[Ballot comment]
Base spec:


draft-ietf-simple-msrp-relays:
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.

[Ballot comment]
Base spec:


draft-ietf-simple-msrp-relays:
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 maintain 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.

[Ballot discuss]
Section 8.6:
The ABNF definition of accept-types SDP attribute is not providing possibility to include the media type parameters. That prevents indication of further information about the media type allowed. An issue with introducing this is that syntax of the parameter and their values. Have this been discussed?

Section 15.2:

This list is missing some headers defined in this document, like Message-ID.


MSRP-relays:

Section 8, second paragraph. I think this paragraph and the possibility to not use port numbers in the URI is a direct violation of the base specification which states that port number always will be included. This seems to have potential for creating interoperability issues.

[Ballot comment]
Base spec:

Section 7.1:

At what scope should the transaction ID be unique? Is it host unique, session unique?

Section 7.1, second last paragraph before 7.1.1:

It seems to me that this paragraph is a repetition of earlier stated text in slight variation.

Section 8, third paragraph:
"An MSRP media-line (that is, a media-line proposing MSRP) in the
  session description is accompanied by a mandatory "path" attribute."

I think RFC 2119 language would make sense instead of "mandatory" in the above sentence. "REQUIRED" seems suitable.

I do react to the usage of MIME everywhere in the text. In most cases it seems that the usage of "media type" would be more correct in this specification.

Section 9, ABNF definition for "gen-param":
How much consideration was put into this definition of the parameter syntax. Have it considered the most likely media formats, including audio files etc?


draft-ietf-simple-msrp-relays:
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 maintain 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.

[Ballot discuss]
Section 7.1.1:

"When an endpoint has a message to deliver, it first generates a new
  Message-ID.  This ID MUST be globally unique."

It is very difficult to create something that is globally unique in a strict sense. I don't think I know how to accomplish to do that without a registration authority that hands part of a namespace. So I think there needs to be change of wording to indicate what level of uniqness that really is expected here.

I have a similar objection on the MSRP URIs session ID part. There should be formal requirements on the randomness inserted into the URI by the generating party. Otherwise the security properties of this solution are unknown.

Section 8.6:
The ABNF definition of accept-types SDP attribute is not providing possibility to include the media type parameters. That prevents indication of further information about the media type allowed. An issue with introducing this is that syntax of the parameter and their values. Have this been discussed?

Section 9:
ABNF reference to obsolete RFC, please update to meet RFC 4234.

Section 15.2:

This list is missing some headers defined in this document, like Message-ID.

Section 15.4:
The IANA port registration request is insufficently specified. The exact range desired to receive a value from should be specified.

Section 15.5:
URI registration is not using the mandatory template from RFC 4395.

MSRP-relays:

Section 8, second paragraph. I think this paragraph and the possibility to not use port numbers in the URI is a direct violation of the base specification which states that port number always will be included. This seems to have potential for creating interoperability issues.

[Ballot discuss]
I'm afraid that the long time these were in process means they were caught by an update in the URI procedures.  They now need to follow the procedures in RFC 4395 and to complete the
template there for a "permanent" registration.  Given that this protocol has been discussed within the IETF, the comment period may be shortened from the 4 weeks if there is early positive feedback.

I believe it would also be valuable to consider a statement on what the session-id length
and randomness properties are.

[Ballot discuss]
First a more discussier kind of discuss.

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.

Section 7.1.1:

"When an endpoint has a message to deliver, it first generates a new
  Message-ID.  This ID MUST be globally unique."

It is very difficult to create something that is globally unique in a strict sense. I don't think I know how to accomplish to do that without a registration authority that hands part of a namespace. So I think there needs to be change of wording to indicate what level of uniqness that really is expected here.

I have a similar objection on the MSRP URIs session ID part. There should be formal requirements on the randomness inserted into the URI by the generating party. Otherwise the security properties of this solution are unknown.

Section 8.6:
The ABNF definition of accept-types SDP attribute is not providing possibility to include the media type parameters. That prevents indication of further information about the media type allowed. An issue with introducing this is that syntax of the parameter and their values. Have this been discussed?

Section 9:
ABNF reference to obsolete RFC, please update to meet RFC 4234.

Section 15.2:

This list is missing some headers defined in this document, like Message-ID.

Section 15.4:
The IANA port registration request is insufficently specified. The exact range desired to receive a value from should be specified.

Section 15.5:
URI registration is not using the mandatory template from RFC 4395.

MSRP-relays:

Section 8, second paragraph. I think this paragraph and the possibility to not use port numbers in the URI is a direct violation of the base specification which states that port number always will be included. This seems to have potential for creating interoperability issues.

[Ballot comment]
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...

[Ballot comment]
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"?

[Ballot comment]
draft-ietf-simple-message-sessions-15:

  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/


  draft-ietf-simple-msrp-relays-08:

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

  s/crypto/cryptographic mechanisms/

[Ballot discuss]
draft-ietf-simple-message-sessions-15:

  Section 5.4 says:
  >
  > ... certificate MUST be valid ...
  >
  A normative reference to RFC 3280 is needed here.

  Section 5.4 goes on to discuss mutual authentication with TLS.  It
  tells that the server's SubjectAltName MUST match the hostname
  part of the URL, which is fine.  What name matching is performed on
  the client's certificate?

  In section 5.4 and section 14:
  s/certificate authority/certification authority/

  In section 14.1:
  s/certificate authorities/certification authorities/

  Section 14.2 requires SHA-1 for digital signatures.  SHA-1 is
  weaker than expected, and many groups are transitioning to SHA-256.
  At a minimum, support for SHA-256 is needed.
 
  Section 14.2 requires RSA.  I assume this is for both key management
  and digital signatures.  Implementations MUST support keys of 1024
  bits.  Implementations SHOULD support keys of 2048 bits or more.


  draft-ietf-simple-msrp-relays-08:

  Section 3 includes a discussion of TLS.  What name matching is
  performed on the relay's certificate?  When client authentication
  is used, what name matching is performed on the client's certificate?
  This could be done with a pointer to section 9.2 if that text is
  expanded to handle optional mutual authentication.

  The discussion in section 3 or the discussion in section 9.2 (or
  both) need to include a normative reference to RFC 3280 regarding
  certificate validation.

[Ballot discuss]
I'm afraid that the long time these were in process means they were caught by an update in the URI procedures.  They now need to follow the procedures in RFC 4395 and to complete the
template there for a "permanent" registration.  Given that this protocol has been discussed within the IETF, the comment period may be shortened from the 4 weeks if there is early positive feedback.

I believe it would also be valuable to consider a statement on what the sender-id length
and randomness properties are.

[Ballot discuss]
Section 7.1.1:

"When an endpoint has a message to deliver, it first generates a new
  Message-ID.  This ID MUST be globally unique."

It is very difficult to create something that is globally unique in a strict sense. I don't think I know how to accomplish to do that without a registration authority that hands part of a namespace. So I think there needs to be change of wording to indicate what level of uniqness that really is expected here.

I have a similar objection on the MSRP URIs session ID part. There should be formal requirements on the randomness inserted into the URI by the generating party. Otherwise the security properties of this solution are unknown.

Section 8.6:
The ABNF definition of accept-types SDP attribute is not providing possibility to include the media type parameters. That prevents indication of further information about the media type allowed. An issue with introducing this is that syntax of the parameter and their values. Have this been discussed?

Section 9:
ABNF reference to obsolete RFC, please update to meet RFC 4234.

Section 15.2:

This list is missing some headers defined in this document, like Message-ID.

Section 15.4:
The IANA port registration request is insufficently specified. The exact range desired to receive a value from should be specified.

Section 15.5:
URI registration is not using the mandatory template from RFC 4395.

MSRP-relays:

Section 8, second paragraph. I think this paragraph and the possibility to not use port numbers in the URI is a direct violation of the base specification which states that port number always will be included. This seems to have potential for creating interoperability issues.

[Ballot comment]
Base spec:

Section 7.1:

At what scope should the transaction ID be unique? Is it host unique, session unique?

Section 7.1, second last paragraph before 7.1.1:

It seems to me that this paragraph is a repetition of earlier stated text in slight variation.

Section 8, third paragraph:
"An MSRP media-line (that is, a media-line proposing MSRP) in the
  session description is accompanied by a mandatory "path" attribute."

I think RFC 2119 language would make sense instead of "mandatory" in the above sentence. "REQUIRED" seems suitable.

I do react to the usage of MIME everywhere in the text. In most cases it seems that the usage of "media type" would be more correct in this specification.

Section 9, ABNF definition for "gen-param":
How much consideration was put into this definition of the parameter syntax. Have it considered the most likely media formats, including audio files etc?


draft-ietf-simple-msrp-relays:
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.

[Ballot discuss]
Section 7.1.1:

"When an endpoint has a message to deliver, it first generates a new
  Message-ID.  This ID MUST be globally unique."

It is very difficult to create something that is globally unique in a strict sense. I don't think I know how to accomplish to do that without a registration authority that hands part of a namespace. So I think there needs to be change of wording to indicate what level of uniqness that really is expected here.

I have a similar objection on the MSRP URIs session ID part. There should be formal requirements on the randomness inserted into the URI by the generating party. Otherwise the security properties of this solution are unknown.

Section 8.6:
The ABNF definition of accept-types SDP attribute is not providing possibility to include the media type parameters. That prevents indication of further information about the media type allowed. An issue with introducing this is that syntax of the parameter and their values. Have this been discussed?

Section 9:
ABNF reference to obsolete RFC, please update to meet RFC 4234.

Section 15.2:

This list is missing some headers defined in this document, like Message-ID.

Section 15.4:
The IANA port registration request is insufficently specified. The exact range desired to receive a value from should be specified.

Section 15.5:
URI registration is not using the mandatory template from RFC 4395.

[Ballot comment]
Base spec:

Section 7.1:

At what scope should the transaction ID be unique? Is it host unique, session unique?

Section 7.1, second last paragraph before 7.1.1:

It seems to me that this paragraph is a repetition of earlier stated text in slight variation.

Section 8, third paragraph:
"An MSRP media-line (that is, a media-line proposing MSRP) in the
  session description is accompanied by a mandatory "path" attribute."

I think RFC 2119 language would make sense instead of "mandatory" in the above sentence. "REQUIRED" seems suitable.

I do react to the usage of MIME everywhere in the text. In most cases it seems that the usage of "media type" would be more correct in this specification.

Section 9, ABNF definition for "gen-param":
How much consideration was put into this definition of the parameter syntax. Have it considered the most likely media formats, including audio files etc?

[Ballot comment]
Base spec:

Section 7.1:

At what scope should the transaction ID be unique? Is it host unique, session unique?

Section 7.1, second last paragraph before 7.1.1:

It seems to me that this paragraph is a repetition of earlier stated text in slight variation.

Section 8, third paragraph:
"An MSRP media-line (that is, a media-line proposing MSRP) in the
  session description is accompanied by a mandatory "path" attribute."

I think RFC 2119 language would make sense instead of "mandatory" in the above sentence. "REQUIRED" seems suitable.

I do react to the usage of MIME everywhere in the text. In most cases it seems that the usage of "media type" would be more correct in this specification.

Section 9, ABNF definition for "gen-param":
How much consideration was put into this definition of the parameter syntax. Have it considered the most likely media formats, including audio files etc?

[Ballot discuss]
Section 7.1.1:

"When an endpoint has a message to deliver, it first generates a new
  Message-ID.  This ID MUST be globally unique."

It is very difficult to create something that is globally unique in a strict sense. I don't think I know how to accomplish to do that without a registration authority that hands part of a namespace. So I think there needs to be change of wording to indicate what level of uniqness that really is expected here.

I have a similar objection on the MSRP URIs session ID part. There should be formal requirements on the randomness inserted into the URI by the generating party. Otherwise the security properties of this solution are unknown.

Section 8.6:
The ABNF definition of accept-types SDP attribute is not providing possibility to include the media type parameters. That prevents indication of further information about the media type allowed. An issue with introducing this is that syntax of the parameter and their values. Have this been discussed?

Section 9:
ABNF reference to obsolete RFC, please update to meet RFC 4234.

[Ballot comment]
Base spec:

Section 7.1:

At what scope should the transaction ID be unique? Is it host unique, session unique?

Section 7.1, second last paragraph before 7.1.1:

It seems to me that this paragraph is a repetition of earlier stated text in slight variation.

Section 8, third paragraph:
"An MSRP media-line (that is, a media-line proposing MSRP) in the
  session description is accompanied by a mandatory "path" attribute."

I think RFC 2119 language would make sense instead of "mandatory" in the above sentence. "REQUIRED" seems suitable.

I do react to the usage of MIME everywhere in the text. In most cases it seems that the usage of "media type" would be more correct in this specification.

[Ballot discuss]
Section 7.1.1:

"When an endpoint has a message to deliver, it first generates a new
  Message-ID.  This ID MUST be globally unique."

It is very difficult to create something that is globally unique in a strict sense. I don't think I know how to accomplish to do that without a registration authority that hands part of a namespace. So I think there needs to be change of wording to indicate what level of uniqness that really is expected here.

[Ballot comment]
Section 7.1:

At what scope should the transaction ID be unique? Is it host unique, session unique?

Section 7.1, second last paragraph before 7.1.1:

It seems to me that this paragraph is a repetition of earlier stated text in slight variation.

[Ballot comment]
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.

[Ballot discuss]
This is a DISCUSS for now because I'm not entirely sure that some of these aren't important (support for IDNs, session resumption and byte-range requirements).  I expect that a couple answers, if reassuring, ought to allow me to quickly clear the DISCUSS and leave everything else as comments for the discretion of the authors and shepherd to deal with as they please.

General

1.  Reports and sessions: I see that SEND requests might result in reports, which are considered separate messages.  MUST a report be sent in the same session?  Alternatively, MUST the report sender attempt to start a new session, if necessary creating a new connection?  I asked myself this question early on, and I believe the answer is indirectly given in related text in various places later on in the document:
- The receiver of a report is warned (7.3.2) to be able to handle reports received out of the session where the send request was originally sent
- The text for failure reports (7.1.4) says a little more than the text for success reports, but it doesn't address whether it's desirable to create a new session to send a report, or if a new session needs to be created for other reasons, is it desirable to send the report on it. 
If a MSRP endpoint has nothing to say but owes a success or failure report and has no active session, SHOULD or MUST it open a new session? 

2.  I don't yet see how multiple proxies (or any) are indicated in the path.  I see no examples, nor do I see what TO address the sending client is supposed to use when it talks to the proxy, presumably by picking the first address in the path. If this is covered instead in draft-simple-msrp-relays.txt, then shouldn't that reference be Normative?

Section 5.1

Shouldn't the chunking example have the first Byte-Range as
Byte-Range: 1-*/8

As is, the example has "1-4/8" which would imply that the request is *not* interruptible and terminating after four bytes as shown is legal, but not an example of interrupting the request.  If you intended to show interrupting the request as opposed to planned-ahead chunking, that is, which the text seems to imply.

Section 5.4

Paragraph 5 requires that the received certificate be signed by an acceptable certificate authority when NOT in TLS peer-to-peer mode.    That means that for any mode other than peer-to-peer, self-signed certs are forbidden.
- What other modes are there?  MSRP with a relay/proxy, I presume, and if that's the only one, why not just say that self-signed certs MUST NOT be used with relays?  The converse is more confusing to read.
- Why would self-signed certs be forbidden from relays?

Later on in the same section, I see the requirement "endpoints SHOULD NOT split chunks between sessions under non-failure circumstances."  Is the only failure circumstance loss of the underlying connection?  If so then this requirement should read "endpoints SHOULD NOT split chunks between sessions except in the case where the underlying connection was lost and [the same?] sessions recreated." 

If there are other failure circumstances, are they insufficiently documented, or am I suffering from a failure of imagination?

Section 6.1: URL comparison

Can hostnames be IDNs? Should RFC3491 be referenced? Ted would know better than me...


Section 7.1.3, a nit

This nit is esoteric enough that I must point it out to prove that my mom was an English teacher and I inherited her finickiness  :) .  Para. 2 has "Alternately, it MAY generate incremental success REPORTs..."  I'm pretty sure the word you want is "Alternatively", meaning "As an alternative to the approach just suggested".  The sentence as is means "In turn with doing the action just mentioned, it MAY generate incremental success reports..."


Section 7.1.3

You might want to mention that the "implementation-defined comment phrase" is intended for debugging and trouble-shooting purposes, NOT for display to the user.  Otherwise we'll start to talk about i18n...

Section 11.1

Shouldn't the SEND examples have Byte-Range headers?  I thought from earlier text that this header was REQUIRED.

[Ballot comment]
draft-ietf-simple-message-sessions-15

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 (http://rtg.ietf.org/~fenner/abnf.cgi)


--------------------------------------------------------------
draft-ietf-simple-msrp-relays-08

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 (http://rtg.ietf.org/~fenner/abnf.cgi)


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/?

IANA Last Call Commenet:

Upon approval of this document, the IANA will create a new registry named
"Message Session Relay Protocol (MSRP) Registry"
with the following intial contents. The registry will be located at TBD.



Methods specified:
SEND - [RFC-simple-message-sessions]
REPORT - [RFC-simple-message-sessions]

MSRP Header Fields
To-Path - [RFC-simple-message-sessions]
From-Path - [RFC-simple-message-sessions
Success-Report - [RFC-simple-message-sessions]
Failure-Report - [RFC-simple-message-sessions]
Byte-Range - [RFC-simple-message-sessions]
Status - [RFC-simple-message-sessions]

Status-codes Defined: (see section 10)

Code NAME REF
200 Success [RFC-simple-message-sessions]
400 Unintelligble [RFC-simple-message-sessions]
403 Action-not-allowed [RFC-simple-message-sessions]
408 Transaction-did-not-complete-in-allotted-time [RFC-simple-message-
sessions]
413 Stop-sending-message [RFC-simple-message-sessions]
415 MIME-not-understood [RFC-simple-message-sessions]
423 Parameter-out-of-bounds [RFC-simple-message-sessions]
481 Session-does-not-exist [RFC-simple-message-sessions]
501 Request-method-not-understood [RFC-simple-message-sessions]
506 Wrong-session [RFC-simple-message-sessions]






Uppon approval of this document IANA will register a port for use by MSRP.




Upon approval of this document, the IANA will make the following assignments
in the "Permanent URI Schemes" registry located at http://www.iana.org/
assignments/uri-schemes.html

msrp Message Session Relay Protocol [RFC-simple-message-sessions]
msrps Message Session Relay Protocol Secure [RFC-simple-message-sessions]





Upon approval of this document, the IANA will make the following assignments
in the "Session Description Protocol (SDP) Parameters" registry located at
http://www.iana.org/assignments/sdp-parameters

Type SDP Name Reference
---- ------------------ ---------
proto TCP/MSRP [RFC-simple-message-sessions]
TCP/TLS/MSRP [RFC-simple-message-sessions]




Upon approval of this document, the IANA will make the following assignments
in the "Session Description Protocol (SDP) Parameters" registry located at
http://www.iana.org/assignments/sdp-parameters
Type SDP Name Reference
---- ------------------ ---------
att-field (media level only)
accept-types [RFC-simple-message-sessions]
accept-wrapped-types [RFC-simple-message-sessions]
max-size [RFC-simple-message-sessions]
path [RFC-simple-message-sessions]

We understand the above to be the complete list of IANA Actions for this
document.

PROTO Write-up

1.a) The chairs have reviewed this version of the ID and
ask that the IESG consider it for publication.

1.b) This document has been sufficiently reviewed by the
working group. It has also been reviewed by the mmusic
WG chairs focusing on the SDP extension. Sam Harman,
the Security AD, has also reviewed the ID. His comments
are incorporated in this version of the AD.

1.c) The chairs do not believe further cross-area review
is needed. Jon Peterson, Transport AD contributed
substantively to discussions around the semantics and
security of the information this protocol is meant to
convey. Also, as already mentioned, Sam Hartman has
reviewed the ID.

1.d) There are no specific concerns in this document.

1.e) This document reflects a strong consensus position from
the working group. The working group has been working on this
draft for years and have arrived at this after several re-starts.

1.f) There have been no indications of intent to appeal.

1.g) This document adheres to ID-nits.

1.h) The document appropriately splits references into
Informative/Normative.

1.i) Announcement Writeup

Technical Summary

A series of related instant messages between two or more parties can
be viewed as part of a "message session", that is, a conversational
exchange of messages with a definite beginning and end. This is in
contrast to individual messages each sent independently. Messaging
schemes that track only individual messages can be described as
"page-mode" messaging, whereas messaging that is part of a "session"
with a definite start and end is called "session-mode" messaging.

This document describes the Message Session Relay Protocol, a
protocol for transmitting a series of related instant messages in the
context of a session.

Working Group Summary

This document reflects WG consensus. It defines the Message Session
Relay Protocol (MSRP). The working group has been working on this
draft for years and have arrived at this after several re-starts.

Protocol Quality

Hisham Khartabil was the PROTO shepherd for this document.