Subject: [Geopriv] SIP lbyr location deref using draft-mahy-geopriv-sip-loc-pkg-02.txt

From: "Rohan Mahy" <[email-masked]>
Date: Sat, 14 Jul 2007 12:45:57 -0700

Hi,

I resurrected an old draft I wrote.  It is a SIP event package that
could be used to deref lbyr location URIs. This proposal is in
addition to whatever way we decide to deref using HTTP.

The document is in the repository now as: draft-mahy-geopriv-sip-loc-pkg-02.txt
If you prefer, the HTML version is at:
http://svn.resiprocate.org/rep/ietf-drafts/rohan/locpkg/draft-mahy-geopriv-sip-loc-pkg-02.html

thanks,
-rohan

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 14 Jul 2007 21:48:20 +0200

I noticed the publication of this document and I wasn't quite sure why 
it is necessary.

---

From: "Rohan Mahy" <[email-masked]>
Date: Sat, 14 Jul 2007 13:08:00 -0700

Hi Hannes,

Lets take the classic lbyr scenario where the target does not know its
own location. Say that the target discovers the LIS and asks for lbyr.
 The LIS provides the target with both an http ref [1] and a sip
reference [2].  The target passes the SIP reference to its presence
server.  The presence server subscribes to the raw location of the
target using this new package.

What would you do instead?  Clearly you need some description of how
to do the dereferencing.  As I've said several times, I feel that the
presence event package is a very poor choice because the semantics of
the package is providing filtered presence (ability to communicate) of
a presentity identified by its address used for communications (its
SIP AOR such as [3]). Also, a SIP presence server role typically
receives PUBLISH requests and SUBSCRIBE requests and generates NOTIFY
requests for the presence event package, while a SIP deref requires
the thing that runs as a presence server to *generate* SUBSCRIBE
requests for this same package and correctly filter them.

In short I think this new proposed package is useful and captures the
semantics correctly. On the other hand, the presence event package has
the wrong semantics, the wrong identity, the wrong default privacy and
security assumptions, and the wrong role for the job.

Finally, if you did frankenstein the presence event package, you would
need to write a pretty beefy document describing how to profile it to
your needs.  Why not just define a new package?  They don't cost
anything?

thanks,
-rohan

[1] https://lis892.provider.net/loc/P3hFzgeePiRpDS6/lexMhHPfO+kAsRKSe61DDB/YFGU=
[2] sips:P3hFzgeePiRpDS6/lexMhHPfO+kAsRKSe61DDB/YFGU=@lis892.provider.net
[3] sip:[email-masked]

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 14 Jul 2007 17:12:40 -0400

I'm sorry, I am confused.  Perhaps you could expand on some of this:

1. How you do dereferencing: you are given a sip uri.  You subscribe to it.
It immediately returns a PIDF.  The PIDF has location in it.  Depending on
the filter parameters, you may get location (presence) updates.

2. Is there a rule somewhere that says that a presence URI has to be an AoR?
I don't recall one.  Is there some problem with an arbitrary string used to
identify which presentity you want presence for?  For example, if it was a
hash of a telephone number, would that run afoul of some specification?

3. I am mightily confused by "requires the thing that runs as a presence
server to *generate* SUBSCRIBE requests".  See item 1 above.  You subscribe
to the URI you are given, it returns presence-with-location.  Where am I
losing you?

4. The presence server will get PUBLISH requests, although I expect quite a
few Location Information Servers who have presence interfaces to get the
information through another protocol.  However, the case where an endpoint
has a GPS chip and PUBLISHES his location to his presence server should also
be common.

5. I'll admit that we need somewhat different filter characteristics for
location than for other presence data.  You want a filter that is something
like "send me an update when location changes by x-amount, but don't send
more than y updates per second/minute/hour/day".  However, it really is a
filter, and I *think* that's a pretty straightforward extension to the
presence filter mechanism.

Brian

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Saturday, July 14, 2007 4:08 PM
> To: Hannes Tschofenig
> Cc: GEOPRIV; [email-masked]; Rohan Mahy
> Subject: Re: [Geopriv] SIP lbyr location deref usingdraft-mahy-geopriv-
> sip-loc-pkg-02.txt
> 
> Hi Hannes,
> 
> [1]
> https://lis892.provider.net/loc/P3hFzgeePiRpDS6/lexMhHPfO+kAsRKSe61DDB/YFG
> U=

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 14 Jul 2007 23:49:06 +0200

Hi Rohan,

> target using this new package.
So, here the disconnect starts.

We cannot the presence server just subscribe to the PIDF-LO as a 
presence event package?
What it get's is a PIDF-LO. Done.

> to do the dereferencing.

We have this since the idea of Jon was once that we just use the 
presence mechanisms we have and apply them to the GEOPRIV work.

I could understand to define something new when we just carry "raw 
location" -- the LO part of the PIDF-LO. This is, however, not want we 
want -- at least not for the last few years.

> As I've said several times, I feel that the
But again in this example. The functionality is just that the PIDF-LO is 
created and when you SUBSCRIBE to it then you receive it via a NOTIFY.
Done. There is just nothing else. Still, that does not require a new 
event package.

The fact that in this case there is no PUBLISH should not cause any 
troubles.

> security assumptions, and the wrong role for the job.
When it comes to the policy I recently suggested what should go in the 
PIDF-LO per default. It might have found its way into SIP Location 
Conveyance version -08.

> your needs.  Why not just define a new package?  They don't cost

Ciao
Hannes

> thanks,
> -rohan
>
> [1] 
> https://lis892.provider.net/loc/P3hFzgeePiRpDS6/lexMhHPfO+kAsRKSe61DDB/YFGU= 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 14 Jul 2007 23:55:12 +0200

I fully agree with Brian here.

On item (5), didn't you Rohan exactly write such a document that 
provides these filters?
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-01.txt

Ciao
Hannes

>>>> http://svn.resiprocate.org/rep/ietf-drafts/rohan/locpkg/draft-mahy-
>>>>         
>> geopriv-sip-loc-pkg-02.html
>>     
>>>> thanks,
>>>> -rohan
>>>>
>>>>

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 15 Jul 2007 10:52:46 -0700

Hi,

> What it get's is a PIDF-LO. Done.

"JUST" ...
That's a very dangerous word.

