Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 25 Jul 2006 16:41:31 -0400

As Brian points out, the whole point of using PIDF for location information was the similarity of the early defined use cases to the presence architecture. This certainly included use cases in which one wanted to fetch or subscribe to location information. Those operations require the existence of a reference, and that reference was commonly described as a URI, at the time. Lately, I think the idea of having a URI pointing to location information has become associated with a specific proposal (i.e. HELD), but clearly RFC4079 sketched out an architecture for using presence to acquire location information and it specifically mentions URIs as a way to refer to presence. 

There is no "hidden magic" in any of this. Subscribing to presence, and using URIs to indicate presence information, is exhaustively specified for SIP. PIDF-LO was designed to reuse all of that work and specifically not to require us to go out and reinvent everything in order to be able to refer to location information out in the network.

Basically, I support the direction re: bullet 6. I might further suggest that the CID URI scheme be permitted in the Location header, in order to be able to refer to MIME bodies included in SIP messages. I'm also neutral/favorable on using HTTP GET. But I think either of these URI schemes and their usage in the Location header could just as well be described in subsequent documents.

Jon Peterson
NeuStar, Inc,

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Tuesday, July 25, 2006 1:05 PM
> To: Rosen, Brian
> Cc: [email-masked]; [email-masked]; Marc Linsner
> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to
> location-conveyance
> 
> 
> For the record, I agree with Brian.
> 
> -andy
> 
> On Jul 25, 2006, at 3:50 PM, Rosen, Brian wrote:
> 
> > When the original PIDF-LO RFC came out, location-by-reference was
> > defined.
> >
> > You have a URI.  You can exchange the URI for location.  There is a
> > protocol defined for that purpose (SIP SUBSCRIBE).  That is  
> > location by
> > reference.  It also serves as the location update mechanism, clearly
> > something we need.
> >
> > Some day, there may be other location URI references.  We don't  
> > need to
> > cover them in this draft.  The basic location by reference horse has
> > left the barn.  Were you planning on creating an RFC that 
> specifically
> > disallows a Subscribe on a sip/sips/pres URI to get location?    
> > THAT WAS
> > THE POINT OF MAKING IT PART OF A PIDF.
> >
> > I do think there is some value in defining a way to express a
> > location-by-reference aka presence URI which is not just the AoR.   
> > That
> > is one reason why I want to define the Location URI as being able to
> > contain a sip/sips/pres URI.  The purpose is to allow a UA or a  
> > proxy to
> > insert location where there is no association between the 
> identity of
> > the SIP user and the location.
> >
> > But that is all I think we need.
> >
> > We have a requirement for proxy insertion of location.  If 
> we disallow
> > location-by-reference (which I think is a good idea in general, but
> > futile in practice), then we would need something like the 
> Data URI to
> > support location insertion by proxy.  If we DO allow
> > location-by-reference, then it also serves to meet the location
> > insertion by proxy requirement, and we don't need the Data 
> URI.  We're
> > looking for a use case which requires proxy insertion by value, but
> > haven't heard one yet.
> >
> > You can make an argument that you can take the From:, assume it's an
> > AoR, and SUBSCRIBE to the presence of that AoR to get location,  
> > thus not
> > needing a Location header.  I really think letting the 
> Location header
> > specify an alternate presence URI is a good idea.
> >
> > Brian
> >
> >> -----Original Message-----
> >> From: Marc Linsner [mailto:[email-masked]]
> >> Sent: Tuesday, July 25, 2006 3:29 PM
> >> To: Rosen, Brian; [email-masked]
> >> Cc: [email-masked]
> >> Subject: RE: [Geopriv] Consensus on changes to location-conveyance
> >>
> >> In-line.....
> >>
> >>> -----Original Message-----
> >>> From: Rosen, Brian [mailto:[email-masked]]
> >>> Sent: Tuesday, July 25, 2006 1:38 PM
> >>> To: [email-masked]
> >>> Cc: [email-masked]
> >>> Subject: [Geopriv] Consensus on changes to location-conveyance
> >>>
> >>> I have put out a number of emails on proposed changes to
> >>> location conveyance.  Some of them have sparked a number of
> >>> comments.  My summary of consensus on these issues is:
> >>>
> >>> 1. We proposed to explicitly disallow use of a Data URI,
> >>> which would allow specification of a Location-by-value in a
> >>> header.  There was a lot of list traffic on this, currently
> >>> in the state where Keith asked for a real use case for it.
> >>> So far, we don't see a use case that cannot be provided by
> >>> location-by-reference in a header.  If we don't get a good
> >>> use case, I think consensus is to disallow location-by-value
> >>> in a header.
> >>>
> >>
> >> I see a problem here.  Location-by-reference is nothing more than
> > 'magic
> >> happens here'!  Please point to a wg item documenting the
> >> location-by-reference mechanism.  How can you state the
> >> location-by-reference will cover all the use cases that 
> the Data URI
> > would
> >> when location-by-reference hasn't even been defined 
> anywhere?  You're
> >> loading up the magic with a lot of assumptions.  Location-by- 
> >> reference
> > is
> >> an
> >> individual submission as a solution to a set of requirements that
> > haven't
> >> been fleshed-out in geopriv.
> >>
> >> I believe that Henning/Hannes also recognized this issue, hence the
> >> suggestion of a Data URI.  Dismissing this suggestion based on an
> > already
> >> accepted non-existent mechanism seems like getting the 
> cart before  
> >> the
> >> horse.
> >>
> >> ..........snip
> >>
> >>> 6. We proposed to allow sip/sips and pres: in the location
> >>> header.  I later speculated that if we allow this, it forms a
> >>> simple way to do location-by-reference, and we could
> >>> eliminate the raw HTTP(S) Get proposal, with the parameter
> >>> and registry entirely.  There was some list traffic in favor
> >>> of this.  Martin Thompson is skeptical that SIP Presence
> >>> Subscribe/Notify is actually allowed as a geopriv "using
> >>> protocol".  Several of think that it is.  If we don't get any
> >>> more comments on this proposal, we will allow sip/sips and
> >>> pres, not have any
> >>> http(s) resolution text, and not propose a parameter and
> >>> accompanying registry.
> >>
> >> I certainly think it's more prudent to define the dereferencing
> > mechanism
> >> prior to making claims about the protocol.
> >>
> >> Do I believe location-by-reference will happen?  Probably, 
> but making
> >> assumptions about the mechanism now is quite premature.
> >>
> >> -Marc-
> >>
> >>>
> >>> If this does not reflect your position, please speak up now.
> >>>
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 25 Jul 2006 17:37:12 -0500

