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

From: Adam Roach <[email-masked]>
Date: Thu, 24 Jul 2008 00:30:29 -0500

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:[email-masked]">
       <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:[email-masked]">
       <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:[email-masked]">
       <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:[email-masked]">
       <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
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 24 Jul 2008 01:34:31 -0500

Adam

Thanks for doing this analysis.  I learned a lot in what you wrote below.

I don't know if you know this, but at least I (in 
draft-polk-sip-location-get) didn't know the 
other IDs were coming - and I suspect each of the 
other authors were in the same situation.

I thought draft-ietf-geopriv-loc-filters was dead 
(from the IETF69 that presence was to be the only 
event package used for location), and didn't know 
about draft-winterbottom-sip-location-package as 
that ID was submitted after mine.  That doesn't 
make mine right, but it could give you a hint as 
to how these 3 IDs basically 'showed up at the same time'.

All that said, I can't disagree with what you 
said about draft-polk-sip-location-get below, and 
will take the guidance as 'what I should do' in the next version of the ID.

Thank you

James

At 12:30 AM 7/24/2008, 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 
>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.
>
>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.
>
>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.
>
>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).
>
>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":
>
>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:
>
>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:
>
>(or, if the event package name ends up changing -- I'll comment on this below)
>
>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):
>
>Turning now to draft-polk-sip-location-get-00; 
>I'll use the various filter types in section 6 to guide the use cases:
>
>(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).
>
>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 
>This is particularly nice, because it extends 
>naturally without having to define tokens for 
>every combination of location types one might want.
>
>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, 
>(where we define a new "mandatory" attribute to 
>the <include> element, or something similar).
>
>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> 
>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"?

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Jul 2008 13:15:59 +0300

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:
> 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 
> elsewhere can accomplish most of what is desired. I'll take the 
> "initial list of Interesting Events" as a starting point.
>
> 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.
>
> 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).
>
> draft-singh-geopriv-pidf-lo-dynamic; and, define a new attribute for 
> the <changed> element, called "toMoreThan":
>
> 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 
> 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.
>
> than once every 10 seconds, the SUBSCRIBE message would contain an 
> 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):
>
> 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?
>
> 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.
>
> 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 
> 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"?

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 24 Jul 2008 09:17:25 -0400

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: [email-masked] [mailto:[email-masked]] 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,
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 24 Jul 2008 09:31:11 -0400

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

> From: Brian Rosen [mailto:[email-masked]]
> 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-
> 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:
> 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.
> 

> > >           /gp:geopriv/gp:location-info/gml:location/gml:coordinates
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.

> > > but I'm pretty sure you can't refer to sub-portions of CDATA with
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.

This one is not such a bad extension, again assuming we decide to go this
direction

> > > <changed>/gp:geopriv/gp:location-info/c1:civilAddress/c1:PC</changed>
Yes, agree, again with the caveat.

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'

---

From: Adam Roach <[email-masked]>
Date: Thu, 24 Jul 2008 13:56:46 -0500

> explains the poor implementer fairly quickly on how to get things done.

Yes, a non-normative informational call-flows document that helps tie it 
all together is a great idea.

> this stuff. When do you arrive?

I'm landing on Saturday morning, though I'm not certain whether I'll 
spend Saturday out at the hotel or back towards civilization.

/a

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 24 Jul 2008 22:00:26 +0300

Hi Hannes,

maybe it should be useful try to setup a meeting between Adam and all 
the people interested on this stuff

/Sal

Hannes Tschofenig wrote:
> 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.
>
>> 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.
>>
>> 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.
>>
>> by specific event packages to accommodate the specific data 
>> associated with those event packages.
>>
>> 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).
>>
>> reports, but that is exactly the kind of requirement that can be 
>> added with very little effort.
>>
>> restrictions documented in draft-polk-sip-location-get, such as 
>> having the same triggers for all the resources in the subscription).
>>
>> This is particularly nice, because it extends naturally without 
>> having to define tokens for every combination of location types one 
>> might want.
>>
>> 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.
>>
>> (where we define a new "mandatory" attribute to the <include> 
>> element, or something similar).
>>
>> 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.
>>
>> a user's presence, and the format being used is precisely PIDF. How 
>> is this not RFC 3856?
>>
>> 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

---

From: Adam Roach <[email-masked]>
Date: Thu, 24 Jul 2008 14:50:01 -0500

