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

["Brian Rosen" <[e-mail]>]

Woops, left off the in line comments, they are below

> -----Original Message-----
> From: Brian Rosen [mailto:[e-mail]]
> Sent: Thursday, July 24, 2008 9:17 AM
> To: 'Hannes Tschofenig'; 'Adam Roach'
> Cc: 'GEOPRIV Working Group'; 'Rohan Mahy'; 'James Winterbottom'; 'James
> Polk'
> Subject: RE: [Geopriv] GEOPRIV Event Package Drafts (draft-ietf-geopriv-
> loc-filters, draft-polk-sip-location-get, and draft-winterbottom-sip-
> location-package)
> 
> I appreciate the review Adam did on the documents.
> 
> I will try to take a lot of his advice to re-use existing work, but I'm
> not entirely convinced that it actually is better to warp an existing doc
> to fit a new use if the warp looks ugly.  Let me cite an example:
> Motion filtering is a really basic notion for location.  However, although
> the location reporting is done lat/lon, a motion filter is nearly always
> expressed in linear meters (or other directly convertible units like
> feet).  Using the 4660/4661 paradigm, we would pretty much be constrained
> to use degrees as the units.  Conversions are, of course, possible, but
> pretty expensive using some model of the earth shape.  If you want
> accuracy (and admittedly, you often don't need much accuracy), the model
> can be somewhat complex.
> 
> Some further comments are in-line.
> 
> I think 3856 is quite sufficient for dereferencing in SIP.  I remain
> confused by what draft-polk-sip-location-get-00 is attempting to do that
> 3856 doesn't, and why some entirely new filter mechanism beyond the work
> group item on filters is needed.
> 
> Brian
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> Behalf
> > Of Hannes Tschofenig
> > Sent: Thursday, July 24, 2008 6:16 AM
> > To: Adam Roach
> > Cc: GEOPRIV Working Group; Rohan Mahy; James Winterbottom; James Polk
> > Subject: Re: [Geopriv] GEOPRIV Event Package Drafts (draft-ietf-geopriv-
> > loc-filters, draft-polk-sip-location-get, and draft-winterbottom-sip-
> > location-package)
> >
> > 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>
> > >     <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>
See comment above on units
Also note the explosion in the size of the filter, and the difference in
clarity of purpose.  It may be possible to come up with some extension to
4660/1 that makes this more reasonable.  I'll think about that.

> > >
> > > 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>
IF we accept the singh work, and IF we decide commonality with 4660/1 is
more important that the issues raised above, then I agree.

> > >
> > > ------------------------------------------------------------
> > >
> > >   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>
This one is not such a bad extension, again assuming we decide to go this
direction

> > >
> > >
> > > ------------------------------------------------------------
> > >
> > >   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>
Yes, agree, again with the caveat.

> > >
> > > ------------------------------------------------------------
> > >
> > >   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
Yeah, I can see this.  Probably more clearly than the 4660/1 connection.
We'll have to ask Aki if he would consider adding 'force'

> > >
> > > ------------------------------------------------------------
> > >
> > > 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