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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 Sep 2003 16:04:49 -0400

[email-masked] wrote:

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

This seems only an optimization to reduce the size of filters. It does 
not seem to add any significant value, except possibly in cases where 
the recipient of the filtered material is 'passing through' things to 
somebody else without having to understand them.

> - selecting all elements: //

Does this include things like 'element named <status>'?

> - selecting element using attribute and its value as key: [@x='y']

Can you give a use case for the ones below?

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 17 Sep 2003 16:04:49 -0400

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Sep 2003 18:07:48 -0400

inline.

> somebody else without having to understand them.

Right. That would include cases where status information can be 
rendered without understanding. An example would be placetype, where a 
client can render "placetype:" and the value, and it would still make 
sense.

Perhaps this is pushing it and not a real need. Overall I think we 
need some good uses cases for the various filter applications to 
understand the scope. In particular, I don't understand the 
application for a lot of the xpath rules you have asked for below. I 
still believe we can unify this between authorization and filtering, 
and you have listed, below, far more than we seem to think is needed 
for authorization. I would think that any filter use case that would 
motivate the need could be turned into an authorization use case too...

>> - selecting following and preceding elements: following:: , preceding::

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Sep 2003 18:07:48 -0400

inline.

-Jonathan R.