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

[Peter Saint-Andre - &yet <[e-mail]>]

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

> SIP Response From/To:
>
> The SIP responses swap the From and To from the associated requests.
> This is not correct, To and From of a SIP response matches the To and
> From of the original request. (More to the point, the To and From in
> a response do not change to indicate the direction of the response
> message.) I note that the groupchat draft had this issue at one
> point, but it's been fixed.

Noted. Will fix.

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

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

> (And note that the CSeq of a BYE, sent by the peer that
> initiated the INVITE, would never be "1")

True.

> Security Considerations, last sentence:
>
> The text non-normatively "suggests" the use of RFC3862 for end-to-end
> protection. That seems to want to have it both ways (non-normative
> and recommended) . I suggest either making that normative, or
> reducing the strength to say RFC3862 could be used for this purpose.
> (I realize we do this all the time with "ought to", but it seems like
> we need a sharper line for something like e2e crypto.)

See previous reply about the -im document.

Peter

-- 
Peter Saint-Andre
https://andyet.com/