Subject: [Sipping] draft-vakil-sipping-Notify-pause-01

From: "Brian Stucker" <[email-masked]>
Date: Thu, 26 Jul 2007 13:33:07 -0500

Mohammad,

Have you considered adding an options-tag to your draft so it's very
explicit at the device whether or not the notifier understands and is
willing to accept your extension? Also, I assume in the next revision
you'll remove the bit about not sending the immediate notification sent
back to the SUBSCRIBE message itself? Not doing so would break the
behavior of 3265 when the SUBSCRIBE forks.

Regards,
Brian
_______________________________________________
Sipping mailing list  https://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: Mohammad Vakil <[email-masked]>
Date: Thu, 26 Jul 2007 11:55:10 -0700

Brian,

Yes, I'm planning on adding option-tag of "notify-pause" to the next version. Secondly, I'll clarify about the first notify as a result of initial subscription, which would always be sent. Are you referring to all the notification resulting from refresh subscription with notify=off?

Thanks,
-Mohammad

From: Brian Stucker [mailto:[email-masked]]
Sent: Thursday, July 26, 2007 11:33 AM
To: Mohammad Vakil
Cc: [email-masked]
Subject: draft-vakil-sipping-Notify-pause-01

Mohammad,

Have you considered adding an options-tag to your draft so it's very explicit at the device whether or not the notifier understands and is willing to accept your extension? Also, I assume in the next revision you'll remove the bit about not sending the immediate notification sent back to the SUBSCRIBE message itself? Not doing so would break the behavior of 3265 when the SUBSCRIBE forks.

Regards,
Brian

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 26 Jul 2007 14:08:39 -0500

Initial subscription, but I would encourage the refresh subscription to
also generate an immediate NOTIFY to simplify the processing in the
notifier to the existing case: I get a SUBSCRIBE, I send a NOTIFY. It's
just the interim notifications that can benefit from throttling. If the
device is contacting the network, I think it's fair to expect that they
are prepared to receive a NOTIFY for their effort (plus a notifier not
compliant is going to send it to you anyway).
 
Regards,
Brian

________________________________

	From: Mohammad Vakil [mailto:[email-masked]] 
	Sent: Thursday, July 26, 2007 1:55 PM
	To: Stucker, Brian (RICH1:AR00)
	Cc: [email-masked]
	Subject: RE: draft-vakil-sipping-Notify-pause-01

	Brian, 

	Yes, I'm planning on adding option-tag of "notify-pause" to the
next version. Secondly, I'll clarify about the first notify as a result
of initial subscription, which would always be sent. Are you referring
to all the notification resulting from refresh subscription with
notify=off? 

	Thanks,

	-Mohammad 

	Mohammad, 

	Have you considered adding an options-tag to your draft so it's
very explicit at the device whether or not the notifier understands and
is willing to accept your extension? Also, I assume in the next revision
you'll remove the bit about not sending the immediate notification sent
back to the SUBSCRIBE message itself? Not doing so would break the
behavior of 3265 when the SUBSCRIBE forks.

	Regards, 
	Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2007 15:45:57 -0400

Its not apparent to me that an option tag is needed, since the 
subscriber can cope whether the feature is supported or not. Support can 
be signaled by the presence of the event header parameter in the 
response to the subscribe and the NOTIFY. Lacking such indication of 
support the subscriber will know that the functionality isn't available, 
and it will have to carry on without it.

	Paul

Brian Stucker wrote:
> ------------------------------------------------------------------------
>

---

From: Mohammad Vakil <[email-masked]>
Date: Thu, 26 Jul 2007 13:22:35 -0700

Paul,

Shouldn't we at least specify this option-tag, and it's up to the implementation to use it optionally? They may require or they may not make it mandatory.

Thanks,
-Mohammad

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Thursday, July 26, 2007 12:46 PM
To: Brian Stucker
Cc: Mohammad Vakil; [email-masked]
Subject: Re: [Sipping] draft-vakil-sipping-Notify-pause-01

        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2007 16:28:50 -0400

> compliant is going to send it to you anyway).

Not sending any NOTIFY when resubscribing with notify=off is a feature. 
The extra messages are, well, extra and undesired in this case.

	Paul

