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

Hi Ben,

Thanks for your comments

On 04/09/2012 16:26, Ben Campbell wrote:
> (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"


I would like to include a reference to the section in RFC 4975 that 
discusses this topic. I guess it is Section 5.3, when it discusses what 
happens if a transport connection fails.

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

Exactly. Here we clearly need to refer to Section 5.3 of RFC 4975.

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

Ok, we can clarify it. Actually, we do not mention what can go in an 
accept-wrapped-types, because it was obvious that any type can go in. But 
it might be worth adding some explicit mention to it.

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

Hmmm, that is true. I suggest to move away from MUST/MAY/must/may. I 
think the text ought to say: "According to RFC 4975, the endpoint needs 
to  ...". This is makes it clear, and we do not over-specify.

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