Subject: RE: [Simple] Event Notification Filtering Drafts

From: [email-masked]
Date: Wed, 5 Nov 2003 14:17:47 +0200

Jonathan,

Thank you for the interest in this work.

Come comments inline...

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, November 04, 2003 4:55 AM
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: [Simple] Event Notification Filtering Drafts
> 
> 
> Hisham,
> 
> Thanks for your continued work on this.
> 
> A few comments. Firstly, the filter format seems quite 
> complicated. It 
> is very rich, allowing for conditional inclusions, inclusion by 
> namespace and element names, triggers of various kinds, 
> inclusions and 
> exclusions, and level filtering. As we did with xcap-auth, I 
> wonder if 
> we should scale this back a bit, and start small. Instead, focus on 
> the real must-haves that are needed today, and ensure that there is 
> sufficient extensibility to add some of the other stuff later.

Of course we can scale down. Lets me list the features and describe their importance:

- conditional inclusions: only include tuples with certain values (eg: basic value of open or class value of MMS). I think this is needed. The syntax can of course be simplified as follows:
   - remove the <condition> element
   - <include> elements carry the condition in a xpath like expression: //tuple[class="MMS"]/status

- level: if we require the subscriber to explicitly list (using <include>s) all the elements and attributes that it wants, then we can do without the levelling: descendent, ancestor, and self.

- inclusion by namespace: It could be that a subscriber does not understand all namespaces and so would like to filter out other namespaces. It does that by specifying the namespace it wants included.

- exclusion: If a subscriber explicitly specifies the includes, it no longer needs to specify the excludes. The only scenario that remains with exclude is when a subscribe includes a namespace and then wants to exclude elements from that namespace. I don't think this is so complicated and can remain.

- type: we need the namespace and xml-element types. We can do without the token.

- triggering: there are 3 ways to trigger a notification: Element/attribute value has changed, an element/attribute was added, and an element/attribute was removed.
   - changed: this is the essence of trigger filtering and is needed, IMO.
   - Added and removed: an example of this is that a notifier did not include a <contact> element in the original NOTIFY, and I want to know when the
                        <contact> element is added. I'm on the border with these 2.

> 
> Secondly, you have defined your own xpath-type syntax. Interestingly, 
> I did a similar thing in the xcap spec. Your syntax covers a superset 
> of the functionality I am providing. Can we get away with just one 
> format? 

Sure we can. They are very close as they are now. Your syntax does not allow things like // and * and you need to explicitly express the full path of an element. I'm not sure if // or * are allowed in an http URI. I think those 2 are needed for <includes>, especially if you don't care about the position that an element appears in .

> Indeed, depending on the scope there may not be a need for 
> xpath style expressions at all. I booted them out of xcap-auth, in 
> fact. i've backed down from the position that they don't make 
> sense in 
>   a filter; I think they do. However, there is still a question if 
> they are needed at all.

I think they are needed or the reasons above. We also can't mandate that any extension to pidf will not include 2 elements with the same name. eg:
<pidfext:ext1>
    <pidfext:ext2>
       <pidfext:ext1>
       </pidfext:ext1>
    </pidfext:ext2>
</pidfext:ext1>

> 
> It seems that the filter format could cause the presence server to 
> create presence documents that are not schema compliant. That shoudnt 
> be allowed. Unfortunately, its not clear that this could be known at 
> the time the filter is uploaded. How do we deal with error 
> handling in 
> this case? One option is to reduce the scope to make sure that the 
> filters cannot cause the server to create presence documents that 
> arent schema compliant.

We have text in the format draft as well as the functionality draft how to handle this. There are 2 ways: reject the request (if this is know when filter is uploaded) or the server includes all mandatory elements/attributes required to make the resulting XML document a valid one. 

> 
> There could be some potential for confusion around namespaces. You 
> need to allow for addressing of elements using fully qualified names 
> (i.e., prefix:local-name). In this case, is the prefix the 
> one defined 
> in the filter document, or in the presence document? FOr example:
> 
> filter:
> 
> <?xml version="1.0" encoding="UTF-8"?>
>     <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
>     		xmlns:foo="urn:ietf:params:xml:ns:pidf:rpid-tuple"
>     		package="presence">
>           <filter id="mess" uri="sip:[email-masked]">
>     	      <what>
>     	      		<condition base-element="//tuple" 
> type="xml-element">foo:class="IM" or rpid:class="SMS" or 
> rpid:class="MMS"
>     			</condition>
>     			<include level="self" 
> type="xml-element">//tuple</include>
>     			<include level="descendant">//tuple</include>
>     			<include level="ancestor">//tuple</include>
>                 </what>
>     	   </filter>
>     </filter-set>
> 
> 
> 
> and presence document:
> 
> <presence xmlns:foo="some-other-extension-using-class">
>    <tuple>
>      <foo:class>SMS</foo:class>
>      <basic>open</basic>
>    </tuple>
> </presence>
> 
> 
> I believe that the prefix is purely local to the XML document 
> in which 
> its defined, in whcih case the filter would remove the class element 
> in the presence document above. But, you probably want to clearly 
> define the matching operations to make sure this is so. The 
> namespaces 
> specification has some text on canonicalization which can 
> probably help.

Actually, in this example, the tuple is not selected as all. In any case, I think you are right. We need to explain this namespace issue a little more.

Regards,
Hisham

> 
> 
> 
> Thanks,
> Jonathan R.
> [email-masked] wrote:
> 
> > An update to the Event Notification Filtering solutions is 
> now available.
> > 
> > The XML format is defined in:
> > 
> http://www.ietf.org/internet-drafts/draft-khartabil-simple-fil
ter-format-01.txt
> 
> The functionality draft is defined in:
> http://www.ietf.org/internet-drafts/draft-khartabil-simple-filter-funct-01.txt
> 
> One major change in the format draft is that we removed the xpath expression and defined a trimmed down version suitable for the filtering solution needs. The functionality draft changes were minor.
> 
> The requirements drafts can be found behind the following links:
> http://www.ietf.org/internet-drafts/draft-ietf-simple-pres-filter-reqs-02.txt
> http://www.ietf.org/internet-drafts/draft-ietf-simple-winfo-filter-reqs-00.txt
> 
> There has been no update to the requirements document due to lack of comments.
> 
> Regards,
> Hisham
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

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

---

From: [email-masked]
Date: Wed, 5 Nov 2003 14:17:47 +0200

Jonathan,

Come comments inline...

Regards,
Hisham

ter-format-01.txt