Subject: [Simple] why location and presence should be different packages

From: Rohan Mahy <[email-masked]>
Date: Fri, 16 Sep 2005 10:56:49 -0700

Hi Folks,

I've listed below a number of reasons why I believe presence and 
location should be different event packages.

1. Location and Presence have different sources and often different 
notifiers

2. Often location and presence have different subscribers, especially 
for application usage of location, and UAs getting their own location.

3. Location information requires a semantic rather than syntactic 
filtering approach.

4. There are different privacy implications for the two types of data 
(again mostly semantic, ex: obfuscation of a numerical quantity results 
in different civic values.)  Accuracy is also semantic and differs for 
the two data types.

5. Location is used as a source of presence, but it is not the only 
application that needs raw location.  presence (by definition) can use 
a variety of factors (like location and calendaring info) to generate 
more accurate human presence, but forming combined presence documents 
is necessarily a lossy operation.

5b. A presence server will need to SUBSCRIBE to location information or 
the UA will need to SUBSCRIBE to location information for some 
resource, but it seems unlikely that a location server will PUBLISH 
location data to a presence server (again, because location data is 
inherently a smooth gradient, so how does a separate location server 
know when to send a PUBLISH?)

6. presence cannot fork.  there are reasonable applications of forking 
for location information.  for example, it is reasonable for a resource 
to have instances with several different locations.  For example 
sip:[email-masked] might have several different locations, but 
according to the presence event package it can only have a single 
presence document.

7. The two data types are often routed to different notifiers.  You 
can't use the routing by package method that is used today to many 
implementations to forward subscriptions to different SIP nodes by 
event package (for example message-waiting notifications are often 
forwarded automatically to a voicemail server)

8. A user agent often want to fetch its own location.  It does not make 
sense to use the user's AOR to fetch this information, since the 
information desired is "raw" information about a single UA instance and 
since the user agent may serve multiple users. (The URI used to 
subscribe for this location information often cannot be the GRUU of the 
UA instance, since the UA usually does not have the location 
information itself.)  So what URI do we use in this case?  I recommend 
using a URI like the one used in the config package.  note that the 
location server that knows about this location of this instance can be 
in a different administrative domain than the presence server for the 
corresponding user(s).

Discussion welcome.

thanks,
-rohan

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 17 Sep 2005 13:01:46 -0400

Rohan,

Thanks for collecting these discussion arguments. I would find it 
helpful to distinguish two issues:

(1) Do we need a location-only document format and event type? (Rather 
than just returning a PIDF-LO document that only contains location 
information, say).

(2) Does location information make sense within a presence document 
(current PIDF-LO model) or should it always be separate (i.e., ditch the 
PIDF-LO+data model approach)?

Some of the points below seem to speak to (1), others to (2).

I could quibble with many of the assumptions in your list below, but it 
would help me, at least, to understand what question you are trying to 
address before getting lost in the details.

Henning

Rohan Mahy wrote:
> application that needs raw location.  presence (by definition) can use a 
> variety of factors (like location and calendaring info) to generate more 
> accurate human presence, but forming combined presence documents is 
> necessarily a lossy operation.
> 
> the UA will need to SUBSCRIBE to location information for some resource, 
> but it seems unlikely that a location server will PUBLISH location data 
> to a presence server (again, because location data is inherently a 
> smooth gradient, so how does a separate location server know when to 
> send a PUBLISH?)
> 
> implementations to forward subscriptions to different SIP nodes by event 
> package (for example message-waiting notifications are often forwarded 
> automatically to a voicemail server)
> 
> UA instance, since the UA usually does not have the location information 
> itself.)  So what URI do we use in this case?  I recommend using a URI 
> like the one used in the config package.  note that the location server 
> that knows about this location of this instance can be in a different 
> administrative domain than the presence server for the corresponding 
> user(s).
> 
> Discussion welcome.
> 
> thanks,
> -rohan
> 
>

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 17 Sep 2005 11:10:26 -0700

> than just returning a PIDF-LO document that only contains location 

My view is that returning a PIDF-LO is fine for location, but that I 
should be able to subscribe to location explicitly using a separate 
package.  When I do this, the resulting PIDF-LO should not contain any 
elements which we traditionally associate with presence (ex: 
open/closed, rpids, cipids).

> (current PIDF-LO model) or should it always be separate (i.e., ditch 
> the PIDF-LO+data model approach)?

I think it is perfectly fine to include to include "cooked" and policy 
filtered location information in a presence document when subscribing 
to the presence package.  Similarly I think it is fine to include 
processed and policy filtered information about my free busy list in a 
presence document, but not to the exclusion of getting calendar data 
with another package or mechanism.

I hope this clarifies my position.
thanks,
-rohan

