On Thu, Jul 9, 2009 at 6:43 PM, Philipp Hancke <[email protected]>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". > It seems storing pending requests in the roster is no longer mentioned in what is now section 3.1.3 5) in bis - so that has fixed the wording :) > 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). > It looks like the explanation of "None+ Pending in" has been moved to appendix A.1 in bis and it now reads: ""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 wording has been changed but its not really clearer. The whole concept of storing pending requests in the roster still seems very vague to me (but admittedly I have only skimmed the new bis). In the old RFC 3921 the concept was introduced in parenthesis (quoted in my first post) which was a bit vague but now that the line has been removed it seems Im left with a lot more guessing here. From the new bis I can deduct from appendix A.1 that pending request are stored in the roster but its not obvious and I think the bis could use a separate chapter to introduce the concept. Its not obvious to store pending requests in the roster because roster items and pending request are not sent at the same time. Roster items are sent as reply to "roster get" and pending items are sent when the users becomes "available" after sending initial presence to the server. On top of that I cant interpret A.1 in the new bis any other way than it prevents roster items from being sent in reply to "roster get" when the state is "None + Pending in" which still means that an existing item that was previously visible when it was just "None" now has become hidden because a request from a contact has put it in a pending state. > > philipp > -- Mvh Søren Poulsen