Please have a look at my email to Brian.

> location" -- the LO part of the PIDF-LO. This is, however, not want  
> we want -- at least not for the last few years.

Hopefully you read the draft.  It is quite short.

Getting "raw" location is EXACTLY what my presence server wants to  
get from my LIS.  This is EXACTLY why I proposed a new event package  
for this specific purpose.

To be VERY clear, the event package I proposed would only be used to  
dereference location-only URIs.  We would continue to use the  
presence event package to get the authenticated, authorized, and  
possibly filtered, hidden, and obfuscated presence and embedded  
location associated with a PRESENTITY from a PRESENCE AGENT (one  
which is probably what the industry colloquially calls a presence  
server).

> But again in this example. The functionality is just that the PIDF- 
> LO is created and when you SUBSCRIBE to it then you receive it via  
> a NOTIFY.
> Done. There is just nothing else. Still, that does not require a  
> new event package.

Well perhaps we could use the message-summary event package to get  
raw location too!   I can "just" put "application/pidf+xml" in the  
Accept header in the SUBSCRIBE right?  Of course this idea is absurd  
because the event package has the WRONG SEMANTICS.

> The fact that in this case there is no PUBLISH should not cause any  

Please read my response to Brian.

> When it comes to the policy I recently suggested what should go in  
> the PIDF-LO per default. It might have found its way into SIP  
> Location Conveyance version -08.

What is described in section 3.6 of location conveyance is not a  
dereferencing scheme as described in draft-marshall-geopriv-lbyr- 
requirements. This section hopelessly confuses location included with  
bonafide presence (ability to communicate), from raw location that  
contains no information about the ability to communicate.

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 15 Jul 2007 10:52:44 -0700

Hi Brian,

> I'm sorry, I am confused.  Perhaps you could expand on some of this:

Before I start, let me point out that so far there is no *technical*  
objection to defining a new location event package.  I think everyone  
will have to concede that the approach I described will work.  I also  
cannot imagine any harm being caused if we decide to define a new  
location event package.

All the objections that have been raised against defining a new event  
package are that we already have an event package that some claim can  
be bended and blended to our purposes.  All around me I hear folks  
say "we can *just* use the presence event package", or "using the  
presence event package is obvious and trivial".  I think we have been  
talking about this for so long that many of us assume that the  
problem is trivial without having bothered to examine all the  
problems associated.

Also, just because you can do a thing, it does not mean that you  
should.  I think it is very important that each event package has a  
crisp set of semantics.  Having a few extra event packages than if we  
try to maximally conserve them is a good thing.

Below I will raise (again) the legitimate technical and semantic  
objections I have to reusing the presence event package.

> the filter parameters, you may get location (presence) updates.

We agree that the dereferencer sends a SUBSCRIBE request to the  
location URI.  I think this dereferencing should use a dedicated  
event package. I feel that using the presence event package is  
inappropriate and harmful for conveying *raw* location.

> hash of a telephone number, would that run afoul of some  

I think it is sensible that a presence URI should be able to provide  
presence data.
When generating a location reference, the LIS/LCS will need to  
generate a location URI.  This URI must not be a pres: URI because  
the URI would not provide any PRESENCE data (information about the  
ability of the presentity to communicate) and certainly by my  
definition, the URI does not even refer to a PRESENTITY.

As for using an AOR for presence data, we have tradition and  
deployment experience to guide us.
The traditional usage of the presence event package is to subscribe  
to presence information about a presentity. Also traditionally in SIP/ 
SIMPLE systems this subscription is sent to an AOR.  Deployed  
implementations either operate a presence server (presence agent co- 
located with a proxy server), or they fork subscriptions to multiple  
edge presence agents. In both cases, the Request URI in the SUBSCRIBE  
is an AOR that can also be used to communicate with the presentity.

> to the URI you are given, it returns presence-with-location.  Where  

Sorry. That was not especially clear. Lets not use any pronouns.   
Pronouns will make an ambiguous sentence even more ambiguous.

Lets say that provider.net operates a SIP-based presence service.   
For convenience, I will use the term "presence server" to mean a  
centralized, data-center set of nodes that act as PRESENCE AGENTs and  
perform presence aggregation, policy, authorization, and filtering.   
The presence server at sip:provider.net  expects to receive SUBSCRIBE  
and PUBLISH requests for the presence event package, and SUBSCRIBE  
requests for watcher info.  The presence server at provider.net  
combines all the raw information it has for the PRESENTITY Alice  and  
composes a handful of presence documents: one each for neutral state,  
any buddy, coworkers, and close friends.

The provider.net presence server follows a traditional, well- 
understood industry definition of one type of "presence-server".  A  
key simplicity of defining the role of a presence server is that is  
receives presence subscriptions and publications and generates  
notifications for its active subscriptions.

I think it is terribly confusing and very sloppy semantics to now  
have a "presence-server" also generate subscribe requests to the very  
same presence event package.  "But Mommy, I thought a presence-server  
*received* subscribe requests?  Yes, dear *usually* it does, but  
*this* presence server is *different*"

> has a GPS chip and PUBLISHES his location to his presence server  

An endpoint that generates its own location should be able to  
disclose it in the context of presence or not.  Sending a presence  
publication with embedded location is fine.  The presentity better be  
very sure that the presence server understands whether it needs to  
further filter that location.  Here is one of the ambiguities of  
using the presence event package.

Case 1.  The target wants to do its own filtering.  It obfuscates or  
fuzzes its location appropriately and then incorporates it in a  
presence publication.  The presence server only has to know if a  
specific watcher is allowed to get the location object.

Case 2. The target provides completely raw unprocessed location to  
the presence server.  The presence server does location-based  
filtering based on the raw location on a watcher-by-watcher basis.

I am sure you can imagine errors where confusing these two cases can  
lead to leaking private information or sending friends to the wrong  
location.

> presence filter mechanism.

We already have a working group item for a filter mechanism:  draft- 
ietf-geopriv-loc-filters-01
This is not an extension to presence filtering, it is a standalone  
filter format that is a very straightforward example of the RFC 3265  
event package filter concept.  It would work with both presence and/ 
or a separate location event package.

The reason I think a new event package is appropriate is that the  
semantics would be clearer.

In addition, I think the following are additional compelling  
technical or semantic reasons to use a separate package.

