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

[Salvatore Loreto <[e-mail]>]

Hi Hannes,

maybe it should be useful try to setup a meeting between Adam and all 
the people interested on this stuff

/Sal

Hannes Tschofenig wrote:
> 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
>

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