Multi-party Chat Using the Message Session Relay Protocol (MSRP)
draft-ietf-simple-chat-18

[Ballot discuss]
Updated based on -17:

1)
This question isn't answered to some extend:
How should an MSRP node react to them, e.g., how to deal with nodes that are constantly overloaded by receiving messages?
The current text assumes that this is an temporary issue, but what it is not temporarily? E.g., the particular interface is down? A link to any other place in the document describing the desired behavior would suffice .

2) Picking up this point below (also related to Wes' comments)
" In order to  inform the user of the congestion, the MSRP switch can send a regular MSRP message indicating the user that some messages are discarded due to network congestion."

In what direction do you send this message? Back to the originator of the message or down the congested path? Please clarify this in the text.

Further: How can a piece of software learn from the chat messages (e.g., an error code or similar) that congestion is occurring?

[Ballot discuss]
-17 resolves my discusses except for #2

1. cleared

2. p13, SHOULD start the distribution process as soon as the
first chunk is received is a potential DoS vector. How is that
mitigated? I think adding a sentence or reference to the
security considerations would be enough here, e.g. saying that
servers SHOULD implement some sanity checking in such cases.
MSRP's security considerations say it can't be used as a DoS
amplifier, but I guess this can based on the above.  (This is
similar to, but not the same as, Adrian's last discuss point.)

In -17 I do see the pointer from p15 (was p13) to the
security considerations, but I don't see a warning about
DoS in section 11, here's a suggestion:

"A chat room is by its nature a potential Denial-of-Service
(DoS) accellerator as it takes a message from one entity and
sends that to many. Implementers of both UAs and switches
need to carefully consider the set of anti-DoS measures
that are appropriate for this application and switch
implementations in particular ought to include appropriate
anti-DoS features. The details of what is appropriate will
vary over time and will also depend on the specific needs
of the implementation and so cannot be specified here."

3. cleared

4. Cleared. This AD is sometimes dim:-)

5. cleared

[Ballot comment]
I was very much on the fence about whether to ballot ABSTAIN or NO OBJECTION.  It's clear that a lot has happened in the eight and a half years since this larva hatched, and the five since it pupated as a working group document.  I don't think the result is a butterfly; rather, it's been overtaken by events, and I'm not at all sure that it's best for the Internet to standardize this.  There are lots of instant messaging systems out there, and picking yet another about which to say, "This is a Proposed Standard," is questionable, I think.  In the end, because this isn't defining the IM system from the start, but is layering chat-room function on top of what's already there, and because it's been implemented, I've decided to go with NO OBJECTION.

To be clear: None of that internal debate I was having with myself had anything to do with the quality of the document.  It's a fine document, well written, and I appreciate the time spent on it over the many years.  We frequently have documents that are so long in the making that we don't want to abandon them, and this is only one.  So carry on, and I have no official objection to seeing this finished.

Version -17 addresses the two minor editorial items I had; thanks.

[Ballot discuss]
Section 1 says:

  Similar conferences supporting chat rooms are already available
  today.  For example, Internet Relay Chat (IRC) [RFC2810], Extensible
  Messaging and Presence Protocol (XMPP): Core [RFC6120] based chat
  rooms, and many other proprietary systems provide chat room
  functionality.  Specifying equivalent functionality for MSRP-based
  systems provides competitive features and enables interworking
  between the systems.

I do not think this document enables interworking; at least I don't think there's sufficient information here to justify that claim.  Further, I don't think the motivation given here suffices to do yet-another-messaging-protocol, simply because N others already exist.  Particularly, with regards to existing IETF Standards Track protocols, I think there needs to be better motivation for adding yet another.

It might help me clear if there was some description of how this is being used in practice or whether people really are doing interworking.

[Ballot comment]
My comments are related to the congestion avoidance section.  I think it needs to be tweaked somewhat, as the recommendations are not really effective.  However, I don't feel the need to make this a DISCUSS, because in the end, the authors are right that TCP is protecting the network paths ... the only downside to doing things poorly (i.e. using the current recommendations in the document) is suboptimal performance in the application.  So it will be in the WG's best interest to improve this, but it won't cause the Internet to fail.

Section 6.4, in the first paragraph, I think the motivations are misguided.  The issue is not fast or slow paths, but rather the total loading of traffic on the paths from this and other applications.  Also note that the messaging applications do not really send at any "rate", since message flow is highly asynchronous.  I believe that the buffers discussed in this section need to be sized such that nominal bursts of messages can be accommodated arriving asynchronously, and with the understanding the overly large buffers in comparison to the link rate will create excessive delay to be shared by all other messages on that TCP connection due to head-of-line blocking.

The first suggestion of sending messages to let a destination know that it's TCP connection is congested seems to be a bit counter-productive.  It's equivalent to sending emails to someone to inform them that their inbox is full.

Also not that inferring congestion via the length of the TCP send buffer is not quite so easy to do as the document assumes.  First of all, the send buffer's length is not part of the typical TCP API, so you're likely going to need OS-specific ways of accessing this.  Further, all this means is that you have pending data, not that there's actually congestion on the network path which is causing losses.  You could be getting serious congestion and losses without the send buffer growing to the high-water mark defined, or due to a limited advertised receive window, you could be throttled by the receiving application and not losing packets at all inside the network.

[Ballot discuss]
1) REQ-4 and S8: I'm confused by the following in s8:

For example, a participant would like to learn if the
MSRP switch supports private messaging, otherwise, the participant
may send what he believes is a private instant message addressed to a
participant, but since the MSRP switch does not support the functions
specified in this memo, the message gets eventually distributed to
all the participants of the chat room.

Aren't servers required to support private messages?  I get that clients might not support 'em, but based on REQ-4 don't servers have to support 'em?

[Ballot comment]
1) So this is probably a .0001% case (maybe need some more zeros there :), but it might be worth mentioning that clients who use TLS client side certificates with real names in the certificates won't be anonymous to whatever server they connect to.  The name in the certificate might not get used by the MSDP protocol but the server will have the certificate with an actual name in it.

2) s8: Had trouble parsing the following:

In this type of extensions, are must be
taken in the selection of the token to avoid a clash with any of the
tokens previously defined.

[Ballot comment]
5.2:

  The conference focus of a chat room MUST learn the chat room
  capabilities of each participant that joins the chat room.  The
  conference focus MUST inform the MSRP switch of such support in order
  to prevent the MSRP switch from distributing private messages to
  participants who do not support private messaging.

The first MUST is superfluous. Try this instead:

  The conference focus of a chat room MUST inform the MSRP switch of
  the chat room capabilities of each participant that joins the chat
  room in order to prevent the MSRP switch from distributing private
  messages to participants who do not support private messaging.

There are a few other examples of such superfluous uses below, but I'm sure I didn't catch all of them. Please review for places where the 2119 keyword is being used (incorrectly) for a description of the behavior instead of (correctly) for the protocol requirement.
 
6.1:

  The actual instant message
  payload MUST be included as payload of the 'Message/CPIM' wrapper

Silly MUST. Instead: "The payload of the 'Message/CPIM' wrapper will be the actual instant message payload."

  An MSRP switch that uses this fast forwarding procedure MUST
  temporarily store the Message-Id of the MSRP message to correlate the
  different chunks, as well as it MUST temporarily store the list of
  recipients to which the initial chunks were delivered.

Why does the switch have to store the Message-Ids and recipients? Is it so that it can figure out which recipients got which messages? If so, then these are not protocol requirements. In order to accomplish the protocol requirement ("SHOULD forward subsequent chunks only to..."), the switch "will need to" store these things.

  An MSRP endpoint that receives a SEND request from the MSRP switch
  containing a Message/CPIM wrapper SHOULD first inspect the To header
  field of the Message/CPIM wrapper.  If the To header field is set to
  the chat room URI, it should render it as a regular message that has
  been distributed to all the participants in the chat room.  Then the
  MSRP endpoint SHOULD inspect the From header field of the Message/
  CPIM wrapper to identify the sender.

Why SHOULD the endpoint inspect the headers? Again, I suspect that the *inspection* is not the protocol requirement. I'm not even sure I know what is in this paragraph.

6.2:

  Then the MSRP switch MUST inspect the To header field of the Message/
  CPIM wrapper.

Superfluous sentence, let alone superfluous MUST. Delete.

  Then the MSRP switch MUST verify
  that the To header of the Message/CPIM wrapper matches the URI of a
  participant of the chat room.

Same as above.

  Finally, the MSRP switch MUST verify that the recipient supports
  private messages.

Same as above.

  It is RECOMMENDED that the MSRP switch can map a
  URI to two or more MSRP sessions.

It is "RECOMMENDED" that the switch "can" do something? That doesn't make sense.

6.3:

  MSRP switches MUST follow the success report and failure report
  handling described in section 7 of RFC 4975 [RFC4975], complemented
  with the procedures described in this section.  The MSRP switch MUST
  act as an MSRP endpoint receiver of the request according to section
  5.3 of RFC 4975 [RFC4975].

Wouldn't this be better as:

  The MSRP switch is an MSRP endpoint receiver of the report requests
  as described in section 5.3 of 4975 and will follow the report
  handling procedures described in section 7 of 4975, complemented with
  the procedures described in this section.
 
7:

First it says:

  Therefore, if a user joins the
  chat room under the same URI from multiple devices, he or she may
  request the same nickname across all these devices.
 
Then it says:

  This memo specifies the nickname as a string.  The nickname string
  MUST be unambiguous within the scope of the chat room (conference
  instance).

These two statements seem like they are in conflict. I think a bit more explaining is in order. Can I use the same nickname across all devices or can't I?
 
7.1:

  This mitigates the problem of nickname duplication, but it does not
  solve a problem whereby users can choose similar (but different)
  characters to represent two different nicknames.  For example, "BOY"
  and "B0Y" are different nicknames which can mislead users.  The
  former uses the capital letter "O" while the latter uses the number
  zero "0".  In many fonts the letter "O" and the number zero "0" might
  be quite similar, and difficult to be perceived as different
  characters.  Chat rooms MAY provide a mechanism to mitigate
  confusable nicknames.

I don't see how this discussion is really necessary. Whether confusables are an issue at all is a completely implementation specific detail, not a protocol issue.

  In addition to preparing and comparing following the rules above, the
  MSRP switch SHOULD validate that the SIP AOR identifying the user is
  entitled to reserve the nickname.  This may include, e.g., allowing
  that the participant's URI may use the same nickname when the
  participant has joined the chat room from different devices under the
  same URI.
 
The protocol requirement is not to validate that the user is entitled to reserve the nickname. The protocol requirement is that the MSRP switch SHOULD only allow the registration of a duplicate nickname if the same user that is currently using the nickname is making the second request. As written, this is confusing.

  If the MSRP switch is able to accept the suggested nickname to be
  used by this user, the MSRP switch MUST answer the NICKNAME request
  with a 200 response as per regular MSRP procedures.

MUST? No, I think that's a MAY. Why would it be a MUST?

[Ballot discuss]
These should all be very easy discuss points to resolve.

1. 5.2, what is an "anonymous URI"? What kind of anonymity is
being provided here? I think you need at least a reference or
else to get rid of the paragraph or else provide more text
that says how it might work so that a client could implement
it with a reasonable expectation that a server will be ok with
it.

2. p13, SHOULD start the distribution process as soon as the
first chunk is received is a potential DoS vector. How is that
mitigated? I think adding a sentence or reference to the
security considerations would be enough here, e.g. saying that
servers SHOULD implement some sanity checking in such cases.
MSRP's security considerations say it can't be used as a DoS
amplifier, but I guess this can based on the above.  (This is
similar to, but not the same as, Adrian's last discuss point.)

3. Where are the security considerations about unsafe content?
E.g. HTML scripts that are phishing attempts. Again, I think a
reference to some other document or small bit of text is
needed.

4. Cleared. This AD is sometimes dim:-)

5. (Promoted from a comment at the request of an author, so
it gets tracked.)
Everyone sends an 'accept-types' attribute, right?  Is it
clear what happens if an IM containing a CPIM containing a
payload with a MIME type that's not supported everywhere is
sent to all?

[Ballot comment]
- I agree with Adrian's first discuss point about the need to
better reference or describe how policy stuff can be done
here.

- Don't we prefer one protocol for each thing in general, so
why not say that? That is, shouldn't we say somewhere that, in
general, folks ought use XMPP but that this protocol is useful
for SIP-oriented deployments? (Apologies if I've stirred a
hornet's nest but I think we prefer XMPP, based on our own
usage at least.)

- section 1: Saying that this "provides competitive features"
to XMPP seems wrong, I'd suggest deleting that phrase.

- section 1: it wasn't clear to me if "interop" here is being
used just for SIMPLE clients and servers or more broadly to
mean interop with other chat services, in particular XMPP.  I
assume you mean the former.

- section 1: Is the last sentence saying this is a short-term
solution only or that this is something that'll be available
soon? The latter would be fine (if true) but the former would
seem problematic without more warnings for implementers about
when they may need to replace this.