This makes sense.  I think that this supports Brian's suggestion.  I was against any syntactic constraints, but will acquiesce in the interests of progress.

Let it be sip/sips/pres/cid.

Cheers,
Martin

p.s. I regret the possibility that the concept of a reference could have been tainted by association - certainly, we did not think that we had invented anything new.

> From: Peterson, Jon [mailto:[email-masked]]
> Sent: Wednesday, 26 July 2006 6:42 AM
> To: Andrew Newton; Rosen, Brian
> Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-
> conveyance
> 
> 
> As Brian points out, the whole point of using PIDF for location
> information was the similarity of the early defined use cases to the
> presence architecture. This certainly included use cases in which one
> wanted to fetch or subscribe to location information. Those operations
> require the existence of a reference, and that reference was commonly
> described as a URI, at the time. Lately, I think the idea of having a URI
> pointing to location information has become associated with a specific
> proposal (i.e. HELD), but clearly RFC4079 sketched out an architecture for
> using presence to acquire location information and it specifically
> mentions URIs as a way to refer to presence.
> 
> There is no "hidden magic" in any of this. Subscribing to presence, and
> using URIs to indicate presence information, is exhaustively specified for
> SIP. PIDF-LO was designed to reuse all of that work and specifically not
> to require us to go out and reinvent everything in order to be able to
> refer to location information out in the network.
> 
> Basically, I support the direction re: bullet 6. I might further suggest
> that the CID URI scheme be permitted in the Location header, in order to
> be able to refer to MIME bodies included in SIP messages. I'm also
> neutral/favorable on using HTTP GET. But I think either of these URI
> schemes and their usage in the Location header could just as well be
> described in subsequent documents.
> 
> Jon Peterson
> NeuStar, Inc,
> 

------------------------------------------------------------------------------------------------
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: "Brian Rosen" <[email-masked]>
Date: Tue, 25 Jul 2006 18:51:21 -0400

So, you are arguing against proxy insertion of a location-by-reference?

You don't have a problem with UA insertion of location-by-reference in a
Location header?

Agree that Location insertion by proxy could assume an INVITE arriving at a
proxy without any location.

I've always had a problem with proxy insertion of location because I am
worried that proxies will do this without regard to user's wishes.  In an
emergency case, however, there are no such worries.  I don't see any
difference between by-value and by-reference.

Proxies may disregard advice we supply, but Location URIs in Location
headers probably should not have any user identification information in
either the URI itself, or the resulting PIDF.  If such information is
desired, use the AoR.

De-referencing should always be subject to user rulesets, and would not be
any different than by-value except the obvious issue that the owners of the
proxy may not provide the user with the facilities to control the ruleset,
my original worry.  

Would you not agree that if a proxy is allowed to insert location-by-value,
the concerns would be the same?

Brian

> Sent: Tuesday, July 25, 2006 6:17 PM
> To: 'Peterson, Jon'; 'Andrew Newton'; 'Rosen, Brian'
> Cc: [email-masked]; [email-masked]
> I have no problem with pidf/pidf-lo/presence.
> 
> I have no problem with a ua placing a uri pointing to their presence
> service
> in a header of a sip invite.
> 
> Context check:  We're discussing a sip invite (assumed pointed to
> emergency
> service) that arrives at a proxy with zero location information.
> 
> I'm the only one that has a problem with any (visited) proxy/LIS creating
> a
> uri that can be de-referenced by anyone without regard to user
> security/privacy rules?
> 
> -Marc-
> 
> 
> 
> 
> 
> > Sent: Tuesday, July 25, 2006 4:42 PM
> > Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to
> > location-conveyance
> >
> >
> > As Brian points out, the whole point of using PIDF for
> > location information was the similarity of the early defined
> > use cases to the presence architecture. This certainly
> > included use cases in which one wanted to fetch or subscribe
> > to location information. Those operations require the
> > existence of a reference, and that reference was commonly
> > described as a URI, at the time. Lately, I think the idea of
> > having a URI pointing to location information has become
> > associated with a specific proposal (i.e. HELD), but clearly
> > RFC4079 sketched out an architecture for using presence to
> > acquire location information and it specifically mentions
> > URIs as a way to refer to presence.
> >
> > There is no "hidden magic" in any of this. Subscribing to
> > presence, and using URIs to indicate presence information, is
> > exhaustively specified for SIP. PIDF-LO was designed to reuse
> > all of that work and specifically not to require us to go out
> > and reinvent everything in order to be able to refer to
> > location information out in the network.
> >
> > Basically, I support the direction re: bullet 6. I might
> > further suggest that the CID URI scheme be permitted in the
> > Location header, in order to be able to refer to MIME bodies
> > included in SIP messages. I'm also neutral/favorable on using
> > HTTP GET. But I think either of these URI schemes and their
> > usage in the Location header could just as well be described
> > in subsequent documents.
> >
> > Jon Peterson
> > NeuStar, Inc,
> >
> > > > protocol defined for that purpose (SIP SUBSCRIBE).  That
> > is location
> > > > by reference.  It also serves as the location update mechanism,
> > > > clearly something we need.
> > > >
> > > > Some day, there may be other location URI references.  We
> > don't need
> > > > to cover them in this draft.  The basic location by
> > reference horse
> > > > has left the barn.  Were you planning on creating an RFC that
> > > specifically
> > > > proxy to insert location where there is no association between the
> > > identity of
> > > > AoR, and SUBSCRIBE to the presence of that AoR to get
> > location, thus
> > > > not needing a Location header.  I really think letting the
> > > Location header
> > > >>> I have put out a number of emails on proposed changes
> > to location
> > > >>> conveyance.  Some of them have sparked a number of
> > comments.  My
> > > >>> 1. We proposed to explicitly disallow use of a Data URI, which
> > > >>> would allow specification of a Location-by-value in a header.
> > > >>> There was a lot of list traffic on this, currently in the state
> > > >>> where Keith asked for a real use case for it.
> > > >>> location-by-reference in a header.  If we don't get a good use
> > > >>> case, I think consensus is to disallow location-by-value in a
> > > >>> header.
> > > >>>
> > > >>
> > > >>> 6. We proposed to allow sip/sips and pres: in the
> > location header.
> > > >>> I later speculated that if we allow this, it forms a
> > simple way to
> > > >>> do location-by-reference, and we could eliminate the
> > raw HTTP(S)
> > > >>> Get proposal, with the parameter and registry entirely.
> >  There was
> > > >>> some list traffic in favor of this.  Martin Thompson is
> > skeptical
> > > >>> that SIP Presence Subscribe/Notify is actually allowed as a
> > > >>> geopriv "using protocol".  Several of think that it is.  If we
> > > >>> don't get any more comments on this proposal, we will allow
> > > >>> sip/sips and pres, not have any
> > > > This list is for NEW development of the core SIP Protocol Use
> > > > [email-masked] for questions on current sip Use
> > > > [email-masked] for new developments on the application of sip
> > >
> > >

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 26 Jul 2006 01:21:42 +0200

