Re: Simple chat. Gen-ART comments

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

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

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

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