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

In my previous e-mail, please s/5.3/5.4

To be explicit: the MSRP Connection Model is described in Section 5.4 of 
RFC 4975.

/Miguel

On 05/09/2012 9:15, Miguel A. Garcia wrote:
> 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