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

From: [email-masked]
Date: Fri, 30 May 2003 17:49:57 +0300

> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> Sent: Thursday, May 29, 2003 6:32 PM
> To: Khartabil Hisham (NMP/Helsinki); [email-masked]
> Cc: [email-masked]
> Subject: Re: [Simple] RE: Comments on
> draft-khartabil-simple-filter-funct-00
> 
> > 
> > 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 authorised or pending. If 
> the implementation wants to examine the filter criteria 
> before authorising 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?

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 May 2003 19:35:06 -0400

Well, I'm not Adam but I'll comment.

I think that the operation should be atomic; if you accept the 
subscription, you also accept the filter. I think it is worth making 
this clear in the filtering mechanism spec, since it will undoubtedly 
cause confusion otherwise.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 30 May 2003 19:35:06 -0400

-Jonathan R.