Re: [Stox] Comments on stox-chat-09

[Ben Campbell <[e-mail]>]

> On Feb 11, 2015, at 9:35 PM, Peter Saint-Andre - &yet <[e-mail]> wrote:
> 
> On 2/9/15 3:59 PM, Ben Campbell wrote:
>> (Resending to include STOX list) (No hats yet)
>> 
>> Hi Peter and Alissa,
>> 
>> I've looked over draft-ietf-stox-chat-09. It looks mostly good, but
>> there are still a few issues.
>> 
>> Thanks!
>> 
>> /Ben
>> 
>> ----------------------------
>> 
>> MSRP Failure-Report headers:
>> 
>> The examples assume the MSRP Failure-Report header field is set to
>> no. It's missing from the first SEND, but explicitly set to no in the
>> rest. The responses to SEND requests are left off throughout. This is
>> allowed, but non-default behavior for MSRP. If the intent is to set
>> Failure-Report: no, it would be good to say a few words about it. If
>> the intent is to leave that to the implementation, then I would
>> expect the examples to follow the defaults.
> 
> As I see it:
> 
> Because the XMPP message receipts specification (XEP-0184) does not support failure reports, there is no mapping for the MSRP Failure-Report header field and gateways SHOULD set that header field to "no".
> 

That's reasonable. A few words to that effect might help keep others from tripping over it.

[...]

>> Session Termination
>> 
>> I would like to see a little more prominent discussion about when the
>> XMPP side might terminate a session. It's mentioned in the
>> "Composing" section, but that seems to bury an important concept. I
>> note both primary examples show the SIP side terminating the
>> session--it would be nice to see one of those examples let the XMPP
>> side do it.  (Is the "gone" composing state the only way this would
>> happen?)
> 
> There is no concept of an explicit messaging session in RFC 6121: the conversation just trails off. The "gone" state is the only way to indicate that the session is over, but that's not defined in RFC 6121.

Got it. Then my only real comment here is it might be nice (but completely optional) to say something about that in the main flow examples, instead of bury it in the "composing" state section.

> 
>> SIP CSeq:
>> 
>> CSeq is missing from most SIP requests, except oddly for BYE
>> requests.
> 
> Are you saying that CSeq is typically not included in SIP requests (even in dialogs) per the specs, or that we have mistakenly left them off here? I think the latter, but I want to make sure.
> 

The latter. "most SIP requests" should have been "most SIP requests in this draft".

[...]