Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
Note: This ballot was opened for revision 20 and is now closed.
(Gonzalo Camarillo) Yes
(Alexey Melnikov) Yes
Comment (2011-01-19 for -)
I like Robert's comments, modulo the 4th point in his DISCUSS, which I think is already covered by rfc3920bis. In 4.3.2: Implementation Note: The handling of the 'id' attribute in relation to presence probes was unspecified in RFC 3921. Although the pattern of "send a probe and receive a reply" might seem like a request-response protocol similar to the XMPP <iq/> stanza, in fact it is not because the response to a probe might consist of multiple presence stanzas (one for each available resource currently active for the contact). For this reason, if the contact currently has available resources then the contact's server SHOULD preserve the 'id' attribute of the contact's original presence stanza (if any) when sending those presence notifications to the probing entity; however, Use of "however" can be read as if the 'id' attribute is not to be returned in the case specified below, however it is still returned. I suggest dropping "however" here. if the contact currently has no available resources, the probing entity is not authorized (via presence subscription) to see the contact's presence, or an error occurs in relation to the proble, then the contact's server SHOULD mirror the 'id' of the user's presence probe when replying to the probing entity. In 4.5.2: The user's server MUST also send the unavailable notification to all of the user's available resources (including the resource that generated the presence notification in the first place). Comment: The text in (): but the resource is unavailable :-). The <subject/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]). Should the same be said about presence' <status> element? 11. Security Considerations o A user's server MUST NOT leak the user's network availability to entities who are not authorized to know the user's presence, either via an explicit subscription as described herein or via an existing trust relationship (such as presence-enabled user directories within organizations). I don't understand this paragraph. If a user is subscribed to presence, then she is authorized to know user's presence?
(Robert Sparks) (was Discuss) Yes
(Sean Turner) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Ralph Droms) No Objection
(Lars Eggert) No Objection
Comment (2011-01-17 for -)
Section 2.3.3., paragraph 1: > the roster get, or even <not-llowed/> if the server only allows Nit: s/<not-llowed/>/<not-allowed/>/ Section 4., paragraph 7: > presence, or an error occurs in relation to the proble, then the Nit: s/proble,/probe,/
(Adrian Farrel) No Objection
Comment (2011-01-17 for -)
I'm ballotting "no objection" based on selective reading of a few sections of this I-D and "trust" of the WG, the author, and the ADs who have ballotted "yes".