- section 2: it might be good to note explicitly that a
"private" IM is seen by the server and isn't only seen by the
sender and recipient.

- section 3 talks about the "identifier" of a sender or
recipient, but that's not a term defined in section 2. It'd be
better to clarify that I think.

- s4, p10: s/is logged/is logged in/ and do you need to define
what you mean by "logged in" in section 2? (Not sure, its
fairly clear I think, but this is the first time you've said I
can be connected more than once.)


- last para of section 8: Just noting that I expected the
extension to be called "foo.chat" given the reversal of
example.com. Is the text correct?

- Section 8: should you note that implementations cannot
assume anything about similar private extension names because
they won't know which bit is the DNS name and which is the
extension name?  i.e. uk.co.bbc.foo.bar and ie.tcd.foo.bar
don't tell me that both are doing foo.bar (or bar.foo;-)

[Ballot discuss]

These should all be very easy discuss points to resolve.

1. 5.2, what is an "anonymous URI"? What kind of anonymity is
being provided here? I think you need at least a reference or
else to get rid of the paragraph or else provide more text
that says how it might work so that a client could implement
it with a reasonable expectation that a server will be ok with
it.

2. p13, SHOULD start the distribution process as soon as the
first chunk is received is a potential DoS vector. How is that
mitigated? I think adding a sentence or reference to the
security considerations would be enough here, e.g. saying that
servers SHOULD implement some sanity checking in such cases.
MSRP's security considerations say it can't be used as a DoS
amplifier, but I guess this can based on the above.  (This is
similar to, but not the same as, Adrian's last discuss point.)

3. Where are the security considerations about unsafe content?
E.g. HTML scripts that are phishing attempts. Again, I think a
reference to some other document or small bit of text is
needed.

4. Cleared. This AD is sometimes dim:-)

[Ballot comment]
- I agree with Adrian's first discuss point about the need to
better reference or describe how policy stuff can be done
here.

- Don't we prefer one protocol for each thing in general, so
why not say that? That is, shouldn't we say somewhere that, in
general, folks ought use XMPP but that this protocol is useful
for SIP-oriented deployments? (Apologies if I've stirred a
hornet's nest but I think we prefer XMPP, based on our own
usage at least.)

- section 1: Saying that this "provides competitive features"
to XMPP seems wrong, I'd suggest deleting that phrase.

- section 1: it wasn't clear to me if "interop" here is being
used just for SIMPLE clients and servers or more broadly to
mean interop with other chat services, in particular XMPP.  I
assume you mean the former.

- section 1: Is the last sentence saying this is a short-term
solution only or that this is something that'll be available
soon? The latter would be fine (if true) but the former would
seem problematic without more warnings for implementers about
when they may need to replace this.

- section 2: it might be good to note explicitly that a
"private" IM is seen by the server and isn't only seen by the
sender and recipient.

- section 3 talks about the "identifier" of a sender or
recipient, but that's not a term defined in section 2. It'd be
better to clarify that I think.

- s4, p10: s/is logged/is logged in/ and do you need to define
what you mean by "logged in" in section 2? (Not sure, its
fairly clear I think, but this is the first time you've said I
can be connected more than once.)

- Everyone sends an 'accept-types' attribute, right?  Is it
clear what happens if an IM containing a CPIM containing a
payload with a MIME type that's not supported everywhere is
sent to all?

- last para of section 8: Just noting that I expected the
extension to be called "foo.chat" given the reversal of
example.com. Is the text correct?

- Section 8: should you note that implementations cannot
assume anything about similar private extension names because
they won't know which bit is the DNS name and which is the
extension name?  i.e. uk.co.bbc.foo.bar and ie.tcd.foo.bar
don't tell me that both are doing foo.bar (or bar.foo;-)

[Ballot comment]
A small but important matter - my compliments to the document shepherd
for the well-written and comprehensive description of the working
group process and document review for this document, and for the due
diligence I infer on the part of the document shepherd in preparing
the writeup and document for IESG review.

[Ballot discuss]
I have no general concerns with this draft, but one discuss issue:

Section 6.4.  Congestion Avoidance

I am not sure that you are really discussing congestion in the sense of network path congestion (including end hosts), but this is more about overload handling at MSRP nodes IMHO. It is a different level where the congestion can occur, i.e., in the MSRP application. A cause for  congestion at this level can be a congested network path.