1) We could make a clear distinction by package between processed  
(presence) and raw (location).  This would avoid ambiguities and  
disclosure errors.

2) Caller preferences/Callee Capabilities routing by event package  
would work much more effectively.

3) The traditional authentication and authorization of presence  
subscriptions (dynamic user-based prompting) is different from the  
authentication and authorization mechanisms used for location (metro- 
ticket or pre-existing trust).

4) Watcher info is not as essential for location-only subscriptions.

5) Avoid the confusion of presence servers subscribing to pseudo- 
presence.

6) By definition, the information we are subscribing to is not  
presence (ability to communicate), it is location information.  The  
name and definition of the package should match its actual use.

thanks,
-rohan

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 15 Jul 2007 14:35:22 -0400

Rohan

I am sorry, but I'm baffled.  I read your answer twice and can't make heads
or tails over it.  There is something in your head that isn't coming
through.

So far as I can tell, you have not offered a single technical argument.
Using presence to return a PIDF with location works for all uses your event
package does.  Nothing in the presence RFCs even suggests that using
presence in the way we are talking about is wrong.

You argue that we have built up some conventions on how we use presence, so
far, that this use would not conform to.  I'll give you that, but I don't
see any harm, and I see considerable good, in having a somewhat richer
notion of presence.  Specifically, any single aspect of presence could have
some separate mechanism for getting it if all you wanted was that one thing.
But I	think the notion that we should invent a separate event package for
each doesn't make any sense, and I don't see why location should be
different.

I am particularly confused by the presence server that subscribes
discussion.  Are you thinking that there is a problem with a "real" (in your
eyes) presence server subscribing to an access networks presence server so
that the "real" presence server can provide location?  That's the only way I
can interpret what you said.  I can't think of any other reason a presence
server would need to subscribe.  If that's it, then the "real" presence
server is a presence aggregator, which I think we'll see a lot of and should
not be at all worried about it.  "Real" presence requires aggregation of
multiple service providers who provide a subset of presence for one service.
To aggregate, the aggregator subscribes to the service presence system to
build a composite view.  This case is EXACTLY that; the access network
operates a genuine presence system.  It's just that the only really
interesting tags in the PIDF are the PIDF-LO tags.  So what?  Why is that in
any way not in the spirit of presence?  Why is the notion that a "real"
presence server might have to subscribe to another to build up a more
complete picture of the user offend you?

Brian

> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Sunday, July 15, 2007 1:53 PM
> To: Brian Rosen
> Cc: Rohan Mahy; 'Rohan Mahy'; 'Hannes Tschofenig'; 'GEOPRIV';
> [email-masked]

---

From: "Dawson, Martin" <[email-masked]>
Date: Sun, 15 Jul 2007 14:24:34 -0500

I think that Rohan is saying that the LIS is not a presence server. I
agree with him. So something other than a presence package for
subscribing to a location feed is more appropriate.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, 16 July 2007 4:35 AM
To: 'Rohan Mahy'
Cc: 'GEOPRIV'; [email-masked]
Subject: RE: [Geopriv] SIP lbyr location
derefusingdraft-mahy-geopriv-sip-loc-pkg-02.txt

Rohan

I am sorry, but I'm baffled.  I read your answer twice and can't make
heads
or tails over it.  There is something in your head that isn't coming
through.

So far as I can tell, you have not offered a single technical argument.
Using presence to return a PIDF with location works for all uses your
event
package does.  Nothing in the presence RFCs even suggests that using
presence in the way we are talking about is wrong.

You argue that we have built up some conventions on how we use presence,
so
far, that this use would not conform to.  I'll give you that, but I
don't
see any harm, and I see considerable good, in having a somewhat richer
notion of presence.  Specifically, any single aspect of presence could
have
some separate mechanism for getting it if all you wanted was that one
thing.
But I	think the notion that we should invent a separate event package
for
each doesn't make any sense, and I don't see why location should be
different.

I am particularly confused by the presence server that subscribes
discussion.  Are you thinking that there is a problem with a "real" (in
your
eyes) presence server subscribing to an access networks presence server
so
that the "real" presence server can provide location?  That's the only
way I
can interpret what you said.  I can't think of any other reason a
presence
server would need to subscribe.  If that's it, then the "real" presence
server is a presence aggregator, which I think we'll see a lot of and
should
not be at all worried about it.  "Real" presence requires aggregation of
multiple service providers who provide a subset of presence for one
service.
To aggregate, the aggregator subscribes to the service presence system
to
build a composite view.  This case is EXACTLY that; the access network
operates a genuine presence system.  It's just that the only really
interesting tags in the PIDF are the PIDF-LO tags.  So what?  Why is
that in
any way not in the spirit of presence?  Why is the notion that a "real"
presence server might have to subscribe to another to build up a more
complete picture of the user offend you?

Brian

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 15 Jul 2007 22:03:17 +0200

A LIS is not a presence server. That's fine. But this terminology aspect 
is pretty irrelevant for this discussion.

Dawson, Martin wrote:
>> Subject: Re: [Geopriv] SIP lbyr location deref
>>     
> usingdraft-mahy-geopriv-
>   
>> sip-loc-pkg-02.txt
>>
>> Hi Brian,
>>
>>> filter, and I *think* that's a pretty straightforward extension to
>>>       
> the
>   
>>>> What would you do instead?  Clearly you need some description of
>>>>         
> how
>   
>>>> to do the dereferencing.  As I've said several times, I feel that
>>>>         
> the
>   
>>>> presence event package is a very poor choice because the semantics
>>>>         
> of
>   
>>>> receives PUBLISH requests and SUBSCRIBE requests and generates
>>>>         
> NOTIFY
>   
>>>> In short I think this new proposed package is useful and captures
>>>>         
> the
>   
>>>> need to write a pretty beefy document describing how to profile it
>>>>         
> to
>   
>>>>>> I resurrected an old draft I wrote.  It is a SIP event package
>>>>>>             
> that
>

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 15 Jul 2007 13:42:53 -0700

> So far as I can tell, you have not offered a single technical  

Please go back and go through my points numbered at the bottom one-by- 
one.  At minimum, the ambiguity issue and the caller preferences  
issue are both technical.  You have not provided a reply to either of  
these.

> presence in the way we are talking about is wrong.

... except the definition of presence and presentity.

> notion of presence.

Let me remind you of a basic definition: Presence = Availability to  
Communicate.

There is no "rich presence" in raw location information, because BY  
DEFINITION the raw location provided by an LCS contains no presence  
data at all.  Zero. Zip. Zilch. Nada. Niente.  It actually contains  
LESS information about the availability to communicate than the  
message-summary event package typically does.   Presence information  
needs to be about a PRESENTITY - an entity with whom you can  
potentially communicate with, and exchange information about the  
presentity's availability to communicate.

> Specifically, any single aspect of presence

Location is not a subset of presence.  There are many valid use cases  
for location information that do not involve availability to  
communicate.  We had a nice thread discussing package tracking for  
example.  Commercial location servers are often used for asset  
tracking.  In fact the bulk of deployed enterprise location servers  
have no presence component at all.

Location is a set of information in its own right.  It is not an  
"aspect" of presence.  It is possible to include location information  
as supplemental information (when properly filtered) as supplemental  
information in a presence document.  Likewise, calendaring data is a  
set of information in its own right, which can also optionally be  
included as supplemental data in a presence document.  This does not  
make calendaring data an "aspect" of presence.

> could have some separate mechanism for getting it if all you wanted  
> was that one thing.
> I think the notion that we should invent a separate event package for
> each doesn't make any sense,and I don't see why location should be
> different.

Since location is not an "aspect" of presence and is valuable data in  
many contexts that have no relevance to presence, it seems logical to  
be able to access it with a separate event package.

> eyes) presence server subscribing to an access networks presence  

Lets make the terminology crisp.  We are talking about the  
provider.net presence server (for example) dereferencing location- 
specific URIs from an LCS in an access network.  The thing in the  
access network is an LCS, not a presence server.  Certainly the LCS  
is not acting as a presence server when it dereferences an HTTP  
reference.

> build a composite view.

I seriously doubt that real aggregation will happen in this way.   
With what credentials will google.com use to fetch my own raw  
presence information from yahoo.com on my behalf?  This is  
unrealistic.  "Real" presence does indeed require aggregation, but I  
seriously doubt that the aggregating presence server will use the SIP  
presence event package to subscribe to individual tuples to  
aggregate.  The aggregating presence server will use other protocols  
(ex: calendar access) and other event packages (for example, the  
registration event package) to fetch the raw data that it uses to  
compose a variety of presence documents for consumption by watchers.   
Deployed servers are doing what I described (using other event  
packages and other protocols).  Why do YOU have a problem with this  
successful model?

> This case is EXACTLY that; the access network
> operates a genuine presence system.

This fits no written definition of a presence system that I was able  
to find.

> It's just that the only really

Ah, the "application/pidf+xml is just an XML container that we can  
fill with whatever we want" garbage pit of the world argument.
I certainly hope you will not suggest that the only way to fetch  
calendaring data should be with presence.

thanks,
-rohan

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 15 Jul 2007 17:50:40 -0400

Well gee Rohan, I went back and read 3863, which references 2778, and you
know what?  It doesn't talk about presence as having anything to do with
"ability to communicate".  It talks about presence as being a set of state
data of the user.

   A presence and instant messaging system allows users to subscribe to
   each other and be notified of changes in state, and for users to send
   each other short instant messages. 
   
IN fact, no where in 3863 or 2778 does it even hint that "ability to
communicate" is what presence is for.  

I don't think there is any "ambiguity" between presence and raw location.
Raw location is one form of presence.  A location server can process
location in the same way any presence server can do that.  It can give one
watcher a different form than another.

I also don't see how caller pref/caller capabilities is enhanced in any way
that is helpful in any practical sense.  The only callee capabilities of
interest would be those of the server to whom you SUBSCRIBE.  If you got the
URI from a Geolocation header, then you understand what happens when you
used it.  Similar for other forms of presence.  Caller Preference?  Who
would use either on a SUBSCRIVE in caller preference?  "I don't want no
stinkin presence, I only want location"?  

I absolutely think presence aggregation will happen, among other ways by an
aggregator subscribing to another presence system.  It's just a watcher.  It
would use whatever credentials it needed to be a watcher.  The presentity
would tell its presence system what to give it.

Let's use a simple example.  Suppose I have a mobile phone, which is on the
T-Mobile network, and a home phone, which is on the Comcast network.  My
presence is an aggregation of both the T-Mobile and the Conmcast presence
information.  An aggregator could subscribe as a watcher to both T-Mobile
and Comcast and produce a presence document much more effective that either
could.  In fact, the aggregator watcher may end up being the only watcher
for each of the services.

Now, there may indeed be other ways to get the data, but a watcher
subscription is a pretty useful, general purpose way.  Have you ever used a
financial data sweep service?  Look at yodlee for an example.  You give it
credentials at all your bank, credit card and investment websites, and it
gives you a composite picture of everything. None of your individual
financial service companies can do that (unless they do what yodlee does,
which some of them offer).

Anyway, I still don't see it.  To me, a PDIF with just location data is a
fine way to represent a piece of presence, just line a PIDF with just, oh,
<time-offset>.
  
Brian

> Sent: Sunday, July 15, 2007 4:43 PM
> To: Brian Rosen

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 15 Jul 2007 17:04:51 -0500

>contains no information about the ability to communicate.

Robert has strongly suggested this section (3.6) of Conveyance 
include an event package - with rules of usage.  After talking with 
him about it, I agree.  This will be a new event package and will 
only allow a single (Expires: 0) dereference (i.e., one NOTIFY 
containing the PIDF-LO), and not allow pending subscriptions or 
target tracking (i.e., numerous NOTIFYs returned).

The new event package will likely be called something like 
"location-deref", verses something else like "location-tracking" for 
a future effort that's out of scope for Conveyance.

Rohan, I'm open to your suggestions on how to further make section 
3.6 clearer, as Conveyance right now doesn't allow "raw" location to 
be sent anywhere.

James

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 15 Jul 2007 17:10:17 -0500

>be able to access it with a separate event package.

I don't disagree with this statement, but there is a history of folks 
saying (publicly) that location is a part of Presence.  They where wrong IMO.

James

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Jul 2007 18:23:31 -0400

This clearly has the potential of another fun GEOPRIV philosophy  
discussion.

