Re: Simple chat. Gen-ART comments

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

On 24/02/2012 15:56, Ben Campbell wrote:
>
> 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:
>>
>> 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.
>>
>
> 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".

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".


>
>>
>>
>> 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 receives a subsequent _chunk_...

Fixed.

>
>>   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.
>>
>
> 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.


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