Subject: RE: [Sip] FW: [Simple] Alignment of sip-events and watcherinfo

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 10 Dec 2001 16:48:06 -0800

Hi Jonathan,

> 
> (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.
>  

Re-adding SIMPLE after resend.

> > 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 disagree. I think this is very much the concern of subscription and not
the Event package. 

Example: If I create a subscription that is associated with a televised
concert that occurs at some time in the future. When the concert finishes,
obviously the subscription should also terminate, the reason for the
termination is that the subscribed object has terminated. This is not an
Event Package related reason. Likewise, every Event Package (e.g., my
"Excessive Decibels" Monitoring Event Package) should not have to deal with
understanding/reporting when the concert is valid (and why the subscription
was terminated) - the package is only concerned with reporting when the
audio component of the associated object exceeds a certain threshold.
<contrived but it will do>

This argument applies equally to the pending state. I want to create a
subscription to this concert before it starts so I don't miss the beginning.
So the subscription is not active until the concert actually starts - once
again my Decibel Monitoring Event Package has no concern for this. It is a
function of the subscription itself to know when the object (and hence the
subscription) is pending/active/terminated.

Thus both the terminated & pending reason causes should be
Subscription-Expire reasons and not solely contained in the Event package
bodies themselves. 

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

I made a couple in my last email (some of which you have already covered):

	- Terminated/rejected because authorization failed
	- Terminated because subscribed object terminated
	- Terminated because subscriber requested termination.
	- Expired. Subscriber did not refresh subscription.
	- Terminated at request of notifier.

Regards,

Robert.

> > 
> > 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.
>

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 11 Dec 2001 01:22:34 -0600

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Monday, December 10, 2001 6:48 PM
> To: 'Jonathan Rosenberg'; [email-masked]'
> Cc: [email-masked]'
> Subject: RE: [Sip] FW: [Simple] Alignment of sip-events and 
> watcherinfo
> 
> 
> Hi Jonathan,
> 
> > 

I would have to disagree (is there any other reason to post to this thread
=). 

I think there's a co-mingling of terms that is going on here, either that or
I've totally misunderstood what you were trying to get across. 

A subscription being pending or active, at least to me when I brought up my
proposal to split out the subscription state from the message body about a
month back, dealt completely with the actual state of the subscription, not
the resource it is watching.

In your scenario, even though the resource is pending (the concert hasn't
started yet), the subscription to it is NOT pending. It's active. You will
receive a notification when that concert begins (should that be the behavoir
that the subscription was setup to handle). If the subscription were
pending, meaning it had not been authorized, you would NOT get a
notification that the concert started necessarily. Likewise, there's no
reason that the subscription needs to be terminated explicitly either. The
server processing your subscription could simply send you a final NOTIFY
(the concert ended) and then dump the subscription in the bit bucket. It's
not very polite, but it's allowed in the draft.

Therefore, the two are distinct. This is what I was trying to avoid by
suggesting that using an "Illegal" message body in the NOTIFY doesn't work
well, and thus, we need a more explicit header to do the job to keep
everything more understandible.

A subscription can be pending to an active resource, or pending to a pending
resource. The two are distinct. They are separate finite state machines, and
thus should be processed separately. The state that the subscription is in
has nothing at all to do with the state of the resource on a basic level.
The resource may cause the subscription to be handled differently, for sure,
but at a generic sip-events level, there is no coupling in my mind.

Cheers,

Brian

> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>