2010/9/10 Florian Zeitz <[email protected]>: >> 2010/9/10 Florian Zeitz <[email protected]>: >>> Probably. This one or jdev@ I guess. >>> The "reason" you're looking for is probably that the >>> subscription-attribute (as opposed to the subscription-state) can only >>> have the values "to", "from", "both", and "none". >> >> Humm, but when a user is offline and other user subscribes to him, >> next time the user becomes online receives a new roter ite, with >> "subscription=None + Pending In", so... >> > Where did you see that? > He won't receive a roster item yet AFAIK, instead he will receive a > <presence type='subscribe'/>. If he accepts the request he'll receive a > roster push with subscription='from'.
You are right, I failed to understand RFC 3921 section 8.2 point 6: ----------------------- Upon receiving the presence stanza of type "subscribe" addressed to the contact, the contact's server MUST determine if there is at least one available resource from which the contact has requested the roster. If so, it MUST deliver the subscription request 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" as defined under Subscription States, however a server SHOULD NOT push or deliver roster items in that state to the contact). ----------------------- It's clear what you say: "with a state of "None + Pending In" as defined under Subscription States, however a server SHOULD NOT push or deliver roster items in that state to the contact" Thanks for clarification. -- Iñaki Baz Castillo <[email protected]>
