Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Wed, 21 Nov 2001 05:54:48 -0800

Adam,

I too agree - the NOTIFY should only try to convey information about the
subscription not the transactions. 

However I don't think the Subscription-Expires (in its current form) is well
suited to that purpose. Currently the "Subscription-Expires" reason only has
any meaning when the Expires valid is set to zero. In other words, the
header is a cobbling together of two functions - subscription expires (on
success) and a failure reason. 

It cannot convey information that the subscription is pending (or why) or
when a subscription becomes active.

I would support a extension of the header to include a subscription state:

Subscription-Expires: <expires> <state> <Reason> 

[This syntax is also backwards compatible.]

An example of subscription states:
	"pending" 
	"active"
	"terminated"

The expires value for a successful session should only be taken from an
"active" Subscription-Expires indication. In other states it will be equal
to the Expires header value.

Comments?

Robert.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, November 20, 2001 10:00 PM
> To: 'Jonathan Rosenberg'; 'Brian Stucker'; Michael Hammer
> Cc: Paul Kyzivat; 'James Undery'; 'Fairlie-Cuninghame, Robert';
> [email-masked]; [email-masked]
> Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01
> 
> 
> I agree with Jonathan's analysis of the situation.
> 
> As it stands, we have a mechanism which allows us to convey
> whether the subscription is active: is Subscription-Expires > 0?
> We also have a way to indicate roughly why this value
> is anything other than what the subscriber might expect.
> 
> Is this sufficient? I think it is. The reason codes seem better
> geared towards conveying transaction state (like they do in
> REFER). I agree with Jonathan that we want to convey subscription
> state, not transaction state.
> 
> This still leaves the authentication issues, to which the reason
> codes offered an incomplete solution. As I previously
> argued, authentication through a forking proxy is a general
> problem which impacts INVITE (and all other methods) at least
> as severely as it does SUBSCRIBE. I am loathe to solve a general
> problem in a method-specific manner.
> 
> Perhaps I don't understand the problem that people are trying
> to solve here, but I think the current mechanism (Subscription-Expires
> with an optional reason parameter) accomplishes what is necessary to
> make things go.
> 
> If someone has additional requirements that aren't fulfilled by this
> scheme, please explain the problem you see with the current draft.
> 
> /a
> 

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Bert Culpepper" <[email-masked]>
Date: Wed, 21 Nov 2001 14:56:42 -0500

comments below...

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Fairlie-Cuninghame, Robert
> Sent: Wednesday, November 21, 2001 8:55 AM
> To: [email-masked]'; 'Jonathan Rosenberg'; 'Brian Stucker';
> Michael Hammer
> Cc: Paul Kyzivat; 'James Undery'; [email-masked]

I thought this too.  However, upon re-reading the new I-D the use of
Expires in NOTIFY requests seems to be deprecated.  The new
Subscription-Expires header in NOTIFYs conveys remaining subscription
duration, plus a reason phrase.

> to the Expires header value.

Well, we've lost the Expires header in NOTIFYs.  However, if subscription
state other than active/non-active is needed we'll need something like
this header extension.  The only comment I have then is do we need
"active" and "terminated", since the expires value indicates "active"
when >0 and "terminated" when 0.

Regards,
Bert