Subject: Re: [Geopriv] New draft on using SIP events as an L7 location configuration protocol

From: John Schnizlein <[email-masked]>
Date: Wed, 1 Nov 2006 16:50:38 -0500

It is in the archive now:
http://www.ietf.org/internet-drafts/draft-schulzrinne-geopriv- 
locationref-00.txt

Why not allow the SIP Event Package to enable subscribing to the value  
of a location as well as the limited-duration reference?  This would  
avoid the extra step of subscribing for de-referencing for those  
situations where the value is not embargoed.

John

On Oct 17, 2006, at 1:24 PM, Henning Schulzrinne wrote:

> Until it appears in the archives, you can find a draft at
>
> http://www.cs.columbia.edu/sip/draft/l7-presence/draft-schulzrinne- 
> geopriv-locationref-00.txt
>
> or, in technicolor,
>
> http://www.cs.columbia.edu/sip/draft/l7-presence/draft-schulzrinne- 
> geopriv-locationref-00.html
>
> This is the joint effort of a number of folks, but given the short  
> gestation period between conception and birth, not all contributors  
> have had a chance to vet the text, so the errors are all mine.
>
> Comments are appreciated.
>
> Henning
>
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
>

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 01 Nov 2006 17:16:21 -0500

John Schnizlein wrote:
> http://www.ietf.org/internet-drafts/draft-schulzrinne-geopriv-locationref-00.txt 
> 
> 

This is already possible, simply by subscribing to one's own presence 
package. Whether a separate location-only package is necessary is 
somewhat a matter of taste, as a watcher-filter can accomplish the same 
thing. However, a watcher filter doesn't deal well with the 
semi-anonymous subscription model we have here. Thus, there are two 
options, at least:

(1) Same mechanism, subscribe to 'presence' event, but the LIS by its 
nature will only return PIDF-LO, where none of the other presence 
information is available (since a LIS presumably has no clue about your 
RPID information, say, beyond maybe the location type);

(2) Create a new event type for returning a PIDF-LO with only location 
information.

(1) has the advantage that there are indeed location-related RPID 
elements that a LIS could know and that are useful to the UA.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 1 Nov 2006 17:32:48 -0500

Sorry, I am confused by this answer.

You can't subscribe to LIS presence event, because you don't know the AoR at
the LIS until you get that from the proposed protocol.

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, November 01, 2006 5:16 PM
> To: John Schnizlein
> Cc: [email-masked]
> Subject: Re: [Geopriv] New draft on using SIP events as an L7
> locationconfiguration protocol
> 
> 
> 
> John Schnizlein wrote:

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 1 Nov 2006 22:09:43 -0500

Let me try to be a bit more specific. The basic approach is:

(1) Get address of LIS (via DHCP, etc., as described). This obviously  
doesn't depend on the format of the data returned.

(2) Send SUBSCRIBE to that location. As noted, the subscription is  
simply to the LIS, with no user part (sip:lis.example.com). The Event  
header contains 'presence'. For a one-time retrieval, the Expires  
header is 0.

(3) The NOTIFY returns the LO to the subscriber (target).

This is only alluded to in the document, under a TBD, and clearly  
needs to be fleshed out.

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 2 Nov 2006 09:10:50 -0500

Got it.  Like it.  Would this actually be a change to the definition of the
presence package?

Brian