>     *From:* Mohammad Vakil [mailto:[email-masked]]
>     *Sent:* Thursday, July 26, 2007 1:55 PM
>     *To:* Stucker, Brian (RICH1:AR00)
>     *Cc:* [email-masked]
>     *Subject:* RE: draft-vakil-sipping-Notify-pause-01
> 
>     Brian,
> 
>      
> 
>     Yes, I’m planning on adding option-tag of “notify-pause” to the next
>     version. Secondly, I’ll clarify about the first notify as a result
>     of initial subscription, which would always be sent. Are you
>     referring to all the notification resulting from refresh
>     subscription with notify=off?
> 
>      
> 
>     Thanks,
> 
>     -Mohammad
> 
>      
> 
>     *From:* Brian Stucker [mailto:[email-masked]]
>     *Sent:* Thursday, July 26, 2007 11:33 AM
>     *To:* Mohammad Vakil
>     *Cc:* [email-masked]
>     *Subject:* draft-vakil-sipping-Notify-pause-01
> 
>      
> 
>     Mohammad,
> 
>     explicit at the device whether or not the notifier understands and
>     is willing to accept your extension? Also, I assume in the next
>     revision you'll remove the bit about not sending the immediate
>     notification sent back to the SUBSCRIBE message itself? Not doing so
>     would break the behavior of 3265 when the SUBSCRIBE forks.
> 
>     Regards,
>     Brian
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2007 16:40:26 -0400

This is the same issue that came up in some other context earlier in the 
week. Jonathan described why an option tag wasn't needed in that case. 
This one is almost the same.

The option tag doesn't help either the subscriber or the notifier, so 
why have it?

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Thu, 26 Jul 2007 16:52:09 -0500

> Sent: Thursday, July 26, 2007 3:29 PM
> Subject: Re: [Sipping] RE: draft-vakil-sipping-Notify-pause-01
> 
> 
> 
> Brian Stucker wrote:
> > Initial subscription, but I would encourage the refresh 
> subscription 
> > to also generate an immediate NOTIFY to simplify the 
> processing in the 
> > notifier to the existing case: I get a SUBSCRIBE, I send a NOTIFY. 
> > It's just the interim notifications that can benefit from 
> throttling. 
> > If the device is contacting the network, I think it's fair 
> to expect 
> > that they are prepared to receive a NOTIFY for their effort (plus a 
> > notifier not compliant is going to send it to you anyway).
> 

Sorry, but I disagree. I don't see a large benefit to changing the usual
SUBSCRIBE-NOTIFY stimulus pattern when the primary goal of the mechanism
is to address notifications that are generated as a result of a PUBLISH
(or similar action).

What is the feature to be had here? If you send the NOTIFY to the
SUBSCRIBE then I think this fits well with what is already in RFC-3265
section 3.2.2:

---
3.2.2. Notifier NOTIFY Behavior

   When a SUBSCRIBE request is answered with a 200-class response, the
   notifier MUST immediately construct and send a NOTIFY request to the
   subscriber.  When a change in the subscribed state occurs, the
   notifier SHOULD immediately construct and send a NOTIFY request,
   subject to authorization, local policy, and throttling
   considerations.
---

The notify= value becomes an input to the local policy/throttling
mechanism without touching the normative MUST at the top of the section.

Further, you need to get the subscription-state header value for your
SUBSCRIBE which is in the NOTIFY to the SUBSCRIBE. 

What happens if you send SUBSCRIBE with notify=off (with the notifier
using your logic above) when the subscription is terminated while
processing the SUBSCRIBE? The notifier doesn't send a NOTIFY, and that's
what the client was expecting technically but for entirely different
semantics. The UA thinks the notifications are paused when the
subscription is really terminated.

How about a deactivated subscription because the notifier is moving to a
different box for maintenance reasons and wants to get the UA to
re-subscribe to the new box? How would the UA get a correct subscription
expiry value for their subscription if they don't get the NOTIFY to
their subscribe with the Subscription-State header.

Is this the feature you want?

Just keep it simple: send the NOTIFY to the SUBSCRIBE always, let the
semantics of the notify= value apply only to what's triggered by state
changes at the ESC (e.g. PUBLISH), avoid these weird error cases and use
that time to enjoy a beer instead.

Regards,
Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2007 19:40:19 -0400

inline

> is to address notifications that are generated as a result of a PUBLISH

Well, the benefit is eliminating the notify and response, including 
whatever body that would have been included in it.

You might argue that the messages are not a big deal, but the body 
certainly could be. An alternative, which was discussed, is to introduce 
the notions of persistent vs. one-time filters. That would be an 
alternative, but this seemed simpler.

>    subject to authorization, local policy, and throttling

It is true that as proposed this would be a change to 3265. I don't see 
that as a big deal. I don't think has more significance on the 
implementation.

> subscription is really terminated.

Well, you do highlight one thing: the NOTIFY can't be suppressed if the 
subscription state is terminated. And it probably should not be 
suppressed if the expiration time of the subscription has been changed 
(from what it would be if it had just continued to count down from when 
it was last changed.)

> that time to enjoy a beer instead.

Well, its not my draft.

As I mentioned above, another possibility that came up in discussion was 
to introduce one-time filters in addition to persistent filters. So you 
could send the "I don't want anything"  persistent filter as alternative 
to notify=off, and then do notify=once with a one-time filter of "show 
me everything" (or whatever you do want). I don't what Mohammad thinks 
of such an approach.

I think either way can be made to work while addressing the issues you 
raise.

	Paul