Re: Fwd: Re: Adrian Farrel's Discuss on draft-ietf-simple-chat-16: (with DISCUSS and COMMENT)

(As individual)

Hi,

I agree with Miguel's responses except as noted inline

Thanks!

Ben.

On Sep 4, 2012, at 8:35 AM, "Miguel A. Garcia" <[email protected]> wrote:
> 
>> 
>> ---
>> 
>> 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?
> 
> Yes, we can add that the temporary storage is released when the last
> chunk is seen or after a reasonable time passes.

The "how long to wait for a chunk" problem is no different than for any other endpoint, is it, other than possibly differences of scale? I suggest we refer back to 4975 for this, with the possible note to the effect of "This is no different than for any MSRP endpoint that receives a chunked message. However, since a conference switch will typically participate many sessions at one time, storage management may be more critical"

>> 
>> 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?
> 
> Yes, on one side, the assumption is that if a last chunk is not seen is
> because there has been a transport failure. Since TCP is used, then the
> TCP connection was broken, and is in the process of being re-established.
> I am more concerned about what happens if the last chunk is not seen at
> all, I am not sure the state the MSRP session will be, even if the
> connection is re-established.

Keep in mind there could be an MSRP relay between the sender and the switch, so the transport connection may not be direct. But again, this is no different than for any other MSRP endpoint.

> 
> 
>> ---
>> 
>> 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.
>> 
>> 
> 
> I think this MAY should actually be a MUST, because as you said, a types
> must be said, and this type cannot be anyone, but it MUST be one of those
> negotiated.

This is already mandated in RFC4975 (as you go on to say...). The only thing new is the normative requirement for a particular wrapper type. It might be worth commenting that this is accomplished by putting only Message/CPIM in accept-types, and all allowed leaf types in accept-wrapped-types.

> 
> I like the "according to the MSRP rules", as a mechanism to indicate that
> we are not mandating something new, but just copying what MSRP mandates.
> 

... in which case it should be stated descriptively, not normatively.