Subject: [Simple] Alginment of sip-events and watcherinfo

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Dec 2001 14:50:37 -0500

(resend; first attempt seemed to have been garbled)

I'm cc'ing SIMPLE since this is a joint issue that affects both the
watcherinfo work and sip-events. Also, sip-events is a sip work item, not
sipping, so I am changing the list to sip.

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Wednesday, November 28, 2001 2:00 PM
> To: 'Brian Stucker'; Jonathan Rosenberg; 'Bert Culpepper';
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01
> 
> 
> This sounds like a good suggestion to me Brian.
> 
> I would like to suggest the watherinfo reason codes are 
> expanded a little.
> For instance, the watcherinfo assumes that the pending states 
> is waiting for
> authorization. It could however be pending while waiting for 
> the subscribed
> object to become active (note: I am not referring to the 
> subscribed Event
> package here). This sort of behavior may be typical/useful 
> when you are
> trying to subscribe to an event that has not started yet (and 
> yet you desire
> to have the subscription in place _before_ the event begins). 

OK, but in this case, the subscription itself is not pending, its the state
of the object that is effectively "TBD". This should be reflected in the
presence document delivered in the first NOTIFY, not in the state of the
subscription, IMHO.

> I also think
> the rejection/termination reasons could be expanded a little more.

Suggestions?

Brian Stucker wrote:
> 
> I can't see much use in including the 
> event field since
> (presumably) the watcher will know what event triggered the 
> NOTIFY, and if
> they can't, they can use watcherinfo to get it.

No, these are not events of the presentity, they are events of the
subscription. These events correspond quite closely to the "reason"
parameters Adam has currently specified. In fact, for the rejecttion events,
here is the mapping:

sip-events      watcherinfo
----------      -----------
migration  <->   deactivated
maint      <->    ?
refused    <->   rejected
timeout    <->   expired
 ?         <->   timeout

Clearly, these should be aligned, and should be present in both the
SUbscription-Expires and the watcherinfo format. 

Its not clear to me what the semantics of maint are; should the client retry
after some period? Presuming we can define it conciesely, we should add it
to the watcherinfo package. 

So, here would be my proposal for the unified set:

deactivated: subscription is terminated, but client SHOULD retry immediately
with a new subscription. This handles migration plus other cases
potentially.

probation: subscription is terminated; but client SHOULD retry at some later
time (we could include a Retry-After header in the case of presence in the
Subscription-Expires header)

rejected: subscription terminated due to change in authorization policy.
Retrying will not help.

timeout: subscription terminated because it was not refreshed. 

giveup: could not obtain authorization in a timely fashion, and so the
pending subscription is being terminated. The client can retry and will
likely get put back into pending state.

THanks,
Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com