Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
RFC 6121

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

(Gonzalo Camarillo) Yes

(Alexey Melnikov) Yes

Comment (2011-01-19 for -)
No email
send info
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 -)
No email
send info
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 -)
No email
send info
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".

(Russ Housley) No Objection

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) Recuse