> Sent: Wednesday, November 01, 2006 10:10 PM
> To: Brian Rosen
> Cc: 'John Schnizlein'; [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 2 Nov 2006 09:58:51 -0500

> Got it.  Like it.  Would this actually be a change to the  

Yes, there will need to be one change, namely the addition of event  
parameters similar to the locationref parameters in Section 7.2. It  
is unclear to me, procedurally, how to best extend existing packages  
with parameters. This is an issue that requires some thought in  
SIMPLE, as it seems likely that we'll be facing similar problems  
elsewhere. In this case, the "ignore it if you don't know it"  
approach seems to be sufficient.

I will note in passing that a different geopriv draft by Vishal Singh  
and myself (on dynamic features) touches on the issue that we don't  
have good negotiation capabilities for subscriptions. Some  
combination of namespace tags and maybe subscription filters may be  
needed, but this isn't specific to the L7 issue.

Henning

---

From: "Rohan Mahy" <[email-masked]>
Date: Mon, 6 Nov 2006 14:22:51 -0800

Hi,

I've read the draft and I think this is on the wrong track.

First of all, I'd like to point out that none of the entities in the
draft are actually interested in the presence of a presentity.  I'm
using the IMPP WG definition of presence as "willingness to
communicate".   As I brought up when I proposed a separate location
package ~2 years ago, there is a difference between presence with
embedded location information (this information can be filtered,
obscured, or otherwise processed), and raw location information with
no interpretation about what this means about the ability or
willingness of a resource to communicate.  I'll point out that the
resource in the raw location case is not an AOR that is useful for
communication.  I think it is important that we use the presence
package to get presence (which can optionally contain cooked
location), and raw location that is uncorrelated to presence.

Second, this mechanism uses a fixed-length, implicit, non-renewable
lifetime for the location subscription.  There is no way to get a
longer-term URI, and no way to revoke a URI. Why is this a problem?
Lets assume that my endpoint wants to get its RAW location to its
Presence Server for one of its AORs.   One of the main motivators we
discussed for HELD is the ability for the PS to get accurate raw
location information from the LIS without requiring the endpoint to
PUBLISH every time its location changes.  The endpoint has no idea how
granular the cooked location provided by the PS will be.  Therefore it
does not know how often it needs to provide the RAW location to the PS
as it moves.
 (I am much happier using something like HELD to explicitly get
individual URIs that the endpoint can control.  The endpoint can hand
one to its PS and fetch another URI that it can use for emergency
calls. )

Finally, the discovery mechanism says to use normal SIP SRV/NAPTR to
find the LIS.  These records already exist and are *extremely
unlikely* to point at a LIS.  In the 802.11 TGv mechanism I can
discover my LIS via a URI provided by layer 2.  Using a separate SRV
lookup for an L7 LIS protocol would also work.

thanks,
-rohan

On 10/17/06, Henning Schulzrinne <[email-masked]> wrote:
> http://www.cs.columbia.edu/sip/draft/l7-presence/draft-schulzrinne-geopriv-locationref-00.txt
>
> or, in technicolor,
>
> http://www.cs.columbia.edu/sip/draft/l7-presence/draft-schulzrinne-geopriv-locationref-00.html
>
> gestation period between conception and birth, not all contributors have
> had a chance to vet the text, so the errors are all mine.
>

---

From: Andrew Newton <[email-masked]>
Date: Mon, 6 Nov 2006 18:42:23 -0500

> I've read the draft and I think this is on the wrong track.

Rohan,

I don't have a dog in this fight, but I'm very puzzled by your  
logic.  The basis of your argument is that you view location and  
presence in terms that are different than that of the GEOPRIV model,  
and therefore this proposal before the GEOPRIV working group is  
wrong.  Is that an incorrect interpretation?

-andy

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 8 Nov 2006 15:06:48 -0800

Hi Andy,

Thanks for asking.

My objections to this document are related to two issues.  The first
objection is that I don't think the proposal meets the requirements
described in the mobility section of the L7 draft.  I want my target
to be able to get a long-term location reference from the LIS and give
it my presence server.  That's not enabled by Henning's proposal.

The second objection is using a presence event package to carry data
that contains no information about presence. I don't have any problem
using PIDF as a container document format to carry either raw location
or potentially filtered, obfuscated, or otherwise processed location
included with genuine presence data. AFAIK a document format is
primarily syntactic. However, I consider the _semantics_ of a raw
location event package to be very different from those of the presence
event package.  For example, the actors involved are different, the
authorization rules are very different, the composition rules are
complex for presence and non-existent for raw-location, the
scalability requirements are different, etc. I've enumerated these
comments before. If folks are interested, I can dig up my comments
from shortly after my presentation on draft-mahy-geopriv-loc-pkg.

I hope this clarifies things.
thanks,
-rohan

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 8 Nov 2006 18:44:01 -0800

Rohan,

I have no problem making the lifetime of the URL configurable.

Also, as I noted, the mechanism is fairly general, so one could image  
a "x-ref" mechanism which would allow retrieving a reference to any  
event package object. I'm not sure we need that full generality, but  
it might be worth discussing.

A separate question is whether constructing a separate location  
object XML and tracking all the profile issues is worth the effort,  
given that almost all of the non-location information in PIDF-LO is  
optional and can be omitted where it doesn't make sense. So far, the  
working group seems to have been disinclined to make that effort. (We  
do have the location profiles in LoST as one "pure location" object.)

I'll also note that HELD currently uses PIDF-LO, as far as I can  
tell, so I'm curious to hear why your objections apply to the  
locationref proposal, but not to HELD.

Henning

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 9 Nov 2006 10:01:04 -0800

Henning,

As I said in another mail yesterday, I do not object to using PIDF-LO
to carry location, since I consider document formats to be primarily
syntactic in nature.  An event package, though has a lot of semantic
behavior built very deeply into it.

thanks,
-rohan

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 9 Nov 2006 10:10:44 -0800

> behavior built very deeply into it.

In my view, an event package indicates when the object conveyed has  
changed in some meaningful way. Can you expand on "semantic behavior"?

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 9 Nov 2006 11:40:14 -0800

Without going into a lengthy treatise, all the elements in an event
package definition, such as if forking is permitted, default lifetime,
event-package parameters, mandatory to implement document formats or
profiles, security considerations, etc.

A location package would include mandatory profiles that presence does
not even if it uses the same container document (PIDF).

thanks,
-rohan