Of course, there is a concern that if we specify a profile, there will be consumers of filters that do not implement the full generic functionality. But I think that we can demonstrate that this complete implementation is unlikely or even impossible.
I reviewed 4661 late in the piece and made a comment about how difficult it would be to implement and how its generic nature was also its biggest weakness.
For instance, there is a requirement that if a required element is specified then that implicitly requires that all other XML nodes necessary to make the document valid. This is actually quite difficult to implement. As long as you have a simple schema, it's probably workable, but complex content models are something of a challenge. I can also give examples of cases where it is possible to specify an element in such a way that this could be achieved in several ways.
PIDF-LO is a great example of such a problem. //ca:A1 can be included, validly, in any of several trees, as you mentioned earlier.
Specifying values in the changed element is different. Implementation is relatively easy. All the filter does is establish a node set - and thereby a set of values - that the server extracts from documents and monitors for changes. That is fairly easily implementable.
I don't want this to head in a direction where we invite string matching or other such un-interoperable hacks. That is, I don't want someone to look for "//${ca}:A1" or something like that.
--Martin
> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Hannes Tschofenig
> Sent: Wednesday, 29 July 2009 8:40 PM
> To: 'Brian Rosen'; geopriv@ietf.org
> Subject: Re: [Geopriv] My concern with draft-ietf-geopriv-loc-filters-
> 05.txt
>
> I don't know how well RFC 4661 is interoperable.
>
> I care about the persons who have to implement this.
> Note that we are talking about dumping this functionality into a LIS.
> The
> LIS will most likely have to implement this functionality without
> potential
> for re-use with other applications.
>
> Maybe the implementation of RFC 4661 is simple and I am worried without
> a
> reason.
>
> Ciao
> Hannes
>
> >-----Original Message-----
> >From: Brian Rosen [mailto:br@brianrosen.net]
> >Sent: 29 July, 2009 20:52
> >To: 'Hannes Tschofenig'; geopriv@ietf.org
> >Subject: RE: [Geopriv] My concern with
> >draft-ietf-geopriv-loc-filters-05.txt
> >
> >Having looked at this, I'm wondering if restricting
> >(prohibiting) certain 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
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
