Re: [Geopriv] GEOPRIV Event Package Drafts (draft-ietf-geopriv-loc-filters, draft-polk-sip-location-get, and draft-winterbottom-sip-location-package)

Adam

Thanks for doing this analysis.  I learned a lot in what you wrote below.

I don't know if you know this, but at least I (in 
draft-polk-sip-location-get) didn't know the 
other IDs were coming - and I suspect each of the 
other authors were in the same situation.

I thought draft-ietf-geopriv-loc-filters was dead 
(from the IETF69 that presence was to be the only 
event package used for location), and didn't know 
about draft-winterbottom-sip-location-package as 
that ID was submitted after mine.  That doesn't 
make mine right, but it could give you a hint as 
to how these 3 IDs basically 'showed up at the same time'.

All that said, I can't disagree with what you 
said about draft-polk-sip-location-get below, and 
will take the guidance as 'what I should do' in the next version of the ID.

Thank you

James

At 12:30 AM 7/24/2008, Adam Roach wrote:
>Robert has asked me to review the 
>RFC3265-related work currently underway in 
>GEOPRIV, and to provide feedback where necessary.
>
>I'll preface this by saying that I am only dimly 
>aware of the overall state of GEOPRIV and its 
>documents, and I have not been following list 
>discussion. Forgive me if I show naïvité in 
>GEOPRIV-specific matters. On the other hand, I 
>believe I can render an informed opinion on the 
>RFC3265-related aspects of this work.
>
>My general impression, on first read, is that 
>there is a lot of work underway that is either 
>re-inventing solutions that are under 
>development elsewhere; or developing 
>point-solutions that are laser-specific to 
>GEOPRIV problems, when generalized solutions can 
>be developed with little or no additional effort.
>
>In the first case, I believe (based on the 
>constituents involved) that the re-invention is 
>being done because the ongoing work elsewhere 
>doesn't *quite* meet GEOPRIV's requirements. I 
>would argue that a more fruitful approach would 
>be ensuring that the mechanisms under 
>development in the various SIP working groups 
>take GEOPRIV's requirements into consideration 
>(or, where RFCs are already published, extending 
>those mechanisms instead of reinventing them). 
>In the second case, I suspect that there has 
>simply been no need to consider whether 
>particular approaches can be made general, so 
>the entire concept has simply been ignored.
>
>Some specific examples (forgive the lack of rigor in the XML):
>
>draft-ietf-geopriv-loc-filters defines a novel 
>format for conveying event filtering, even 
>though mechanisms developed and being developed 
>elsewhere can accomplish most of what is 
>desired. I'll take the "initial list of 
>Interesting Events" as a starting point.
>
>------------------------------------------------------------
>
>   1.  the resource moves more than a specific distance horizontally or
>       vertically since the last notification
>
>
>This is currently proposed to use something like:
>
>   <location-filter>
>     <movedHoriz uom="urn:ogc:def:uom:EPSG::9001">20</movedHoriz>
>     <movedVert uom="urn:ogc:def:uom:EPSG::9001">3</movedVert>
>   </location-filter>
>
>However, use of RFC4660/4661 would appear to be 
>sufficient for this purpose. Keep in mind that 
>RFC4660/4661 is *intended* to be extended by 
>specific event packages to accommodate the 
>specific data associated with those event packages.
>
>I'm going to throw out a strawman based on 4660/4661:
>
>  <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
>     <ns-bindings>
>       <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
>     </ns-bindings>
>     <filter id="123" uri="sip:presentity@example.com">
>       <trigger>
>         <changed component="latlong" by="20">
>           /gp:geopriv/gp:location-info/gml:location/gml:coordinates
>         </changed>
>       </trigger>
>       <trigger>
>         <changed component="altitude" by="3">
>           /gp:geopriv/gp:location-info/gml:location/gml:coordinates
>         </changed>
>       </trigger>
>     </filter>
>   </filter-set>
>
>Because <gml:coordinates> is effectively a 
>compound type, we're having to define a new 
>"component" attribute for <changed>, but this 
>seems a reasonable package-specific extension. 
>(This would be cleaner if we could use xpath to 
>point at a specific component of the 
>coordinates, but I'm pretty sure you can't refer 
>to sub-portions of CDATA with xpath).
>
>------------------------------------------------------------
>
>   2.  the resource exceeds a specific speed
>
>This requires just a touch of extra work which, 
>I'm happy to notice, someone has already brought 
>to the GEOPRIV working group. I would propose 
>that you leverage the new elements defined in 
>draft-singh-geopriv-pidf-lo-dynamic; and, define 
>a new attribute for the <changed> element, called "toMoreThan":
>
>  <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
>     <ns-bindings>
>       <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
>     </ns-bindings>
>     <filter id="123" uri="sip:presentity@example.com">
>       <trigger>
>         <changed toMoreThan="3">
>           /gp:geopriv/gp:location-info/gml:speed
>         </changed>
>       </trigger>
>     </filter>
>   </filter-set>
>
>------------------------------------------------------------
>
>   3.  the resource enters or exits one or more GML objects (for
>       example, a set of 2-dimensional or 3-dimensional regions)
>       included or referenced in the filter.
>
>This one is, admittedly, more tricky than the 
>rest. However, I wouldn't abandon the event 
>filter framework altogether here -- it was 
>specifically designed to be extended with new 
>trigger types. So, instead of wrapping the 
><enterOrExit> in the GEOPRIV-specific 
><location-filter>, things would work just as well with:
>
>  <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
>     <ns-bindings>
>       <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
>     </ns-bindings>
>     <filter id="123" uri="sip:presentity@example.com">
>       <trigger>
>        <gp:enterOrExit>
>         <my:Building>
>          <gml:name>Building 10</gml:name>
>          <gml:extentOf>
>            <gml:Polygon
>     srsName="urn:ogc:def:crs:EPSG::4326"
>     xmlns:gml="http://www.opengis.net/gml">
>              <gml:exterior>
>                <gml:LinearRing>
>                 <gml:posList
>                      37.41188 -121.93243
>                      37.41142 -121.93243
>                      37.41142 -121.93132
>                      37.41188 -121.93132
>                      37.41188 -121.93243
>                 </gml:posLis>
>                </gml:LinearRing>
>              </gml:exterior>
>            </gml:Polygon>
>          </gml:extentOf>
>         </my:Building>
>        </gp:enterOrExit>
>       </trigger>
>     </filter>
>   </filter-set>
>
>
>------------------------------------------------------------
>
>   4.  one or more of the values of the specified address labels has
>       changed for the resource (for example, the A1 value of the
>       civilAddress has changed from California to Nevada)
>
>This is the _exact_ kind of use case that RFC 4660/4661 was defined for:
>
>  <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
>     <ns-bindings>
>       <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
>     </ns-bindings>
>     <filter id="123" uri="sip:presentity@example.com">
>       <trigger>
>
><changed>/gp:geopriv/gp:location-info/c1:civilAddress/c1:A1</changed>
>       </trigger>
>       <trigger>
>
><changed>/gp:geopriv/gp:location-info/c1:civilAddress/c1:A2</changed>
>       </trigger>
>       <trigger>
>
><changed>/gp:geopriv/gp:location-info/c1:civilAddress/c1:A3</changed>
>       </trigger>
>       <trigger>
>
><changed>/gp:geopriv/gp:location-info/c1:civilAddress/c1:PC</changed>
>       </trigger>
>     </filter>
>   </filter-set>
>
>------------------------------------------------------------
>
>   5.  a mininum and maximum rate of reports regardless of movement
>
>Here, we leave the 4660/4661 work behind, and 
>start looking at throttling. Specifically, I 
>point to draft-niemi-sipping-event-throttle-06. 
>Admittedly, that work does not yet take into 
>account the prospect of forcing a minimum rate 
>of reports, but that is exactly the kind of 
>requirement that can be added with very little effort.
>
>So, for example, if notifications were to be 
>sent no more frequently than once every 10 
>seconds, the SUBSCRIBE message would contain an 
>Event header field looking something like this:
>
>    Event: presence;throttle=10
>
>(or, if the event package name ends up changing -- I'll comment on this below)
>
>    Event: loc-event;throttle=10
>
>Now, if we wanted to force updates to be sent 
>even when they wouldn't otherwise happen, we can 
>add another requirement to the ongoing throttle 
>work. I imagine the solution would end up 
>looking something like this (no more frequently 
>than once every 10 seconds, and no less frequently than once every 60 seconds):
>
>    Event: presence;throttle=10;force=60
>or
>    Event: loc-event;throttle=10;force=60
>
>------------------------------------------------------------
>
>Turning now to draft-polk-sip-location-get-00; 
>I'll use the various filter types in section 6 to guide the use cases:
>
>   Filter #1 - specifies that a watcher wants location from a specific
>               presentity/target, or a group of presentities/targets
>               (i.e., a bulk transfer).
>
>This is a list subscription (RFC4662) with an 
>ad-hoc URI list 
>(draft-ietf-sip-uri-list-subscribe-02) and list 
>subscribe bodies 
>(draft-roach-sip-list-subscribe-bodies-00). It 
>doesn't need to be a filter at all. (This 
>approach also gets around the some of the 
>restrictions documented in 
>draft-polk-sip-location-get, such as having the 
>same triggers for all the resources in the subscription).
>
>------------------------------------------------------------
>
>   Filter #2 - specifies which location format the watcher wants
>               returned in the NOTIFY (coordinate, civic, or future
>               location format). The watcher can place a wildcard 'any'
>               format that is available to the presentity Any filter
>               specifying more than one locationURI will have all other
>               filters applied to it within a dialog.
>
>This appears to be a straightforward application 
>of the <include> and <exclude> elements from 
>RFC4661. I'm concerned by suggestions that we 
>might define a new set of enumerated choices, 
>such as "geo-only", "civic-only", etc, when you 
>can achieve these just fine with:
>
>    <!-- civic only -->
>    <what>
>      <include 
> type="xpath">/gp:geopriv/gp:location-info/c1:civilAddress</include>
>      <exclude 
> type="xpath">/gp:geopriv/gp:location-info/gml:location</exclude>
>    </what>
>
>(and obvious variations on the theme).
>
>This is particularly nice, because it extends 
>naturally without having to define tokens for 
>every combination of location types one might want.
>
>------------------------------------------------------------
>
>   Filter #3 - a watcher could want to specify that it wants the
>               subscription to last over a period of time, or for a
>               specific number of updates.  This would be creating a
>               dialog, to have the subscription last longer than a
>               one_time_only location reply.
>
>I don't have a specific proposal here. However, 
>I feel rather strongly that any solution to this 
>kind of filter should be crafted so as to be 
>general to all event packages instead of 
>specific to GEOPRIV. I can easily imagine other 
>event packages needing to do this in the future, 
>and it would be unfortunate to force them to reinvent this particular wheel.
>
>------------------------------------------------------------
>
>   Filter #4 - a watcher could specify exactly which elements of
>               location it needs to have in the reply.
>I think this is most appropriately an extension of 4661; something like:
>
>
>    <what>
>      <include mandatory="true" type="xpath">
>        /gp:geopriv/gp:location-info/c1:civilAddress/c1:PC
>      </include>
>    <what>
>
>(where we define a new "mandatory" attribute to 
>the <include> element, or something similar).
>
>------------------------------------------------------------
>
>   Filter #5 - a watcher could add specifically which elements of
>               location it wants to have in the reply, in other words,
>               which location elements are optional to include (based
>               on availability and permissions), but not mandatory to
>               include in the notification.
>
>This is the RFC4661 <include> usage straight up.
>
>------------------------------------------------------------
>
>   Filter #6 - filter for periodic intervals
>
>See the discussion of draft-niemi-sipping-event-throttle-06, above.
>
>------------------------------------------------------------
>
>   Filter #7 - filter for triggered notifications
>
>   Filter #8 - filter for what constitutes 'movement' in Filter#7, for
>               example, how many feet did a target move since the last
>               notification, or how many fractions of a degree did a
>               target move since the last notification.
>
>
>These two filter appear to refer to most of the 
>"Interesting Events" from 
>draft-ietf-geopriv-loc-filters-02, discussed 
>above. There may be some additional work 
>necessary to specify units on the <trigger> 
>predicates, but that should be straightforward work.
>
>------------------------------------------------------------
>
>Turning finally to 
>draft-winterbottom-sip-location-package-00 -- 
>I'm a bit befuddled by this work, and I'm 
>relatively sure it's a lack of background on my part.
>
>My initial reaction is, "Why are we defining a 
>new event package for this? Why are we using a 
>different MIME type?" As far as I am aware, the 
>information that is being conveyed is precisely 
>information about a user's presence, and the 
>format being used is precisely PIDF. How is this not RFC 3856?
>
>I'm sure there are good answers to these 
>questions -- or at least, to the one about MIME 
>types. I don't necessarily want them given in 
>response to this email (as I can imaging they 
>may be elementary for most WG participants). 
>These reasons should, however, be addressed in 
>the sip-location-package document itself -- I 
>would suggest a "relationship to RFC 3856" section in the document.
>
>Also, please keep in mind that the change of 
>MIME type does not necessitate a change to the 
>event package type. It would be eminently 
>reasonable to simply define how 
>application/held+xml is used with RFC 3856. This 
>would help save you the trouble of re-inventing 
>that part of the wheel. (A casual read of the 
>proposed loc-event event package currently being 
>proposed doesn't reveal any implied requirements that make 3856 unsuitable).
>
>/a
>
>P.S. If you'll forgive a curmudgeonly comment 
>that is quite squarely in the "bike shed 
>painting" category -- Assuming GEOPRIV sees 
>reason to define a new event package, "loc-event 
>event package" is awkward to say and to type. 
>And context makes it clear that it's an event 
>package, so "-event" is completely redundant. 
>What's wrong with calling the event package "location"?

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv