Subject: [sipcore] 3265bis: 200, 202 and filters

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 8 Sep 2009 22:07:06 +0200

Hi,

When reading section 3.3.4 of RFC 4660 it seems that, when the filter
mechanism is used, 200 and 202 responses have different meaning to the
subscriber: 200 means that the filter was accepted, while 202 means that
the filter has yet not been accepted.

(The RFC does not explicitly say how the client will find out in case of
forking (the client never gets the 200/202), but I assume it will figure
it out based on whether the NOTIFY contains state information or not?)

In any case, in 3265bis, would we need to say that subscription
extensions CAN define usages of both 200 and 202, event if the default
would be to always use 202?

Are there any other extensions with similar issues? 

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Tue, 08 Sep 2009 15:30:38 -0500

On 9/8/09 15:07, Sep 8, Christer Holmberg wrote:
> subscriber: 200 means that the filter was accepted, while 202 means 
> that the filter has yet not been accepted.
>

The behavior of 202 in 4660 is consistent with that of 202 in 3265. And, 
because it suffers the forking problem, it's equally useless. I don't 
think discouraging the sending of 202 in 3265bis will impact 4660 
implementations negatively.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 9 Sep 2009 07:26:41 +0200

Hi,
 
>>When reading section 3.3.4 of RFC 4660 it seems that, when the filter mechanism is used, 200 and 202 >>responses have different meaning to the subscriber: 200 means that the filter was accepted, while 202 means >>that the filter has yet not been accepted.
>
>The behavior of 202 in 4660 is consistent with that of 202 in 3265. And, because it suffers the forking >problem, it's equally useless. I don't think discouraging the sending of 202 in 3265bis will impact 4660 >implementations negatively.
 
The draft talks about removing the 202 response.
 
Regards,
 
Christer

---

From: Adam Roach <[email-masked]>
Date: Wed, 09 Sep 2009 10:17:03 -0500

> The draft talks about removing the 202 response.

The discussion in Sweden basically resolved to adding text that 
basically says "don't send it, and don't expect it, but don't choke on 
it either."

I don't see how 4660 impacts the decision either way.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 10 Sep 2009 07:02:09 +0200

Hi, 

>>>>When reading section 3.3.4 of RFC 4660 it seems that, 
>>>>when the filter mechanism is used, 200 and 202 >>responses 
>>>>have different meaning to the subscriber: 200 means that the 
>>>>filter was accepted, while 202 means >>that the filter has 
>>>>yet not been accepted.
>>>>       
>>>>The behavior of 202 in 4660 is consistent with that of 202 
>>>>in 3265. And, because it suffers the forking >problem, it's 
>>>>equally useless. I don't think discouraging the sending of 
>>>>202 in 3265bis will impact 4660 >implementations negatively.
>>>     
>>  
>The discussion in Sweden basically resolved to adding text 
>that basically says "don't send it, and don't expect it, but 
>don't choke on it either."
> 

It is probably just a wording issue. I simply ask that we choose a
wording so that nobody later can claim that 4660, since it does send
202, goes against 3265bis.

It is similar to INFO, where we have wording saying that just because we
now require info events legacy usage of INFO is still "valid".

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 11 Sep 2009 12:30:13 +0200

Hi,

Section 4.2.1.2 in 3265bis says:

"Upon successfully accepting or refreshing a subscription, notifiers
MUST send a NOTIFY message immediately to communicate the current
resource state to the subscriber."

Now, RFC 4660 allows the subscriber to, using the filter <trigger>
element, indicate when notifications are to be sent. 

I ASSUME that, whatever filter one specifies, that MUST NOT affect the
fact that the notifier must send a NOTIFY request immediately after
accepting a subscription. I don't find any text about that in RFC 4660.

When forking occurs this issue exists already in 3265.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 11 Sep 2009 12:33:52 +0200

Actually, subclause 3.3.4 of 4660 says that a 200-class response will
always trigger a NOTIFY, and that the filter acceptance may come later,
so I assume there is no issue.

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 11. syyskuuta 2009 13:30
> To: [email-masked]
> Subject: [sipcore] 3265bis: Filters and first notify
> 
> 
>  
> Hi,
> 
> "Upon successfully accepting or refreshing a subscription, 
> notifiers MUST send a NOTIFY message immediately to 
> communicate the current resource state to the subscriber."
> 
> Now, RFC 4660 allows the subscriber to, using the filter 
> <trigger> element, indicate when notifications are to be sent. 
> 
> I ASSUME that, whatever filter one specifies, that MUST NOT 
> affect the fact that the notifier must send a NOTIFY request 
> immediately after accepting a subscription. I don't find any 
> text about that in RFC 4660.
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Sep 2009 11:00:01 -0400

ISTM that the initial NOTIFY following a SUBSCRIBE, or especially a 
reSUBSCRIBE, is often a significant concern in the design of features. I 
think it would be advantageous if it was possible to design a filter 
that could intentionally suppress that first notify.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Sun, 13 Sep 2009 13:58:25 -0500

On 9/11/09 10:00, Sep 11, Paul Kyzivat wrote:
> reSUBSCRIBE, is often a significant concern in the design of features. 
> I think it would be advantageous if it was possible to design a filter 

Subnot-etags provides that functionality -- at least, for resubscribes. 
You can't suppress the initial NOTIFY in a subscription due to the 
potential for forking.

/a

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 13 Sep 2009 21:59:33 +0200

Hi,

>You can't suppress the initial NOTIFY in a subscription due to the

So, just to clarify:

Since you can suppress the initial NOTIFY (at least for resubscribes) that means that the SUB 200 OK will terminate the re-transmission of the SUB request - normal SIP transaction handling, that is.

So, also for initial subscriptions, I assume the 200 OK will also terminate the re-transmission of the SUB requests - even if the associated DIALOG will not be established until the initial INVITE arrives.

Correct?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 13 Sep 2009 16:04:10 -0400

> Subnot-etags provides that functionality -- at least, for resubscribes. 

That covers a lot of cases, but maybe not all.
For instance, suppose you want to change the scope of a filter, so it 
filters out more information than it did before. In many cases the 
information that would be returned in the initial notify after that 
change will just be the new subset of what was previously received, and 
you wouldn't want to receive that. But I *think* the etag will be 
different for that, won't it? So you will have no way to suppress that 
notify.

That seemed to be the kind of thing that might happen with the 
geolocation filtering that was discussed some time ago.

> You can't suppress the initial NOTIFY in a subscription due to the 

I understand that.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 13 Sep 2009 22:37:33 +0200

Hi Paul,
 
For filters, remember that the first NOTIFY (the first NOT sent after each SUB/re-SUB has been received, that is) does not necessarily contain the information based on the filters. So, even if you would supress that first NOTIFY, I believe you may still receive the "subset" information in a later NOTIFY.
 
Regards,
 
Christer

________________________________

From: Paul Kyzivat [mailto:[email-masked]]
Sent: Sun 13/09/2009 22:04
To: Adam Roach
Cc: Christer Holmberg; [email-masked]
Subject: Re: [sipcore] 3265bis: Filters and first notify

I understand that.

        Thanks,
        Paul