Subject: [Geopriv] Location in SIP and "retransmission-allowed"

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 1 May 2007 13:08:03 -0400

In finishing off sip-location-conveyance we have been discussing the
"retransmission-allowed" parameter.

RFC4119 says:
'retransmission-allowed': When the value of this element is 'no', the
      Recipient of this Location Object is not permitted to share the
      enclosed Location Information, or the object as a whole, with
      other parties...

In SIP, we have two issues with this that need to be resolved.

One is that proxy servers are in the path from UAC to UAS.  We have been
interpreting "retransmission-allowed=no" as a proxy may forward the
message to its next hop with location, but it may not send location
anywhere else.  The UAS receiving location could not send it to any
other entity.

We have a similar problem with location based routing.  As you know,
ecrit has developed a location based routing mechanism where you send a
LoST server a location and a service indicator, and you get back a URI.
An example of using this mechanism would be a call to Pizza Hut.  There
could be a pizza-hut service, the UAC may send its location, a proxy
server may consult LoST to route the call to the appropriate restaurant,
and the restaurant may receive the location to use to deliver the pizza.
The UAC would like to set retransmission-allowed=no, so that Pizza Hut
could not send location to anyone else.  However, having set it to "no",
would that prevent the proxy from sending it to the LoST server?  Please
note that when the location is sent to LoST, no identity information is
included; just the Location Information.

In the current (-07) version of -conveyance, we have assumed that the
proxies are permitted to send location to next hop even if
retransmission-allowed=no.  In the current version of -conveyance, we
have proposed a new tag for PIDF "routing-query-allowed" to specifically
cover the proxy sending location.  In a review of the conveyance
document, the requirement for the latter was questioned.

So, I would like to get consensus of geopriv on the following questions:
1. Does the current definition of retransmission-allowed=no permit a sip
proxy server from sending location it receives from the UA to its next
hop?

2. Does the -conveyance document just say that, or does it need to
normatively update 4119?

3. Does the current definition of retransmission-allowed=no permit a sip
proxy server to send Location Information to a LoST server (without
identity)?

4. If the answer to 3 is yes, does -conveyance document just say that,
or does it need to normatively update 4119

5. If the answer to 4 is no, is the suggested "routing-query-allowed" as
a normative update to 4119 an appropriate way to permit the LoST query?

Brian

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

---

From: Ted Hardie <[email-masked]>
Date: Tue, 1 May 2007 10:35:17 -0700

>proxy server from sending location it receives from the UA to its next

I think you've got the question half in each camp (permit from?),
so I am not sure how to answer with a "yes" or "no".  
I do not believe that retransmission-allowed=no prevents SIP, as a using
protocol, from sending location from a proxy to the next hop proxy. 
The proxy in the forwarding case is not a recipient;
it is a network element which does not consume the location while
forwarding.   An SMTP server forwarding a PIDF-LO mime body is a
parallel, if you are considering how other using protocols might work.
The SMTP servers forwarding the mime body along the path do not
"receive" it in the GEOPRIV sense; they just send it along, as the routers
do at a layer below.

>2. Does the -conveyance document just say that, or does it need to

I think it can say that, and I think it should not normatively update 4119.

>proxy server to send Location Information to a LoST server (without

No, I don't think so.  Whether you consider the proxy or the Lost server
to be a recipient in that case, I believe one of the two is.  I think
the routing-query-allowed solution is better than allowing retransmission=no
to be weakened for this in the Pizza case.  If retransmission=no is
allowed to include this case, I see no way for an end user which did not
want to to allow routing queries to be performed to express that; so
the choices appear to be to create an explicit permission or add a
"no, really, even including routing queries" entry.  The explicit permission
seems cleaner and clearer.

>or does it need to normatively update 4119

It just says that.

>a normative update to 4119 an appropriate way to permit the LoST query?

I believe so.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 1 May 2007 13:55:51 -0400

I think what got lost in the long message is the crucial distinction  
that the LoST request contains no personally identifiable information  
about the querier (except maybe the IP address of the proxy server),  
unlike a normal PIDF-LO. This is logically no different than making,  
say, a query to Google that shows some street address. So far, at  
least, nobody has asked Google to cease and desist to use Google Maps  
since it is not GEOPRIV compliant.

To further show that this leads to something absurd, let's go through  
the various permutations:

(1) Proxy server has a local database that maps locations to URLs  
(not LoST, just some script or SQL table). Presumably, no privacy  
concerns.

(2) The database is now in a separate server, operated by the same  
organization. Is this retransmission?

(3) The proxy operates the LoST resolver (on the same box as the  
proxy), but not the FG and other components. Is that retransmission?  
Only if the answer is not already cached?

(4) It's an emergency call; no retransmission allowed. No LoST query?

We're getting into heavy-duty protocol lawyering here, out of touch  
with reality as perceived by the rest of the world.

Henning

---

From: Ted Hardie <[email-masked]>
Date: Tue, 1 May 2007 12:28:59 -0700

At 1:55 PM -0400 5/1/07, Henning Schulzrinne wrote:
>I think what got lost in the long message is the crucial distinction that the LoST request contains no personally identifiable information about the querier (except maybe the IP address of the proxy server), unlike a normal PIDF-LO.

It wasn't lost on me.  The proxy gets a PIDF-LO and it acts on it; that acting on
it includes removing some of the identifying information before sending it
as a LoST query, but that does not change the fact that it is acting as a recipient
by routing based on the location.  I believe it should not do so unless it
is authorized to do so.  That fits with the overall privacy aims of this
group, which are clear in its charter.    Sorry if you think that is lawyering,
but I think this isn't the place to object to it.  Feel free to argue for
a recharter with Robert; it's always a nice way to be greeted as a new chair.

There are two ways forward:  agree that we add a state for routing queries,
which handles this fairly cleanly, or add a state that says "Absolutely no" that
forbids even routing queries, since we have re-written "no" to mean
"no, except for routing queries".  There MUST be some way for a user
agent to say "no" to redistribution and mean it.  GEOPRIV is nonsense
with that.

>(4) It's an emergency call; no retransmission allowed. No LoST query?

For emergency calls, we can talk in ECRIT's PhoneBCP about when violating the
geopriv privacy rules is justified.  The example given was Pizza delivery,
though, not a 911 call.

I am also frankly tired of emergency calling being used a spectre for
weakening the privacy infrastructure.   The chartered baseline for the
group is private information (see the default "no" to redistribution in
4119) and control by the user.  It can be relaxed, but that is the baseline.
If you'd like to change that, feel free to propose an update to 4119
that changes the defaults.

			regards,
				Ted

>We're getting into heavy-duty protocol lawyering here, out of touch with reality as perceived by the rest of the world.
>
>Henning
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 1 May 2007 15:38:55 -0400

I fail to see the privacy aims that are met by this restriction. You  
did not in any way my technical argument, just argued by appeal to  
authority. It's the usual "we can't answer you technically, but just  
imagine the wasted time you go through trying to argue it, so you'll  
see why it's best if you don't even try".

My prediction: We'll end up with some meaningless token that  
everybody always inserts or ignores, depending on the circumstances,  
since nobody outside a small group of people will understand as to  
why a LoST query has GEOPRIV privacy implications when Google Maps  
does not.

On May 1, 2007, at 3:28 PM, Ted Hardie wrote:

>> I think what got lost in the long message is the crucial  
>> distinction that the LoST request contains no personally  
>> identifiable information about the querier (except maybe the IP  
>> address of the proxy server), unlike a normal PIDF-LO.
>
>> We're getting into heavy-duty protocol lawyering here, out of  
>> touch with reality as perceived by the rest of the world.
>>
>> Henning
>>
>>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 1 May 2007 12:54:29 -0700

At 3:38 PM -0400 5/1/07, Henning Schulzrinne wrote:
>I fail to see the privacy aims that are met by this restriction.

It retains a mechanism that allows the user to say "don't redistribute
to *anyone* for *any purpose*".  That's important.  Making "no"
mean something other than "no" eliminates it without replacing
it.  I object to that.

>You did not in any way my technical argument, just argued by appeal to authority. It's the usual "we can't answer you technically, but just imagine the wasted time you go through trying to argue it, so you'll see why it's best if you don't even try".

Actually, you argued first by reference to an unrelated service (Google Maps,
a proprietary service which has nothing to do with the chartered work of
the group or of SIP), then in 1-3 by exploring bits of the problem space that
I thought obviously the same.  If you act on the location or based on the location,
you are acting as a recipient, and the rules apply to you.  That includes redistribution.
If you are just forwarding along to the recipient they don't.  That seems pretty
simple to me. I did and continue to challenge the correctness of using your
4 as a baseline.

>My prediction: We'll end up with some meaningless token that everybody always inserts or ignores, depending on the circumstances, since nobody outside a small group of people will understand as to why a LoST query has GEOPRIV privacy implications when Google Maps does not.

Ah, the "we can't win, so let's not try" argument, supplemented with a reference
to the same unrelated service .

We're talking about whether a specific token can be used in SIP context, not
whether that context will get compared to something else.  If SIP developers
and deployers can get "location-based routing has to be approved by the user
unless trumped by emergency", then we're squarely in the territory of
SIP as using protocol of GEOPRIV.  Given the other things they've folded their
brains around, I'm pretty sure they can.
			regards,
				Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 1 May 2007 16:16:25 -0400

I think our fundamental disconnect is that I believe that location  
information, by itself, has no privacy implications. After all,  
there's nothing private about "1600 Pennsylvania Avenue" or "40 N, 20  
E". The privacy implications occur when location information is  
combined with a (personal) identity, as in "Dick Cheney is at 1600  
Pennsylvania Avenue" (as opposed to an undisclosed location). The  
privacy risk discussions have been about revealing a person's  
location, not a location by itself. (Indeed, the fact that Google  
Maps is proprietary is irrelevant. Even an OGC-certified map  
retrieval protocol would have the same considerations. I'm pretty  
sure OGC does not use privacy indicators in their mapping protocols.)

I'm trying not to argue by appeal to charter; I'm trying to argue by  
privacy interests we both try to protect. By the way, the charter  
talks about "geographic location information about certain resources  
or entities.", as opposed to location by itself.

Henning

On May 1, 2007, at 3:54 PM, Ted Hardie wrote:

>> You did not in any way my technical argument, just argued by  
>> appeal to authority. It's the usual "we can't answer you  
>> technically, but just imagine the wasted time you go through  
>> trying to argue it, so you'll see why it's best if you don't even  
>> try".
>
>> everybody always inserts or ignores, depending on the  
>> circumstances, since nobody outside a small group of people will  
>> understand as to why a LoST query has GEOPRIV privacy implications  
>> when Google Maps does not.
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 01 May 2007 18:12:17 -0400

Perhaps location information, by itself, devoid of all context, has no 
privacy implications.  But in practice, there's always context.

If I see a LoST query go by containing a location, I can infer that 
there's something at that location, and probably something capable of 
calling for emergency services.  If I want to jam emergency calls in an 
area, LoST queries give me enough information to know where to put my 
jammers.  Or if I'm watching a stream of periodic LoST queries, and I 
see one go outside the usual pattern, then I know the location of 
someone making an emergency call.

I have to agree with Ted: No means no, and when there are exceptions, 
they should be made explicit.

--Richard

Henning Schulzrinne wrote:
> information, by itself, has no privacy implications. After all, there's 
> nothing private about "1600 Pennsylvania Avenue" or "40 N, 20 E". The 
> privacy implications occur when location information is combined with a 
> (personal) identity, as in "Dick Cheney is at 1600 Pennsylvania Avenue" 
> (as opposed to an undisclosed location). The privacy risk discussions 
> have been about revealing a person's location, not a location by itself. 
> (Indeed, the fact that Google Maps is proprietary is irrelevant. Even an 
> OGC-certified map retrieval protocol would have the same considerations. 
> I'm pretty sure OGC does not use privacy indicators in their mapping 
> protocols.)
> 
> privacy interests we both try to protect. By the way, the charter talks 
> about "geographic location information about certain resources or 
> entities.", as opposed to location by itself.
> 
> Henning
> 
>>> You did not in any way my technical argument, just argued by appeal 
>>> to authority. It's the usual "we can't answer you technically, but 
>>> just imagine the wasted time you go through trying to argue it, so 
>>> you'll see why it's best if you don't even try".
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 1 May 2007 19:42:13 -0400

Your example seems to assume that the flag adds privacy by being set.  
Unfortunately, that's not the case.

In your example, the privacy-conscious (emergency) caller will say  
'no'. Let's assume that we have the standard two-stage routing (local  
+ emergency services network). The call reaches the ESN and the flag  
indicates "sorry, no LoST". In this case, the only alternative is to  
fail the call. It's not like the LoST lookup is some optional frill  
for this call. Thus, the call will fail and, if you're lucky, the UA  
will retry, presumably after displaying a warning message to the user  
to the effect that no call will go through until they click off on  
the privacy release. The outcomes are thus exactly the same with or  
without the flag: a successful call, but no additional privacy, or no  
call.

The hypothetical disclosure of information you mention is in no way  
prevented by having this flag set to 'no', even if all entities in  
the call path observe the flag. The correct way to protect privacy is  
to privacy-protect the signaling channel or, if you're truly  
paranoid, do bogus LoST queries to obfuscate real ones.

The same is true for the pizza call, so this does not depend on the  
specific example.

Henning

On May 1, 2007, at 6:12 PM, Richard Barnes wrote:

> Perhaps location information, by itself, devoid of all context, has  
> no privacy implications.  But in practice, there's always context.
>
> there's something at that location, and probably something capable  
> of calling for emergency services.  If I want to jam emergency  
> calls in an area, LoST queries give me enough information to know  
> where to put my jammers.  Or if I'm watching a stream of periodic  
> LoST queries, and I see one go outside the usual pattern, then I  
> know the location of someone making an emergency call.
>
> I have to agree with Ted: No means no, and when there are  
> exceptions, they should be made explicit.
>
> --Richard
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Tue, 1 May 2007 19:12:32 -0500

I'd submit that perhaps the important issue is who are considered to be
the peer parties in the communication. That is, should the location
information only be regarded as part of the session layer establishment
or does the sender intend that its context exist in the application
layer as well.

Clearly, in Brian's example, the intended use of the location
information is for routing - that is the session layer establishment to
the correct end node. Does the user intend the location information to
be forwarded in that context? The answer is "yes" to the extent that it
is necessary to establish the session. So, the proxy may need to forward
the location information if such forwarding is necessary to complete the
session establishment. It shouldn't be necessary for it to be sent to
the final point associated with the connection.

Do the proxies, etc, know that this is a Pizza Hut call? I doubt it.
Once the session is established the end point now has a peer
relationship with the Pizza Hut franchise. The latter would like the
location information in order to be able to deliver the product to a
paying recipient (btw, at this stage they may care more about the
integrity of the source of the location information). This is an
application layer consideration - it just happens to care about location
but, just because it's nominally the same quantity used in the session
establishment, it doesn't mean it should be extracted from the same
parameter used in the session layer.

To further highlight this, the form of location suitable for the session
layer may actually be geodetic where the application layer may actually
prefer civic. While the nominal quantity is the same thing, the form and
attributes suitable to each context may be different.

It would certainly be nice if, given an established session, there was
now an application layer associated with location information exchange
(including appropriate form and integrity) between the peers. Having to
second guess this application requirement in the session establishment
layer is what, I think, leads to the pain.

Perhaps it would cause less contortion if the role of SIP was clearer -
even for the use case presented. Is it only for session initiation, or
does it represent some other application function and, if so, what are
the boundaries of that? If it does go beyond the initiation phase, then
perhaps the semantics for further location information exchange belong
to a different set of messages.

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: Wednesday, 2 May 2007 9:42 AM
To: Richard Barnes
Cc: Ted Hardie; [email-masked]; Rosen,Brian
Subject: Re: [Geopriv] Location in SIP and "retransmission-allowed"

Henning

------------------------------------------------------------------------------------------------
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: Ted Hardie <[email-masked]>
Date: Tue, 1 May 2007 17:19:17 -0700

At 7:42 PM -0400 5/1/07, Henning Schulzrinne wrote:
>Your example seems to assume that the flag adds privacy by being set. Unfortunately, that's not the case.
>

<snipped emergency example>
I continue to think using the emergency case as the driving example is
warping this discussion.  I've reproduced a different example to reinforce
this point below.

>The same is true for the pizza call, so this does not depend on the specific example.
>
>Henning

Let's go with the pizza example, or, even better, a car service example.  I occasionally
call a car service to go to the airport, rather than driving and leaving my car there
or getting a ride.  There are several local car services that are truly local to me,
and a few that have local numbers but are regional or national operators.  As a
consumer I prefer to deal with the truly local operators, since I want to
keep my dollars in my area and believe that they are more reliable than operators
that may have to negotiate traffic just to get to me.  I also occasionally find that
one of my "local" car services has been sold, so that calling them transfers me
to one of the big operators.

I don't want that, and I hang up when I realize it.

The parallel in the LoST-using case is any situation where the end user would
be willing to share location with the intended recipient, but is not willing for
it to be used to route the call to the service provider the proxy/LoST combination
finds.

You may not find that a particularly compelling use case.  But the simple fact
is that this semantic, "willing to distribute to the recipient, but not wiling for
this to be used in routing", is achievable with one of the two syntax proposals
and it is not achievable with the other.  Since the second proposal (relaxing
what "no" means) runs contrary to the basic principles of the work:  user
control and a default no, I believe there is no strong reason to accept it
and that loss.  It violates the principle of least surprise (no means no to most
folks).  There is an obvious way to make sure that the semantics retain
their original force and are appropriately extended.  Let's adopt that obvious
way, and move on.
				Ted

---

From: "Moore, Lyn E" <[email-masked]>
Date: Wed, 2 May 2007 10:30:40 +1000

To pick up on Martin's point.  Currently, PSTN location-based routing
occurs via SS7 and "phone number to Address" database lookups internal
to a telco. I would consider that in a SIP environment that Martin's
pizza example would still be carried out as location-based routing
"in-bound" calling application within a telco.  This could take the form
of an IMS Application Server that processes in bound calls to the
nearest pizza hut and routes them to the nearest one.  Other IMS
Application Servers could be used in conjunction to provide the relevant
location information in the correct format, all within the telco
environment.  I assume this will be an "unpopular" point of view.

Regards
Lyn Moore

-----Original Message-----
From: Dawson, Martin [mailto:[email-masked]] 
Sent: Wednesday, 2 May 2007 10:13 AM
To: Henning Schulzrinne; Richard Barnes
Cc: Ted Hardie; [email-masked]; Rosen, Brian
Subject: RE: [Geopriv] Location in SIP and "retransmission-allowed"

Cheers,
Martin

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Wednesday, 2 May 2007 9:42 AM
To: Richard Barnes
Cc: Ted Hardie; [email-masked]; Rosen,Brian
Subject: Re: [Geopriv] Location in SIP and "retransmission-allowed"

In your example, the privacy-conscious (emergency) caller will say 'no'.
Let's assume that we have the standard two-stage routing (local  
+ emergency services network). The call reaches the ESN and the flag
indicates "sorry, no LoST". In this case, the only alternative is to
fail the call. It's not like the LoST lookup is some optional frill for
this call. Thus, the call will fail and, if you're lucky, the UA will
retry, presumably after displaying a warning message to the user to the
effect that no call will go through until they click off on the privacy
release. The outcomes are thus exactly the same with or without the
flag: a successful call, but no additional privacy, or no call.

The hypothetical disclosure of information you mention is in no way
prevented by having this flag set to 'no', even if all entities in the
call path observe the flag. The correct way to protect privacy is to
privacy-protect the signaling channel or, if you're truly paranoid, do
bogus LoST queries to obfuscate real ones.

Henning

> calling for emergency services.  If I want to jam emergency calls in 
> an area, LoST queries give me enough information to know where to put 
> my jammers.  Or if I'm watching a stream of periodic LoST queries, and

> I see one go outside the usual pattern, then I know the location of 

------------------------------------------------------------------------
------------------------
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: Henning Schulzrinne <[email-masked]>
Date: Tue, 1 May 2007 21:03:07 -0400

To pursue this one a bit: Let's assume we have this flag. Would the  
definition be "no location-based lookup" at all or only under some  
circumstances, e.g., based on where the server is located?

Can we build a new MIME attachment called 'application/lawyer' while  
we're at it, so that we can include an attorney with the call attempt?

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 1 May 2007 21:13:41 -0400

Your example doesn't work. There are two cases:

(1) You use a service URN for "car service". The first proxy needs to  
do a LoST lookup, or the call will fail. Saying 'no' simply ensures  
that the call fails. Thus, there's no additional privacy.

(2) You dial a specific car service, say (in NYC) CARMEL. You are  
willing to disclose your location to that particular service, for  
dispatch. But for some reason, you're not willing to disclose it to  
route the call? (In your example, your evil mega-corporation will  
have obtained the location by the time they answer with "New  
EvilCorp, formerly friendly neighborhood car service". They'll  
probably default route to their national call center in Bangalore...)

I have to admit that I find this highly contrived and can't imagine  
that anybody would constructively use such a feature.

The costs, in terms of error handling and failure modes, seem like a  
bad trade-off for a feel-good, do-nothing flag.

If you truly want to prevent location-based routing, why not just  
skip the Geolocation header and simply include a (location) body? Or  
simply encrypt the information so that only the intended recipient  
can read it? That offers real security, as opposed to make-believe  
security.

Henning

> warping this discussion.  I've reproduced a different example to  

Richard made up the example, not I.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 01 May 2007 21:27:44 -0400

> circumstances, e.g., based on where the server is located?

Once you start expanding the scope, though, where do you draw the line? 
  Can it be used to query a location-based rate computation system?  Can 
it be used to deliver location-targeted ads?  Is the telco authorized to 
do whatever it wants?

If you want to go that route, maybe we could define an 
"allowed-services" element that the user could use to express that the 
enclosed LI/LO could be used with particular protocols.  LoST would be 
the first example, RADIUS might be another, I'm sure more would come up. 
  This could be a nice compliment to the identity-based rules in RFC 4745.

> we're at it, so that we can include an attorney with the call attempt?

I hear that Verizon has claimed IPR on that.  :)

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Tue, 01 May 2007 21:42:18 -0400

> If you truly want to prevent location-based routing, why not just skip 
> the Geolocation header and simply include a (location) body? 

This is probably the simplest solution to achieve the desired effect. 
As Martin pointed out, there is a distinction between SIP information 
(the header) and application-layer information (the body).

However, it's really beside the point, since you still have to deal with 
the case when a Geolocation value arrives with retransmission-allowed 
set to "no".

--RB

> Or simply
> encrypt the information so that only the intended recipient can read it? 
> That offers real security, as opposed to make-believe security.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 1 May 2007 21:51:23 -0400

On May 1, 2007, at 9:27 PM, Richard Barnes wrote:

>> To pursue this one a bit: Let's assume we have this flag. Would  
>> the definition be "no location-based lookup" at all or only under  
>> some circumstances, e.g., based on where the server is located?
>
> Once you start expanding the scope, though, where do you draw the  
> line?  Can it be used to query a location-based rate computation  
> system?  Can it be used to deliver location-targeted ads?  Is the  
> telco authorized to do whatever it wants?

