Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions
draft-ietf-stox-chat-11

-- Section 1 --

   In SIP-based systems that use MSRP, a chat session is formally
   negotiated just as any other session type is using SIP.

Nit: you need an appositive comma before "using SIP".

-- Section 6 --

   Here the idle state indicates that the
   sender is not actively composing a message, and the active state
   indicates that the sender is indeed actively composing a message (the
   sending client simply toggles between the two states, changing to
   active if the user is actively composing a message and changing to
   idle if the user is no longer actively composing a message).

This really sounds repetitious (because the repeating sounds repetitious when it repeats).  I think you could end the parenthetical after "toggles between the two states", because you've really already said the rest.

-- Section 11 --
The second paragraph looks like it's exactly the same as what's added in stox-im, and that's a normative reference already.  Why not add a citation to the security considerations in stox-im, and delete the second paragraph, incorporating it by reference?

No objection to the publication of this document, but I do have a question for you to consider...

Sections 4 and 6 talk about implementing timers to deal with the lack of a GONE message in XMPP.  Any thoughts on having this document suggest possible values for such timers?  Not sure if that makes sense for protocols much closer to real users, but thought I would ask.

I'm disappointed but unsurprised that this does not address the question of end-to-end encryption especially as it addressed  signaling through protocol translating middleboxes, it seems like if it works there it can work anywhere.

I support Stephen's comment on OTR, if it is possible to add mention of how to do this, that would be good to have some end-to-end reference for confidentiality.  Thanks.

Looks good, but a question: Shouldn't F6 in section 4 and F18 in section 5 result in sending an XMPP Chat State Notification of "active" or "inactive" to the XMPP client? If so, adding that, and a discussion in section 6, seems useful.

- OTR works for xmpp. I think (not sure) it could be made
work for MSRP or SIMPLE, and presumably then it might work
here. If that's true, be good to note that and explain a bit
how to do that. (And I don't mean the long-promised OTR I-D,
just a pointer at the inevitably bad best reference we can
find.)

- End of p12: "are suggested" is odd to see in an RFC, it
might be better if you find some other wording.