> accuracy (and admittedly, you often don't need much accuracy), the model

As I understand things, the conversion from °/'/" to meters has to take 
place somewhere in the system. You're arguing for a model in which the 
LIS applies a one-size-fits-all conversion. Using 4660/4661 most 
naturally lends itself to a a requestor-supplied conversion.

As you point out, in most cases the accuracy is not that critical for a 
filter -- triggering on a move that is 1 meter versus 1.0073 meters will 
result in similar enough user experience as to make no difference. On 
the other hand, the entity that best knows what level of accuracy is 
required will be the requestor. So, if he knows that the trigger is very 
approximate, he can approximate the earth as a smooth sphere and get 
perfectly adequate results. If higher precision is needed for some 
reason, he can apply an appropriately complex conversion model.

On the other hand, if the LIS is performing the conversion, it must 
convert using a the most complex model required by any client.

> Some further comments are in-line.

Responses to one block of comments below.

>>>           /gp:geopriv/gp:location-info/gml:location/gml:coordinates
...
> clarity of purpose.

Yes. Point solutions will pretty much always be more concise than general tools that can be used to build solutions. On the other hand, they're usually not as flexible, and hamper future innovation.

I would point you to <http://tools.ietf.org/html/draft-ohta-notasip-04> and its companion <http://tools.ietf.org/html/draft-fujikawa-iphone-url-01> as an example.

> It may be possible to come up with some extension to

That would be a good approach. Another point I meant to make in my previous email is that I'm concerned that GEOPRIV will come up with all these nice means of talking about PIDF-LO that are completely immiscible with the ways that we can talk about PIDF. I would like to be able to subscribe to a presence server that includes all kinds of user presence -- including location -- and apply the filters that GEOPRIV is defining as well as the normal PIDF filters defined in 4661. If you use something outside the 4660/4661 framework, I'm left having to reinvent all that work.

/a

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 25 Jul 2008 09:01:02 -0600

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:
> 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  
> 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.
>
> 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.
>
> 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.
>
> 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).
>
> 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  
> 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  
> 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:
>
> 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):
>
> 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>
>
> 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.
>
> 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  
> most WG participants). These reasons should, however, be addressed  
> in the sip-location-package document itself -- I would suggest a  
> 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.

---

From: Adam Roach <[email-masked]>
Date: Fri, 25 Jul 2008 10:39:03 -0500

> from and my current beliefs on the subject.

Thanks for weighing in. I appreciate understanding the historical basis 
for the decisions made in the development of this docment.

> 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.
>
> I-Ds). 

That does go a long way towards explaining the divergent formats.

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

Well, at least *the* filter format for PIDF and its extensions.

Your implications about the immediate necessity for alternate formats 
confuses me a bit. 4660/4661 was explicitly designed to be arbitrarily 
extensible. In a degenerate case, you could take all the syntax defined 
in geopriv-loc-filters and wedge it into the 4661 syntax (with 
accompanying description of semantics). Now, I clearly think that's the 
wrong thing to do, but it certainly would address a substantial portion 
of my concerns.

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

Require/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.

MIME-type is a very blunt (and often ambiguous) instrument for 
negotiating support of a protocol feature. If I advertise that I 
understand "application/resource-lists+xml", am I saying that I support 
ad-hoc list subscriptions, or subscriptions to XCAP documents?

We have an explicit feature negotiation mechanism for this kind of 
thing. It seems a more appropriate choice.

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

Generation of a literal, serialized XML document and then running a 
conventional XPATH expression across it is certainly one very simplistic 
way that this could be implemented, but it is certainly not the only one.

Fundamentally, XML is just a textual representation of a tree of data. 
The underlying tree can be indexed, and the nodes indicated by XPATH 
expressions can be cached for O(1) operation on live data. Done 
correctly, this won't be any more inefficient than any other approach.

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

As I mentioned initially, I haven't followed the development of this 
document, so I don't know whether the property of being useful in 
conjunction with other 4461 criteria was in earlier drafts. But that 
capability is certainly absent now. Or perhaps I'm missing something 
that you can clear up.

Can you show an example of a filter that says, "I want to be notified 
whenever sip:[email-masked] changes from closed to open or moves more 
than 15 feet"?

/a

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 28 Jul 2008 07:47:40 -0700

Hi Adam,

I don't want this thread to devolve into me sending periodic rants to  
this mailing list. I have a philosophical difference of opinion here  
with many of the other core contributors. While my opinion was formed  
based on technical grounds, there are many who don't care about the  
use cases I care about--especially the case where a commercial  
"location server" provides location about a bunch of objects, many of  
which have no classic presence.  However, the industry cares deeply  
about this use case. I urge all of you to ask the question "what if I  
don't care at all about presence" at least once a day when working on  
location issues.

I'm not planning to reply further to this thread. Adam, if you don't  
understand some aspect of my opinion and you want to understand it,  
feel free to call my cell. I would be happy to catch up on life,  
family, and then settle in for a good discussion. If you understand  
where I am coming from but just don't agree, that's fine.

> Rohan Mahy wrote:
[snip]
> Well, at least *the* filter format for PIDF and its extensions.