I generally agree with Brian; four additional quick remarks:

(1) I don't think we do well in trying to discern intent or  
"meaning". (See where the "using protocol" mess has gotten us...). We  
tend to have fewer arguments if we stick to externally observable  
behavior. In other words, "I don't care why you want these bits and  
what you want to do with them, as long as they serve your needs (and  
you're allowed to have them), be my guest.". Thus, we should try to  
clearly articulate differences in behavior that a third party could  
actually observe.

Similarly, a second test is whether a server of type A could serve  
the needs of client of type B. In this particular case, this appears  
to be true. If I hand out a SIP URL of a PIDF-LO understanding  
"presence" server, it would indeed seem to be able to answer the  
"where-is-he" question in a way that the querier can use.

(2) I will note that RFC 3863 allows <contact> and <basic> to be  
omitted. Without this, there isn't much to communicate with. (The loc- 
pkg draft doesn't seem to require that the server omits these  
elements in its response.)

(3) My larger concern is that the event labeling mechanism is fairly  
coarse-grained. Thus, you can easily get combinatorial explosion  
since each new subset of data needs a new label. I think the  
filtering mechanism is a much more appropriate tool to pick and  
choose PIDF(-LO)/RPID/... elements, rather than trying to name each  
possible combination of data about an entity identified by a SIP URI.  
In particular, this allows re-use of the same infrastructure.

(4) There are two choices in terms of the data returned: Either  
indeed anything that is application/pidf+xml is legal for both  
presence and any other related events, or there is some implied  
subsetting. In the former case, the extension fails the test of being  
discernible by an external observer. In the latter, every new PIDF/ 
PIDF-LO extension has to be profiled for all these event packages,  
with little obvious gain in system functionality or simplicity.

My general conclusion is that a single event type can return multiple  
different content types (XML documents), but that returning the exact  
same XML content via multiple event types seems to have dubious  
characteristics, as it implies behavior, rather than making it  
explicit and observable.

Henning

On Jul 15, 2007, at 5:50 PM, Brian Rosen wrote:

>>>>> I don't recall one.  Is there some problem with an arbitrary  
>>>>> string
>>>>> used to
>>>>> to the URI you are given, it returns presence-with-location.   
>>>>> Where
>>>>> am I
>>>>> losing you?
>>>>
>>>>> 4. The presence server will get PUBLISH requests, although I  
>>>>> expect
>>>>> quite a
>>>>>> Lets take the classic lbyr scenario where the target does not  
>>>>>> know
>>>>>> its
>>>>>> semantics correctly. On the other hand, the presence event  
>>>>>> package
>>>>>> has
>>>>>> the wrong semantics, the wrong identity, the wrong default  
>>>>>> privacy
>>>>>> and

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 15 Jul 2007 19:55:33 -0400

Why?  What is different about this than a subscription to the presence
package with Expires:0?.  It has identical message flow, syntax and
addressing as presence.  This is the same argument with the same lack of
reason-to-be-different.

Brian

> From: James M. Polk [mailto:[email-masked]]
> Sent: Sunday, July 15, 2007 6:05 PM
> To: Rohan Mahy; Hannes Tschofenig
> Cc: GEOPRIV; Rohan Mahy; [email-masked]

---

From: Rohan Mahy <[email-masked]>
Date: Sun, 15 Jul 2007 19:16:03 -0700

Brian,

Any data can be described as "a set of state data".  This is a  
meaningless definition.  I think I came up with a very useful working  
definition of presence.  If you don't like that definition, please  
propose something concrete and meaningful.

Until then, it will be impossible for me to engage in constructive  
debate with you about what is and is not presence data.

Location is clearly useful in contexts both inside and outside of  
"availability to communicate", so is calendaring data.  So what do  
you think makes location more inherently presence-like?

thanks,
-rohan

---

From: "Brian Rosen" <[email-masked]>
Date: Sun, 15 Jul 2007 22:43:41 -0400

Come-on Rohan, it's the set of state in a PIDF.

We have a set of state that we think is interesting state about a user that
a watcher wants to know when it changes.  That's presence.  State not in a
PIDF isn't presence.  

It's certainly true that one use for presence is deciding whether an how to
communicate, but I certainly don't think that is a limiting use.  It's just
a use.  

We have this useful mechanism and we have a specific set of data in it.
Unless we have a really good reason, we shouldn't invent ANOTHER mechanism
to provide that set of data.

You keep bringing up calendaring data.  We use iCal as a way to represent
certain useful state in a PIDF, and we know that there are other calendar
events outside a PIDF.  I don't see there is a real link between the fact
that we have other ways to carry some dates and needing something other than
presence to carry location.  If the presence mechanism really didn't work,
then I might be more interested, but so far I don't see it.

Brian

> Sent: Sunday, July 15, 2007 10:16 PM
> To: Brian Rosen

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 16 Jul 2007 02:16:31 -0500

In Rohan's defence, I offer the following from 4079

"Presence is a service defined in RFC2778 [2] that allows users of a
   communications service to monitor one another's availability and
   disposition in order to make decisions about communicating.  Presence
   information is highly dynamic, and it generally characterizes whether
   a user is online or offline, busy or idle, away from communications
   devices or nearby, and the like."

Given the heritage of the "presence" concepts and the fact that it's
been linked with Instant Messaging since people started trying to define
it ten years ago, I think it's reasonable to relate it to the
communication function.

Perhaps more fundamentally, 2778 defines a presence service as
supporting presentities and watchers. I don't believe a LIS fits this
description at all. A presentity publishes the presence information to
the presence server so that watchers can retrieve it. A LIS determines
location of a device on request. A device has a transient "presence" in
an access network certainly, and it has a transient "identity"
associated with this presence. However, these are suggestive of
presence; the metaphor breaks down on close examination.

Actually, I seem to recall that an early draft of HELD included the
concept of the device providing the usage rules and this was ruled-out
(no pun intended), and subsequently dropped, on the basis that the LIS
is not a presence service for the device.

I hope nobody ends up arguing that since location is encoded in a PIDF
extension that we must be dealing with a presence service with respect
to the LIS. When I read the Geopriv charter and 4119, my sense is that
location wasn't seen as presence-encumbered initially. The purpose of
the PIDF-LO was to provide the glue for presence-related information
(usage rules etc) that may be attached to a given instance of some
location info. As it seems to have turned out, the PIDF-LO has become
the generic location-blob encoding that happens to have some presence
add-ons.

If this (hey, it's a PIDF) argument does get used then I'd have to side
with Rohan on the basis that this is exactly the sort of confusion that
could arise in the future if you try to apply a presence package to a
service which isn't a presence service. Somebody will adopt a dogmatic
position that a LIS can't be used in some way because it is a "presence
service". It would also make me feel that it might have been better to
define a location info object, with the location info element,
completely separately to 4119. This is probably when nice clean location
got broken.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, 16 July 2007 7:51 AM
To: 'Rohan Mahy'
Cc: 'GEOPRIV'; [email-masked]
Subject: RE: [Geopriv] SIP lbyr location

Well gee Rohan, I went back and read 3863, which references 2778, and
you
know what?  It doesn't talk about presence as having anything to do with
"ability to communicate".  It talks about presence as being a set of
state
data of the user.

I don't think there is any "ambiguity" between presence and raw
location.
Raw location is one form of presence.  A location server can process
location in the same way any presence server can do that.  It can give
one
watcher a different form than another.

I also don't see how caller pref/caller capabilities is enhanced in any
way
that is helpful in any practical sense.  The only callee capabilities of
interest would be those of the server to whom you SUBSCRIBE.  If you got
the
URI from a Geolocation header, then you understand what happens when you
used it.  Similar for other forms of presence.  Caller Preference?  Who
would use either on a SUBSCRIVE in caller preference?  "I don't want no
stinkin presence, I only want location"?  

I absolutely think presence aggregation will happen, among other ways by
an
aggregator subscribing to another presence system.  It's just a watcher.
It
would use whatever credentials it needed to be a watcher.  The
presentity
would tell its presence system what to give it.

Let's use a simple example.  Suppose I have a mobile phone, which is on
the
T-Mobile network, and a home phone, which is on the Comcast network.  My
presence is an aggregation of both the T-Mobile and the Conmcast
presence
information.  An aggregator could subscribe as a watcher to both
T-Mobile
and Comcast and produce a presence document much more effective that
either
could.  In fact, the aggregator watcher may end up being the only
watcher
for each of the services.

Now, there may indeed be other ways to get the data, but a watcher
subscription is a pretty useful, general purpose way.  Have you ever
used a
financial data sweep service?  Look at yodlee for an example.  You give
it
credentials at all your bank, credit card and investment websites, and
it
gives you a composite picture of everything. None of your individual
financial service companies can do that (unless they do what yodlee
does,
which some of them offer).

Anyway, I still don't see it.  To me, a PDIF with just location data is
a
fine way to represent a piece of presence, just line a PIDF with just,
oh,
<time-offset>.
  
Brian

usingdraft-mahy-geopriv-
string
Where
expect
know
package
privacy

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 16 Jul 2007 00:19:22 -0700

> Come-on Rohan, it's the set of state in a PIDF.

That's a tautological argument using circular reasoning.  Just answer  
the question.  How do you define presence?

We need a way to decide what is useful to put in a PIDF document and  
not all of that is inherently presence data.  Some information you  
can supplementally include (like location and calendar data) is  
useful in its own right.

I think it is particularly telling that you keep talking about "the  
user".  The reference provided by an LCS refers to a target, not to a  
user.  In many cases there will be no user associated with the  
target.  I have a hard time stretching the definition of presence to  
cover the location of a dialysis machine, just because you can put  
that location in a PIDF-LO.

> a watcher wants to know when it changes.  That's presence.  State  

WHY is a particular piece of information relevant in a PIDF?  It is  
relevant if and only if it provides hints to a watcher about the  
presentity's availability to communicate.  That is its reason for  
inclusion, IMO.

> to provide that set of data.

We do have a very good reason. Location data is useful completely  
outside the scope of presence, just like calendaring data is.

> events outside a PIDF.

Yes.  And we know that lots of people currently represent location  
information outside of presence, and many of them (god forbid) use  
formats other than PIDF to do it. Do you think all the other people  
out there are going to say "Thank you Brian, I didn't realize that I  
was wrong all these years, that data can be placed in a PIDF-LO so  
therefore it must have been presence all along and could never be  
anything else.  How silly of me."  I guess I should go retire my  
message-summary event package now.

> I don't see there is a real link between the fact
> presence to carry location.
> If the presence mechanism really didn't work,

We came to consensus that we will provide an HTTP location  
dereference option.  I hope you are not going to tell me that the  
HTTP fetch is a presence operation.  If so, why isn't fetching my  
calendar always considered presence information?

Now lets look closely at the market.  How many commercial location  
servers are out there that support SIP?  I can't even come up with  
one, yet there are several commercial location servers out there with  
HTTP-based and proprietary protocol solutions.  None of them call  
their system a presence server. I suspect those folks don't think  
location is presence either.

thanks,
-rohan

>>>>>>> 2. Is there a rule somewhere that says that a presence URI  
>>>>>>> has to
>>>>>>> be an AoR?
>>>>>>> identify which presentity you want presence for?  For  
>>>>>>> example, if
>>>>>>> it was a
>>>>>>> server to *generate* SUBSCRIBE requests".  See item 1 above.   
>>>>>>> You
>>>>>>> subscribe
>>>>>>> information through another protocol.  However, the case  
>>>>>>> where an
>>>>>>> endpoint
>>>>>>> location than for other presence data.  You want a filter  
>>>>>>> that is
>>>>>>> something
>>>>>>>> own location. Say that the target discovers the LIS and asks  
>>>>>>>> for
>>>>>>>> lbyr.
>>>>>>>> Finally, if you did frankenstein the presence event package,  
>>>>>>>> you
>>>>>>>> would
>>>>>>>>>> http://svn.resiprocate.org/rep/ietf-drafts/rohan/locpkg/ 
>>>>>>>>>> draft-
>>>>>>>>>> mahy-

---

From: "Dawson, Martin" <[email-masked]>
Date: Mon, 16 Jul 2007 02:19:36 -0500

Don't you think it's true that "location" is a valid parameter of
somebody's presence information? I think it is - but (per my previous
post) I don't think it's only relevant in a presence context and
deserves to be able to be measured, determined, acquired, and conveyed
without "presence encumbrances".

