2009/7/10 Me Self <wmso...@gmail.com>: > > 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. >
Roster always stores the subscription state, which is now "none". How you store the actual request is up to you. That kind of implementation details do not reflect in the network, so that is not the kind of stuff the spec can dictate. The only think you need to know is that the item is "hidden" to the user until the subscription is approved or the item is explicitly added by the user. That's all you need to know to implement it. How exactly you do it doesn't matter here.
