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

[Hannes Tschofenig <[e-mail]>]

Hi Adam,

I was aware that the work Rohan did will be continued in the GEOPRIV 
working group as it is a chartered item and several folks asked for it 
getting completed.

I obviously wasn't aware of the document James Polk was preparing.

We did work on a HTTP dereferencing protocol in GEOPRIV and I wanted to 
accomplish the same functionality with SIP -- I couldn't figure out how 
todo that and hence I helped James Winterbottom with his work on the 
document.

I know that SIP is so complex that one needs experts to extend and use 
it but I was hoping that we could write something into a document that 
explains the poor implementer fairly quickly on how to get things done.

I would like to chat with you at the IETF meeting about the details of 
this stuff. When do you arrive?

Ciao
Hannes

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:[e-mail]">
>       <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:[e-mail]">
>       <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:[e-mail]">
>       <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:[e-mail]">
>       <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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv