xpath constructions is wise. I agree suggesting specific ways (the first in
your examples) is preferred.
Do you see an actual interoperability problem, or merely an opportunity to
provide a short cut method to avoid implementing the full xpath?
Brian
> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> Sent: Wednesday, July 29, 2009 1:02 PM
> To: 'Brian Rosen'; geopriv@ietf.org
> Subject: RE: [Geopriv] My concern with draft-ietf-geopriv-loc-filters-
> 05.txt
>
> For example, RFC 4661 would allow you to detect changes in civic
> address
> tokens in the following way:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
> <ns-bindings>
> <ns-binding prefix="ca"
> urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
> </ns-bindings>
> <filter id="123" uri="sip:presentity@example.com">
> <trigger>
> <changed>//ca:A1</changed>
> </trigger>
> </filter>
> </filter-set>
>
> Or
>
> <?xml version="1.0" encoding="UTF-8"?>
> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
> <ns-bindings>
> <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
> <ns-binding prefix="gp"
> urn="urn:ietf:params:xml:ns:pidf:geopriv10"/>
> <ns-binding prefix="cl"
> urn="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"/>
> </ns-bindings>
> <filter id="1" uri="sip:presentity@example.com">
> <trigger>
> <changed>
>
> /pidf:presence/pidf:tuple/pidf:status/gp:geopriv/gp:location-
> info/cl:civicAd
> dress/cl:A1
> </changed>
> <changed>
>
> /pidf:presence/pidf:device/gp:geopriv/gp:location-
> info/cl:civicAddress/cl:A1
>
> </changed>
> <changed>
>
> /pidf:presence/pidf:person/gp:geopriv/gp:location-
> info/cl:civicAddress/cl:A1
>
> </changed>
> </trigger>
> </filter>
> </filter-set>
>
>
> Do we know anything about the implementation status of RFC 4661?
>
> Ciao
> Hannes
>
>
> >-----Original Message-----
> >From: Brian Rosen [mailto:br@brianrosen.net]
> >Sent: 29 July, 2009 18:21
> >To: 'Hannes Tschofenig'; geopriv@ietf.org
> >Subject: RE: [Geopriv] My concern with
> >draft-ietf-geopriv-loc-filters-05.txt
> >
> >Could you cite some examples, please.
> >
> >Brian
> >
> >> -----Original Message-----
> >> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> >> Behalf Of Hannes Tschofenig
> >> Sent: Wednesday, July 29, 2009 10:30 AM
> >> To: geopriv@ietf.org
> >> Subject: [Geopriv] My concern with draft-ietf-geopriv-loc-filters-
> >> 05.txt
> >>
> >> Hi all,
> >>
> >> after reading RFC 4660 and RFC 4661, which is heavily used by
> >> draft-ietf-geopriv-loc-filters-05.txt I had some concerns.
> >RFC 4661 is
> >> a very generic format for event notification filtering and
> >it is good
> >> to re-use the work that was done there. There is, however, a problem
> >> with reusing it without putting additional restrictions on
> >its usage,
> >> namely one can accomplish the similar (if not the same) effect using
> >> many different ways (at least the XML documents look different that
> >> are sent in the SUBSCRIBE body).
> >>
> >> To me that sounds a lot like the issues we went through with GML.
> >> There we also wanted to make the life of the implementer easier by
> >> restricting the available options down to an acceptable minimum.
> >>
> >> I believe we should do the same with
> >draft-ietf-geopriv-loc-filters as
> >> well.
> >> If we find a way how to accomplish a certain functionality then the
> >> structure of the XML document is going to be described in detail and
> >> that's the way how it looks like and nothing else is allowed.
> >>
> >> Do others share my concerns?
> >>
> >> Ciao
> >> Hannes
> >>
> >>
> >> _______________________________________________
> >> Geopriv mailing list
> >> Geopriv@ietf.org
> >> https://www.ietf.org/mailman/listinfo/geopriv
> >
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
