Subject: [Geopriv] two use cases

From: Rohan Mahy <[email-masked]>
Date: Tue, 17 Jul 2007 09:31:47 -0700

Hi Everyone,

The main reason I want to have a separate location event package is  
because I see location information as a first-class object.  For  
first-class objects I would like to a have a way to explicitly access  
that information directly and that information alone.  I am also  
perfectly OK with including location and other first-class objects  
inside a presence subscription that has an open and a closed status.

Here are a few other pieces of data that have their own protocol or  
event package, but can also be conveyed in a presence document:
on-hook / off-hook state -- dialog event package
registration state -- registration event package
calendaring data -- iCal and CalDAV

Below are a few use cases, that I hope will show how ambiguities can  
arise if we don't have a way to separate presence with some location  
added, and pure location.

1.  [email-masked] has a traditional presence server.  She has  
device with a GPS or transponder that reports its location, but has  
no communication capabilities.  She also has a laptop with a  
traditional IM/presence client that publishes her presence to her  
presence server.  As with many IM/presence clients, Alice can  
manually enter a city and country to provide to her watchers from her  
laptop.

Consider the following publication. In the first case, Alice is  
reporting her presence and also helpfully letting the watchers in her  
buddy list know that she is in Boston:

PUBLISH sip:[email-masked] SIP/2.0
To: <sip:[email-masked]>
From: <sip:[email-masked]>
Event: presence
Content-Type: application/pidf+xml

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
     xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
     xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
     xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
     xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
     entity="pres:[email-masked]">
   <tuple id="sg89ae">
    <status>
     <basic>open</basic>
     <gp:geopriv>
       <gp:location-info>
         <cl:civicAddress xml:lang="en-us">
           <cl:country>us</cl:country>
           <cl:A1>MA</cl:A1>
           <cl:A3>Boston</cl:A3>
         </cl:civicAddress>
       </gp:location-info>
       <gp:usage-rules>
         <gp:retransmission-allowed>yes</gp:retransmission-allowed>
         <gp:retention-expiry>2006-07-17T18:00:00Z</gp:retention-expiry>
       </gp:usage-rules>
       <gp:method>manual</gp:method>
     </gp:geopriv>
    </status>
   <contact priority="0.9">im:[email-masked]</contact>
    <timestamp>2006-07-17T16:57:29Z</timestamp>
   </tuple>
   <dm:device id="pc147">
     <rp:user-input idle-threshold="600"
          last-input="2006-07-17T16:44:21Z">idle</rpid:user-input>
      <dm:deviceID>urn:uuid:00000000-0000-1000-8000-000A95A0E128</ 
dm:deviceID>
      <dm:note>PC</dm:note>
   </dm:device>
   <dm:person>
     <rp:activities><<rp:lunch/></rp:activities>
     <dm:note xml:lang="en-us">Eating Lunch</note>
   </dm:person>
</presence>

Alice is actually sitting in the NW corner of the Lemon Tree  
Restaurant in Burlington, MA [1] (that Thai place near where we had  
one of our interims), but most people have never heard of Burlington,  
so she just types Boston.  She means the greater Boston area anyway.

[1] http://maps.google.com/maps?f=q&hl=en&geocode=&q=lemon+tree 
+restaurant,+bedford, 
+ma&ie=UTF8&cd=1&mpnum=0&ll=42.496482,-71.226275&spn=0.001125,0.002768&t 
=h&z=19&iwloc=B&om=1

Her device with GPS also published its last good location, just after  
it lost signal before going inside.  This device is publishing raw  
location.  It is not providing any basic (open/closed) status and it  
is not providing any contacts:

PUBLISH sip:[email-masked] SIP/2.0
To: <sip:[email-masked]>
From: <sip:[email-masked]>
Event:  ????
Content-Type: application/pidf+xml

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
     xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
     xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
     entity="sip:[email-masked]">
   <tuple id="la8chjaq">
    <status>
     <gp:geopriv>
       <gp:location-info>
         <gml:location>
           <gml:Point gml:id="point1" srsName="epsg:4326">
             <gml:coordinates>42:29:46.8457N 71:13:34.6368W</ 
