Subject: [Simple] Simple chat. Gen-ART comments

From: "Miguel A. Garcia" <[email-masked]>
Date: Fri, 24 Feb 2012 12:11:22 +0100

When Suresh did the Gen-ART review of the SIMPLE chat draft, he had two 
comments. Here is a proposal for his resolution. Please comment, 
especially if you disagree or can improve the text:

1) REQ-3: It is unclear why this is separate from REQ-2. In my reading,
REQ-2 already covers REQ-3.

I propose to make REQ-2 a requirement to identify the sender and REQ-3 a 
requirement to identify the recipient. My proposal:

    REQ-2:  A conference participant must be able to determine the
            identifier of the sender of received instant messages.  Note
            that the actual identifier depends on the one which was used
            by the sender when he or she joined the conference.

    REQ-3:  A conference participant must be able to determine the
            identifier of the recipient of received messages.  For
            instance, the recipient of the message might be the entire
            conference or a single participant of the conference (i.e., a
            private message).  Note that the actual identifier may depend
            on the one which was used by the recipient when he or she
            joined the conference.

2) Section 6.1

This sentence is not clear. Can you clarify/reword.

"Having the header of the Message/CPIM wrapper only in the first chunk,
the MSRP switch MUST track the Message-Id until the last chunk of the
message has been distributed."

I agree that the sentence is only clear to the MSRP savvy guy, and I 
don't like the "MUST track", because it does not really have a clear 
action to a normative statement, so I propose to write instead:

    Note that the MSRP switch does not need to wait for the reception of
    the complete MSRP chunk or MSRP message before it starts the
    distribution to the rest of the participants.  Instead, once the MSRP
    switch has received the headers of the Message/CPIM wrapper it SHOULD
    start the distribution process.

    When forwarding chunked messages as soon as they are received, the
    Message/CPIM wrapper is only present in the first chunk.  Subsequent
    chunks will contain the rest of the message, but not the Message/CPIM
    headers.  Therefore, an MSRP message that receives a subsequent
    message may face challenges in determining the correct list of
    recipients of the message.  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 first chunk was
    delivered.  The MSRP switch SHOULD forward subsequent chunks only to
    those recipients of the first chunk, except if the MSRP switch has
    knowledge that one of the recipients of a first chunk has dropped
    from the chat.  This avoids new participants who joined the chat when
    the first chunk has been distributed to receive subsequent chunks
    that would otherwise need to be discarded.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Ben Campbell <[email-masked]>
Date: Fri, 24 Feb 2012 08:56:57 -0600

On Feb 24, 2012, at 5:11 AM, Miguel A. Garcia wrote:

> When Suresh did the Gen-ART review of the SIMPLE chat draft, he had two comments. Here is a proposal for his resolution. Please comment, especially if you disagree or can improve the text:
> 
> I propose to make REQ-2 a requirement to identify the sender and REQ-3 a requirement to identify the recipient. My proposal:
> 
> 

I'm fine with REQ-2. For REQ-3, who is the participant? Are we talking about the sender, the recipient, or someone else? In the case of a sender, the operative word is probably "select" rather than "determine".

> I agree that the sentence is only clear to the MSRP savvy guy, and I don't like the "MUST track", because it does not really have a clear action to a normative statement, so I propose to write instead:
> 
>   recipients of the message.

An MSRP _switch_ that receives a subsequent _chunk_...

>  An MSRP switch that uses this fast

It's possible, by the way, for Message/CPIM header fields to occur in a chunk other than the first one. It's highly unlikely, but I can envision a message with a huge Message/CPIM header splitting the header, or a message that got interrupted very shortly after starting. In any given field should occur only once, but even an individual field could get split across chunks--particularly in the case of the recipient list.

> 
> 
> 
> /Miguel
> 
> 
> -- 
> Miguel A. Garcia
> +34-91-339-3608
> Ericsson Spain
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/simple

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Sat, 25 Feb 2012 10:19:34 +0100

Hi Ben, thanks for the comments. See inline replies.

> I'm fine with REQ-2. For REQ-3, who is the participant? Are we talking about the sender, the recipient, or someone else? In the case of a sender, the operative word is probably "select" rather than…

Good point. The requirement is not about any participant, but a recipient 
of a message. In a chat room with multiple participants, if I send you a 
private message, the requirement is that you (the recipient) must be able 
to determine who sent it (REQ-2) and to who is addressed (me: it's a 
private message, rather than the whole chat room) (REQ-3).

I will replace "conference participant" with "recipient of an instant 
message in a chat room".

> An MSRP _switch_ that receives a subsequent _chunk_...

Fixed.

> It's possible, by the way, for Message/CPIM header fields to occur in a chunk other than the first one. It's highly unlikely, but I can envision a message with a huge Message/CPIM header splitting…

This is a good point too. So, I am now trying to reflect that the 
Message/CPIM header typically occurs in the first chunk. And rather than 
talking of the "first chunk", I am talking of "initial chunks" and 
"subsequent chunks".

Here is the proposed text:

	  When forwarding chunked messages as soon as they are
	  received, the Message/CPIM wrapper is only present at the
	  beginning of the message, typically within the first
	  chunk. Subsequent chunks will contain the rest of the
	  message, but not the Message/CPIM headers. Therefore, an
	  MSRP switch that receives a subsequent message may face
	  challenges in determining the correct list of recipients of
	  the message. 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 MSRP switch SHOULD
	  forward subsequent chunks only to those recipients who were
	  sent the initial chunks, except if the MSRP switch has
	  knowledge that one of the recipients of the initial chunks has
	  dropped from the chat room. This behavior also avoids new
	  participants who joined the chat room when the first chunk has
	  been distributed to receive subsequent chunks that would
	  otherwise need to be discarded.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain