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

Hi Folks,

As the original author of draft-ietf-geopriv-loc-filters I would like  
to provide some explanation of what I was thinking.  I no longer have  
any plans to stay actively involved with this work, but I at least  
hope that others have the option of understanding where I was coming  
from and my current beliefs on the subject.

First, the last version of the draft for which I was the editor  
referenced the throttle mechanism in the Niemi draft, and I agree  
with Adam that the throttle mechanism is still the correct way to  
solve that problem.  I think this is somewhat unrelated to the rest  
of the issues in Adam's email.

Next, I think there are many good technical reasons to have a set or  
family of multiple filter mechanisms. I would like to point out that  
draft-ietf-geopriv-loc-filters predates RFC4660/4661 (and its source  
I-Ds). RFC4660 describes itself as *the* filter mechanism instead of  
*a* filter mechanism, but RFC4660 was not the first nor will it be  
the last such filter mechanism proposed. I see a number of problems  
with using only the RFC4660 event filtering mechanism for the uses  
described in draft-ietf-geopriv-loc-filters. One of these problems is  
difficulty in negotiating support for the necessary extensions. How  
does a subscriber find out if all the right bits for location  
filtering are supported? By using a separate filter body, that  
negotiation can be done explicitly based on MIME type and the built- 
in RFC 3261/3265 negotiation mechanism, instead of implicitly based  
on some vague combination of factors.

The other major technical problem I see relates to representing  
continuously variable quantities. I think the semantics and  
processing of the filter in RFC4660/4661 is cumbersome in the  
specific case of smooth gradients. RFC4660/4661 is a filter format  
and package designed to filter discrete changes in an XML document.  
To use the RFC4661 filter body generically on continuous gradients  
requires the notifier to constantly regenerate a dynamic XML document  
and the filter format to figure out if the document has changed. For  
example, a subscriber interested in the location of the piece of  
medical equipment (say a dialysis machine) does not care about small  
motions of the machine from one side of the room to another, but it  
does care about the equally small movement between a room and the  
hallway and vice versa. Generating an XML document for every actual  
movement before you can figure out if the movement is relevant is  
pretty absurd and will never scale even on a single system.  
Alternatively the notifier could treat gradients as a special case  
and treat them effectively as a completely different type of filter.  
I think it is cleaner and easier to explicitly describe and implement  
as a separate filter on the wire.

Finally, much of my motivation for this work is my belief that it is  
useful to have a moderately narrow "classic" definition of presence,  
and to have other event packages as first class citizens who are  
peers with the presence event package.  My moderately narrow  
definition of "classic presence" means "willingness and availability  
to communicate". In my view this "classic presence" always contains  
willingness and availability status, but can contain all manner of  
other supplementary information including (possibly obfuscated,  
fuzzed, and filtered) location data, offhook status, and calendar  
data. However, I believe there are many times when a subscriber who  
is not a watcher wants to get only (raw) location, calendar, or  
dialog status from a notifier (who is not a presentity) as a first  
class object. This is the case for the dialysis machine example. I  
designed the filter format so it would be hopefully useful whether it  
was contained in a presence subscription (supplementary location) or  
a separate location event package of some kind.

I hope this explains the motivation a bit better.

thanks,
-rohan

On Jul 23, 2008, at 11:30 PM, 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