The reasons are that there are number of cases why message(s) to a certain MSRP receiver/agent cannot be delivered, e.g., :
- TCP cannot deliver in-time, as the network path or the receiving system are congested

- the particular interface is down

- the IP address used for the TCP connection is just gone

- the DNS resolution for the FQDN in the SIP URI just takes too long

- (as you noted) the sender is sending with a rate that cannot be received by a receiver

- the at other end is overwhelmed with the processing of the messages


How should an MSRP node react to them, e.g., how to deal with nodes that are constantly overloaded by receiving messages?

Did you actually check back with the SIP overload control work?

This said, a section about overload handling is good to have.

[Ballot discuss]
I have no general concerns with this draft, but one discuss issue:

Section 6.4.  Congestion Avoidance

I am not sure that you are really discussing congestion in the sense of network path congestion (including end hosts), but this is more about overload handling at MSRP nodes IMHO. It is a different level where the congestion can occur, i.e., in the MSRP application. A cause for  congestion at this level can be a congested network path.

The reasons are that there are number of cases why message(s) to a certain MSRP receiver/agent cannot be delivered, e.g., :
- TCP cannot deliver in-time, as the network path or the receiving system are congested
- the particular interface is down
- the IP address used for the TCP connection is just gone
- the DNS resolution for the FQDN in the SIP URI just takes too long
- (as you noted) the sender is sending with a rate that cannot be received by a receiver
- the at other end is overwhelmed with the processing of the messages

How should an MSRP node react to them, e.g., how to deal with nodes that are constantly overloaded by receiving messages?

Did you actually check back with the SIP overload control work?

This said, a section about overload handling is good to have.

[Ballot comment]
Section 2., paragraph 8:

>    Recipient:  the destination chat room participant(s).  This defaults
>      to the full conference participant list minus the IM Sender.

  Expand 'IM' on first use.

>    REQ-2:  A recipient of an instant message in a chat room must be able
>            to determine the identifier of the sender of the message.
>            Note that the actual identifier depends on the one which was
>            used by the sender when he or she joined the chat room.

  A complete nuts nit: what if the sender isn't he or she, but
  a sensor? Also interesting in conjunction with Section 6.4, i..e. how to tell such a machine to stop sending?

[Ballot discuss]


These should all be very easy discuss points to resolve.

1. 5.2, what is an "anonymous URI"? What kind of anonymity is
being provided here? I think you need at least a reference or
else to get rid of the paragraph or else provide more text
that says how it might work so that a client could implement
it with a reasonable expectation that a server will be ok with
it.