Cheers,
Martin

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Monday, 16 July 2007 8:10 AM
To: Rohan Mahy; Brian Rosen
Cc: 'GEOPRIV'; Rohan Mahy; [email-masked]
Subject: Re: [Geopriv] SIP lbyr location

I don't disagree with this statement, but there is a history of folks 
saying (publicly) that location is a part of Presence.  They where wrong
IMO.

James

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Jul 2007 10:38:29 +0200

There is a bit of terminology confusion.

This is raw location information:

        <cl:civicAddress>
          <cl:country>US</cl:country>
          <cl:A1>New York</cl:A1>
          <cl:A3>New York</cl:A3>
          <cl:A6>Broadway</cl:A6>
          <cl:HNO>123</cl:HNO>
          <cl:LOC>Suite 75</cl:LOC>
          <cl:PC>10027-0401</cl:PC>
        </cl:civicAddress>

This is a PIDF-LO (from RFC 4119):

<?xml version="1.0" encoding="UTF-8"?>
 <presence xmlns="urn:ietf:params:xml:ns:pidf"
    xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
    xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
    entity="pres:[email-masked]">
  <tuple id="sg89ae">
   <status>
    <gp:geopriv>
      <gp:location-info>
        <cl:civicAddress>
          <cl:country>US</cl:country>
          <cl:A1>New York</cl:A1>
          <cl:A3>New York</cl:A3>
          <cl:A6>Broadway</cl:A6>
          <cl:HNO>123</cl:HNO>
          <cl:LOC>Suite 75</cl:LOC>
          <cl:PC>10027-0401</cl:PC>
        </cl:civicAddress>
      </gp:location-info>
      <gp:usage-rules>
        <gp:retransmission-allowed>yes</gp:retransmission-allowed>
        <gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
      </gp:usage-rules>
    </gp:geopriv>
   </status>
   <timestamp>2003-06-22T20:57:29Z</timestamp>
  </tuple>
 </presence>

When you fetch such a document from a LIS there is obviously no Rich 
Presence in a similar fashion as there might not be rich presence on an 
ordinary presence server either if it just does not have the information.

The information that is in a PIDF-LO beyond the raw location information 
is useful and its good that this stuff is there. A long time ago we 
decided that we would want to provide a PIDF-LO rather than sending 
around raw location information.

I don't see a need to define a new event package just because the term 
LIS is not the same term as a presence server.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Jul 2007 10:41:07 +0200

James M. Polk wrote:
> Robert has strongly suggested this section (3.6) of Conveyance include 
> an event package - with rules of usage.  After talking with him about 
> it, I agree.  This will be a new event package and will only allow a 
> single (Expires: 0) dereference (i.e., one NOTIFY containing the 
> PIDF-LO), and not allow pending subscriptions or target tracking 
> (i.e., numerous NOTIFYs returned).
This is totally wrong. Why would you want to make of a SUBSCRIBE/NOTIFY 
concept if you want to rule out this behavior?
> "location-deref", verses something else like "location-tracking" for a 
> future effort that's out of scope for Conveyance.
>
> Rohan, I'm open to your suggestions on how to further make section 3.6 
> clearer, as Conveyance right now doesn't allow "raw" location to be 
> sent anywhere.
>
This just does not make sense to me.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 16 Jul 2007 10:50:48 +0200

Hi Henning,

> This clearly has the potential of another fun GEOPRIV philosophy 
I fully agree with you and I don't have the time to spend again a few 
months of discussions where we publish documents that have this 
philosophical touch

Ciao
Hannes

> (1) I don't think we do well in trying to discern intent or "meaning". 
> (See where the "using protocol" mess has gotten us...). We tend to 
> have fewer arguments if we stick to externally observable behavior. In 
> other words, "I don't care why you want these bits and what you want 
> to do with them, as long as they serve your needs (and you're allowed 
> to have them), be my guest.". Thus, we should try to clearly 
> articulate differences in behavior that a third party could actually 
> observe.
>
> Similarly, a second test is whether a server of type A could serve the 
> needs of client of type B. In this particular case, this appears to be 
> true. If I hand out a SIP URL of a PIDF-LO understanding "presence" 
> server, it would indeed seem to be able to answer the "where-is-he" 
> question in a way that the querier can use.
>
> omitted. Without this, there isn't much to communicate with. (The 
> loc-pkg draft doesn't seem to require that the server omits these 
> coarse-grained. Thus, you can easily get combinatorial explosion since 
> each new subset of data needs a new label. I think the filtering 
> mechanism is a much more appropriate tool to pick and choose 
> PIDF(-LO)/RPID/... elements, rather than trying to name each possible 
> combination of data about an entity identified by a SIP URI. In 
> particular, this allows re-use of the same infrastructure.
>
> (4) There are two choices in terms of the data returned: Either indeed 
> anything that is application/pidf+xml is legal for both presence and 
> any other related events, or there is some implied subsetting. In the 
> former case, the extension fails the test of being discernible by an 
> external observer. In the latter, every new PIDF/PIDF-LO extension has 
> to be profiled for all these event packages, with little obvious gain 
> in system functionality or simplicity.
>

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 16 Jul 2007 07:27:57 -0700

Hannes,

Thank you for bringing up this terminology question.  What you  
described is not what I meant by raw vs. processed location.  AFAIK  
the syntax of the document format is irrelevant.  Below is my working  
definition.

Raw location is a complete and accurate description of the location  
of a target without any fuzzing or obfuscation. Hopefully it will  
also contain a description of accuracy, and when and how the location  
was generated.  In short, raw location is a "measurement".

Processed location is a "presentation" of the *possible* location of  
a target. This location information should be filtered, it may be  
fuzzed (it might show my location as in the geographic center of  
Boston when I am in some suburb) or obfuscated, it may be entirely  
wrong (it may say that I am sitting at home when I am really in  
Bangkok).  The accuracy may be omitted or reported as more or less  
accurate than reality.

The semantics are very different.  Traditional presence systems allow  
lying and filtering.  They provide a "presentation" and IMO therefore  
provide an appropriate way to convey processed location.  This  
processed location is used as supplemental information by the  
presence watcher.  Raw location is needed by a variety of  
applications.  Only one of these applications is presence and only  
one of them currently uses SIP.  Exactly like calendar data or  
registration data, this raw location can be used as an *input* to  
presence systems.

