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

Thanks, this is a well-written and easy-to-read document, and thanks for 
the work to address my Discuss and Comments.

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.

I'll trust the 5 DISCUSS from my IESG fellows on this document.

I have no problems with the publication of this well-written document.  I do support Adrian's first two DISCUSS points.

Thank you for addressing my concerns.

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?

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.

supporting Adrian's DISCUSS

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.