Brian,

> the concerns would be the same?

That would depend whether the URL dereferences the current location, or the 
location at a particular moment in time. The value of a URI with up2date 
location info is much higher and much more privacy invading than a one-time 
snapshot of a user's location. So perhaps same concerns, but much stronger

For location-by-reference, you'd probably want some additional requirements:
- URL must be valid for a limited amount of time
- URL must be cryptographically hard to guess
- URL must not contain any information that identifies the user / device / 
AoR
- for whatever transport protocol is used: response must be marked as 'no 
cache'
- user must be able to remove the information at the URL, ie explicit 
invalidation
- user must be able to verify correctness of the issued information (ie user 
can access the URL himself)
- user must be able to control who accesses the URL, both upfront and 
history of accesses (for a reasonable period)
- there must be explicit consent before a proxy would insert user location

For the latter point: except for emergency scenario's, the UAC should 
include some flag in the INVITE saying "proxy: please append location". 
You'd probably also want some feedback (eg proxy or UAS adding a header to 
the response saying 'this is the URL that I appended/got'

Regards,

Jeroen

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 25 Jul 2006 20:01:45 -0400

I don't really understand why you think location by reference is so much of
a concern.  If you look at the discussion in context, PIDF-LO defines
location as part of presence.  All of these concerns are relevant there, and
I think they have been adequately covered there.  We even have some work on
anonymization of the identity (and thus of the URI) in presence.  Generally,
a presence uri:

Is not valid for a limited amount of time
Is not hard to guess, if it uses an AoR and could be with anonymous URI.
Identifies the user if it uses an AoR and doesn't with anonymous URI

The protocol (SIP) for retrieving presence, and thus location has the
location ruleset as we defined for PIDF-LO, but otherwise does not have "no
cache" semantics (albeit caching headers is not very interesting in SIP).

Generally, presence systems do have user control of who is allowed to access
information, including location and identifying information, so I think that
is covered fairly well.

Proxy insertion of location, whether by value or by reference has the threat
of not being as subject to user control, but I think in every case you have
to trust your provider to do as you wish, whether it is your presence
provider or your location provider independent of your presence provider,
and proxy insertion doesn't fundamentally alter that.  I worry more about
it, but I don't objectively think it's much different.

Now, if there are other location dereferencing systems, they may need an
analysis like what you are suggesting, but with respect to SIP Presence, as
a form of location by reference, I think we have been over the ground
sufficiently, and we have RFCs that permit it.  Adding restrictions on the
Location header, which I propose is useful precisely to allow an anonymous
presence uri that does not reveal identity is not so great I think.  If you
don't allow that, you would kind of have to use an AoR, which may be
appropriate in some cases, but would not in others.

I think the proponents of proxy insertion argue that providing it means
endpoints don't have to do anything, so I would think they would object to
explicit permission to do so.  You might get away with a flag that says
"don't do it" in the IETF process, but whether such a flag would be deployed
is another matter.   I think we all agree that the emergency case is
different here; laws govern behavior, and in most cases compel location
assertion.

I kind of like the idea that the proxy inserts the header in the response so
the UAC can see it.  What do others think of that? 

Brian

> From: Jeroen van Bemmel [mailto:[email-masked]]
> Sent: Tuesday, July 25, 2006 7:22 PM
> To: Brian Rosen; 'Marc Linsner'; Peterson, Jon; 'Andrew Newton'; Rosen,
> Brian
> Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to location-
> conveyance
> 
> Brian,
>

---

From: Andrew Newton <[email-masked]>
Date: Tue, 25 Jul 2006 20:17:37 -0400

On Jul 25, 2006, at 7:21 PM, Jeroen van Bemmel wrote:
> - URL must not contain any information that identifies the user /  
> device / AoR
> - for whatever transport protocol is used: response must be marked  
> as 'no cache'
> - user must be able to remove the information at the URL, ie  
> explicit invalidation
> - user must be able to verify correctness of the issued information  
> (ie user can access the URL himself)
> - user must be able to control who accesses the URL, both upfront  
> and history of accesses (for a reasonable period)

Please tell me that you are merely suggesting guidelines and  
considerations by operators and are not suggesting 2119 language for  
these?  Because just like you'd never get agreement on the intended  
duration or accuracy or confidence of location-by-value, you'd never  
get agreement on these.

> For the latter point: except for emergency scenario's, the UAC  
> should include some flag in the INVITE saying "proxy: please append  
> location". You'd probably also want some feedback (eg proxy or UAS  
> adding a header to the response saying 'this is the URL that I  
> appended/got'

Just thinking out loud here, but maybe the rule should be that  
proxies never append a Location header except for emergencies.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 25 Jul 2006 20:39:31 -0400

> duration or accuracy or confidence of location-by-value, you'd never
I agree here

> proxies never append a Location header except for emergencies.
Works for me.  Probably wouldn't work for those carriers who do not intend
to support location acquisition by endpoints and do plan to support
commercial location based routing.  They plan to make mucho dineros charging
for location used for location based routing, and don't want those pesky
users to get in the way of their plans.  Of course, they can overcome all
manner of protocol machinery with "As a condition of providing service, user
agrees ...."

Brian

---

From: "Winterbottom, James" <[email-masked]>
Date: Tue, 25 Jul 2006 19:45:30 -0500

Brian,

The fact that people can make money out of a solution scarcely seems a
good reason not to permit it!

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, 26 July 2006 10:40 AM
> To: 'Andrew Newton'; 'Jeroen van Bemmel'
> Cc: [email-masked]; Rosen, Brian; 'Marc Linsner'; [email-masked];
> Peterson,Jon
> manner of protocol machinery with "As a condition of providing
service,
> user

---

From: Andrew Newton <[email-masked]>
Date: Tue, 25 Jul 2006 21:00:54 -0400

