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