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

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