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 at 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 at 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 at 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 at 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 at ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