thanks,
-rohan

On Jul 16, 2007, at 1:38 AM, Hannes Tschofenig wrote:

> When you fetch such a document from a LIS there is obviously no  
> Rich Presence in a similar fashion as there might not be rich  
> presence on an ordinary presence server either if it just does not  
> have the information.
>
> The information that is in a PIDF-LO beyond the raw location  
> information is useful and its good that this stuff is there. A long  
> time ago we decided that we would want to provide a PIDF-LO rather  
> than sending around raw location information.
>
> I don't see a need to define a new event package just because the  
> term LIS is not the same term as a presence server.
>
> Ciao
> Hannes

---

From: "Marc Berryman" <[email-masked]>
Date: Mon, 16 Jul 2007 09:43:54 -0500

Rohan,

I think we all agreed that the original way the location was determined
would be the way the location is passed. There is no "Processed
information" as you put it. 

To paraphrase a previous comment by Brian Rosen, "If the original way
the location was determined yielded a civic, send the civic.  If the
original location was measured and yielded a geo, send the geo.  Never,
ever, convert."

Marc B

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Monday, July 16, 2007 9:28 AM
To: Hannes Tschofenig
Cc: Rohan Mahy; [email-masked]; 'GEOPRIV'
Subject: Re: Terminology....Re: [Geopriv] SIP lbyr location

Hannes,

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 16 Jul 2007 07:57:52 -0700

Marc,

I certainly agreed to no such thing in this working group.

A very common use case in presence systems is that the presentity can  
voluntarily disclose its (apparent) city and country.  I can't  
imagine any reason why a presence server should not be allowed to do  
this processing after receiving a raw location in coordinate form.   
Likewise, inside a presence document I can lie about my availability  
and my location.  I can provide a presence document that says I am  
sleeping in California when I am actually out clubbing in Sweden.

You may be confusing the geopriv working space with the working space  
for ecrit.  Emergency applications clearly wants their location as  
raw as they can get it and they want it to be truthful and accurate.

I hope you see why having one package for presence and one for  
location can provide a clear distinction between these semantics.

thanks,
-rohan

---

From: "Marc Berryman" <[email-masked]>
Date: Mon, 16 Jul 2007 10:21:26 -0500

Inserting an valid, more accurate, or "apparently" more accurate
location in to Geopriv is perfectly acceptable to me, what I am saying
is I have a great issue with "updated and preassembly more information"
vs. "fuzzied , filtered, or best guess" location information.

Marc B

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Monday, July 16, 2007 9:58 AM
To: Marc Berryman
Cc: Rohan Mahy; Hannes Tschofenig; [email-masked]; GEOPRIV
Subject: Re: Terminology....Re: [Geopriv] SIP lbyr location

Marc,

thanks,
-rohan

---

From: "Marc Berryman" <[email-masked]>
Date: Mon, 16 Jul 2007 10:23:28 -0500

My comments should have been transmitted as "updated and presumably more
precise information" and not "updated and preassembly more information"

Marc B

-----Original Message-----
From: Marc Berryman [mailto:[email-masked]] 
Sent: Monday, July 16, 2007 10:21 AM
To: Rohan Mahy
Cc: [email-masked]; GEOPRIV
Subject: RE: Terminology....Re: [Geopriv] SIP lbyr
locationderefusingdraft-mahy-geopriv-sip-loc-pkg-02.txt

Marc B

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Monday, July 16, 2007 9:58 AM
To: Marc Berryman
Cc: Rohan Mahy; Hannes Tschofenig; [email-masked]; GEOPRIV
Subject: Re: Terminology....Re: [Geopriv] SIP lbyr location

Marc,

thanks,
-rohan

---

From: Robert Sparks <[email-masked]>
Date: Mon, 16 Jul 2007 12:53:59 -0500

My feedback to James was that the draft needed to specify which event  
package it would use, not to suggest we needed a new one. However
that argument turns out, the document's going to point to what to do.

The document as written makes the implicit assumption that the  
dereferencing was a simple fetch. If it's not, there's text in the  
document
that will need to be adjusted and _somewhere_ there's going to have  
to be guidance about using the reference over time. If that's not in
this document, this document needs to point to it.

RjS

On Jul 16, 2007, at 3:41 AM, Hannes Tschofenig wrote:

>> include an event package - with rules of usage.  After talking  
>> with him about it, I agree.  This will be a new event package and  
>> will only allow a single (Expires: 0) dereference (i.e., one  
>> NOTIFY containing the PIDF-LO), and not allow pending  
>> subscriptions or target tracking (i.e., numerous NOTIFYs returned).
> This is totally wrong. Why would you want to make of a SUBSCRIBE/ 
> NOTIFY concept if you want to rule out this behavior?
>>
>> "location-deref", verses something else like "location-tracking"  
>> for a future effort that's out of scope for Conveyance.
>>
>> 3.6 clearer, as Conveyance right now doesn't allow "raw" location  
>> to be sent anywhere.
>>

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 16 Jul 2007 21:03:16 -0700

Hi Marc,

I don't think I understand you.  It sounds like you want to be able  
to get raw location information about a target.  I do too.  Do you  
object to watchers being able to get processed location information  
(via presence) about a presentity if that location is intentionally  
less accurate or intentionally deceptive?  I think this an important  
use case. I also expect that an intentionally incomplete or deceptive  
location would not be used in an emergency context.

thanks,
-rohan

---

From: "Marc Berryman" <[email-masked]>
Date: Tue, 17 Jul 2007 06:53:37 -0500

Rohan,
 I think we are very close on this issue, but rather than drag out the
discussion on the list, I suggest we discuss this over a phone call. We
can then post our discussion back to the list and keep everyone in the
loop.

If you provide me a phone number and a time, I think we can close this
issue. I'll be available anytime after noon today (Tuesday).

Thanks,
 Marc

(713) 407-2254

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]] 
Sent: Monday, July 16, 2007 11:03 PM
To: Marc Berryman
Cc: Rohan Mahy; Hannes Tschofenig; [email-masked]; GEOPRIV
Subject: Re: Terminology....Re: [Geopriv] SIP lbyr location

Hi Marc,

thanks,
-rohan