> I could quibble with many of the assumptions in your list below, but 
> it would help me, at least, to understand what question you are trying 
> to address before getting lost in the details.
>
> Henning
>
> Rohan Mahy wrote:
>> Hi Folks,
>> (again mostly semantic, ex: obfuscation of a numerical quantity 
>> results in different civic values.)  Accuracy is also semantic and 
>> differs for the two data types.
>> application that needs raw location.  presence (by definition) can 
>> use a variety of factors (like location and calendaring info) to 
>> generate more accurate human presence, but forming combined presence 
>> documents is necessarily a lossy operation.
>> 5b. A presence server will need to SUBSCRIBE to location information 
>> or the UA will need to SUBSCRIBE to location information for some 
>> 6. presence cannot fork.  there are reasonable applications of 
>> forking for location information.  for example, it is reasonable for 
>> a resource to have instances with several different locations.  For 
>> example sip:[email-masked] might have several different locations, 
>> but according to the presence event package it can only have a single 
>> presence document.
>> 8. A user agent often want to fetch its own location.  It does not 
>> make sense to use the user's AOR to fetch this information, since the 
>> information desired is "raw" information about a single UA instance 
>> and since the user agent may serve multiple users. (The URI used to 
>> subscribe for this location information often cannot be the GRUU of 
>> the UA instance, since the UA usually does not have the location 
>> information itself.)  So what URI do we use in this case?  I 
>> recommend using a URI like the one used in the config package.  note 
>> that the location server that knows about this location of this 
>> instance can be in a different administrative domain than the 
>> presence server for the corresponding user(s).
>> Discussion welcome.
>> thanks,
>> -rohan

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 17 Sep 2005 17:27:02 -0400

> open/closed, rpids, cipids).

There are probably two ways to approach this, which may explain some of 
the diverse opinions:

(1) Separate events for various components, such as "classical" presence 
and filtering

(2) Using draft-ietf-simple-filter-format-05 (or something along those 
lines) to select bits and pieces, including whether to include location 
or RPIDS.

I see the need to allow watchers to pick and choose even among 
"classical" presence components ('only care about <basic>, thank you') 
as well as geo components ('only civic please').

A separate question is whether the watcher should be able to choose the 
raw ("union") composition or the composed version. I believe it should.

As far as I can tell, (2) is a generalization of (1). Given the 
availability of a generic filter, the question remains whether it is 
necessary or simply expedient to also support event-level separation.

Henning

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 17 Sep 2005 18:53:46 -0700

Henning,

The assumption you are making that I am not comfortable with is that 
there is always a compositor.  Sometimes I'd like to get the location 
of an instance.  I do not require a compositor for this operation and I 
am not interested in any presence data.  Requiring a compositor 
(particularly a presence compositor) to correctly process the 
information I want from an instance, reminds me of B2BUAs inviting 
themselves into my calls without my consent.  This is a particularly 
problematic when the thing that knows where I am may be in a completely 
different administrative domain than my presence compositor (if I even 
have one) and my proxy/registrar.

thanks,
-rohan

On Sep 17, 2005, at 14:27, Henning Schulzrinne wrote:
>> package.  When I do this, the resulting PIDF-LO should not contain 
>> any elements which we traditionally associate with presence (ex: 
> There are probably two ways to approach this, which may explain some 
> of the diverse opinions:
>
> (1) Separate events for various components, such as "classical" 
> presence and filtering
>
> lines) to select bits and pieces, including whether to include 
> location or RPIDS.
>
> A separate question is whether the watcher should be able to choose 
> the raw ("union") composition or the composed version. I believe it 
> should.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 17 Sep 2005 22:14:34 -0400

Rohan:

I don't see why anything I said implies the presence of a (lossy) 
compositor. There are two cases: I subscribe to an entity, identified by 
a SIP URI, that derives event data from multiple sources, in which case 
something must combine them into a single document. This can, as in the 
current default policy, be lossless. If there's a single source, there 
is no combining at all.

The filter function can prevent the delivery of presence data if you 
don't care about it.

I don't see why this has anything to do with B2BUAs. There are issues of 
identifying the appropriate URL for the thing you want information 
about, but that's independent of the event package. As you mentioned 
earlier, this may be some kind of device-related identifier.

I don't see why the current model would prevent sending a SUBSCRIBE to 
sip:[email-masked], without traversing a proxy or PA.

One of the reasons, I suspect, that this was considered uncommon for 
most applications is the need to do authorization, which often requires 
human approval. If sip:[email-masked] knows the subscriber 
and requires no further authorization intervention, this should work 
just fine with the existing machinery.

The one problem we have seen is more generic, namely that proxies may 
need to route certain SUBSCRIBEs to a PA, while others should go 
directly to the various end systems, just like any other non-INVITE 
request that gets proxied. This appears to be somewhat under-specified 
right now. I wonder if a caller preferences indication might be the 
right approach. (I believe that the mediated vs. direct model are of 
more general interest than just presence vs. location.)

Henning

Rohan Mahy wrote:
> there is always a compositor.  Sometimes I'd like to get the location of 
> an instance.  I do not require a compositor for this operation and I am 
> not interested in any presence data.  Requiring a compositor