Subject: RE: [Simple] [Fwd: Re: NETCONF WG meeting minutes for IETF #57]

From: [email-masked]
Date: Wed, 17 Sep 2003 13:13:48 +0300

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, September 17, 2003 11:10 AM
> To: Khartabil Hisham (NMP-MSW/Helsinki)
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Simple] [Fwd: Re: NETCONF WG meeting minutes 
> for IETF #57]
> 
> > This might be true to authorisation where the presentity wants to
> > block certain information from being unwillingly delivered to
> > watchers (keeping requirements issues aside for now). But with
> > filtering, the watcher selects information it wants to see, not
> > block. In this case, the implementation at the watcher side better
> > know how to render this presence information, delivered by the PA,
> > to the watcher (end user). Therefore it can only ask for presence
> > info in an xml document it understands.
> 
> I dont agree that filters are only about watchers asking for things 
> they want. It seems perfectly reasonable to me for a watcher to say 
> "give me everything but geolocation information", because it does in 
> fact understand geoloc (and other things too), but just doesnt want 
> that information.

Ok, I was thinking that this could be done by listing all the wanted elements, which it turn eliminates the unwanted ones. But we can add explicit support for excluding elements.

> 
> That said, I'm now convinced (and already indicated in other emails) 
> that it is appropriate to base filters and authorization policiies on 
> xpath style addressing (though a subset for performance reasons). 

Here is a list of xpath style element/attribute addressing that I propose to be supported, along with some negotiable ones that need discussion. I also include a list of addressing styles that I think are not needed. If all agreed (after some discussion, of course) I can create and I-D summarising those and providing examples.

Supported
---------
Note: any combination of these is possible
- selecting root element: /
- selecting all elements: //
- selecting all enclosed elements: *
- selecting attributes: @
- selecting elements using attributes as keys: [@x]
- selecting element using attribute and its value as key: [@x='y']
- selecting descendents: descendent:: , descendent-or-self::
- selecting ancestors: ancestor:: , ancestor or self::
- selecting siblings: following-sibling:: , preceding-sibling::
- selecting following and preceding elements: following:: , preceding::

Probable support
----------------
- using the 'and' operator ('|' in xpath) to combine rules
- selecting first element: [1]
- selecting last element: [last()]
- selecting elements that don't have attributes [not(@*)]

Not needed
------------
- selecting elements with x number of children elements: count()
- selecting element using an attribute value and ignoring leading spaces in the value: normalise-space()
- selecting elements according to length of element name
- selecting elements in a certain position in a document (using mathematical expressions).

Regards,
Hisham

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