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

From: "Brian Stucker" <[email-masked]>
Date: Fri, 9 Nov 2001 12:00:49 -0600

Good point (on the expires) I agree with having both, then, except let's
remove the reason portion of the Subscription-Expires, and just make it into
a timer value, again, to avoid state confusion with Subscription-Status.

I can see what you're getting at with the forking now, as well, but wouldn't
it be the case that a forking proxy would be the one that takes up the
authentication information in the request, prior to forking?

Brian

-----Original Message-----
From: James Undery [mailto:[email-masked]]
Sent: Friday, November 09, 2001 10:46 AM
To: Stucker, Brian [NGB:B635:EXCH]; 'Sean Olson (EUS)'; 'Brazier
Lachlan'; 'Jonathan Rosenberg '; ''Fairlie-Cuninghame, Robert' ';
'sipping'
Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

The problem is forking again, the best response will be returned, 401 isn't
a good response but the entity returning it may have better state. By
returning the NOTIFY you give the subscriber the chance to subscribe at
entities that require authentication even if the SUBSCRIBE was forked to
locations that didn't.

On the subject of Expires vs Subscription-Expires this was discussed on the
list and at the last IETF meeting. Basically the Expires applies to the
NOTIFY request not the subscription.

James
-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: 09 November 2001 16:13
To: James Undery; 'Sean Olson (EUS)'; 'Brazier Lachlan'; 'Jonathan Rosenberg
'; ''Fairlie-Cuninghame, Robert' '; 'sipping'
Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

In the case that there is an immediate problem with the SUBSCRIBE, why
bother to wait until the NOTIFY to say so? Do it immediately. In the case
that you've given that the SUBSCRIBE forked, and one of the entities it's
forked to returns a 2xx, and the others all return a 401, then only the
SUBSCRIBE that returned a 2xx would return a NOTIFY as well. If you can't
authenticate the user you'd want to waste the smallest possible number of
messages on them, so I would argue you'd:
SUBSCRIBE ---->
<--------- 401
...
SUBSCRIBE (credentials) ---->
<--------------------- 200 OK
<--------------- NOTIFY (2xx)
200 OK -------------------->
And leave it at that. No NOTIFY. If you can immediately dispose of the
SUBSCRIBE in a non pending or active state, just return the right return
code and be done with it. The NOTIFY would only be sent if the SUBSCRIBE was
good enough to try to form a subscription, thus putting it into a pending
(202) or active (200) state.
Why can't we put an Expires header into the message to convey the amount of
time the subcription has left? If a NOTIFY shows up with an Expires header,
the value of the expires header is the amount of time left for the
subscription. Seems easy enough to me.
If the subscription is refused, then the status of the subscription isn't
active (thus, not ok). So why not change...
Subscription-Expires: 0 refused
Subscription-Status: 200 OK
(which is ambigouous) to...
Subscription-Status: 603 Declined
Expires: 0
Which is not.
Thoughts?
Brian
-----Original Message-----
From: James Undery [mailto:[email-masked]]
Sent: Friday, November 09, 2001 3:32 AM
To: Stucker, Brian [NGB:B635:EXCH]; 'Sean Olson (EUS)'; 'Brazier
Lachlan'; 'Jonathan Rosenberg '; ''Fairlie-Cuninghame, Robert' ';
'sipping'
Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

Hi,
The most important thing about Subscription-Expires is to convey the time
the subscription is valid for, the reason phrase is the icing on the cake
;-). In your example
Subscription-Expires: 0 refused
Subscription-Status: 200 OK
I'd take this to mean the entity got the SUBSCRIBE okay and refused it
(isomorphic to a 403). However, this raises an interesting point, how would
the entity authenticate the subscriber. If the request is forked and one of
the entities it's forked to returns a 2xx then none of the others could
return 401s. My solution would be for the initial NOTIFY to include
something in the Subscription-Status header to request the subscriber
resubscribes with an Authorization header if they wish to activate this
subscription.
Which also raises the issue of how re-SUBSCRIBE should work, I believe the
subscriber should use the route-set from NOTIFY to refresh individual
subscriptions, yet the latest draft seems to suggest the original SUBSCRIBE
path should be used with the addition of the relevant tag in the To header.
Anyway enough rambling.
James
-----Original Message-----
From: Brian Stucker [mailto:[email-masked]]
Sent: 08 November 2001 17:43
To: James Undery; 'Sean Olson (EUS)'; 'Brazier Lachlan'; 'Jonathan Rosenberg
'; ''Fairlie-Cuninghame, Robert' '; sipping
Subject: RE: [Sipping] Immediate NOTIFIES change in sip-events-01

James,
Yes, it is. You struck upon a good idea!
What would we need the Subscription-Expires for if we had the
Subscription-Status header? We certainly don't want to wind up with state
confusion problems like
Subscription-Expires: 0 refused
Subscription-Status: 200 OK
What would that mean? Is it up, or not? That's why I suggested it replace
the Subscription-Expires. If we're wanting to adjust the length of the
subscription, can't we use a normal Expires header passed back in the NOTIFY
to handle this?
I can (I think) map all of the various uses of the Subscription-Expires
header into the Subscription-Status header. Let's give it a whirl....
Subscription-Expires (Maint):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I assume this is used to adjust the subscription interval.
If timer value is greater than zero...
Maps to=>   Subscription-Status: 183 Session Progress
If timer value is zero...
Maps to=>   Subscription-Status: 486, 487, 500, 503

Subscription-Expires (Refused):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Used to denote that a pending subscription was refused by the resource being
watched.
Maps to=>   Subscription-Status: 401, 402, 403, 603.
Subscription-Expires (Timeout):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Used to denote that the subscription timed out and is now gone.
Maps to=>   Subscription-Status: 408 Timeout
Subscription-Expires (Migration):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here's an interesting one. We might be able to return the contact that the
state agent migrated to (if we know it) in the NOTIFY and include the
following:
Subscription-Status: 301, 302
That would end the current subscription, and give the watcher a good idea of
who to go to to refresh the migrated subscription. If a contact is not
included, then we terminate the current subscription and send a new
subscription request in to let a proxy or server somewhere route us to the
new state agent (like the current mechanism).

On the 182 Queued, I see what you mean there, so you're right 202 Accepted
should be used for pending.

_______________________________________________
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: "James Undery" <[email-masked]>
Date: Mon, 12 Nov 2001 09:21:08 -0000

Authentication may be required by the forking proxy, however, in my opinion
it is far more likely to be done by the entity accepting the subscription.

James