SIMPLE Made Simple: An Overview of the IETF Specifications for Instant Messaging and Presence Using the Session Initiation Protocol (SIP)
draft-ietf-simple-simple-09
Yes
(Robert Sparks)
(Wesley Eddy)
No Objection
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Martin Stiemerling)
(Ralph Droms)
(Ron Bonica)
(Russ Housley)
(Stewart Bryant)
Note: This ballot was opened for revision 08 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(2013-02-12 for -08)
Unknown
Summary: SIMPLE is complex. This simple SIMPLE document explains SIMPLE simply, by providing a simple guide to the SIMPLE documents. Simple.
Seriously, I like this, and thanks for doing it. We should do this sort of thing more often when some of our protocol suites become hairy.
One very, very small point:
Two of the paragraphs in Section 2.1 talk about specific documents and refer to section numbers. Those *could* be read as meaning to refer to section numbers in the documents they're talking about. A quick glance down this file showed me that that was not the case, and it probably won't actually confuse anyone, but to dispel all doubt, perhaps it might be nice to do this?:
NEW
The content
of the NOTIFY messages in this package are presence documents,
discussed in Section 2.2, below.
NEW
A user can manage the entries in their buddy list
using the provisioning mechanisms in Section 2.4, below.
Pete Resnick Former IESG member
Yes
Yes
(2013-02-20)
Unknown
This is perfectly reasonable. It might have been nice to expand this into a full out applicability statement with more info about which particular bits you want to implement to instantiate different sets of services (and such a thing might be nice to write at some point), but this is certainly going to be exceedingly useful itself.
Robert Sparks Former IESG member
Yes
Yes
(for -08)
Unknown
Wesley Eddy Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2013-02-19)
Unknown
I agree with Stephen that it is disappointing that Section 4 does not have anything to say about security for SIMPLE. Surely, some of the existing documents are specifically relevant for security?
Benoît Claise Former IESG member
No Objection
No Objection
()
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
()
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
()
Unknown
Ralph Droms Former IESG member
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(2013-02-19)
Unknown
I agree with Stephen's comments.
Stephen Farrell Former IESG member
No Objection
No Objection
(2013-02-18)
Unknown
- Would it not be an idea to also say how SIMPLE and XMPP relate to one another and why we're putting in effort on SIMPLE when XMPP is perceived to be much more widely deployed? (Sorry if that's controversial, but readers will wonder I reckon.) - Maybe it'd be good to have a list of obsoleted RFCs just to help the reader know that they are obsoleted and by what. - You could add a note that some later numbered RFCs are really updates to earlier ones so the numbering sequence isn't significant. (I'm sure some readers would be confused otherwise, e.g. by 4662 being an extension to 6665.) - It would have been nice if section 5 had given a paragraph or two of overview of SIMPLE security.
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown