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
