Subject: [xmpp] 3921bis - subscription approval

From: Kevin Smith <[email-masked]>
Date: Wed, 21 Jul 2010 14:49:32 +0100

3.1.5 talks about MUST send roster pushes with subscription=from.
Should this text reflect that this is only true if it isn't already
=to (in which case it should be =both)?
Perhaps simply saying "Where the contact does not already have a
subscription to the user" somewhere would do. At the end of 3.1.5, it
then says that this is repeated with the roles reversed - which is not
true in light of the existing subscription (you end up with =both
pushes).

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 24 Jul 2010 04:16:44 -0600

[Typed while in transit, delivery will be delayed.]

> true in light of the existing subscription (you end up with =both

All of Section 3 is narrative, whereas the subscription tables in the
appendix are normative regarding exactly what is sent at each possible
stage of the subscription handshake. See this paragraph in the
introduction to Section 3:

   Subscription states are reflected in the rosters of both the user and
   the contact.  Complete details regarding these subscription states
   can be found Appendix A; those details are not provided in this
   section, which simply narrates the protocol flows for common use
   cases related to presence subscriptions.

Perhaps that paragraph is not clear enough. I've changed it to:

   Subscription states are reflected in the rosters of both the user and
   the contact.  This section does not cover every possible case related
   to presence subscriptions, and mainly narrates the protocol flows for
   bootstrapping a mutual subscription between a user and a contact.
   Complete details regarding subscription states can be found in
   Appendix A.

Then also in Section 3.1.5 and other places I've added explanatory
notes, for instance:

   The contact's server then MUST send an updated roster push to all of
   the contact's interested resources, with the 'subscription' attribute
   set to a value of "from".  (Here we assume that the contact does not
   already have a subscription to the user; if that were the case, the
   'subscription' attribute would be set to a value of "both", as
   defined under Appendix A.)

/psa