Now, now.  Before this degenerates, for non-emergency situations  
having the location flow from the acquisition protocol through the  
UAC on to the call path is completely acceptable and gives the user  
control.  We recognize that emergency cases are different, users  
often are concerned about the emergency and don't need to be bothered  
by interfaces asking "should I include your location".

-andy

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 26 Jul 2006 08:46:22 +0200

> a concern.

Because location by reference involves storage of personal information on a 
server. That suddenly makes all sorts of regulations apply, the points I 
mentioned address only a small part of that. Having an anonymous URL for 
example often makes a difference, because then the information is no longer 
directly linked to a particular person.

When an endpoint inserts location by value, you can reasonably argue that 
opt-in consent requirements (which many countries have) are fulfilled, 
provided the endpoint gives the user control over whether or not location is 
inserted. Same holds for the endpoint inserting a flag asking a proxy to 
fill in the location (by value).
For location-by-reference this is much more fuzzy. You probably don't need a 
lecture on privacy regulations, but e.g. 
http://www.isoc.org/briefings/015/index.shtml (from 2003 but still 
applicable IMO) illustrates the mess.

A while ago I submitted a draft on Temporarily Routable User Agent URIs 
(http://www.ietf.org/internet-drafts/draft-jbemmel-sip-truu-02.txt), which 
provides anonymous, temporary URIs that can be explicitly invalidated. You 
may want to consider something similar for location-by-reference

Regards,

Jeroen

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 25 Jul 2006 18:17:23 -0400

I have no problem with a ua placing a uri pointing to their presence service
in a header of a sip invite.

Context check:  We're discussing a sip invite (assumed pointed to emergency
service) that arrives at a proxy with zero location information.

I'm the only one that has a problem with any (visited) proxy/LIS creating a
uri that can be de-referenced by anyone without regard to user
security/privacy rules?

-Marc-

> Cc: [email-masked]; [email-masked]; From [email-masked] Wed Jul 26 08:04:24 2006
From: "Marc Linsner" <[email-masked]>
To: "'Peterson, Jon'" <[email-masked]>,
	"'Andrew Newton'" <[email-masked]>, "'Rosen, Brian'" <[email-masked]>
Subject: RE: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance
Date: Tue, 25 Jul 2006 18:17:23 -0400
Cc: [email-masked], [email-masked]

I have no problem with a ua placing a uri pointing to their presence service
in a header of a sip invite.

Context check:  We're discussing a sip invite (assumed pointed to emergency
service) that arrives at a proxy with zero location information.

I'm the only one that has a problem with any (visited) proxy/LIS creating a
uri that can be de-referenced by anyone without regard to user
security/privacy rules?

-Marc-

> > > specify an alternate presence URMarc Linsner

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP ProtocoI is a good idea.

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 26 Jul 2006 09:01:57 -0400

In-line... 

> So, you are arguing against proxy insertion of a 

No, if done properly....but reading the latest threads, I get the feeling
that www.whereintheworldisbrianrosen.com is an acceptable reference.

> 
> You don't have a problem with UA insertion of 
> location-by-reference in a Location header?

This assumes the user's presence service (contracted by the user) will do
the right things to protect the privacy/security of the location
information.

> 
> Agree that Location insertion by proxy could assume an INVITE 
> arriving at a proxy without any location.

I suspect there will be many cases where proxy will supplant whatever is
supplied by the user with proxy derived data.

> 
> I've always had a problem with proxy insertion of location 
> because I am worried that proxies will do this without regard 
> to user's wishes.  In an emergency case, however, there are 
> no such worries.  I don't see any difference between by-value 
> and by-reference.

Simplicity?  Call/dispatching failures from dereferencing problems?  Since
emergency calling is the use case driving this, why not opt for less
complexity with a better chance of actually working?

What seems odd is to dismiss L-by-V in the header simply because the L-by-R
has been in this draft for so long.  That is the way I read Keith's message.
Yes, if the stars and moon are all aligned, L-by-R will work, hence
obviating the need for an 'overlapping' L-by-V.  But, if it's a cloudy day,
the complexity associated with dereferencing WILL cause failures.

> 
> Proxies may disregard advice we supply, but Location URIs in 
> Location headers probably should not have any user 
> identification information in either the URI itself, or the 
> resulting PIDF.  If such information is desired, use the AoR.
> 
> De-referencing should always be subject to user rulesets, and 
> would not be any different than by-value except the obvious 
> issue that the owners of the proxy may not provide the user 
> with the facilities to control the ruleset, my original worry.

My worry also.  
  
> 
> Would you not agree that if a proxy is allowed to insert 
> location-by-value, the concerns would be the same?

As pointed out by others, by-value is a moment in time, by-reference makes
current information available for a yet-to-be-specified period.

-Marc-

> > service in a header of a sip invite.
> > 
> > I'm the only one that has a problem with any (visited) proxy/LIS 
> > creating a uri that can be de-referenced by anyone without 
> regard to 
> > user security/privacy rules?
> > 
> > -Marc-
> > 
> > 
> > 
> > 
> > 
> > > presence architecture. This certainly included use cases in which 
> > > one wanted to fetch or subscribe to location information. Those 
> > > operations require the existence of a reference, and that 
> reference 
> > > was commonly described as a URI, at the time. Lately, I think the 
> > > idea of having a URI pointing to location information has become 
> > > RFC4079 sketched out an architecture for using presence 
> to acquire 
> > > location information and it specifically mentions URIs as 
> a way to 
> > > refer to presence.
> > >
> presence, 
> > > and using URIs to indicate presence information, is exhaustively 
> > > specified for SIP. PIDF-LO was designed to reuse all of that work 
> > > and specifically not to require us to go out and reinvent 
> everything 
> > > in order to be able to refer to location information out in the 
> > > network.
> > >
> > > Basically, I support the direction re: bullet 6. I might further 
> > > suggest that the CID URI scheme be permitted in the 
> Location header, 
> > > in order to be able to refer to MIME bodies included in SIP 
> > > messages. I'm also neutral/favorable on using HTTP GET. 
> But I think 
> > > either of these URI schemes and their usage in the 
> Location header 
> > > could just as well be described in subsequent documents.
> > >
> > > Jon Peterson
> > > NeuStar, Inc,
> > >
> > > > > When the original PIDF-LO RFC came out, location-by-reference 
> > > > > was defined.
> > > > >
> > > > > proxy to insert location where there is no 
> association between 
> > > > > the
> > > > identity of
> > > > >>> There was a lot of list traffic on this, currently in the 
> > > > >>> state where Keith asked for a real use case for it.
> > > > >> suggestion of a Data URI.  Dismissing this 
> suggestion based on 
> > > > >> an
> > > > > already
> > > > > [email-masked] for questions on current sip 
> > > > > Use [email-masked] for new developments on the 
> application of 
> > > > > sip
> > > >
> > > >

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jul 2006 09:11:09 -0400

