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

From: "Brian Stucker" <[email-masked]>
Date: Thu, 8 Nov 2001 11:42:46 -0600

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.

Thoughts?

Brian Stucker
Nortel Networks

-----Original Message-----
From: James Undery [mailto:[email-masked]]
Sent: Thursday, November 08, 2001 11:13 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,

Close to what I suggested although, with your header Subscription-Status it
should not replace Subscription-Expires, and 182 has a totally different
meaning to pending, I'd use 202.

James

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

ACKing the response to the SUBSCRIBE seems like a bad idea. If for no other
reason than it then precludes the ability for a user to fork a SUBSCRIBE out
to create subscriptions with all of another user's contacts, without
explicit knowledge of what all those contacts are. The ACK model basically
is going to limit us to essentially no useful forking mechanism for
SUBSCRIBE/NOTIFY because we do not receive all of the provisional responses
like an INVITE does.
Using the INVITE as a model for how to process the 3-way handshake for
SUBSCRIBE/NOTIFY is really like trying to build an apple by taking apart an
orange.
We can detect forking with the mechanism Adam has proposed. We can either
accept or get rid of forked subscriptions that we didn't get the 2xx
response for with his mechanism as well. It's not broken, and it's
efficient.
If I recall, this all started around the 200/202 problem of trying to denote
if a subscription is pending. Here's a solution for that, and other
problems:
Replace the new Subscription-Expires header with a Subscription-Status
header. The contents of the header is simply a status code, and optional
reason string. We can use this new header to denote the status of the
subscription dialog itself, instead of using the message body. This is
exactly what Subscription-Expires was designed to do, but has just been
extended a bit. Make the immediate NOTIFY, and make the Subscription-Status
header mandatory in the NOTIFY for event packages in which the subscription
can have more than one state (the only package I know of that fits this bill
is for REFER, packages such as presence would require the header to be
present).
Subscription-Status: 182 Queued         => Subscription is Pending
Subscription-Status: 200 OK                     => Subscription is Active
Subscription-Status: 4xx, 5xx, 6xx              => Subscription is
Terminated
All other status-codes are not allowed as a starting point for the
discussion.
Thoughts?
Regards,
Brian Stucker
Nortel Networks

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

> Hello,
>
>as SUBSCRIBE is compared to INVITE, can't we send an ACK request to the
>response of the SUBSCRIBE? I'm not sure if a ACK would pass a
>proxy when no
>INVITE did before????
I understand what you are going for, but I have two immediate
gut reactions. 1) I hope no proxies out there try to block
an ACK because they don't remember the ACK. 2) ACK is so closely
tied to INVITE in the current spec. that it would be difficult
to extend it to other methods in most implementations.
BR,
sean

---

From: "James Undery" <[email-masked]>
Date: Fri, 9 Nov 2001 09:32:18 -0000

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

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,

_______________________________________________
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