Subject: [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00

From: [email-masked]
Date: Wed, 28 May 2003 10:56:52 +0300

> -----Original Message-----
> From: ext [email-masked] [mailto:[email-masked]]
> Sent: Sunday, May 25, 2003 10:40 PM
> To: Khartabil Hisham (NMP/Helsinki); [email-masked]
> Cc: [email-masked]
> Subject: Comments on draft-khartabil-simple-filter-funct-00
> 
> 
> Hisham,
> 
> I have some comments regarding 
> draft-khartabil-simple-filter-funct-00, which also have 
> potential impact on the format defined in 
> draft-khartabil-simple-filter-format-00. 
> 
> First comment relates to clause 3.3 Subscriber Generating 
> SUBSCRIBE Request and clause 3.3.3 Changing Filter Criteria 
> within a Dialog:
> 
> As I stated in my earlier email regarding the requirement 
> draft I have a concern with the replace semantics of the 
> filter criteria in the Subscribe. I am concerned that the 
> filter criteria could become quite large especially if the 
> watcher has different filter criteria for different 
> presentities within presence lists. Do we need to have every 
> refresh subscriptions include all the filter criteria for 
> every presentity being watching everytime as our goal is 
> bandwidth efficiency between the watcher and the network? I 
> think that filter criteria will be modified by watchers a lot 
> less regularly than the period of refresh subscriptions and 
> so it is better to have some very small extra overhead when 
> creating, modifying or deleting the filter than having to 
> include the filter criteria in every refresh. I think some 
> similar functionality to the partial drafts may be the way 
> forward here.

As I commented earlier, I share your concern and will look into it before the next version of the I-D is released.

> 
> Next comment is applies to clause 3.3.2 Request-URI vs. 
> Filter Criteria URI, and clause 4.1 Request-URI vs. Filter 
> Criteria URI:
> 
> IMO we should indicate in the filter criteria that the URL is 
> targeted at a particular leaf node of a particular branch of 
> a tree of resource lists (i.e is a member of a particular sub 
> list and indicate the path to the resource). 

Not sure I got your point here, but I can comment that the URI in the filter is not restricted to leaves (presentities), but may also contain list URIs. This is where the RLS comes into play.

> I think the 
> advocated approach of propagating the filter criteria to all 
> the fanned out subscriptions is going to introduce a number 
> of security and error case handling issues for example many 
> of the propagated subscriptions may have a final destination 
> at the same node resulting in a server getting multiple 
> duplicates of the same filter for the resource that it owns. 
> Also other nodes will get filters for resources that they do 
> not own (shouldn’t this result in some kind of error 
> indication back to the originator otherwise stale filter 
> criteria for resources that are no longer reachable will 
> likely accumulate in the Subscribe requests?). Also I think 
> we are increasing the potential severity of a DOS attack 
> because this approach unnecessarily duplicates the filter 
> criteria for the back end subscriptions creating more 
> messages with larger message bodies which have to be handled 
> by the server.

Only the filter concenred with the resource where the subscribe is being propagated is included. Section 4.1 says:

"   If the URI indicated by the filter criteria is for one resource who's
   URI is one of the URIs that result from a lookup, by the RLS, on the
   Request-URI, the filter criteria for that particular resource are
   extracted and propagated in the SUBSCRIBE request sent to that
   resource.  (it is possible to have more than one filter criteria in a
   SUBSCRIBE body, and therefore a filter criteria specific to a
   resource must be extracted and only that is propagated. For example,
   if the Request-URI  in a SUBSCRIBE has the value
   "sip:[email-masked]" where "[email-masked]" is a
   resource belonging to that list, and the URI in a filter criteria is
   "sip:[email-masked]", the filter criteria specific for Bob are
   extracted and placed in the body of the SUBSCRIBE sent to
   "[email-masked]"."

> 
> 
> Next comment is I think we should be clear that the filter 
> criteria only relates to the dialog that is established. If I 
> create a new subscribe-notify dialog then the filter criteria 
> for the previous dialog are not affected and do not apply to 
> the new dialog. I think this point should be clarified in 
> clause 5.2.1 Request-URI vs. Filter Criteria URI

Will clarify.

> 
> 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.

> 
> I think we need a separate mechanism to indicate the 
> difference between options 2 and 3. Also the UAC should be 
> able to indicate whether option 2 is acceptable since option 
> 2 could result in a large presence document being sent in a 
> Notify, which may not be acceptable to the UAC.

I will remove references to the word "ignore" in the next version. If a server does not like a filter, it rejects it. When it comes to authorisation, the server can examine the filter after its has applied the authorisation policy. I'll clarify that also.

> 
> Maybe we should consider defining filtering as an option-tag 
> used in Supported or Require headers. If Option 2 is 
> unacceptable to the UAC then it should use a Require:  
> Filtering in the subscribe, otherwise it uses Supported: 
> Filtering and includes a Content-Disposition header 
> indicating that the use and understanding of the body is 
> optional. If the server takes option 1 then a Require: 
> Filtering is included in the response. If option 2 is taken 
> then no Require: Filtering is in the response. Option 3 would 
> then be a 420 (if Require was in the Subscribe and the server 
> does not accept filter criteria) or 415 if the content-type 
> is not understood or some other appropriate 4xx response if 
> the problem was the filter itself. 

I think this complication is unnecessery.

Thanks for the comments.

Hisham

> 
> I am not convinced that 488 is an appropriate response as 
> this appears to be currently restricted in RFC 3261 to INVITE 
> and SDP and the body if present should contain SDP indicating 
> what SDP would be accepted. I would defer to Jonathan’s 
> opinion though on whether the usage of 488 as defined in the 
> draft is acceptable. I think we may need a new response code 
> for when some aspect of the filter is unacceptable that would 
> allow indication in the body of the part of the filter that 
> is a problem so that remedial action can be taken.
> 
> Regards
> Andrew
> 
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: [email-masked]
Date: Thu, 29 May 2003 11:31:41 -0400

Hi Hisham,

My response is included inline preceded with the usual [AA].

Regards

Andrew

  Subj:    [Simple] RE: Comments on draft-khartabil-simple-filter-funct-00 
  Date:    5/28/2003 2:56:52 AM Eastern Standard Time 
  From:    [email-masked] 
  To:    <[email-masked]>, <[email-masked]> 
  Sent from the Internet (Details) 

Hisham,

[AA] OK

[AA] see below

[AA] The text at issue here is in clause 4.1 “If the URI indicated by the filter criteria is for one resource who's URI is NOT one of the URIs that result from a lookup, by the RLS, on the Request-URI, the filter criteria are propagated to all the fanned out subscriptions. This is to accommodate the scenario where the
subscriber knows that there are sub-lists in the list that the original subscription was sent to, and the subscriber wishes to set a filter criteria for a resource in that sub-list.”

[AA] The issue that I am identifying is when the filter criteria corresponds to a resource that is a child of a sub list of the list. For instance 3 lists A, B, and C, each in different domains where A is a child of B and B is a child of C:    CàBàA

[AA] Now in the subscription to C I want to be able to include filter criteria that is targeted at a particular member of list A (Amember1). In order to target the URI member of A in the subscription to list C we need to specify the path of the URI: C->B->A->Amember1. Maybe Xpath can also be used for this purpose? For the reasons stated I think simply propagating the filter criteria corresponding to a resource unknown to the RLS to every descendent, (as I understand from this text is proposed), is a bad idea. Instead the filter criteria should only be propagated down the specific branch that contains the target. In addition to the issues raised earlier, I think also there may be privacy concerns with broadcasting the filter criteria to other branches of the tree that are possibly in different domains from the target (i.e Do you want your company to know who all your personal contacts are?)

Will clarify.

[AA] OK

[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.

[AA] This is certainly one approach we could take however this means that if I would like to use filtering but I am willing to accept the subscription without filtering then I may have to make two subscription attempts one with and one without filtering. It seems to me that it would be more efficient to use the SIP extension use negotiation capabilities (Supported and Require) for a more efficient and flexible mechanism. This is also along the lines of what is currently proposed in draft-lonnfors-simple-partial-notify where the option is there to indicate whether the use of the extension is required or not. IMO it would make sense to be consistent with subscription state handling for both partial notifications and filtering.

[AA] I don’t think this is complicated, just standard SIP extension negotiation as used in extensions such as Preconditions.

Thanks for the comments.

Hisham

> is a problem so that remedial action can be taken.

[AA] Do you have any comment on my 488 applicability comment? I think we need a response code that would allow us to include the problem filter in the body of the response.

---

From: [email-masked]
Date: Thu, 29 May 2003 11:31:41 -0400

Hi Hisham,

Regards

Andrew

Hisham,

[AA] OK

[AA] see below

Will clarify.

[AA] OK

Thanks for the comments.

Hisham