2. p13, SHOULD start the distribution process as soon as the
first chunk is received is a potential DoS vector. How is that
mitigated? I think adding a sentence or reference to the
security considerations would be enough here, e.g. saying that
servers SHOULD implement some sanity checking in such cases.
MSRP's security considerations say it can't be used as a DoS
amplifier, but I guess this can based on the above.  (This is
similar to, but not the same as, Adrian's last discuss point.)

3. Where are the security considerations about unsafe content?
E.g. HTML scripts that are phishing attempts. Again, I think a
reference to some other document or small bit of text is
needed.

4. Can a valid conference participant send a message with
a From: field containing the identifier (e.g. AOR) of another
valid conference participant and have that work? I don't
think this is just down to "policy," but presumably just
MUST NOT work, right?

[Ballot comment]

- I agree with Adrian's first discuss point about the need to
better reference or describe how policy stuff can be done
here.

- Don't we prefer one protocol for each thing in general, so
why not say that? That is, shouldn't we say somewhere that, in
general, folks ought use XMPP but that this protocol is useful
for SIP-oriented deployments? (Apologies if I've stirred a
hornet's nest but I think we prefer XMPP, based on our own
usage at least.)

- section 1: Saying that this "provides competitive features"
to XMPP seems wrong, I'd suggest deleting that phrase.

- section 1: it wasn't clear to me if "interop" here is being
used just for SIMPLE clients and servers or more broadly to
mean interop with other chat services, in particular XMPP.  I
assume you mean the former.

- section 1: Is the last sentence saying this is a short-term
solution only or that this is something that'll be available
soon? The latter would be fine (if true) but the former would
seem problematic without more warnings for implementers about
when they may need to replace this.

- section 2: it might be good to note explicitly that a
"private" IM is seen by the server and isn't only seen by the
sender and recipient.

- section 3 talks about the "identifier" of a sender or
recipient, but that's not a term defined in section 2. It'd be
better to clarify that I think.

- s4, p10: s/is logged/is logged in/ and do you need to define
what you mean by "logged in" in section 2? (Not sure, its
fairly clear I think, but this is the first time you've said I
can be connected more than once.)

- Everyone sends an 'accept-types' attribute, right?  Is it
clear what happens if an IM containing a CPIM containing a
payload with a MIME type that's not supported everywhere is
sent to all?

- last para of section 8: Just noting that I expected the
extension to be called "foo.chat" given the reversal of
example.com. Is the text correct?

- Section 8: should you note that implementations cannot
assume anything about similar private extension names because
they won't know which bit is the DNS name and which is the
extension name?  i.e. uk.co.bbc.foo.bar and ie.tcd.foo.bar
don't tell me that both are doing foo.bar (or bar.foo;-)

[Ballot comment]
I was very much on the fence about whether to ballot ABSTAIN or NO OBJECTION.  It's clear that a lot has happened in the eight and a half years since this larva hatched, and the five since it pupated as a working group document.  I don't think the result is a butterfly; rather, it's been overtaken by events, and I'm not at all sure that it's best for the Internet to standardize this.  There are lots of instant messaging systems out there, and picking yet another about which to say, "This is a Proposed Standard," is questionable, I think.  In the end, because this isn't defining the IM system from the start, but is layering chat-room function on top of what's already there, and because it's been implemented, I've decided to go with NO OBJECTION.

To be clear: None of that internal debate I was having with myself had anything to do with the quality of the document.  It's a fine document, well written, and I appreciate the time spent on it over the many years.  We frequently have documents that are so long in the making that we don't want to abandon them, and this is only one.  So carry on, and I have no official objection to seeing this finished.

Apart from what Adrian caught, there's one very minor editorial thing that I noticed while I was reviewing:

-- Section 11 --

  If a participant wants to avoid eavesdropping, the participant's MSRP
  client can send the messages over a TLS [RFC5246] transport
  connection, as allowed by MSRP.  It's up to the policy of the MSRP
  switch if the messages are forwarded to the other participant's in
  the chat room using TLS [RFC5246] transport.

The first clause is ambiguous, and when I first read it I thought it was talking about the participant not wanting to *be* the eavesdropper.  I suggest re-wording it.  While you're at it, you can take that stray apostrophe out of "participants" at the end.

Oh, also... In Section 12, I know that at least one of the Contributors has changed affiliations.  Have you checked with them to make sure the affiliations you list are what they want to have there now?

[Ballot discuss]
Thanks, this is a well-written and easy-to-read document. Just a couple
(well, three) of small issues that I would like to Discuss.

---

Surpised that there are no requirements on authetication or control of
admission to chat rooms. Was this topic discussed by the WG and left out
on purpose (in which case we should add a note to that effect), was it
forgotten (in which case we should address it), or is it not relevant
for this type of chat (in which case you just need to explain it to me)?

I would assume that the INVITE can be policed in some way. The best I
could find was in Section 5.2

  Participants usually join the chat room by sending an INVITE request
  to the chat room URI.  As long as the chat room policy allows, the
  INVITE request is accepted by the focus and the user is brought into
  the actual chat room.

Indeed, there are several mentions of things being allowed according to
chat-room policy, but no wider discussion of the full set of policy
attributes, or how chat room policy is set.

---

Section 6.1

  On sending a regular message the sender MUST populate the To header
  of the Message/CPIM wrapper with the URI of the chat room.  The
  sender SHOULD populate the From header of the Message/CPIM wrapper
  with a proper identifier by which the user is recognized in the chat
  room.

I'm uncomfortable with the "SHOULD" here. It implies that you can think
of a good reason why the sender MAY use some other (improper) identifier
or no identifier at all. Can you either give an example (perhaps: "The
sender MAY set an arbitrary and meaningless value in order to hide its
identitiy"), or tighten the SHOULD to a MUST.

---

Section 6.1

  An MSRP
  switch that uses this fast forwarding procedure MUST temporarily
  store the Message-Id of the MSRP message to correlate the different
  chunks, as well as it MUST temporarily store the list of recipients
  to which the initial chunks were delivered.

The motivaiton is clear. I think you could add that the storage can be
released when the last chunk is seen. But what happens when the last
chunk is not seen (or delayed)? How temporary is the storage, and how is
it released?

Or do we assume that because MSRP uses TCP (or similar) that loss will
always be accompanied by connection failure and so that is the only
trigger needed to abandon temporary storage?

[Ballot comment]
Section 4

  In order to enter a chat room, one must first be created.

Obviously, I spend to much time hanging out with the Queen, but when you
say "one must be created" I suspect you meant the chat room, not one's
self. Maybe reword as...
   
Before a chat room can be entered, it must be created.

---

Section 6.1 (trivial nit)

  The SEND request MUST contain a top-level wrapper of type 'Message/
  CPIM' according to RFC 3862 [RFC3862].  The actual instant message
  payload MUST be included as payload of the 'Message/CPIM' wrapper and
  MAY be of any type negotiated in the SDP 'accept-types' attribute
  according to the MSRP rules.

I think s/MAY/may/. That is, a type must be set, and the type must be
only one of those that has been negotiated.

IANA understands that, upon approval of this document, there are four
actions which need to be completed.

First, in the MSRP Methods registry in the Message Session Relay
Protocol (MSRP) Parameters registry located at:

http://www.iana.org/assignments/msrp-parameters/msrp-parameters.xml

a new method is to be added to the registry as follows:

Description: NICKNAME
Reference: [ RFC-to-be ]

Second, in the MSRP Header Fields registry also located in the Message
Session Relay Protocol (MSRP) Parameters registry located at:

http://www.iana.org/assignments/msrp-parameters/msrp-parameters.xml

a new header field is to be added as follows:

Description: Use-Nickname
Reference: [ RFC-to-be ]

Third, in the MSRP Status Codes registry also located in the Message
Session Relay Protocol (MSRP) Parameters registry located at:

http://www.iana.org/assignments/msrp-parameters/msrp-parameters.xml

three new status codes are to be added as follows:

Value: 404
Description: Failure to resolve recipient's URI
Reference: [ RFC-to-be ]

Value: 423
Description: Unable to allocate requested nickname
Reference: [ RFC-to-be ]

Value: 428
Description: Private messages not supported
Reference: [ RFC-to-be ]

Fourth, in the SDP media level only attribute registry (att-field (media
level only)) located in the Session Description Protocol (SDP)
Parameters located at:

www.iana.org/assignments/sdp-parameters/sdp-parameters.xml

a new attribute will be added as follows:

Type: att-field (media level only)
SDP Name: chatroom
Reference: [ RFC-to-be ]

IANA understands these to be the only actions required upon approval of
this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Multi-party Chat Using the Message Session Relay Protocol (MSRP)) to Proposed Standard


The IESG has received a request from the SIP for Instant Messaging and
Presence Leveraging Extensions WG (simple) to consider the following
document:
- 'Multi-party Chat Using the Message Session Relay Protocol (MSRP)'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Message Session Relay Protocol (MSRP) defines a mechanism for
  sending instant messages within a peer-to-peer session, negotiated
  using the Session Initiation Protocol (SIP) and the Session
  Description Protocol (SDP).  This document defines the necessary
  tools for establishing multi-party chat sessions, or chat rooms,
  using MSRP.


Note that This document has a downward reference to RFC 4353.
Please comment during the last call on the appropriateness of
this downref.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-simple-chat/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-simple-chat/


No IPR declarations have been submitted directly on this I-D.

PROTO writeup for http://tools.ietf.org/id/draft-ietf-simple-chat-12.txt : "Multi-party Chat Using the Message Session Relay Protocol"


  (1.a)  Who is the Document Shepherd for this document?  Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The document shepherd for this document is Ben Campbell.

The document has been reviewed and is ready for forwarding to IESG for
publication.


  (1.b)  Has the document had adequate review both from key WG members
        and from key non-WG members?  Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

The document has quite a bit of review over its lifespan in the SIMPLE
work group. It lists Eva Leppanen, Adamu Haruna, Adam Roach, Matt
Lepinski, Mary Barnes, Ben Campbell, Paul Kyzivat, Adrianv Georgescu,
and Nancy Greene as reviewers in the acknowledgments.

The document has undergone an MMUSIC expert review by Flemming
Andreasen, since it contains SDP extensions.

The Document Shepherd does not have concerns about the depth or breadth
of the reviews.


  (1.c)  Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization, or XML?

The document should undergo the usual Gen-ART review. But otherwise the
Document Shepherd does not have concerns over the level and breadth of
review for this document.


  (1.d)  Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?  For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it.  In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here.  Has an IPR disclosure related to this document
        been filed?  If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

The shepherd has previously argued that the nickname management
extension to MSRP is in fact a signaling or control function that should
be handled in the control layer, not as part of the media stream. This
was extensively discussed in the working group, and the consensus was to
keep the nickname management extension as described in this document.
The shepherd accepts the consensus.

  (1.e)  How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

Among the people currently active in the WG there is a wide consensus
behind the document. No significant objections have been raised to this
version of the document.

However, there has been some controversy over how this work relates to
XCON. See the Working Group Summary in section 1.k, below.


  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarize the areas of conflict in
        separate email messages to the Responsible Area Director.  (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

Nobody has threatened an appeal or otherwise indicated extreme
discontent.

  (1.g)  Has the Document Shepherd personally verified that the
        document satisfies all ID nits?  (See
        http://www.ietf.org/ID-Checklist.html and
        http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
        not enough; this check needs to be thorough.  Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type, and URI type reviews?  If the document
        does not already indicate its intended status at the top of
        the first page, please indicate the intended status here.


The Document Shepherd believes that the document contains all needed
information. The document has undergone an MMUSIC expert review, since
it contains an SDP extension.


  (1.h)  Has the document split its references into normative and
        informative?  Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?  If such normative references exist, what is the
        strategy for their completion?  Are there normative references
        that are downward references, as described in [RFC3967]?  If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

The draft contains both normative and informative references. There is a
normative downref to RFC 4353 (The conferencing framework.). This was
discussed in the working group, with a consensus that RFC 4353 was
necessary to fully understanding this document.

There are normative references to draft-ietf-xcon-common-data-model-32
and draft-ietf-xcon-event-package-01, both of which are in the RFC
editor's queue at the time of this writing.

  (1.i)  Has the Document Shepherd verified that the document's IANA
        Considerations section exists and is consistent with the body
        of the document?  If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?  Are the IANA registries clearly identified?  If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations?  Does it suggest a
        reasonable name for the new registry?  See [RFC2434].  If the
        document describes an Expert Review process, has the Document
        Shepherd conferred with the Responsible Area Director so that
        the IESG can appoint the needed Expert during IESG Evaluation?


The Document Shepherd believes that the IANA Consideration contains the
appropriate information, and is consistent with the rest of the
document.


  (1.j)  Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

The authors indicate that the ABNF in this draft was verified with an
automatic checker.

  (1.k)  The IESG approval announcement includes a Document
        Announcement Write-Up.  Please provide such a Document
        Announcement Write-Up.  Recent examples can be found in the
        "Action" announcements for approved documents.  The approval
        announcement contains the following sections:

        Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

The Message Session Relay Protocol (MSRP) defines a mechanism for
sending instant messages within a peer-to-peer session, negotiated using
the Session Initiation Protocol (SIP) and the Session Description
Protocol (SDP).  This document defines the necessary tools for
establishing multi-party chat sessions, or chat rooms, using MSRP.

        Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

There has been controversy about doing this work in SIMPLE. The XCON
working group was chartered to do create similar mechanisms in a media
independent fashion. There was a compromise consensus to do this draft
in SIMPLE with the idea that, with its smaller scope, it could complete
more quickly than the XCON work, and that it would be a short-term
solution until XCON completed the more general work.

This in fact did not occur, as this draft took longer than expected due
to several editor changes. Discussion at the SIMPLE meeting at IETF75
concluded that we should capture the parts of this draft were specific
about mixing MSRP at a conference bridge, but abandon the rest in favor
of XCON. However, this conclusion did not achieve consensus when brought
it to the working group list at large.

We readdressed this on the SIMPLE list in September 2010. A few
participants strongly argued that the work should be abandoned, as it
conflicted with (now substantially complete) work in XCON. But others
(including at least one implementor) argued for completion. In
particular, several people argued that this draft enabled them to build
a light weight text-chat service without requiring all the features
enabled by XCON. Note that the XCON working group has since completed
its work and closed.

In summary, the working group originally had a consensus to complete
this work, and has not achieved a consensus to change that plan.

We had agreement to pubreq version 07 in late 2010. The shepherd found
some issues during the PROTO review. The work group discussed the
substantive changes since version 07 on list, and we believe we have a
similar consensus to pubreq version 11 without a new WGLC


        Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

There are at least two existing implementations, "Blink" as a client and
"SylkServer" as a server. A few others have indicated the intent to
implement it.

        Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

The document shepherd for this document is Ben Campbell.

The responsible Area Director is Gonzalo Camarillo.

The IANA Expert(s) for the registries in this document are .