I don't understand this. Location-targeted ads would be delivered by  
the end system, which are not affected by this flag (or any other  
flag under discussion, for that matter). The carrier already knows  
where I live (even if they won't share it with anybody else), just by  
looking at my IP address, so they don't need this flag to deliver  
location-based ads. My VSP can deliver targeted ads based on my  
billing address, if it wanted to.

With your flag, would location-based ads be ok if the flag was set to  
yes?

My delineation is fairly straightforward: It's permissible to do  
'external' call routing based on locations only, as long as the  
identity is not included. Nothing else. Call routing is a necessary  
and core function of proxies; targeted ads are not.

>
> If you want to go that route, maybe we could define an "allowed- 
> services" element that the user could use to express that the  
> enclosed LI/LO could be used with particular protocols.  LoST would  
> be the first example, RADIUS might be another, I'm sure more would  
> come up.  This could be a nice compliment to the identity-based  
> rules in RFC 4745.

If you want complete privacy, encrypt the location information with  
the public key of the recipient. That's real security, not make- 
belief security.

>
>> Can we build a new MIME attachment called 'application/lawyer'  
>> while we're at it, so that we can include an attorney with the  
>> call attempt?
>

Unfortunately, their lawyers exceed the maximum payload size and  
would get fragmented.

Henning

---

From: "Moore, Lyn E" <[email-masked]>
Date: Wed, 2 May 2007 11:54:03 +1000

I would not think the aim of this work is to replace location-based
services with a protocol. 

Telcos etc provide LBS but, at least in Australia, the user needs to
agree to be positioned.  There are industry guidelines, the Privacy Act
and a Telecommunication Act to protect the rights of the users of LBS.
These are strictly adhered to by the LBS providers.  

I realise that this group is here to protect geoprivacy, but to be
realistic this step is going too far.  I sugest that GeoPriv keep to
your scope, and leave the LBS providers to differentiate and implement a
range of services any way they see fit within the letter of the law of
the country of origin. A protocol will not save souls from dubious
service providers - they just won't implement it.  

Lyn

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Wednesday, 2 May 2007 11:28 AM
To: Henning Schulzrinne
Cc: Moore, Lyn E; GEOPRIV
Subject: Re: [Geopriv] Location in SIP and "retransmission-allowed"

  This could be a nice compliment to the identity-based rules in RFC
4745.

--Richard

>> occurs via SS7 and "phone number to Address" database lookups 
>> internal to a telco. I would consider that in a SIP environment that 
>> Martin's pizza example would still be carried out as location-based 
>> routing "in-bound" calling application within a telco.  This could 
>> take the form of an IMS Application Server that processes in bound 
>> calls to the nearest pizza hut and routes them to the nearest one.  
>> Other IMS Application Servers could be used in conjunction to provide

>> the relevant location information in the correct format, all within 
>> the telco environment.  I assume this will be an "unpopular" point of
view.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 1 May 2007 21:54:20 -0400

On May 1, 2007, at 9:42 PM, Richard Barnes wrote:

>
> However, it's really beside the point, since you still have to deal  
> with the case when a Geolocation value arrives with retransmission- 
> allowed set to "no".

Only the UAS is allowed to inspect the body under that regimen, and  
UAS don't do call routing (except as B2BUAs), so I don't understand  
your comment.

Henning

---

From: Richard Barnes <[email-masked]>
Date: Wed, 02 May 2007 08:46:53 -0400

Henning,

I've addressed your specific comment below, but I think we're getting 
down in the weeds, and I'd like to step back a little.

The point of GEOPRIV is to allow rule makers to clearly express their 
preferences for handling of LI and LOs, in a manner that is independent 
of the application that is using an LI/LO.  With that in mind, the 
options before us are:

1. Specify that retransmission-allowed=no has the meaning given in RFC 
4119, with the exception that use of the enclosed LI for a LoST query is 
also allowed.

2. Allow proxies to infer from the inclusion of an LO via a Geolocation 
header that the rule maker consents to use of the LI for LoST.

3. Provide an explicit indicator of whether a LoST query is allowed or 
not (e.g., binary "routing-query-allowed" or multi-valued "allowed-usage").

With respect to (1): I think this violates the principle of 
application-independence, since SIP is not the only application that 
this would influence.  If I send an LO to Google Maps, it seems 
reasonable that they should be requested not to use that location for a 
LoST query.

With respect to (2): This violates the principle of least surprise; Jon 
Rosenberg might say this is a "DWIM" instead of a "DWIS" approach.

This leaves us with (3), explicitly indicating that LI may be used for 
LoST.  IMO, it would be more future-proof to provide for a list of 
allowed uses (with LoST as the first instance), but the 
routing-query-allowed binary value provides enough information to 
provide a clear indication about LoST.

--Richard

>> with the case when a Geolocation value arrives with 
>> retransmission-allowed set to "no".
> 
> Only the UAS is allowed to inspect the body under that regimen, and UAS 
> don't do call routing (except as B2BUAs), so I don't understand your 
> comment.

Right, IF the UAC doesn't put in a Geolocation header.  But it's still 
possible for a UAC to insert a Geolocation header that points to a 
location with retransmission-allowed=no, so you either have to define 
UAS behavior in that case (i.e., do or don't use for LoST), or you have 
to require that if a location is included via a Geolocation header, then 
it MUST have retransmission-allowed=yes.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 2 May 2007 09:04:20 -0400

Another thought on this topic, which seems to have gotten lost. In  
the end, this is all about trust. We sometimes have the notion that  
SIP proxies are kind of like routers, operated by random entities  
that we don't control. However, that's a clear misunderstanding of  
how SIP request routing works. Those familiar with SIP will have seen  
the SIP trapezoid picture, consisting of a proxy in the outbound  
domain (typically, my VSP) and in the destination domain.

For the topic at hand, as I noted, there are two cases:

(1) The destination URL is a service URN. If not resolved by the UA,  
it needs to be resolved by the very first (outbound) proxy. Thus,  
this proxy needs to do a location-based lookup. There simply is no  
choice other than failing the call, assuming that there is no  
worldwide catch-all call center for that service. Thus, any privacy  
indication in this case is simply a waste of time, since you might as  
well have a "fail this call, please" flag.

(2) The second case is that of a second-level resolution, i.e., after  
the service URN has been resolved to a specific SIP URL. This could  
be the emergency service network or PizzaHut's internal network. In  
other words, this occurs if I place a call so  
sip:[email-masked] which is then delivered to  
sip:[email-masked], say.

In this second case, however, the trust domain for the UA and the  
proxy is exactly the same organization. In other words, as a caller,  
I have decided to hand my location information to PizzaHut so that  
they can deliver their service to me. The proxy is owned by PizzaHut.  
Thus, it seems rather strange that I would give PizzaHut my location  
information for pizza delivery, but not to route the call. This gets  
even stranger if it were ok that PizzaHut were to operate a back-to- 
back UA, extract the information, and then, as a UA, re-issue the  
call. On top of that, in this particular case, the LoST server  
hierarchy is likely to be operated by PizzaHut, too.

I think we need to rely on organizational boundaries, rather than  
whether there's an Ethernet cable between the proxy and the location  
lookup service or other angels-on-a-pin distinctions. As far as I  
know, all privacy restrictions in the real world operate like that.  
In other words, the typical privacy rule that (a good) company X has  
is something like "we'll use the information you provide us with as  
necessary to provide the service you contracted for, but we won't  
hand the information to third parties, unless compelled to do so by  
law, or to our marketing department unless you opt in".

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 2 May 2007 09:08:20 -0400

Richard,

You keep ignoring the distinction between non-identifiable location  
information and a PIDF-LO (personally identified) location object.  
Until this distinction is made, including its impact on privacy, we  
have no rational basis for discussion.

Please also see my next message about how SIP routing works and that  
the proposal you make has no basis in SIP routing or in accepted  
privacy standards. This discussion is indeed about SIP, not some  
other hypothetical protocols.

Henning

On May 2, 2007, at 8:46 AM, Richard Barnes wrote:

> Henning,
>
> I've addressed your specific comment below, but I think we're  
> getting down in the weeds, and I'd like to step back a little.
>
> The point of GEOPRIV is to allow rule makers to clearly express  
> their preferences for handling of LI and LOs, in a manner that is  
> independent of the application that is using an LI/LO.  With that  
> in mind, the options before us are:
>
> 1. Specify that retransmission-allowed=no has the meaning given in  
> RFC 4119, with the exception that use of the enclosed LI for a LoST  
> query is also allowed.
>
> 2. Allow proxies to infer from the inclusion of an LO via a  
> Geolocation header that the rule maker consents to use of the LI  
> for LoST.
>
> 3. Provide an explicit indicator of whether a LoST query is allowed  
> or not (e.g., binary "routing-query-allowed" or multi-valued  
> "allowed-usage").
>
> application-independence, since SIP is not the only application  
> that this would influence.  If I send an LO to Google Maps, it  
> seems reasonable that they should be requested not to use that  
> location for a LoST query.
>
> With respect to (2): This violates the principle of least surprise;  
> Jon Rosenberg might say this is a "DWIM" instead of a "DWIS" approach.
>
> This leaves us with (3), explicitly indicating that LI may be used  
> for LoST.  IMO, it would be more future-proof to provide for a list  
> of allowed uses (with LoST as the first instance), but the routing- 
> query-allowed binary value provides enough information to provide a  
> clear indication about LoST.
>
> --Richard

---

From: Richard Barnes <[email-masked]>
Date: Wed, 02 May 2007 10:23:55 -0400

Perhaps it would help if we were more concrete.

Quoth RFC 4119:
"When the value of this [the retransmission-allowed] element is 'no', 
the Recipient of this Location Object is not permitted to share the 
enclosed Location Information, or the object as a whole, with other 
parties."

The critical part of this criterion for this discussion seems to be the 
definition of "parties": Is a party a process, a box, a LAN, a trust 
domain, a legal entity?  These distinctions are what I suppose you're 
referring to as "angels-on-a-pin" distinctions.  But I also think that 
they're largely irrelevant to this discussion, because allowing a 
general LoST query will hand location to another "party" by any 
reasonable definition.

First, let me say that there are situations in which 
retransmission-allowed=no WOULD allow for location-based services.  For 
instance, if a telco were considered a party (as it is a legal Party to 
a EULA), the location could be passed around within the telco for 
whatever purposes.

However, focusing for the moment on the emergency case: When a proxy 
does a LoST lookup, the query progresses through the LoST infrastructure 
as described in the mapping architecture.  In the base case, this means 
that the "enclosed Location Information" is transmitted all the way to 
the authoritative LoST server.  Which means that in order to interpret 
retransmission-allowed=no as allowing LoST queries, you'd have to 
consider every authoritative LoST server as part of the same "party". 
This hardly seems like a reasonable definition of "party".

So it seems clear that retransmission-allowed=no, with the semantic 
given in RFC 4119, disallows LoST queries in general.  With that in 
mind, what is your proposed modification?

--Richard

Henning Schulzrinne wrote:
> Another thought on this topic, which seems to have gotten lost. In the 
> end, this is all about trust. We sometimes have the notion that SIP 
> proxies are kind of like routers, operated by random entities that we 
> don't control. However, that's a clear misunderstanding of how SIP 
> request routing works. Those familiar with SIP will have seen the SIP 
> trapezoid picture, consisting of a proxy in the outbound domain 
> (typically, my VSP) and in the destination domain.
> 
> (1) The destination URL is a service URN. If not resolved by the UA, it 
> needs to be resolved by the very first (outbound) proxy. Thus, this 
> proxy needs to do a location-based lookup. There simply is no choice 
> other than failing the call, assuming that there is no worldwide 
> catch-all call center for that service. Thus, any privacy indication in 
> this case is simply a waste of time, since you might as well have a 
> "fail this call, please" flag.
> 
> the service URN has been resolved to a specific SIP URL. This could be 
> the emergency service network or PizzaHut's internal network. In other 
> words, this occurs if I place a call so sip:[email-masked] which 
> is then delivered to sip:[email-masked], say.
> 
> In this second case, however, the trust domain for the UA and the proxy 
> is exactly the same organization. In other words, as a caller, I have 
> decided to hand my location information to PizzaHut so that they can 
> deliver their service to me. The proxy is owned by PizzaHut. Thus, it 
> seems rather strange that I would give PizzaHut my location information 
> for pizza delivery, but not to route the call. This gets even stranger 
> if it were ok that PizzaHut were to operate a back-to-back UA, extract 
> the information, and then, as a UA, re-issue the call. On top of that, 
> in this particular case, the LoST server hierarchy is likely to be 
> operated by PizzaHut, too.
> 
> lookup service or other angels-on-a-pin distinctions. As far as I know, 
> all privacy restrictions in the real world operate like that. In other 
> words, the typical privacy rule that (a good) company X has is something 
> like "we'll use the information you provide us with as necessary to 
> provide the service you contracted for, but we won't hand the 
> information to third parties, unless compelled to do so by law, or to 
> our marketing department unless you opt in".
> 
> Henning
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 2 May 2007 09:33:52 -0500

I'd like to understand the issue a bit more from your perspective though
Richard.

The identity of the user has not been provided to the LoST server
(Henning's point). Indeed, to the LoST server it's just a request to
provide the routing information associated with an arbitrary and
anonymous location.

Do you think that 4119 is trying to say that the location information
should not be used or is it actually saying that the location of the
user should not be forwarded on to other parties (and I'd expect the
intention of "parties" was someone other than the trust domain but who
knows what the author was actually thinking)? That is, is a PIDF-LO
significant if it is in isolation from the rest of the PIDF information?
(I'm assuming it's stripped of anything unique to the user)

Cheers,
Martin

-----Original Message-----
From: Richard Barnes [mailto:[email-masked]] 
Sent: Thursday, 3 May 2007 12:24 AM
To: Henning Schulzrinne
Cc: GEOPRIV
Subject: Re: [Geopriv] Location in SIP and "retransmission-allowed"

Quoth RFC 4119:

--Richard

> (1) The destination URL is a service URN. If not resolved by the UA,
it 

> In this second case, however, the trust domain for the UA and the
proxy 

> lookup service or other angels-on-a-pin distinctions. As far as I
know,

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 2 May 2007 10:59:59 -0400

We are now clearly in the realm of theology, as we're trying to do  
exegesis on ancient documents which may or may not have been divinely  
inspired.

I'd much rather discuss real privacy threats and real engineering  
mechanisms to protect user privacy.

My general concern is that adding a 'do not location-route' means  
that almost all calls that need such routing will fail. I've laid out  
the failure cases earlier, and it would be helpful if you could  
address those.

Thus, in the vast majority of cases, this flag will have no effect  
except causing call failures. The only alternative is that calls will  
get routed to a global call center. I fail to see how that has any  
positive effect on user experience or privacy, given that the call  
taker in some faraway place will see the location information, based  
on the rules. At best, you get to talk to a lady in North Dakota who  
will say "You want pizza in Brooklyn? Let me look this up - I'll  
transfer you after I consult my directory."

I will note that for the case (2) I mentioned, the LoST hierarchy is  
indeed operated by the same logical organization that is being  
addressed by the request URL. In my examples, PizzaHut or the  
regional emergency network. (In case (1), a negative flag will always  
cause call failures, so it's not terribly interesting.)

Thus, based on your "this is about organizations, not wires" notion,  
these would be permitted without a flag. Am I getting this right?

Thus, it would be helpful if you could describe cases, based on how  
SIP routing really works, where the flag would make a real privacy  
difference and not just a call failure.

Henning

On May 2, 2007, at 10:23 AM, Richard Barnes wrote:

> "When the value of this [the retransmission-allowed] element is  
> 'no', the Recipient of this Location Object is not permitted to  
> share the enclosed Location Information, or the object as a whole,  
> with other parties."
>
> The critical part of this criterion for this discussion seems to be  
> the definition of "parties": Is a party a process, a box, a LAN, a  
> trust domain, a legal entity?  These distinctions are what I  
> suppose you're referring to as "angels-on-a-pin" distinctions.  But  
> I also think that they're largely irrelevant to this discussion,  
> because allowing a general LoST query will hand location to another  
> "party" by any reasonable definition.
>
> First, let me say that there are situations in which retransmission- 
> allowed=no WOULD allow for location-based services.  For instance,  
> if a telco were considered a party (as it is a legal Party to a  
> EULA), the location could be passed around within the telco for  
> whatever purposes.
>
> However, focusing for the moment on the emergency case: When a  
> proxy does a LoST lookup, the query progresses through the LoST  
> infrastructure as described in the mapping architecture.  In the  
> base case, this means that the "enclosed Location Information" is  
> transmitted all the way to the authoritative LoST server.  Which  
> means that in order to interpret retransmission-allowed=no as  
> allowing LoST queries, you'd have to consider every authoritative  
> LoST server as part of the same "party". This hardly seems like a  
> reasonable definition of "party".
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 02 May 2007 11:57:45 -0400

Henning,

The point of GEOPRIV is to provide a format for expressing privacy 
preferences.  The semantics indicated by that format is thus a central 
concern of the working group.  Call it theology if you want, but that's 
our job.

My point in previous emails is that according to existing 
specifications, retransmission-allowed=no means that you can't do an 
arbitrary LoST query.  You need to ensure that the LoST query won't 
cause the location information to be transmitted to a third party, 
where, e.g.,  the LoST emergency mapping infrastructure is counted as a 
third party.  Thus, a LO included via a Geolocation header with 
retransmission-allowed=no would prevent that location from being used 
for some (perhaps most) LoST queries.  This would cause calls such as 
your case (1) to fail, essentially because the UAC would have 
constructed a contradictory message. (Note, however, that this could 
still be overridden in limited cases, e.g., by phonebcp.)

How do you want to change this situation?

0. Instruct proxies to ignore the value of retransmission-allowed for 
locations included via a Geolocation header.

[RLB] This would standardize behavior inconsistent with RFC 4119. 
Nothing requires Location Recipients to abide by privacy rules, but we 
shouldn't require them to break privacy rules either.  This behavior is 
only suitable for special situations, e.g., emergency calling.

1. Revise the meaning of retransmission-allowed=no to indicate that the 
location may be used for LoST, no matter where it gets sent.

[RLB] As I've said before, this is an application-specific modification 
to a field that is intended to be application-agnostic.

2. Require that a location included in a Geolocation header have 
retransmission-allowed=yes.

[RLB] This is a problem because locations conveyed in a Geolocation 
header can be Received by both a proxy and the UAS.  The endpoint might 
want the proxy to send the location on for routing, but the UAS not to 
transmit it, and the UAC would need to include two separate locations to 
allow this.

3. Add an additional usage-rules field to indicate explicit permission 
to do LoST.

[RLB] Minimal overhead, minimal complexity; maximal clarity.

4. Something else?

--Richard

Henning Schulzrinne wrote:
> My general concern is that adding a 'do not location-route' means that 
> almost all calls that need such routing will fail. I've laid out the 
> failure cases earlier, and it would be helpful if you could address those.
> 
> positive effect on user experience or privacy, given that the call taker 
> in some faraway place will see the location information, based on the 
> rules. At best, you get to talk to a lady in North Dakota who will say 
> "You want pizza in Brooklyn? Let me look this up - I'll transfer you 
> after I consult my directory."
> 
> indeed operated by the same logical organization that is being addressed 
> by the request URL. In my examples, PizzaHut or the regional emergency 
> network. (In case (1), a negative flag will always cause call failures, 
> so it's not terribly interesting.)
> 
> Thus, it would be helpful if you could describe cases, based on how SIP 
> routing really works, where the flag would make a real privacy 
>> trust domain, a legal entity?  These distinctions are what I suppose 
>> you're referring to as "angels-on-a-pin" distinctions.  But I also 
>> think that they're largely irrelevant to this discussion, because 
>> allowing a general LoST query will hand location to another "party" by 
>> any reasonable definition.
>>
>> retransmission-allowed=no WOULD allow for location-based services.  
>> For instance, if a telco were considered a party (as it is a legal 
>> Party to a EULA), the location could be passed around within the telco 
>> for whatever purposes.
>>
>> does a LoST lookup, the query progresses through the LoST 
>> infrastructure as described in the mapping architecture.  In the base 
>> case, this means that the "enclosed Location Information" is 
>> transmitted all the way to the authoritative LoST server.  Which means 
>> that in order to interpret retransmission-allowed=no as allowing LoST 
>> queries, you'd have to consider every authoritative LoST server as 
>> part of the same "party". This hardly seems like a reasonable 
>> definition of "party".
>>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 2 May 2007 09:44:49 -0700

At 9:04 AM -0400 5/2/07, Henning Schulzrinne wrote:
>Another thought on this topic, which seems to have gotten lost. In the end, this is all about trust. We sometimes have the notion that SIP proxies are kind of like routers, operated by random entities that we don't control. However, that's a clear misunderstanding of how SIP request routing works. Those familiar with SIP will have seen the SIP trapezoid picture, consisting of a proxy in the outbound domain (typically, my VSP) and in the destination domain.
>
>(1) The destination URL is a service URN. If not resolved by the UA, it needs to be resolved by the very first (outbound) proxy. Thus, this proxy needs to do a location-based lookup. There simply is no choice other than failing the call, assuming that there is no worldwide catch-all call center for that service. Thus, any privacy indication in this case is simply a waste of time, since you might as well have a "fail this call, please" flag.

Henning, I think you're missing the possibility that the call may get transferred
or otherwise retargeted.  I make a call to [email-masked].  They've
been bought, and my call is now forwarded to [email-masked],
which wants to do location based routing.  The user might be fine with
it going to the original recipient and even fine with the forwarding, but
not okay with the location based routing that occurs as a result.

I am sorry if you feel this is not a compelling example, but I don't think
you can guarantee that this semantic (the "real no") is never needed.
I think Richard's notion of something beyond a binary "routing permitted"
flag is probably a good one, since it gives extensibility, but I'm fine
with "routing permitted" if we want to do one thing and stop.

I'm not fine with us breaking one of the core semantics of GEOPRIV,
and your attempts to mock that position simply won't convince me.
We can go around and around, but that's probably not productive.
There is an easy way past this.  Let's take it and move on.

			regards,
				Ted
					Ted

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 02 May 2007 22:17:25 -0400

Ted, your call transfer example suggests something wrong in the interpretation 
of the PIDF-LO rules. It doesn't seem right to me that an LO addressed to one 
party can be transferred to another party without permission. Wouldn't there be 
an authentication failure that would prevent that transfer?

Ted Hardie wrote:
>> Another thought on this topic, which seems to have gotten lost. In the end,
>> this is all about trust. We sometimes have the notion that SIP proxies are
>> kind of like routers, operated by random entities that we don't control.
>> However, that's a clear misunderstanding of how SIP request routing works.
>> Those familiar with SIP will have seen the SIP trapezoid picture,
>> consisting of a proxy in the outbound domain (typically, my VSP) and in the
>> destination domain.
>> 
>> needs to be resolved by the very first (outbound) proxy. Thus, this proxy
>> needs to do a location-based lookup. There simply is no choice other than
>> failing the call, assuming that there is no worldwide catch-all call center
>> for that service. Thus, any privacy indication in this case is simply a
>> waste of time, since you might as well have a "fail this call, please"
>> flag.
> 
> Henning, I think you're missing the possibility that the call may get
> transferred or otherwise retargeted.  I make a call to
> [email-masked].  They've been bought, and my call is now forwarded
> to [email-masked], which wants to do location based routing.  The
> user might be fine with it going to the original recipient and even fine with
> the forwarding, but not okay with the location based routing that occurs as a
> result.
> 
> you can guarantee that this semantic (the "real no") is never needed. I think
> Richard's notion of something beyond a binary "routing permitted" flag is
> probably a good one, since it gives extensibility, but I'm fine with "routing
> permitted" if we want to do one thing and stop.
> 
> I'm not fine with us breaking one of the core semantics of GEOPRIV, and your
> attempts to mock that position simply won't convince me. We can go around and
> around, but that's probably not productive. There is an easy way past this.
> Let's take it and move on.
> 
> regards, Ted Ted
> 
> _______________________________________________ Geopriv mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/geopriv
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 2 May 2007 23:00:01 -0400

As Tom pointed out, re-targeting is a whole different can of worms  
and largely independent of the LoST issue. This is probably something  
worth thinking about and is a bit more complicated than you hint at.  
This is something that the draft should cover, as it is SIP-specific  
and really not addressed in general GEOPRIV documents, as far as I  
can tell.

(Most) any SIP proxy, other than outbound, will do retargeting -  
otherwise, it shouldn't be there...

Let's assume that retargeting would not be allowed if the PIDF-LO  
prohibits retransmission. This sounds fairly simple, but is tricky in  
practice.

Is the translation between [email-masked]' and  
[email-masked]' retargeting in your definition? Or does  
this depend on an organizational change? In your example,  
carservice.com is now part of the giantco, so it is not a different  
organization. Otherwise, any time that an organization has new  
management, you'd have to fail calls.

In this case, I actually sympathize with your desire to prohibit  
redistribution by call routing (although this has nothing to do with  
whether the call routing is based on location or, say, just the From  
or To header), as I expected to send my LO, with identity, to X and  
it's going to Y. The hard part will be defining when X is not  
equivalent to Y. An expansive definition will mean that no call that  
has retransmission=no will succeed and thus, people will pretty  
quickly have to give up on that flag if they want location-bearing  
calls to go anywhere.

There are some clear cases that I think we can easily consider  
retransmission: If company X sends a call to some totally  
unaffiliated company Y, this is clearly retransmission. It gets  
trickier for private individuals. What if I forward my son's location- 
bearing calls to the dinner party I'm at? How is my phone supposed to  
know whether that's an ok thing or not?

Usually, privacy policies list all the affiliates and subsidiaries  
that a company considers to be part of the same organization, so this  
is not a new problem.

It is obviously easier if I just agree with your opinion. I've tried  
to make technical arguments why the approach doesn't work and is  
likely to lead to either a false sense of privacy or call failures,  
or likely both, with lots of additional complexity. As far as I can  
tell, you have not been able to provide a single example that  
actually works once one goes through the details. Protocol behavior  
that is under-specified, but is lawyer-bait, just doesn't seem like a  
good idea to me.

Henning

On May 2, 2007, at 12:44 PM, Ted Hardie wrote:

>> the end, this is all about trust. We sometimes have the notion  
>> that SIP proxies are kind of like routers, operated by random  
>> entities that we don't control. However, that's a clear  
>> misunderstanding of how SIP request routing works. Those familiar  
>> with SIP will have seen the SIP trapezoid picture, consisting of a  
>> proxy in the outbound domain (typically, my VSP) and in the  
>> destination domain.
>>
>> (1) The destination URL is a service URN. If not resolved by the  
>> UA, it needs to be resolved by the very first (outbound) proxy.  
>> Thus, this proxy needs to do a location-based lookup. There simply  
>> is no choice other than failing the call, assuming that there is  
>> no worldwide catch-all call center for that service. Thus, any  
>> privacy indication in this case is simply a waste of time, since  
>> you might as well have a "fail this call, please" flag.
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 2 May 2007 21:23:29 -0700

At 11:00 PM -0400 5/2/07, Henning Schulzrinne wrote:
>As Tom pointed out, re-targeting is a whole different can of worms and largely independent of the LoST issue. This is probably something worth thinking about and is a bit more complicated than you hint at. This is something that the draft should cover, as it is SIP-specific and really not addressed in general GEOPRIV documents, as far as I can tell.
>
>(Most) any SIP proxy, other than outbound, will do retargeting - otherwise, it shouldn't be there...
>
>Let's assume that retargeting would not be allowed if the PIDF-LO prohibits retransmission. This sounds fairly simple, but is tricky in practice.
>
>Is the translation between [email-masked]' and [email-masked]' retargeting in your definition? Or does this depend on an organizational change? In your example, carservice.com is now part of the giantco, so it is not a different organization. Otherwise, any time that an organization has new management, you'd have to fail calls.

I am apparently not being clear enough here.  Let me try again.  My view is that
if the proxy acts to forward the call without reference to the location, then it is
not acting as a recipient.  That is related to the first point Brian raised in the
email that started this thread.  The proxy is simply acting as one hop in a
hop-by-hop protocol in its normal manner.  From the point of view of location
privacy, it is just passing things along.

If the proxy does use the location, either by reference to some local cache,
a distant LoST server, or related mechanism, to *pick a destination for the
call*, then I think the proxy is no longer acting as pass-through from the
point of view of location privacy.  At that point, all of the location privacy
rules have to be considered.  We need to make sure that the vocabulary
of those rules is rich enough to allow users to permit that when they wish
to allow it and to forbid it when they do not.    Overloading "retransmission=no"
eliminates needed semantics, in my opinion.

I believe this is relatively easy to express ("If a proxy uses the location
to route the request, it must have permission to do so, expressed by
retransmission="routing-permitted" or retransmission="yes").

This does not eliminate any potential privacy concerns that may exist
when SIP's normal behavior would cause the location to go to someone
surprising to the end user.  I agree with your points that this would
require more, probably the initiating user encrypting the location
so that only the original recipient can read it.  If the original recipient
sold the key with the business, then even that bet is off.

>In this case, I actually sympathize with your desire to prohibit redistribution by call routing (although this has nothing to do with whether the call routing is based on location or, say, just the From or To header), as I expected to send my LO, with identity, to X and it's going to Y. The hard part will be defining when X is not equivalent to Y. An expansive definition will mean that no call that has retransmission=no will succeed and thus, people will pretty quickly have to give up on that flag if they want location-bearing calls to go anywhere.
>
>There are some clear cases that I think we can easily consider retransmission: If company X sends a call to some totally unaffiliated company Y, this is clearly retransmission. It gets trickier for private individuals. What if I forward my son's location-bearing calls to the dinner party I'm at? How is my phone supposed to know whether that's an ok thing or not?
>
>Usually, privacy policies list all the affiliates and subsidiaries that a company considers to be part of the same organization, so this is not a new problem.
>
>It is obviously easier if I just agree with your opinion. I've tried to make technical arguments why the approach doesn't work and is likely to lead to either a false sense of privacy or call failures, or likely both, with lots of additional complexity. As far as I can tell, you have not been able to provide a single example that actually works once one goes through the details. Protocol behavior that is under-specified, but is lawyer-bait, just doesn't seem like a good idea to me.

I am more than willing to do the work to make specify this correctly.  I believe
we are actually disagreeing on the goals.  I believe that this level of user control
is both needed and consistent with GEOPRIV's charter.  Your responses seem to
indicate that you do not.  Your opinion appears instead to be that it is not
needed because proxy can use a mechanism to route that does not require it
reveal the identity on whose behalf it made the query.  I don't think that eliminates
the need, for many of the same reasons Richard has already put forward.  If
I have misunderstood you and we  do agree on the goals, then I have misunderstood
how you can achieve them while overloading retransmission=no.  If that is the
case, please restate that for me.
				thanks,
					Ted

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 May 2007 09:14:12 -0400

The discussion on this item seems to have died down.  Could the chair please
call the consensus so we can change the text in the conveyance document?

I believe the consensus on the first issue, which was whether a proxy can
forward a sip message containing location to the next hop if
retransmission-allowed=no, is a yes, it can.

I think several people spoke in favor of requiring a new tag,
"routing-query-allowed" which, when set to "yes" would permit a sip element
to send location to some other entity for the purpose of doing location
based routing if retransmission-allowed=no.  Henning strongly denounced this
as being unnecessary because the location did not have any user identity in
it. 

If the consensus is to require routing-query-allowed, -conveyance will
normatively update PIDF-LO to add this tag.  Although there was some
sentiment to make a more broadly applicable tag with multivaried values, the
authors would prefer to have routing-query-allowed, and there was not, in my
opinion, enough of a consensus on this aspect.  It's a chair call, of
course. 

Brian

-----Original Message-----
From: Ted Hardie [mailto:[email-masked]] 
Sent: Thursday, May 03, 2007 12:23 AM
To: Henning Schulzrinne
Cc: GEOPRIV
Subject: Re: [Geopriv] Location in SIP and "retransmission-allowed"

At 11:00 PM -0400 5/2/07, Henning Schulzrinne wrote:
>As Tom pointed out, re-targeting is a whole different can of worms and
largely independent of the LoST issue. This is probably something worth
thinking about and is a bit more complicated than you hint at. This is
something that the draft should cover, as it is SIP-specific and really not
addressed in general GEOPRIV documents, as far as I can tell.
>Let's assume that retargeting would not be allowed if the PIDF-LO prohibits
retransmission. This sounds fairly simple, but is tricky in practice.
>Is the translation between [email-masked]' and
[email-masked]' retargeting in your definition? Or does this
depend on an organizational change? In your example, carservice.com is now
part of the giantco, so it is not a different organization. Otherwise, any
time that an organization has new management, you'd have to fail calls.

I am apparently not being clear enough here.  Let me try again.  My view is
that
if the proxy acts to forward the call without reference to the location,
then it is
not acting as a recipient.  That is related to the first point Brian raised
in the
email that started this thread.  The proxy is simply acting as one hop in a
hop-by-hop protocol in its normal manner.  From the point of view of
location
privacy, it is just passing things along.

If the proxy does use the location, either by reference to some local cache,
a distant LoST server, or related mechanism, to *pick a destination for the
call*, then I think the proxy is no longer acting as pass-through from the
point of view of location privacy.  At that point, all of the location
privacy
rules have to be considered.  We need to make sure that the vocabulary
of those rules is rich enough to allow users to permit that when they wish
to allow it and to forbid it when they do not.    Overloading
"retransmission=no"
eliminates needed semantics, in my opinion.

>In this case, I actually sympathize with your desire to prohibit
redistribution by call routing (although this has nothing to do with whether
the call routing is based on location or, say, just the From or To header),
as I expected to send my LO, with identity, to X and it's going to Y. The
hard part will be defining when X is not equivalent to Y. An expansive
definition will mean that no call that has retransmission=no will succeed
and thus, people will pretty quickly have to give up on that flag if they
want location-bearing calls to go anywhere.
>There are some clear cases that I think we can easily consider
retransmission: If company X sends a call to some totally unaffiliated
company Y, this is clearly retransmission. It gets trickier for private
individuals. What if I forward my son's location-bearing calls to the dinner
party I'm at? How is my phone supposed to know whether that's an ok thing or
not?
>
>Usually, privacy policies list all the affiliates and subsidiaries that a
company considers to be part of the same organization, so this is not a new
problem.
>
>It is obviously easier if I just agree with your opinion. I've tried to
make technical arguments why the approach doesn't work and is likely to lead
to either a false sense of privacy or call failures, or likely both, with
lots of additional complexity. As far as I can tell, you have not been able
to provide a single example that actually works once one goes through the
details. Protocol behavior that is under-specified, but is lawyer-bait, just
doesn't seem like a good idea to me.

I am more than willing to do the work to make specify this correctly.  I
believe
we are actually disagreeing on the goals.  I believe that this level of user
control
is both needed and consistent with GEOPRIV's charter.  Your responses seem
to
indicate that you do not.  Your opinion appears instead to be that it is not
needed because proxy can use a mechanism to route that does not require it
reveal the identity on whose behalf it made the query.  I don't think that
eliminates
the need, for many of the same reasons Richard has already put forward.  If
I have misunderstood you and we  do agree on the goals, then I have
misunderstood
how you can achieve them while overloading retransmission=no.  If that is
the
case, please restate that for me.
				thanks,
					Ted

>>>Another thought on this topic, which seems to have gotten lost. In the
end, this is all about trust. We sometimes have the notion that SIP proxies
are kind of like routers, operated by random entities that we don't control.
However, that's a clear misunderstanding of how SIP request routing works.
Those familiar with SIP will have seen the SIP trapezoid picture, consisting
of a proxy in the outbound domain (typically, my VSP) and in the destination
domain.
waste of time, since you might as well have a "fail this call, please" flag.
>>Henning, I think you're missing the possibility that the call may get
transferred

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 4 May 2007 09:21:42 -0400

I think the broader question is:

When is a LO not a PIDF-LO?

I thought we had agreement long ago that a LO void of user identity (entity)
did not fall under RFC3693/94.

-Marc- 

> 
> The discussion on this item seems to have died down.  Could 
> the chair please call the consensus so we can change the text 
> in the conveyance document?
> 
> I believe the consensus on the first issue, which was whether 
> a proxy can forward a sip message containing location to the 
> next hop if retransmission-allowed=no, is a yes, it can.
> 
> "routing-query-allowed" which, when set to "yes" would permit 
> a sip element to send location to some other entity for the 
> purpose of doing location based routing if 
> retransmission-allowed=no.  Henning strongly denounced this 
> as being unnecessary because the location did not have any 
> user identity in it. 
> 
> If the consensus is to require routing-query-allowed, 
> -conveyance will normatively update PIDF-LO to add this tag.  
> Although there was some sentiment to make a more broadly 
> applicable tag with multivaried values, the authors would 
> prefer to have routing-query-allowed, and there was not, in 
> my opinion, enough of a consensus on this aspect.  It's a 
> chair call, of course. 
> 
> Brian
> 
> largely independent of the LoST issue. This is probably 
> something worth thinking about and is a bit more complicated 
> than you hint at. This is something that the draft should 
> cover, as it is SIP-specific and really not addressed in 
> general GEOPRIV documents, as far as I can tell.
> >
> >prohibits
> [email-masked]' retargeting in your definition? 
> Or does this depend on an organizational change? In your 
> example, carservice.com is now part of the giantco, so it is 
> not a different organization. Otherwise, any time that an 
> organization has new management, you'd have to fail calls.
> 
> I am apparently not being clear enough here.  Let me try 
> again.  My view is that if the proxy acts to forward the call 
> without reference to the location, then it is not acting as a 
> recipient.  That is related to the first point Brian raised 
> in the email that started this thread.  The proxy is simply 
> acting as one hop in a hop-by-hop protocol in its normal 
> manner.  From the point of view of location privacy, it is 
> just passing things along.
> 
> If the proxy does use the location, either by reference to 
> some local cache, a distant LoST server, or related 
> mechanism, to *pick a destination for the call*, then I think 
> the proxy is no longer acting as pass-through from the point 
> of view of location privacy.  At that point, all of the 
> location privacy rules have to be considered.  We need to 
> make sure that the vocabulary of those rules is rich enough 
> to allow users to permit that when they wish
> I believe this is relatively easy to express ("If a proxy 
> uses the location to route the request, it must have 
> permission to do so, expressed by 
> This does not eliminate any potential privacy concerns that 
> may exist when SIP's normal behavior would cause the location 
> to go to someone surprising to the end user.  I agree with 
> your points that this would require more, probably the 
> initiating user encrypting the location so that only the 
> original recipient can read it.  If the original recipient 
> redistribution by call routing (although this has nothing to 
> do with whether the call routing is based on location or, 
> say, just the From or To header), as I expected to send my 
> LO, with identity, to X and it's going to Y. The hard part 
> will be defining when X is not equivalent to Y. An expansive 
> definition will mean that no call that has retransmission=no 
> will succeed and thus, people will pretty quickly have to 
> give up on that flag if they want location-bearing calls to 
> go anywhere.
> >
> unaffiliated company Y, this is clearly retransmission. It 
> gets trickier for private individuals. What if I forward my 
> son's location-bearing calls to the dinner party I'm at? How 
> is my phone supposed to know whether that's an ok thing or not?
> >
> >Usually, privacy policies list all the affiliates and 
> subsidiaries that 
> >a
> company considers to be part of the same organization, so 
> this is not a new problem.
> >
> make technical arguments why the approach doesn't work and is 
> likely to lead to either a false sense of privacy or call 
> failures, or likely both, with lots of additional complexity. 
> As far as I can tell, you have not been able to provide a 
> single example that actually works once one goes through the 
> details. Protocol behavior that is under-specified, but is 
> lawyer-bait, just doesn't seem like a good idea to me.
> 
> I am more than willing to do the work to make specify this 
> correctly.  I believe we are actually disagreeing on the 
> goals.  I believe that this level of user control is both 
> needed and consistent with GEOPRIV's charter.  Your responses 
> seem to indicate that you do not.  Your opinion appears 
> instead to be that it is not needed because proxy can use a 
> mechanism to route that does not require it reveal the 
> identity on whose behalf it made the query.  I don't think 
> that eliminates the need, for many of the same reasons 
> Richard has already put forward.  If I have misunderstood you 
> and we  do agree on the goals, then I have misunderstood how 
> you can achieve them while overloading retransmission=no.  If 
> that is the case, please restate that for me.
> 				thanks,
> 					Ted
> 
> 
> 
> >Henning
> >
> >
> end, this is all about trust. We sometimes have the notion 
> entities that we don't control.
> Those familiar with SIP will have seen the SIP trapezoid 
> picture, consisting of a proxy in the outbound domain 
> needs to be resolved by the very first (outbound) proxy. 
> Thus, this proxy needs to do a location-based lookup. There 
> simply is no choice other than failing the call, assuming 
> that there is no worldwide catch-all call center for that 
> service. Thus, any privacy indication in this case is simply 
> a waste of time, since you might as well have a "fail this 
> call, please" flag.
> >>
> >>it going to the original recipient and even fine with the 
> forwarding, 
> >>but not okay with the location based routing that occurs as 
> a result.
> >>
> >>I am sorry if you feel this is not a compelling example, 
> but I don't 
> >>think you can guarantee that this semantic (the "real no") 
> is never needed.
> >>flag is probably a good one, since it gives extensibility, but I'm 
> >>fine with "routing permitted" if we want to do one thing and stop.
> >>

---

From: Francois Menard <[email-masked]>
Date: Fri, 4 May 2007 09:28:57 -0400 (EDT)

I just listened to the 3h recording of the last session in prague and it 
is still not clear to me as to why under the L7 LCP, 
passing along a location-by-value in a subscription is not getting some 
traction and in fact, would appear to have been kicked out.

Does this mean that people expect that location-by-value will only be used 
in a non-subscritive context, such as via DHCP?

f.

--
[email-masked]

---

From: Richard Barnes <[email-masked]>
Date: Fri, 04 May 2007 09:36:21 -0400

The RFC 3693 term for "just the location, please" (without identity, 
rules, etc.) is Location Information:

<RFC3693>
       Location Information: A relatively specific way of describing
          where a Device is located.
</RFC3693>

"Long ago" may be before I started working in this group, but ISTM that 
RFC 4119 is pretty clear that location information (even without 
identity) is covered by usage rules.  For example, in the specification 
of the retransmission-allowed element:
<RFC4119>
    'retransmission-allowed': When the value of this element is 'no', the
       Recipient of this Location Object is not permitted to share the
       enclosed Location Information, or the object as a whole, with
       other parties.
</RFC4119>

I'm not making any claims as to consensus here, but if that is the case, 
then it would be a departure from the consensus recorded in RFC 4119, 
and a document that requires that LI isn't subject to the rules in 4119 
would have to update 4119 to this effect.

--Richard

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 4 May 2007 09:43:43 -0400

> 
> The RFC 3693 term for "just the location, please" (without 
> identity, rules, etc.) is Location Information:
> 
> <RFC3693>

Void of 'Device', what is it?

Which is what Henning's point has been all along.

-Marc-