gml:coordinates>
           </gml:Point>
          </gml:location>
       </gp:location-info>
       <gp:usage-rules>
         <gp:retransmission-allowed>yes</gp:retransmission-allowed>
         <gp:retention-expiry>2006-07-17T17:40:29Z</gp:retention-expiry>
       </gp:usage-rules>
       <gp:method>gps</gp:method>
     </gp:geopriv>
    </status>
    <timestamp>2006-07-17T16:40:29Z</timestamp>
   </tuple>
</presence>

How does the presence server (as a compositor and aggregator) know  
which of these publications contain "raw" location and which do not?  
I think a very reasonable and logical way to express this  
semantically is to use a different event package.

A similar/related problem exists if the presence server subscribes to  
presence and/or location information from individual user agents.   
The presence server needs a way to know if any location provided is  
raw or already filtered.

2. In the next case, I have a tracking application that wants to get  
the location of some URI.  It has no interest in any presence about  
that URI.

If the subscription is to the presence event package, the expectation  
(its a SHOULD in the presence spec) is that the notifier SHOULD  
perform polite blocking.  It should accept the subscription and  
provide a notification with neutral state.  Likewise if the

When sent by the tracking application using the presence package if  
there is either no authorization or no location information available:

SUBSCRIBE (1)->
<- 200 (to SUBSCRIBE)
<- NOTIFY (2)
200 (to NOTIFY) ->

(1)
SUBSCRIBE sip:[email-masked] SIP/2.0
Event: presence

(2)
NOTIFY
Content-Type: application/pidf+xml

<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
     entity="pres:[email-masked]">
   <tuple id="4jh92">
     <status>
       <basic>closed</basic>
     </status>
   </tuple>
</presence>

Whereas If we used a separate location package and there was an  
authentication/authorization error:

SUBSCRIBE (1) ->
<- 403
<- NOTIFY w/ Subscription-State: terminated (2)
200 OK ->

(1)
SUBSCRIBE sip:[email-masked] SIP/2.0
Event: location

(2)
NOTIFY
Subscription-State: terminated;reason=rejected

And if no location data was available at that time:

SUBSCRIBE (1) ->
<- 480
<- NOTIFY w/ Subscription-State: terminated (2)
200 OK ->

(1)
SUBSCRIBE sip:[email-masked] SIP/2.0
Event: location

(2)
NOTIFY
Subscription-State: terminated;reason=noresource

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Robert Sparks <[email-masked]>
Date: Tue, 17 Jul 2007 13:42:29 -0500

Rohan -

I think you're claiming 3856 requires presence servers to polite  
block at SHOULD strength?
I disagree. The spec talks about polite blocking and what you SHOULD  
do if you want to
provide that, but it does not require polite blocking at any strength.

RjS

On Jul 17, 2007, at 11:31 AM, Rohan Mahy wrote:

>
> If the subscription is to the presence event package, the  
> expectation (its a SHOULD in the presence spec) is that the  
> notifier SHOULD perform polite blocking.  It should accept the  
> subscription and provide a notification with neutral state.

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 17 Jul 2007 12:33:49 -0700

Hi Robert,

I just reread that paragraph from RFC 3856 and that's not how I read  
it, but I see where you are coming from.

Whether polite blocking is SHOULD or MAY, the notifier still needs a  
way to decide how to respond to the subscription request. If a single  
package is used for both presence and location-only subscriptions,  
the notifier has to selectively decide based on the URI whether to  
respond as is typical for traditional presence subscriptions or how  
to respond as seems desirable for location-only subscriptions.  There  
is a lot of implicit decision making if we use one event package for  
both.

thanks,
-rohan

On Jul 17, 2007, at 11:42 AM, Robert Sparks wrote:
> I disagree. The spec talks about polite blocking and what you  
> SHOULD do if you want to