Subject: [XCON] WGLC: draft-ietf-xcon-event-package

From: Adam Roach <[email-masked]>
Date: Thu, 04 Sep 2008 08:05:21 -0500

[as chair]

The chairs would like to announce a two-week working group last call for 
the XCON event package, so that we can submit it to the IESG for 
publication. I encourage all working group participants to give the 
document one final read.

The most recent version of the document may be retrieved here:
  
http://www.ietf.org/internet-drafts/draft-ietf-xcon-event-package-01.txt

This last call period runs until Friday, September 19th.

/a

_______________________________________________
XCON mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xcon

---

From: "Stephen Connolly" <[email-masked]>
Date: Wed, 10 Sep 2008 15:11:42 +0100

I have concerns about this event package using XPath expressions.

These concerns could be resolved for me if the sel parameter was restricted
to a well defined subset of XPath.

My concerns are that without restricting the subset of XPath, clients will
need to process the updates against the XML data that was originally
received (in order to assure themselves that the XPath parsing is correct)

I think that we can easily define a set of rules on the XPath expressions
that will allow us to express any update we need, while at the same time
ensuring that clients can easily implement their own partial XPath evaluator
to allow the client to update their internal representation of the
conference data directly.

My initial stab at this would be:

XPath expressions cannot contain ..
XPath expressions cannot use any functions other than text()
XPath expressions cannot use //
XPath expressions can only use predicates where the LHS of the predicate is
limited to referencing child nodes/attributes and where the RHS is a
constant.  Predicates must be equality, and cannot be composite.

I might also consider removing the use of * and insisting that all XPath
expressions start from the root node (i.e. /)

Thus for example, the following XPath expressions would be allowed:

sel="*/users/allowed-users-list" <!-- from the example in the draft -->
sel="*/users/allowed-users-list[target/@uri =
'sip:[email-masked]<[email-masked]>']"
<!-- if we wanted to remove the entry added in the example in the draft -->
sel="*/conference-state/*/[text() = '5']/text()" <!-- the bodies of all
child nodes of conference-state nodes where the body is equal to 5 -->

Which is quite flexible, but a (relatively) simple parser can be rolled by
hand if you are mapping an internal object model as opposed to the common
data model expressed in XML.

Whereas, more complex XPath expressions would not be allowed, e.g.

sel="*/users/allowed-users-list[target/@uri =
'sip:[email-masked]<[email-masked]>'
or @method= 'refer']/../.."
sel="*/users/allowed-users-list/target[position() &gt;=4 and position
&lt;8]/../../[count(*/target[@uri =
'sip:[email-masked]<[email-masked]>'])
&lt; 1]"

Alternatively, avoid the use of XPath entirely.

-Stephen Connolly

---

From: Jari Urpalainen <[email-masked]>
Date: Tue, 16 Sep 2008 17:29:26 +0300

On Wed, 2008-09-10 at 15:11 +0100, ext Stephen Connolly wrote:
> These concerns could be resolved for me if the sel parameter was
> restricted to a well defined subset of XPath.

rfc5261 defines imo a well defined subset (and a limited one)
> 
> My concerns are that without restricting the subset of XPath, clients
> will need to process the updates against the XML data that was
> originally received (in order to assure themselves that the XPath
> parsing is correct)

personally i've no faith that _all_ changes could be represented by some
reasonable semantic meaning, so imo you MUST keep the patched cached
copy "in memory" (or otherwise as "permanent"). rfc5261 was made to
provide "generic" patching (without restricting those specific "blind"
updates), so as just to reduce the transmission needs. Also I doubt that
in reality this "additional" copy were any showstopper for clients.   
> 
> I think that we can easily define a set of rules on the XPath
> expressions that will allow us to express any update we need, while at
> the same time ensuring that clients can easily implement their own
> partial XPath evaluator to allow the client to update their internal
> representation of the conference data directly.
> 
I've used (implemented in C) a subset parser (this and xcap) and also
utilized a full XPath 1.0 parser (libxml2). So the former is pretty
straightforward to implement (once you have a decent xml parser, i.e.) 

> XPath expressions cannot contain ..
not allowed in rfc5261 either

> XPath expressions cannot use any functions other than text()
pi and comment are that hard ?

> XPath expressions cannot use //
not allowed

> XPath expressions can only use predicates where the LHS of the
> predicate is limited to referencing child nodes/attributes and where
> the RHS is a constant.  Predicates must be equality, and cannot be
> composite.
pretty close to what is in rfc5261

> I might also consider removing the use of * and insisting that all
> XPath expressions start from the root node (i.e. /)
all evaluations start from the root document node, so for not allowing
to skip the '/' character would be wrong. Also if you remove * you add
unnecessary verbosity, which contradicts with the basic aim: the patch
should be as _small_ as possible. If you really drop the base document
after the initial retrieval, you could keep the correct index numbers of
elements in your internal representation. Certainly it would be ugly but
likely to work in this "optimized" parser.   

> sel="*/users/allowed-users-list[target/@uri = 'sip:[email-masked]']"
i think you don't mean to remove <allowed-users-list>. And this kind of
selector is not allowed in rfc5261.

> sel="*/conference-state/*/[text() = '5']/text()" <!-- the bodies of
> all child nodes of conference-state nodes where the body is equal to 5
> -->
once again rfc5261 set is even smaller than this (also a bug /[.. there)
and it doesn't allow _multiple_ target nodes. For OSS submission
<http://sourceforge.net/projects/xmlpatch/> i did implement "msel"
selector but couldn't see enough reasons to push it into the base spec.

> Which is quite flexible, but a (relatively) simple parser can be
> rolled by hand if you are mapping an internal object model as opposed
> to the common data model expressed in XML.
> 
imo nothing is easy to implement, though the parser part is relatively
straightforward. What would be complex and error prone is this
"mapping", though you could probably be able to implement a very
specific one.

> sel="*/users/allowed-users-list[target/@uri = 'sip:[email-masked]'
> &lt;8]/../../[count(*/target[@uri = 'sip:[email-masked]']) &lt; 1]"

certainly skipped as well in 5261

> Alternatively, avoid the use of XPath entirely.
right, you could do e.g. a specific REST/RPC thing for this, which would
have a semantic meaning, which is/was not the purpose of rfc5261

br, jari