I don't agree that this is a good idea. The choice of using PIDF to  
carry location was a decision based on the faulty logic that location  
of all kinds will always be carried around with bona fide presence.  
This assumption turned out to be patently false. While the choice of  
PIDF as a container for location is water under the bridge and a  
format that we can and will live with, I don't believe we should  
follow this chain of logic further ad absurdium with the one-size- 
fits-all arguments that got us there.

> Your implications about the immediate necessity for alternate  
> formats confuses me a bit. 4660/4661 was explicitly designed to be  
> arbitrarily extensible.

Yes. One of the big problems I have is with the overuse of these  
"generic" container formats. I think we have made a mess of PIDF, but  
we have been able to salvage it. I think the problem with resource  
lists you point out later in the thread is due to improper reuse, and  
I think RFC4661 is a nice format for a specific task, but poorly  
designed for use in a generic framework.

> In a degenerate case, you could take all the syntax defined in  
> geopriv-loc-filters and wedge it into the 4661 syntax (with  
> accompanying description of semantics). Now, I clearly think that's  
> the wrong thing to do,

as do I.

> but it certainly would address a substantial portion of my concerns.
>
>> 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?
>
> Require/Supported?

This is a very large and very blunt instrument and currently one that  
requires the the SIP WG to get involved according to our change  
process.  Do you actually have a *practical* way to negotiate support  
for location filtering?  I think the mechanism I was envisioning is  
practical and narrow.

Let's take two cases.  In the first I subscribe to the presence event  
package. I can include a geo-filter in the SUBSCRIBE. If the notifier  
does not support the geo-filter, it rejects the subscription. The  
subscriber can resubscribe with no filter body and just rely on  
notification throttling or let the server send notifications at  
whatever rate it wants. Alternatively the subscriber can decide that  
this notifier is lame and give up.  This works and allows the  
subscriber to request (upshift) to new functionality with full  
backwards compatibility.

In the second case, the subscriber wants pure unadulterated numeric  
location (WGS84 or local coordinate reference frame) by subscribing  
to a possibly future defined location event package. It seems likely  
that support this geo-filter would be required for any such location  
event package. It also seems likely that none of the XML document  
evaluation of RFC 4661 would be needed.  The MIME type negotiation  
mechanism allows a future replacement (a future upshift) if we botch  
the geo-filter format.

> negotiating support of a protocol feature.

I disagree.  It is certainly a more narrowly focussed instrument than  
Require/Supported.  See my description above for

> If I advertise that I understand "application/resource-lists+xml",  
> am I saying that I support ad-hoc list subscriptions, or  
> subscriptions to XCAP documents?

Neither.  You are just advertising that you support the resource list  
MIME type. It is not my fault that we keep defining "generic" MIME  
types without sufficient semantics and conformance. I didn't want to  
use this same format for both. I suggested a Content-Type parameter.

> thing. It seems a more appropriate choice.

I don't get what this "feature" is you think you are negotiating.   
The semantics of the geo-filter is: "if you understand this MIME  
type, you need to be able to filter event notifications on the  
quantities defined here or reject a subscription containing that  
filter".

>> 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.
>
> conventional XPATH expression across it is certainly one very  
> simplistic way that this could be implemented, but it is certainly  
> not the only one.
>
> Fundamentally, XML is just a textual representation of a tree of  
> data. The underlying tree can be indexed, and the nodes indicated  
> by XPATH expressions can be cached for O(1) operation on live data.  
> Done correctly, this won't be any more inefficient than any other  
> approach.

I still don't see how a "generic" implementation of RFC 4660/4661  
would be able to efficiently evaluate changes in any continuous  
scalar quantities.

>> 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.
>
> As I mentioned initially, I haven't followed the development of  
> this document, so I don't know whether the property of being useful  
> in conjunction with other 4461 criteria was in earlier drafts. But  
> that capability is certainly absent now. Or perhaps I'm missing  
> something that you can clear up.
>
> Can you show an example of a filter that says, "I want to be  
> notified whenever sip:[email-masked] changes from closed to open  
> or moves more than 15 feet"?

There was no intent to do this. Indeed, my whole motivation for doing  
these filters is to allow efficient subscriptions to raw location  
when there is no classic presence and no presentity at all (and a  
presence compositor/server could be one of the subscribers). I don't  
see a practical use case for this combination, however if a  
subscriber wants to do this it can certainly evaluate open closed  
status. If the status is closed, subscribe to a filter that says when  
RjS becomes open. When the notification arrives, check the distance  
and if needed update the filter to be a location only filter.

Alternatively, if you want combinations, I think a better approach is  
to have a 4660/4661 filter reference another inline MIME body with  
the location object. The SUBSCRIBE contains a multipart body with a  
geo-filter event body and a 4661 filter body which contains a pointer  
to the Content-ID URI of the geo-filter body.  In many cases, the  
thing evaluating and generating the location filter will be a  
different entity than the one handling classic presence.

thanks,
-rohan