[Stox] Comments on stox-chat-09

[Ben Campbell <[e-mail]>]

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

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.

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?)

SIP CSeq:

CSeq is missing from most SIP requests, except oddly for BYE requests. (And note that the CSeq of a BYE, sent by the peer that initiated the INVITE, would never be "1")

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