Skip to main content

Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions
RFC 7573

Yes

(Richard Barnes)

No Objection

(Adrian Farrel)
(Alia Atlas)
(Benoît Claise)
(Jari Arkko)
(Martin Stiemerling)
(Spencer Dawkins)
(Ted Lemon)

Note: This ballot was opened for revision 10 and is now closed.

Richard Barnes Former IESG member
Yes
Yes (for -10)

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -10)

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -10)

                            
Barry Leiba Former IESG member
No Objection
No Objection (2015-03-02 for -10)
-- 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?
Benoît Claise Former IESG member
No Objection
No Objection (for -10)

                            
Brian Haberman Former IESG member
No Objection
No Objection (2015-03-03 for -10)
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.
Jari Arkko Former IESG member
No Objection
No Objection (for -10)

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2015-03-04 for -10)
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.
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-03-04 for -10)
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.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -10)

                            
Pete Resnick Former IESG member
No Objection
No Objection (2015-03-04 for -10)
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.
Spencer Dawkins Former IESG member
No Objection
No Objection (for -10)

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2015-03-03 for -10)
- 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.
Ted Lemon Former IESG member
No Objection
No Objection (for -10)