> that www.whereintheworldisbrianrosen.com is an acceptable reference.

Damn! I was hoping, but www.whereintheworldisbrianrosen.com doesn't seem 
to be working today. :-(

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Jul 2006 09:56:14 -0400

I think these are reasonable guidelines unless we're suddenly very  
selective about when privacy applies (or limit l-by-r to emergency  
calling in certain no-consent-required jurisdictions).

Specifying the precise 'limited amount of time' is probably something  
that local regulations need to address.

On Jul 25, 2006, at 8:17 PM, Andrew Newton wrote:

>> - user must be able to verify correctness of the issued  
>> information (ie user can access the URL himself)

I think that's desirable unless there's a clear indication by the  
caller to do otherwise, by some consent mechanism. However, by the  
time you implement the consent mechanism, you've probably already  
implemented the better UAC-based mechanism, so it seems hard to argue  
for that complexity. The only technical argument I've heard for proxy  
insertion is legacy equipment, where requiring adding consent flags  
is clearly a non-starter.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Jul 2006 09:59:42 -0400

> it, but I don't objectively think it's much different.

It is slightly different: For the presence provider, I can fairly  
easily verify whether the presence provider does what I tell him to  
do (unless the presence provider is clearly violating my privacy  
rules, which is probably subject to legal breach-of-contract recourse  
in most jurisdictions). This is much harder to do with proxy insertion.

> sufficiently, and we have RFCs that permit it.  Adding restrictions  

The only one that permits is the presence subscription model, which  
gives the target/rule maker a lot of control of who can do what with  
my location data. I can, on a person-by-person basis, restrict access  
to that data. If my proxy inserts some location object or reference  
to it that it made up, I don't even control the privacy rules in the  
object returned.

> the UAC can see it.  What do others think of that?

This is probably a good idea, but imposes additional restrictions on  
the longevity of the reference. How long should I be able to "see"  
it? We don't want LIS to keep the location data around any longer  
than is needed, but there are no expectations set of what's  
reasonable. By-value doesn't suffer from these problems.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Jul 2006 10:10:32 -0400

Henning Schulzrinne wrote:
>> Just thinking out loud here, but maybe the rule should be that proxies 
>> never append a Location header except for emergencies.
> 
> I think that's desirable unless there's a clear indication by the caller 
> to do otherwise, by some consent mechanism. However, by the time you 
> implement the consent mechanism, you've probably already implemented the 
> better UAC-based mechanism, so it seems hard to argue for that 
> complexity. The only technical argument I've heard for proxy insertion 
> is legacy equipment, where requiring adding consent flags is clearly a 
> non-starter.

I believe there are two technical arguments: one is legacy equipment 
(the issue that I'll be facing for quite some time), and environments 
where the location is generated by the network.  For the latter, 
insertion of the Location header only in emergency situations still puts 
the user in control for non-emergency situations.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Jul 2006 11:04:20 -0400

> I believe there are two technical arguments: one is legacy  
> equipment (the issue that I'll be facing for quite some time), and  
> environments where the location is generated by the network.  For  
> the latter, insertion of the Location header only in emergency  
> situations still puts the user in control for non-emergency  
> situations.
>
>

For the latter, the combination of the in-progress L7 protocols, DHCP  
and LLDP should presumably allow the UAC to obtain location and  
insert it by value. Is there a use case not covered by that?

---

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Jul 2006 11:14:10 -0400

Henning Schulzrinne wrote:
>> insertion of the Location header only in emergency situations still 
>> puts the user in control for non-emergency situations.
>>
>>
> 
> and LLDP should presumably allow the UAC to obtain location and insert 
> it by value. Is there a use case not covered by that?

As I said, where location comes from the network.  In this scenario, 
there are two possibilities, both up to the user: 1) the UAC subscribes 
to the location from the network and puts it by value in the call 
flow... meaning all location updates go through the UAC, or 2) the UAC 
hands out a reference so updates can be independent of the UAC or 
updates based on subscription come from the UAC but are independent of 
the call.

-andy

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 26 Jul 2006 17:34:51 +0200

>> environments where the location is generated by the network.  For  the 
>> latter, insertion of the Location header only in emergency  situations 
>> still puts the user in control for non-emergency  situations.
>>
>>
>
> For the latter, the combination of the in-progress L7 protocols, DHCP  and 
> LLDP should presumably allow the UAC to obtain location and  insert it by 
> value. Is there a use case not covered by that?

With the current proposals (location by value in body): the use case for a 
location based routing service, where my location does not get passed to the 
selected targets

It is possible to do a redirect-based callflow, but that has several 
drawbacks:
- more complex, requires extensions beyond basic RFC3261
- inefficient signalling
- adds delay
- no parallel forking possible (though some would call this a benefit)

The data: URI in combination with a 'Proxy-Require: remove-location' flag 
would solve all these nicely

Regards,

Jeroen

PS I suppose one could put PIDF-LO in a SAML artifact. At the very least, 
http://www.ietf.org/internet-drafts/draft-ietf-sip-saml-00.txt section 7.1 
and http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf 
may provide some ideas for a HTTP-based location-by-reference profile

---

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Jul 2006 12:00:29 -0400

Jeroen van Bemmel wrote:
>>> situations still puts the user in control for non-emergency  situations.
>>>
>>>
>>
> With the current proposals (location by value in body): the use case for 
> a location based routing service, where my location does not get passed 
> to the selected targets
> 
> The data: URI in combination with a 'Proxy-Require: remove-location' 
> flag would solve all these nicely

So now we are talking about the data: URI being used in non-emergency 
cases?  Certainly if a UAC can put a data: URI in an INVITE, it can also 
put a PIDF-LO in a MIME part.

With regard to the data: URI, how does that work with a CID URI in the 
ruleset-reference?  I would guess that in the emergency case, there 
wouldn't be one.  But in the non-emergency case....

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Jul 2006 12:47:34 -0400

> wouldn't be one.  But in the non-emergency case....

I'm afraid I don't understand the issue. The ruleset reference wouldn't 
seem to be affected by where and how it is carried. Can you explain?

---

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Jul 2006 13:45:43 -0400

> seem to be affected by where and how it is carried. Can you explain?

So are saying there will be a likely scenario where a ruleset-reference 
in a PIDF-LO encoded into a data: URI and inserted by a proxy will 
reference a MIME part that already exists?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Jul 2006 15:55:43 -0400

> reference a MIME part that already exists?

We may be talking past each other. Currently, RFC 4119 has

  <xs:complexType name="locPolicyType">
    <xs:sequence>
      <xs:element name="retransmission-allowed" type="xs:boolean"
         minOccurs="0" maxOccurs="1"/>
      <xs:element name="retention-expiry" type="xs:dateTime"
         minOccurs="0" maxOccurs="1"/>
      <xs:element name="external-ruleset" type="xs:anyURI"
         minOccurs="0" maxOccurs="1"/>
      <xs:element name="note-well" type="tns:notewell"
         minOccurs="0" maxOccurs="1"/>
      <xs:any namespace="##other" processContents="lax" minOccurs="0"
         maxOccurs="unbounded"/>
    </xs:sequence>
   </xs:complexType>

I assume you're talking about the external-ruleset element. Regardless 
of how the rest of the GEOPRIV object is carried, this can point 
anywhere, including some static web object, a cid, or even be another 
data URL if you want to carry the policy along with the actual location 
information.

Clearly, a cid would be rather implausible if the URL was inserted by 
the proxy.

If this is location by reference, the options for the URL would be the 
same, except for cid.

If this is a location object carried in the body, it could be any of the 
  things I mentioned above. The same is true for the Location-by-value 
option.

As you can probably tell, I'm a bit confused as to why this is an issue, 
so I'm probably belaboring what's obvious to you.

---

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Jul 2006 16:49:00 -0400

> data URL if you want to carry the policy along with the actual location 

Hmmm... we seem to have caught a bug in 4119.  Because the descriptive 
text calls that element 'ruleset-reference' and not 'external-ruleset'. 
  Anyway, from the text (page 8):

       This URI SHOULD use the HTTPS URI scheme; and if it does, the
       server that holds these rules MUST authenticate any attempt to
       access these rules.  Usage rules themselves may divulge private
       information about a Target or Rule Maker.  The URI MAY,
       alternatively, use the CID URI scheme [7], in which case it MUST
       denote a MIME body carried with the Location Object by the using
       protocol.

In other words, it would appear that the list of URIs allowed is HTTPS 
or CID (though this doc SHOULD be more explicit).  data: is not mentioned.

This means that a PIDF-LO with a CID reference cannot be converted to a 
data: URI.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Jul 2006 17:50:38 -0400

> This means that a PIDF-LO with a CID reference cannot be converted to a 

At best, SHOULD NOT. This issue was never discussed during the 4119 
discussion, as far as I can tell, and there doesn't seem to be technical 
reason why it couldn't be.

In any event, for the case at hand, namely proxy insertion, the problem 
is exactly the same: both both (only) use HTTPS. I'm unclear what 
ruleset we can usefully specify today. The common policy set is not 
particularly useful for routing, for example, and not really meant for 
recipients of location information in any event. Thus, at least today, 
this is, at best, some free-text legalese.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 26 Jul 2006 18:33:10 -0500

>Damn! I was hoping, but www.whereintheworldisbrianrosen.com doesn't seem 

I think he's .biz now...   ;-)

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 26 Jul 2006 13:14:08 -0400

For location-based routing case, the likelihood of significant updates 
in the roughly one second that a call might take from caller to callee 
seems unlikely. UAS subscription and polling is clearly more valuable, 
so maybe we need to distinguish these cases. (As discussed earlier, 
mid-routing updates may lead to bad outcomes since the call might have 
been sent to a place A that doesn't know what to do with location update 
n+1 since that new location is really handled by place B.)

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 26 Jul 2006 20:28:00 -0500

In the case you mention below the reality is that if the target has
moved during the course of routing, the target will either be at place B
by the time dispatch occurs, or at point C which may be further away
still. 
At least in the case of a reference you have the possibility of getting
the current location, which is not possible through any of the
"by-value" means described thus far unless the caller is stationary!

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Thursday, 27 July 2006 3:14 AM
To: Andrew Newton
Cc: [email-masked]; IETF SIP List
Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to
location-conveyance

>> and LLDP should presumably allow the UAC to obtain location and
insert

---

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Jul 2006 21:42:14 -0400

On Jul 26, 2006, at 5:50 PM, Henning Schulzrinne wrote:

>> In other words, it would appear that the list of URIs allowed is  
>> HTTPS or CID (though this doc SHOULD be more explicit).  data: is  
>> not mentioned.
>> This means that a PIDF-LO with a CID reference cannot be converted  
>> to a data: URI.
>
> discussion, as far as I can tell, and there doesn't seem to be  
> technical reason why it couldn't be.

It was discussed at length at our interim meeting in DC, and nobody  
ever mentioned anything but HTTPS and CID.

> In any event, for the case at hand, namely proxy insertion, the  
> problem is exactly the same: both both (only) use HTTPS. I'm  
> unclear what ruleset we can usefully specify today. The common  
> policy set is not particularly useful for routing, for example, and  
> not really meant for recipients of location information in any  
> event. Thus, at least today, this is, at best, some free-text  
> legalese.

This is yet another rule, adding more complexity.  You can pass by  
value either via MIME or data: URI.  If you pass by value using the  
data: URI, you have to restrict ruleset references.

-andy

---

From: Andrew Newton <[email-masked]>
Date: Wed, 26 Jul 2006 21:47:04 -0400

> "by-value" means described thus far unless the caller is stationary!

What about a SIP UPDATE?  Section 5.3 of the draft.

-andy

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 26 Jul 2006 20:48:05 -0500

To what do you send the SIP update and for what do you request the
update?

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, 27 July 2006 11:47 AM
To: Winterbottom, James
Cc: Henning Schulzrinne; [email-masked]; IETF SIP List
Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to
location-conveyance

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 26 Jul 2006 22:39:32 -0500

>by the time dispatch occurs, or at point C which may be further away

Henning mentioned above that this is a routing timeframe (of maybe 1 
second), not a dispatch timeframe - and that it seems unlikely that routing 
would be different during that one second.  Regardless, the call get 
completed where the request was sent.

>"by-value" means described thus far unless the caller is stationary!

Henning and Brian have discussed this already, and that is where SUB/NOT 
are useful for the ability to subscribe to that calling endpoint to find 
out where they are at any time during the call.  I mentioned that if the UA 
detects it has moved, it should send a SIP agreed upon UPDATE request (with 
a new l-by-v) to the PSAP informing it that the caller has moved.  This is 
something that belongs in the ECRIT phonebcp, and perhaps a more general 
non-emergency sipping doc.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 26 Jul 2006 22:43:59 -0500

At 09:42 PM 7/26/2006 -0400, Andrew Newton wrote:
>This is yet another rule,

that is if data URI is mentioned...

>adding more complexity.  You can pass by

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 26 Jul 2006 22:57:09 -0500

>To what do you send the SIP update and for what do you request the

to the latter first: UPDATE is not requested, it is a request message just 
like INVITE.

If the PSAP wants to subscribe to the caller, that's a separate transaction 
in SIP.

to the former, are you asking what's the destination address the UPDATE 
goes to, or what triggers the UPDATE message?  Your phrasing could be to 
either the way I read it. I'll answer both below as best I can:

To a destination address, if before the UAC receives a 200 OK with a 
Contact header (indicating the PSAP URI), the UPDATE needs to be built just 
like the original INVITE (with the new location) and sent to the 
urn:service:sos and get routed to the PSAP.  If this results in a new PSAP 
due to movement, the INVITE times out and the new INVITE is to the 
urn:service:sos with a new location and the call goes through.  We can't 
build this to the corner case of someone moving that fast, as much as that 
won't make some happy.

If the 200 OK has been received by the UAC, the UPDATE will go at the PSAP 
URI in the Contact header of that 200 OK, and therefore go straight at the 
PSAP, the fastest way there (barring any route headers that are forced into 
the request).

Due to a trigger, this is UAC device specific as it is the device that 
senses a sufficient change in its location to send a new location.  This 
will in all likelihood be after the 200 OK has been received, even after 
the call has been established, and should follow what is in the paragraph 
above this one to the PSAP.

It has been suggested that a reINVITE can be sent with the new location 
*after* the call is eestablished, and that's fine, but not what the SIP WG 
agreed to several IETFs ago, but it would work in either case.

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 26 Jul 2006 22:58:18 -0500

That's right - and those mechanisms by which the URI remains anonymous
and temporary and access rights to the anonymous form of the location
are controlled are quite extensive considerations.

I understand the conveyance draft just says how to get the location
object and/or reference from one signaling peer to another. It's asking
to much of this specification to anticipate all the possible mechanisms
for applying security to privacy in the by-reference form and thereby
restricting the form of the reference to a particular protocol. This
should be out of scope for the conveyance protocol.

Cheers,
Martin

> Sent: Wednesday, 26 July 2006 4:46 PM
> >I don't really understand why you think location by reference is so
much
> of
> > a concern.
> 
> Because location by reference involves storage of personal information
on
> provided the endpoint gives the user control over whether or not
location
> For location-by-reference this is much more fuzzy. You probably don't
need

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Jul 2006 16:33:18 +0200

Hi Andy,

in the use case where the proxy either adds a location-by-value or 
location-by-reference where would the proxy get the privacy policies 
from in the first place?

If it has the rule and wants to convey location-by-value then why 
wouldn't it just include the rules instead of putting a reference to the 
ruleset in there that has to be retrieved first.

In the Geopriv-L7 design team we were puzzled about the case where a LIS 
adds privacy rules to the PIDF-LO before signing it. In this case the 
LIS is the SIP proxy and the challenges remain the same.

Ciao
Hannes

Andrew Newton wrote:
>> data URL if you want to carry the policy along with the actual 
>> location information.
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Jul 2006 16:33:52 +0200

Hi Marc,

I agree with you.

I also think we should split the work into two parts as Henning 
suggested: One document covers the end host adds location-by-value (and 
potentially location-by-referenc) and another one that deals with the 
proxy doing something. The proxy case is far less understood as we know.

Ciao
Hannes

Marc Linsner wrote:
>>>>You have a URI.  You can exchange the URI for location.  
>>
>>There is a 
>>
>>>>location-by-reference aka presence URI which is not just 
>>
>>the AoR.   
>>
>>>>That
>>>>is one reason why I want to define the Location URI as 
>>
>>being able to 
>>
>>>>location-by-reference (which I think is a good idea in 
>>
>>general, but 
>>
>>>>looking for a use case which requires proxy insertion by 
>>
>>value, but 
>>
>>>>haven't heard one yet.
>>>>
>>>>You can make an argument that you can take the From:, 
>>
>>assume it's an 
>>
>>>>>Subject: RE: [Geopriv] Consensus on changes to 
>>
>>location-conveyance
>>
>>>>>In-line.....
>>>>>
>>>>>
>>comments.  My 
>>>>>>summary of consensus on these issues is:
>>>>>>
>>>>>I believe that Henning/Hannes also recognized this 
>>
>>issue, hence the 
>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Jul 2006 16:34:07 +0200

Hi Brian,

> I don't really understand why you think location by reference is so much of

It is interesting that you say that. In the Geopriv L7 design team you
are the only person that wants to see an applicability statement being
written.

Having a SIP proxy adding something (either location-by-value or
location-by-reference) is not different to the stuff we discuss in the
design team. There, you see a lot of privacy, security, etc. problems.
Here you don't. How come?

If you go through my mail with the large number of scenarios then you
find a number of open issues that need to be answered. Alternatively,
you can also go through draft-tschofenig-geopriv-l7-lcp-ps-00.txt

  If you look at the discussion in context, PIDF-LO defines
> cache" semantics (albeit caching headers is not very interesting in SIP).

You cannot compare presence witht he location-by-reference solution
since the deployment case is different.

> information, including location and identifying information, so I think that

Not true in this case.

Here we have a SIP proxy in the access network doing all the work. You
can compare it with a SIP-based LIS from the Geopriv-L7 work. This node
has no clue about your privacy preferrences and does not know your
identity. This is what we discussed in the past and several proposals
where made, namely:

* end host provides privacy preferences (see HELD)
* end host does not provide privacy preferences since there is no
PIDF-LO (see RELO).

> it, but I don't objectively think it's much different.

In this case you don't really know the provider and it might not be your
  provider.

> appropriate in some cases, but would not in others.

The reference might not reveal the identity but what about the identity
in the PIDF-LO. If you argue that there does not need to be one (or it
is a faked one) then I am puzzled why it has been a source of major
confusion in the Geopriv-L7 design team work (and in previous
discussions about the same subject in Geopriv).

> different here; laws govern behavior, and in most cases compel location
This is indeed an interesting case where the end host indicates
something whether it wants the proxy to add location (by reference).

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Jul 2006 16:33:45 +0200

Hi Andy,
Hi Jeroen,

>> - URL must be valid for a limited amount of time
Ok.

Should it be end point controlled or should the end point be informed 
about the lifetime?

>> - URL must be cryptographically hard to guess

must contain a random,non-guessable component.

>> - URL must not contain any information that identifies the user /  

more difficult if you consider that a PIDF-LO contains identity 
information.

>> - for whatever transport protocol is used: response must be marked  as 
>> 'no cache'
Sounds reasonble.

>> - user must be able to remove the information at the URL, ie  explicit 

Difficult with the SIP based approach we are discussing.
Simpler with the Geopriv-L7 approach being discussed.

>> (ie user can access the URL himself)

Difficult with the discussed SIP-based mechanism since the user does not 
ever see the URI.

>> history of accesses (for a reasonable period)

This has been subject for a long discussion with no conclusion.

>> - there must be explicit consent before a proxy would insert user  
That's not what some of the use cases indicate.

Nice requirements; maybe something for the Geopriv L7 design team.

> duration or accuracy or confidence of location-by-value, you'd never  

Well, some of these requirements are actually protocol capabilities. 
With some other stuff I agree with you, Andy.

>> include some flag in the INVITE saying "proxy: please append  

This is in fact interesting. I haven't seen these requirements so far.

> never append a Location header except for emergencies.

The problem is that the IETF cannot enforce this. Once you have a 
solution for adding location-by-reference by a proxy it can do it.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Jul 2006 16:33:38 +0200

Hi all,

I would really appreciate if you guys make a difference between an end 
host adding a location-by-reference and a proxy adding a 
location-by-reference to a SIP message. If the end host adds something 
you can further differentiate whether it is added to the header or the body.

This differentiation is really important and that was the reason why I 
wrote a long mail (and it took some time) to elaborate on the different 
scenarios and the challenges.

Jeroen van Bemmel wrote:
>> much of
> on a server.

In general it does not.

  That suddenly makes all sorts of regulations apply, the
> points I mentioned address only a small part of that. Having an 
> anonymous URL for example often makes a difference, because then the 
> information is no longer directly linked to a particular person.
> 
> When an endpoint inserts location by value, you can reasonably argue 
> that opt-in consent requirements (which many countries have) are 
> fulfilled, provided the endpoint gives the user control over whether or 
> not location is inserted. Same holds for the endpoint inserting a flag 
> asking a proxy to fill in the location (by value).

One of the use cases I have been told regarding the 
location-by-reference addition by the SIP proxy is that providers want 
to deal with legacy devices that do not learn location information from 
the network.

> need a lecture on privacy regulations, but e.g. 
> (http://www.ietf.org/internet-drafts/draft-jbemmel-sip-truu-02.txt), 
> which provides anonymous, temporary URIs that can be explicitly 
> invalidated. You may want to consider something similar for 
> location-by-reference

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 27 Jul 2006 13:54:33 -0400

> are the only person that wants to see an applicability statement being
We haven't gotten to that yet, but it's a problem of proxy assertion, not
location-by-reference.  Basically, coming up with an identifier to determine
what location to assert (by value or by reference) is much worse than the L7
case, because the SIP signaling plane definitely is subject to being carried
over VPNs and other IP address obscuring things.  You can't possibly use the
IP address as the identifier.  You have to use something else.  What else?
I have no idea.  I can imagine some kinds of wireless systems being able to
know that the device is on their own network, and have some id that works on
that network.

In case I have not been clear enough, I personally DO NOT LIKE proxy
assertion of location.  I do not really like location by reference, although
a SIP presence URI is location-by-reference no matter how you slice and dice
it.

However, I consider both to be requirements in location-conveyance, and
think limiting proxy insertion to be by reference only to be the least
objectionable answer.

> Here you don't. How come?
I see plenty of problems, but in a protocol sense I don't think anything is
different other than this identifier problem.

> since the deployment case is different.
I believe this to be false on its face.  If I give you a sip URI and tell
you a presence server will respond to it including location, then you can
exchange the URI for location, and that is location-by-reference.

You cannot put that cat back in the bag.  A presence URI that reports
location in the PIDF results in location-by-reference.

The idea that you could have a presence URI where the only information
returned in the PIDF that was interesting was location does not need an RFC.
It's obvious, it's allowed, and the anonymized user stuff was created for
this purpose.

Presence is location by reference (it can be identification-by-reference, it
can be happiness-by-reference).  You have a URI, you exchange it for a PIDF.
You are done, stop arguing.

> * end host does not provide privacy preferences since there is no

I don't agree.  A proxy can assert a presence URI in a number of places.
I'm pretty sure, for example, that many carriers intend the P-A-I to be a
presence URI, or (if a tel uri) convertible trivially to a presence URI.

I don't like it, but whether a proxy asserts your presence URI or your
endpoint does, there is no functional difference.  I worry about the issue
of whether the proxy's URI resolves to a PIDF that has the policies you want
asserted.  But that is not a protocol issue.  That is a contract and local
law issue.  The URI and the PIDF have the same capacity to express the users
wishes with respect to identity, location and all the other parts of the
PIDF.

Your carrier's outgoing proxy is perfectly capable of asserting a presence
URI that resolves to a PIDF that represents your policies on your location.

I prefer the endpoint to be the one doing this, because I think there is a
better chance it will get it done right, but that's a pretty soft thing,
having nothing to do with protocols.  The proxy is in the same domain as the
user, and is being trusted by the user to correctly handle its calls.
Putting his location (via presence) is one of the things it is reasonable to
trust the proxy to do.

You could look at this a different way.  If the network determines the user
location, that information belongs to the network.  It would be up to the
network to tell the user, if it wants to.  The user doesn't own the data,
even if it represents his location.  If I take a picture of you, I own the
picture.  Some laws may limit what I can do with it, but it's my data.
Proxy assertion of location is the network telling someone the data it owns.
It's not yours unless the network decides to give it to you, or gives you
control over it.  Again, laws may limit what it can do with the data.
> In this case you don't really know the provider and it might not be your
Actually, it has to be (or it wouldn't know your location).  You have the
case of the visited network not being your carrier, but effectively, if you
are roaming on their network, they are your carrier of choice.

> discussions about the same subject in Geopriv).
See above.  It's easy to generate a completely random identity.  The
difficulty in the L7 case is how the endpoint identifies itself to the LIS
in order to receive the right location or reference.  Proxy insertion has
the same problem of how it knows which location to assert.  You can't do
proxy insertion of location unless you know FOR SURE where the device is.
We do need text on that, as above.