Subject: [Simple] RE: Use of 202 response for subscription with filter (was :RE: [S imple] RE: Comments on draft-khartabil-simple-filter-funct-00)

From: Adam Roach <[email-masked]>
Date: Mon, 2 Jun 2003 11:42:33 -0500

Sorry for taking so long to respond. I was trying to find the
rest of this thread, which I seem to have missed. I'll answer
with the context I can figure out from the messages I've seen.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> 
> > -----Original Message-----
> > From: ext [email-masked] [mailto:[email-masked]]
> > > 
> > > Next comment relates to clause 3.3.4 Subscriber Interpreting 
> > > SIP responses, clause 5.2 Notifier Processing SUBSCRIBE 
> > > Requests, and clause 5.4 Handling Abnormal Cases:
> > > 
> > > The meaning of 200 and 202 responses to Subscribe requests is 
> > > already defined in RFC 3265 and they relate to the state of 
> > > the subscription I don’t think we should further extend their 
> > > meaning to also include a meaning to the state of the filter 
> > > criteria. It seems the server has four basic options:
> > > 
> > > 1)  It can accept the subscription and also accept the filter 
> > > criteria. – 200 OK
> > > 2)  It can accept the subscription but ignore all the filter 
> > > criteria  - 200 OK 
> > > 3)  It can reject the subscription (which also rejects the 
> > > filter criteria) - 4xxx
> > > 4)  It can indicate that the subscription has been 
> > > understood, and that authorization may or may not have been 
> > > granted. - 202
> > 
> > I think the text as it is now is ok. Some implementations of 
> > the server might want to examine the filter after responding 
> > to the SUBSCRIBE. A 202 in this case is needed.
> > 
> > [AA] My concern is with extending the meaning of 200 OK and 
> > 202 from that stated in RFC 3265. The text of concern is in 
> > clause 5.2 “A "200" response indicates that the subscription 
> > has been accepted, the user is authorized and the filter is 
> > accepted.” AND   “A "202" response also indicates that the 
> > filter criteria have not been accepted yet.” 
> > 
> > [AA] IMO even if we go with the approach of rejecting the 
> > subscription if the filter criteria is rejected we do not 
> > need this text since the RFC 3265 wording still applies – the 
> > subscription is either rejected or authorized or pending. If 
> > the implementation wants to examine the filter criteria 
> > before authorizing the subscription then a 202 is appropriate 
> > and I think this is covered in 3265 as well. If we choose to 
> > always reject the subscription if the filter criteria is not 
> > acceptable then all we need to state in the draft is that 
> > rejection of the filter criteria means that the subscription 
> > must also be rejected as you propose below.
> > 
> 
> I still think we need to spell it out in the filtering draft. 
> What do you think Adam?

I'm all for being explicit. However, I see Andrew's concern that
the current wording appears to change what 202 means in response
to a SUBSCRIBE.

So, I would probably change the wording to more closely reflect
how Andrew describes it above: 202 still means that authorization
is pending, and that such an authorization decision may be
predicated on the contents of the filter.

On a different topic, I don't see having a notifier accept a
subscription but reject the filter as being a viable option.
I agree with Jonathan that these operations need to be atomic.
From a practical perspective, any device that puts a filter
in place certainly has a good reason for doing so, and having
the notifier ignore such a filter seems to border on malicious.

/a
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Adam Roach <[email-masked]>
Date: Mon, 2 Jun 2003 11:42:33 -0500

/a