Subject: Re: [xmpp] [Standards] none + pending in

From: Philipp Hancke <[email-masked]>
Date: Thu, 09 Jul 2009 21:51:12 +0200

Peter Saint-Andre schrieb:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Please check the text in draft-ietf-xmpp-3921bis. If it is still
> incorrect, post a message about this to the [email-masked] list.

Ok. See below.

> On 7/9/09 10:43 AM, Philipp Hancke wrote:
>> Me Self schrieb:
>>> Can someone help me interpret this line from rfc 3921 section 8.2 6) that
>>> explain how the contacts server stores a subscribe message offline if it
>>> cannot be delivered to the contact:
>>>
>>> "if not, the contact's server MUST store the subscription request offline
>>> for delivery when this condition is next met; normally this is done by
>>> adding a roster item for the contact to the user's roster, with a
>>> state of
>>> "None + Pending In""
>>>
>>> How can the contacts server add anything to the users roster which
>>> resides
>>> on another server?
>> It seems like "user" and "contact" are mixed up in the last sentence.
>> That should probably have been: "normally this is done by adding a
>> roster item for the USER to the CONTACTS's roster".

That text is no longer present in -bis.
I think rule #5 in section 3.1.3 describes the appropriate action.
But...

>>> If the roster item is meant to be stored in the contacts roster then that
>>> brings me to my next question. How does the contacts server determine
>>> if it
>>> can include a roster item in response to a "roster get"? Section 9.2
>>> seems
>>> to touch this:
>>>
>>> ""None + Pending In" = contact and user are not subscribed to each other,
>>> and contact has sent user a subscription request but user has not replied
>>> yet (note: contact's server SHOULD NOT push or deliver roster items in
>>> this
>>> state, but instead SHOULD wait until contact has approved subscription
>>> request from user) "
>>>
>>> This is according to 9.2 from the users perspective so its talking
>>> about a
>>> roster item in the users roster? I dont get this section either. If the
>>> "owner" of a roster with a roster item in the subscription state "None +
>>> Pending in" sends a "roster get" should the owners server then hide this
>>> item? If thats the interpretation then if the owner had the same item in
>>> state "None" before the request was sent to the owner, that means the
>>> item
>>> went from visible to hidden without the owner doing anything other then
>>> being offline when receiving a subscription request?
>> The user had created a roster item for the contact before the contact
>> subscribed the user? Hiding that item does not make sense, indeed.
>> I think the intended behaviour (not modifiyng the roster) is to deliver
>> the item with subscription=none and deliver the subscription request
>> from the contact after the roster result (see 3.1.3 rule 5 in -bis).

This relates to what is said in A1, state None+Pending In (3):
| "None + Pending In" = contact and user are not subscribed to each
| other, and contact has sent user a subscription request but user has
| not replied yet (note: contact's server SHOULD NOT push or deliver
| roster items in this state, but instead SHOULD wait until user has
| approved subscription request from contact); this is reflected in the
| user's roster by subscription='none'

The state transition NONE => NONE+PENDING IN should not modify the
roster. This would be consistent with the last sentence in 3.1.3.

Instead, PENDING IN is determined by the existence of the the stored
inbound subscription request (see section 3.1.3 rule #5).

Hence, if there is an existing roster entry with subscription=NONE
it SHOULD still be sent to the interested resource, followed by the
subscription request after the roster get is complete.
If there is no existing roster entry, it is not created by the state
change NONE => NONE+PENDING IN. Hence no roster item is sent to a client
which requests the roster, only the subscription request is delivered.

I think this makes the note unnecessary.

There are some consequences of that, for example in 3.3.3.
If the server has stored a subscription request in 3.1.3
(state = NONE+PENDING IN), it must upon receiving a unsubscribe
from the contact (state transition => NONE) delete the
stored subscription request.

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 10 Jul 2009 15:23:17 -0600

> stored subscription request.

I think that is all correct. I shall adjust the spec accordingly.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 01 Aug 2009 00:48:41 +0200

> I think that is all correct. I shall adjust the spec accordingly.

In my working copy I now have the following text:

APPENDIX A.1

   3.  "None + Pending In" = contact and user are not subscribed to each
       other, and contact has sent user a subscription request but user
       has not replied yet; in fact, the user's server MUST NOT add the
       contact to the user's roster or and MUST NOT push or deliver
       roster items to the user in this state, but instead MUST simply
       note the existence of the inbound presence subscription request
       and wait until the user has approved the subscription request
       before adding the contact to the user's roster.

SECTION 3.3.3

   When the contact's server receives the unsubscribe notification, it
   MUST first check if the user is in the contact's roster with
   subscription='from' or subscription='both' (i.e., a subscription
   state of "From", "From + Pending Out", or "Both"; see Appendix A).
   If this check is successful, the contact's server MUST initiate a
   roster push to all of the contact's interested resources, containing
   an updated roster item for the contact with the 'subscription'
   attribute set to a value of "none" (if the subscription state was
   "From" or "From + Pending Out") or "to" (if the subscription state
   was "Both").

...

   Otherwise -- that is, if the contact does not exist, if the user is
   not in the contact's roster, or if the user is in the contact's
   roster with a subscription state other than those described in the
   foregoing check -- then the contact's server MUST silently ignore the
   stanza by not delivering it to the contact, not modifying the
   contact's roster, and not generating a roster push to the contact's
   interested resources.  However, if the contact's server is keeping
   track of an inbound presence subscription request from the user to
   the contact without having added the user to the contact's roster
   because the contact has not yet approved or denied the subscription
   request (equivalent to a roster state of "None + Pending In"), then
   the contact's server MUST simply remove any record of the inbound
   presence subscription request (it cannot remove the user from the
   contact's roster because the user was never added to the contact's
   roster).

Let me know if I missed anything.

Peter

- --
Peter Saint-Andre
https://stpeter.im/