2009/8/26 Benny Prijono <bennylp at teluu.com>:
>> ----------------
>> deactivated: The subscription has been terminated, but the subscriber
>> ? ? ?SHOULD retry immediately with a new subscription. ?One primary use
>> ? ? ?of such a status code is to allow migration of subscriptions
>> ? ? ?between nodes. ?The "retry-after" parameter has no semantics for
>> ? ? ?"deactivated".
>> ----------------
>>
>> Hope I made myself clear now :) Any chances this can be fixed?
>>
>>
>
> You're right. I added that to ticket #937
Good point Sa?l.
I would also add a similar behavior for other "reason" strings when
Subscription-Status is "terminated".
According to RFC 3265 section "3.2.4. Subscriber NOTIFY Behavior":
---------------------------------
deactivated: The subscription has been terminated, but the subscriber
SHOULD retry immediately with a new subscription. One primary use
of such a status code is to allow migration of subscriptions
between nodes. The "retry-after" parameter has no semantics for
"deactivated".
probation: The subscription has been terminated, but the client
SHOULD retry at some later time. If a "retry-after" parameter is
also present, the client SHOULD wait at least the number of
seconds specified by that parameter before attempting to re-
subscribe.
rejected: The subscription has been terminated due to change in
authorization policy. Clients SHOULD NOT attempt to re-subscribe.
The "retry-after" parameter has no semantics for "rejected".
timeout: The subscription has been terminated because it was not
refreshed before it expired. Clients MAY re-subscribe
immediately. The "retry-after" parameter has no semantics for
"timeout".
giveup: The subscription has been terminated because the notifier
could not obtain authorization in a timely fashion. If a "retry-
after" parameter is also present, the client SHOULD wait at least
the number of seconds specified by that parameter before
attempting to re-subscribe; otherwise, the client MAY retry
immediately, but will likely get put back into pending state.
noresource: The subscription has been terminated because the resource
state which was being monitored no longer exists. Clients SHOULD
NOT attempt to re-subscribe. The "retry-after" parameter has no
semantics for "noresource".
--------------------------------
So in case of:
- deactivated
- probation
- timeout
- giveup
then the client should re-subscribe again (immediately or after the
time in "Retry-After" header).
In case of:
- rejected
- noresource
then the client should not re-subscribe again.
"giveup" is important as it means that the presentity didn't authorize
us to see its status in the maximum time allowed by the presence
server, so we must resubscribe again to get a new "pending" status. If
not, the presentity will not receive the presence.winfo notification
and couldn't authorize us (as it doesn't know we are subscribing to
its presence status).
Regards.
--
I?aki Baz Castillo
<ibc at aliax.net>
