Hello,

The response must be 200 OK.

What the RFC 4825 means, is that the result of the predicate application is
only valid if the result is unique. The uniqueness has to be enforced only
when dealing with predicates. Element selection without predicates can
return a list as mentioned earlier in the RFC. I admit that the wording is
not the clearest on the point.

"After the predicates have been applied, the result will be a
no-match, one element, or multiple elements. *If the result is*
*multiple elements, the node selector is invalid.* Each step in a node
selector MUST produce a single element to form the context for the
next step. This is more restrictive than general XPath expressions,
which allow a context to contain multiple nodes. *If the result is a*
*no-match, the node selector is invalid.* *The node selector is only*
*valid if a single element was selected.* This element becomes the
context for the evaluation of the next step in the node selector
expression."

Note that the example in the 6.3 is close to what your are doing.

Regards, Laurent Etiemble.

Need an IMS Client ?
Try out the Mercuro IMS Client
Full support for OMA/3GPP XCAP/XDMS
More info at: http://www.mercuro.net/

2009/11/16 Iñaki Baz Castillo <i...@aliax.net>

> El Lunes, 16 de Noviembre de 2009, Laurent Etiemble escribió:
> > Hello,
> >
> > The response should be 200 OK with the queried node.
> >
> > During the selection process, you can have a result with a list of
> matching
> > context. The uniqueness is only considered AFTER the whole criteria has
> >  been applied. As per RFC 4825 (Para 6.3), emphasis of mine:
>
> Hi, after re-reading section 6.3:
>
> "Each step in a node selector MUST produce a single element to form the
> context for the next step"
>
> So... in my case each step doesn't produce a single element (however the
> final
> node is unique). Then, sure 200 is the correct response?
>
>
> Thanks.
>
>
> > "The selection operation operates as follows.  Within the current
> >   document context, the children of that context are enumerated in
> >   document order.  If the context is the root node of the document, its
> >   child element is the root element of the document.  If the context is
> >   an element, its children are all of the children of that element
> >   (naturally).  Next, those elements whose name is not a match for
> >   NameorAny are discarded.  An element name is a match if NameorAny is
> >   the wildcard, or if it is not a wildcard, the element name matches
> >   NameorAny.  Matching is discussed below.  *The result is an ordered
> >   list of elements*.
> >
> > *The elements in the list are further filtered by the predicates*,
> >   which are the expressions in square brackets following NameorAny.
> >   Each predicate further prunes the elements from the current ordered
> >   list.  These predicates are evaluated in order.  If the content of
> >   the predicate is a position, the position-th element is selected
> >   (that is, treat "position" as a variable, and take the element whose
> >   position equals that variable), and all others are discarded.  If
> >   there are fewer elements in the list than the value of position, the
> >   result is a no-match."
> >
> > ...
> >
> > *After the predicates have been applied*, the result will be a
> >   no-match, one element, or multiple elements.  If the result is
> >   multiple elements, the node selector is invalid.  Each step in a node
> >   selector MUST produce a single element to form the context for the
> >   next step.  This is more restrictive than general XPath expressions,
> >   which allow a context to contain multiple nodes.  If the result is a
> >   no-match, the node selector is invalid.  The node selector is only
> >   valid if a single element was selected.  This element becomes the
> >   context for the evaluation of the next step in the node selector
> >   expression."
> >
> > Regards, Laurent Etiemble.
> >
> > Need an IMS Client ?
> > Try out the Mercuro IMS Client
> > Full support for OMA/3GPP XCAP/XDMS
> > More info at: http://www.mercuro.net/
> >
> > 2009/11/13 Iñaki Baz Castillo <i...@aliax.net>:
> > > Hi, please consider the following pres-rules document in which there
> > > are two rules:
> > > - id = "pres_whitelilst"
> > > - id = "black_whitelist"
> > >
> > > <?xml version='1.0' encoding='UTF-8'?>
> > > <cp:ruleset xmlns:pr="urn:ietf:params:xml:ns:pres-rules"
> > > xmlns:cp="urn:ietf:params:xml:ns:common-policy">
> > >  <cp:rule id="pres_whitelist">
> > >   <cp:conditions>
> > >     <cp:identity>
> > >       <cp:one id="sip:b...@example.org <sip%3a...@example.org> <
> sip%3a...@example.org <sip%253a...@example.org>>"/>
> > >     </cp:identity>
> > >   </cp:conditions>
> > >   <cp:actions>
> > >     <pr:sub-handling>allow</pr:sub-handling>
> > >   </cp:actions>
> > >  </cp:rule>
> > >  <cp:rule id="pres_blacklist">
> > >   <cp:conditions>
> > >     <cp:identity>
> > >        <cp:one id="sip:al...@domain.org <sip%3aal...@domain.org> <
> sip%3aal...@domain.org <sip%253aal...@domain.org>>"/>
> > >     </cp:identity>
> > >   </cp:conditions>
> > >   <cp:actions>
> > >     <pr:sub-handling>block</pr:sub-handling>
> > >   </cp:actions>
> > >  </cp:rule>
> > > </cp:ruleset>
> > >
> > >
> > > What should be the XCAP server response when receiving the following
> >
> > request?
> >
> > > GET /pres-rules/users/
> >
> >
> sip:myu...@domain.org/pres-rules/~~/cp:ruleset/cp:rule/cp:conditions/cp:ide
> > ntity/cp:o...@id= "sip:b...@example.org <sip%3a...@example.org> <
> sip%3a...@example.org <sip%253a...@example.org>>"]
> >
> > > Note that the path is not unique when arriving to
> > > "cp:ruleset/cp:rule/" as there are two <cp:rule> nodes so it's not
> > > unique.
> > > However, the final selector is unique as there is only one <cp:one>
> > > node with id="sip:b...@example.org <sip%3a...@example.org> <
> sip%3a...@example.org <sip%253a...@example.org>>".
> > >
> > > My XML parser allows it and finds the node. I think (but I'm not sure)
> > > that Xpath specifications allows it. However I don't know if XCAP
> > > protocol overrides it so the request should get a "409 Conflict".
> > >
> > > I do know that XCAP doesn't allow a Xpath selector getting more than
> > > one node, but it's not the case of the above request as I've
> > > explained. However the first portion of the Xpath
> > > "cp:ruleset/cp:rule/" is not unique (as there are two <cp:rule>
> > > nodes).
> > >
> > > So, should the XCAP server reply 409? or should accept the request and
> > > reply 200 with the fetched node in the body?
> > >
> > >
> > > Thanks a lot.
> > >
> > > --
> > > Iñaki Baz Castillo
> > > <i...@aliax.net>
> > >
> > > _______________________________________________
> > > Sip-implementors mailing list
> > > Sip-implementors@lists.cs.columbia.edu
> > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >
>
>
> --
> Iñaki Baz Castillo <i...@aliax.net>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to