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

From: "Marc Linsner" <[email-masked]>
Date: Fri, 4 May 2007 10:36:44 -0400

As Henning states:

123 Main St. is not interesting until we place Richard Barnes there.

-Marc- 

> 
> Ah, I see the difference in understanding.  However, I 
> thought the common interpretation was that LI is the position 
> of a Device, regarded 
> separately from identifiers for the device, etc.   For example, in 
> PIDF-LO, the location-info element contains only GML, not any 
> identifiers.
> 
> --Richard
> 
> 
> Marc Linsner wrote:
> >  
> >> 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>
> > 
> > Void of 'Device', what is it?
> > 
> > 
> > Which is what Henning's point has been all along.
> > 
> > -Marc-
> > 
> > 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 May 2007 10:47:06 -0400

But the location IS that of a device.
Are you arguing that 4119 is wrong, and we should normatively change it, or
are you arguing that a routing query does have the LI of a device and thus
the current language of 4119 permits it?

Brian

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Friday, May 04, 2007 10:37 AM
To: 'Richard Barnes'
Cc: 'GEOPRIV'
Subject: RE: [Geopriv] Location in SIP and "retransmission-allowed"

As Henning states:

-Marc-

---

From: Richard Barnes <[email-masked]>
Date: Fri, 04 May 2007 11:02:54 -0400

And I think the cogent point is that there are use cases where the fact 
that there's something at the transmitted location is considered 
sensitive.  So the rules language needs to provide syntax to control 
dissemination of LI derived from an LO, not just the full LO.

--RB

---

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

> But the location IS that of a device.

You are assuming that!  What device?

> Are you arguing that 4119 is wrong, and we should normatively 
> change it, or are you arguing that a routing query does have 
> the LI of a device and thus the current language of 4119 permits it?

No, I'm arguing that GeoPriv doesn't care about a LO void of 'entity'.  It's
not a 'device' until you tie identity to it.

If you are correct, then LoST needs changing.  You are inferring that any LO
must carry "retransmission-allowed" because you assume a device resides at
the location.  The LoST query would need "retransmission-allowed" and the
LoST response would need "retransmission-allowed".  Doesn't that seem odd to
you?

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 4 May 2007 11:31:24 -0400

All locations are of something or other. Even 123 Main Street, all by  
itself, is the location of a building, presumably. I hope you agree  
that saying "123 Main Street" by itself has no privacy implications.  
I think this was our core assumption for GEOPRIV all along, just  
given plain common sense, simply because privacy is defined in  
relationship to people only. You can get the full, far more  
elaborate, discussion at http://www.privacyinternational.org/survey/ 
phr2003/overview.htm

In the case we're talking about, the 'device' has been removed from  
the protocol.

On May 4, 2007, at 10:47 AM, Brian Rosen wrote:

> change it, or

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 May 2007 11:58:07 -0400

Are you being dense on purpose, or have I missed something?

A SIP UA sends its location to a proxy server, which takes the LI out and
sends it to LoST.  What the proxy is sending is the LI of a device.  To me,
that is exactly what the current 4119 language says you can't do if
retransmission-allowed=no.

I'm NOT really arguing one way or another about whether this should be
allowed or not.  I'm trying to figure out if you want a normative change to
4119.  I keep reading your messages as being "NO, I don't think we need to
normatively change 4119".  I'm trying to figure out how you do that.

4119 says you can't send LI of a device.  A SIP proxy sending a UA's
location to a LoST server is sending LI of a device.  Where am I going wrong
here?

Brian

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]] 
Sent: Friday, May 04, 2007 11:22 AM
To: 'Brian Rosen'; 'Richard Barnes'
Cc: 'GEOPRIV'
Subject: RE: [Geopriv] Location in SIP and "retransmission-allowed"

-Marc-

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 4 May 2007 12:22:55 -0400

Brian,

> Are you being dense on purpose, or have I missed something?

I'll admit, dense is a normal state.

> 
> A SIP UA sends its location to a proxy server, which takes 
> the LI out and sends it to LoST.

What makes the LO 'its location'.

  What the proxy is sending 
> is the LI of a device. 

Not if you remove the pieces that makes the LO 'its location'.

 To me, that is exactly what the 
> current 4119 language says you can't do if retransmission-allowed=no.

Agree if the proxy server were to include device/entity identifiers in the
transmission to LoST.

> 
> I'm NOT really arguing one way or another about whether this 
> should be allowed or not.  I'm trying to figure out if you 
> want a normative change to 4119.  I keep reading your 
> messages as being "NO, I don't think we need to normatively 
> change 4119".  I'm trying to figure out how you do that.

Obviously some are trying to explain common sense and others are trying to
lawyer 4119.

Which brings me back to my original question for the lawyer:

What makes a LO a PIDF-LO?

or

Why is a LoST query/response not covered by 4119?

-Marc-

---

From: Richard Barnes <[email-masked]>
Date: Fri, 04 May 2007 13:27:38 -0400

I consulted with corporate counsel, and he observed that RFC 4119 says 
that if retransmission-allowed=no, then that indicates that the user 
doesn't want the recipient to retransmit either the LO (with 
identifiers) or the LI (without).  This seems to me very explicit, very 
common-sense.

So Marc/Henning: Either
1) What about this situation allows retransmission for LoST?  Or,
2) What modification do you propose?

--Richard

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 04 May 2007 13:27:05 -0400

I'll remind you that RFC 3693 points out that defending against traffic analysis 
is out of GEOPRIV's scope. I'm not sure if that extends to analysis of LoST queries.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 4 May 2007 13:50:37 -0400

Now we're definitely into protocol-lawyering...

I suspect that he would give the same answer for a proxy forwarding a  
call that this is retransmission, too.

Let's try logic again. We all agree, I hope, that it's the  
combination of identity and location that is privacy-sensitive (but  
may disagree whether taking location from a LO is privacy-sensitive).  
Thus, by logic, this must be true for the identity part as well, as  
they are co-equal parts of this information. Thus, when a proxy  
extracts the identity (no location) and asks RADIUS or DIAMETER for  
authorization, this would also imply a retransmission and thus be  
disallowed.

I note that you keep avoiding addressing the actual consequences of  
doing what you propose, given that almost all location-based calls  
would fail without setting the flag to yes. This differs from the  
'retransmission' flag, in that the whole point was that the desired  
recipient could do what they needed, but no more, even if the flag  
was set to 'no'.

I have repeatedly proposed a solution; please consult the archives  
for details.

Henning

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

> I consulted with corporate counsel, and he observed that RFC 4119  
> says that if retransmission-allowed=no, then that indicates that  
> the user doesn't want the recipient to retransmit either the LO  
> (with identifiers) or the LI (without).  This seems to me very  
> explicit, very common-sense.
>
> So Marc/Henning: Either

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 4 May 2007 13:52:55 -0400

> What makes the LO 'its location'.
Who is lawyering now?  The point of the exercise is to route the call based
on the location of the device.  When the proxy sends the LI (not the LO) to
LoST, it knows it's the location of a device (it has the LO).  The LoST
server may not know what it is, of course.

> Not if you remove the pieces that makes the LO 'its location'.
Yes it is, it's the LI of the device.  That is the definition of LI, LO
without identification.  The proxy knows it is doing this.

> Agree if the proxy server were to include device/entity identifiers in the
But that is not what 4119 says.  It says LI or LO.  It is quite specific
about it.  I can understand arguing to change that language.  I don't
understand arguing that it doesn't apply.

> What makes a LO a PIDF-LO?
Adherence to 4119

> Why is a LoST query/response not covered by 4119?
Isn't this something roughly like removing the author's name and copyright
on a document, and then publishing it?   

Once you remove the identity AND THE RULESET from a PIDF-LO, you can do
anything you want with it, isn't that what you are saying?

I do understand the point you are making: without identity (and ruleset) a
location is not private, it's just like having a map and finding a place on
the map.  I don't think you can so easily say if I remove the identity and
ruleset from a location I can do anything I want with it.

Let me cite an example.  Suppose the LI had interior room information in it,
information not generally known by the public.  Do you attach ANY privacy
concerns to that?  Your argument is no, once I take the identity and ruleset
out, I can treat it as completely public information.  I think that is
wrong.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 04 May 2007 13:53:31 -0400

This seems to be grinding to a conclusion. To help it along, I have an use case 
that resolves Henning's practical conundrum. Henning argued that disallowing 
routing on location would cause calls to fail. But what if the user device did 
the LoST query, then added location for dispatch purposes? There would be no 
need for intermediate entities to route on location and the call would go 
through properly.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 4 May 2007 13:58:22 -0400

If somebody sent you an email saying "Hi, this this your friend Bob.  
I'm enjoying my vacation in St. Tropez, but please don't tell anyone  
that I'm here", would you consider it retransmission if you went to  
Expedia to now also find plane tickets to St. Tropez? Are you allowed  
to look up St. Tropez in Wikipedia after receiving the email?

We never discussed these location-only issues in the context of 4119,  
so I find it unhelpful to over-interpret these words. We can all  
become constitutional lawyers divining the penumbra of emanations, or  
we can try to solve actual privacy problems using common-sense  
expectations that actually improve user privacy, e.g., by stipulating  
the use of cryptographic methods.

Henning

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 4 May 2007 13:58:12 -0400

> I consulted with corporate counsel, and he observed that RFC 
> 4119 says that if retransmission-allowed=no, then that 
> indicates that the user doesn't want the recipient to 
> retransmit either the LO (with
> identifiers) or the LI (without).  This seems to me very 

I guess I disagree with 'corporate counsel'.

You've yet to answer my question, when is a LO not equal to a PIDF-LO such
that it doesn't fall under GeoPriv requirements?  Or are you stating that
for the purposes of IETF protocols, all location descriptions fall under
GeoPriv requirements regardless if device/entity are identified?

So a location validation within the current LoST would return nothing or
error?  How is the planned access provider LIS going to validate locations
prior to passing them onto the broadband subscriber?  Contact the broadband
customer and get permission to validate 'their' location?

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 4 May 2007 14:03:26 -0400

Clearly, that is the preferred architecture. No lookup, no issues, no  
needs for interpretation of flags. Unfortunately, at least in the  
emergency services architecture that Brian and NENA have been  
drafting, the expectation seems to be that every single (most?)  
emergency call would get a second look-up when reaching the emergency  
services network, using a more detailed version of the LoST database.

Henning

On May 4, 2007, at 1:53 PM, Tom-PT Taylor wrote:

> This seems to be grinding to a conclusion. To help it along, I have  
> an use case that resolves Henning's practical conundrum. Henning  
> argued that disallowing routing on location would cause calls to  
> fail. But what if the user device did the LoST query, then added  
> location for dispatch purposes? There would be no need for  
> intermediate entities to route on location and the call would go  
> through properly.
>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 04 May 2007 14:31:24 -0400

> Let's try logic again. ... Thus, when a proxy extracts the identity (no
> location) and asks RADIUS or DIAMETER for authorization, this would also 
> imply a retransmission and thus be disallowed.

This isn't addressed by 4119 since it's not location, but you're correct 
to observe that identity without location is sensitive in much the same 
way as location without identity.  I imagine that certain 
law-enforcement agencies would be very interested if the VSPs would let 
them know whenever callers with certain identities use an LBS (i.e., 
send a LO).

> doing what you propose, given that almost all location-based calls would 
> fail without setting the flag to yes.   This differs from the
> recipient could do what they needed, but no more, even if the flag was 
> set to 'no'.

If this was the intent, it is not what was recorded in RFC 4119.  I'm 
not saying that its correct or incorrect, just that the standard would 
have to be changed.  I'm curious what language you would use that would 
capture "do what they needed, but no more".

> I have repeatedly proposed a solution; please consult the archives for 
> details.

I'm sorry, nothing in the archive jumps out at me as a concrete 
proposal.  Could I request a retransmission?

--Richard

>> identifiers) or the LI (without).  This seems to me very explicit, 
>> very common-sense.
>>
>> So Marc/Henning: Either

---

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

Okay, so tell me, when 4119 talks about LI or LO in the context of
retransmission allowed, what LI was it talking about?

Again, I can deal with a request to normatively change 4119 to remove the LI
part.  I don't agree with such a change, but it makes sense to me.

It doesn't make sense to say that 4119 doesn't apply, or the words don't
mean what I think they mean.

The LO has a ruleset that specifies what the recipient can do with the
location.  To me, that means LI, not just LO.  As with anything else, if you
sufficiently obscure the location (like just take the country code), then
the rulemaker may not care, so your example may be moot.

To supply a counter-example, can the car service who drives Christina
Aguilera around post the street addresses of every location it has picked up
or dropped off at in the last year on its website in real time?  Can it post
the apartment numbers?  No identifiers, mind you - just the LI.

Brian
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, May 04, 2007 1:58 PM
> To: Brian Rosen
> Cc: 'Marc Linsner'; 'Richard Barnes'; 'GEOPRIV'
> Subject: Re: [Geopriv] Location in SIP and "retransmission-allowed"
>

---

From: Ted Hardie <[email-masked]>
Date: Fri, 4 May 2007 11:56:21 -0700

>server may not know what it is, of course.

I'm hoping that this simple statement by Brian will help clear this all up.
Brian is point out that the *SIP Proxy* has both the LI and the recipient
information and is acting on it (by extracting it and routing based on it).

Marc and Henning have been arguing that what the *LoST Server*
gets is not privacy sensitive because it does not have both the identity
and the location.

But the point is that it is reasonable for a sender to expect that only
the end recipient of his SIP message was going to get and use the
location if "retransmission=no".  If the Proxy does location routing without
explicit permission, it is breaking that expectation.  To fix that
we need to 1) change that expectation 2) provide a semantic
that allows for routing based on location 3) recommend that
retransmission be set to "yes".  This isn't because of anything that
the *LoST Server* does or has access to; it is because of the actions
of the SIP Proxy, which does have the privacy sensitive tie between
the location and the identity to contend with.  I tried to make that
point in a previous message to Henning, where I argued that it did
not much matter whether the SIP Proxy used LoST or something
else to resolve the routing *if it used the embedded location, the
same privacy issue applied*.

I argue that the right thing to do here is 2, but I continue to believe
that we have not all been talking about the same question.  Hopefully
Brian's message above will help us get at least to that point.
			regards,
				Ted

---

From: Richard Barnes <[email-masked]>
Date: Fri, 04 May 2007 15:02:59 -0400

> retransmission be set to "yes".  
>...
> I argue that the right thing to do here is 2

I think that's right, with the addendum that we should also recommend 
that that indicator be set to "yes" when location is used in SIP, 
especially to make an emergency call.

--Richard

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 4 May 2007 18:11:25 -0400

Ted, 

> 
> But the point is that it is reasonable for a sender to expect 
> that only the end recipient of his SIP message was going to 
> get and use the location if "retransmission=no".

Doesn't it seem odd that in we're going to require the UA to include their
location with the sip invite to urn:service:sos and then ask them to include
permission so we can use the required location info for routing?  Isn't that
implied when the UA builds the urn:service:sos invite?

-Marc-

---

From: Ted Hardie <[email-masked]>
Date: Fri, 4 May 2007 16:30:49 -0700

>implied when the UA builds the urn:service:sos invite?

Howdy,

First, please don't base this all on emergency services, which have special
circumstances.

If I read draft-ietf-sip-location-conveyance right, it is covering both cases
where SIP sends location from one SIP entity to another and cases where
location-based routing will occur.  Having "rentransmission=routing-permitted"
and "retransmission=no" as distinct values allows the end user to say
whether a specific message should be treated according to case one or case
two. 

Basically, it is cleaner if we don't try to figure what is implied when
a UA builds their message for [email-masked], but let them
specify it instead.  We've already agreed to trace this (adding the
message-routed-on-this-URI parameter), but that doesn't give the
user any control.  To give the user that control, we have to distinguish
between the case where something is intended for the end recipient *only*
and the case where something may be used to the route the call.

			regards,
				Ted

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 4 May 2007 20:45:44 -0500

Wow - this has been really entertaining.

A lot of the argument has been about whether it's sensible to interpret
4119 the way that many say is quite unambiguous in its intent. This, at
the very least, indicates that there is good scope for
confusion/misinterpretation regardless of which interpretation you'd
like to choose.

I think there's consistency in the view from people who think 4119
forbids, for example, a LoST lookup when retransmission is set to "no"
that this isn't necessarily a reasonable constraint. They just feel that
the wording as it stands currently strictly forbids it. That is, they
are open to a rewording of some sort.

For those that object to the strict interpretation altogether, do you
actually have any serious objection to clarifying and/or modifying the
specification as it's written? It may deprive future generations of the
same entertaining debate - but I'm sure they'll find equally fertile
ground elsewhere.

One possibility is to just change the definition of retransmission such
that it does mean with inclusion of identity. Another may be to say that
retransmission may be subject to policy - for example if it's used for
emergency services. Then, at least, the argument can be about what the
right thing to do is - rather than what the spec is actually saying.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Saturday, 5 May 2007 4:52 AM
To: 'Henning Schulzrinne'
Cc: 'GEOPRIV'; 'Marc Linsner'
Subject: RE: [Geopriv] Location in SIP and "retransmission-allowed"

Again, I can deal with a request to normatively change 4119 to remove
the LI
part.  I don't agree with such a change, but it makes sense to me.

The LO has a ruleset that specifies what the recipient can do with the
location.  To me, that means LI, not just LO.  As with anything else, if
you
sufficiently obscure the location (like just take the country code),
then
the rulemaker may not care, so your example may be moot.

To supply a counter-example, can the car service who drives Christina
Aguilera around post the street addresses of every location it has
picked up
or dropped off at in the last year on its website in real time?  Can it
post
the apartment numbers?  No identifiers, mind you - just the LI.

Brian

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 6 May 2007 19:45:33 -0400

> proposal.  Could I request a retransmission?

Let me try to be more specific, collecting thoughts across multiple  
postings:

The goals are two-fold:

- achieve logical consistency that doesn't make artificial distinctions

- create predictable behavior that users can understand

We have agreed that no-forward does not affect the proxying of  
location information by SIP proxies. There is no logical distinction  
between routing SIP messages and copying a subset of the information  
to some other protocol, from a privacy perspective. Bits are bits,  
whether they are in XML or SIP bodies. Thus, even if we ignore the  
privacy difference between identity-less location and LOs, there are  
two possible logically consistent rules:

(1) Use of location information for call routing and proxying are  
allowed if the information remains within the administrative control  
of the domain named in the SIP request URI, as long as the  
information flow is protected to the same extent as the SIP  
signaling. (Thus, a SIPS call requires use of HTTPS for LoST.)

This covers the emergency calling and PizzaHut case since the LoST  
hierarchy is operated by the same administrative entity (government  
or PizzaHut) that is addressed by the request URI and avoids the  
silliness that the PSAP can see the location and identity if it  
arrives via SIP, but can't see the location only if it were to arrive  
at the LoST server it operates.

Thus, retargeting to a different administrative domain or lookups  
outside that destination domain require explicit permission.

A slightly more liberal interpretation is

(2) No explicit permission is needed when the operator of the SIP  
proxy ensures that the data used for lookups remains private, even if  
the data is handed to a third party (such as a governmental LoST  
hierarchy).

The only other logically consistent rule is to disallow SIP proxying  
and location lookups unless a flag is specified, but since such a  
flag would need to be specified in almost all cases of practical  
interest, this becomes essentially meaningless.

Henning

---

From: Ted Hardie <[email-masked]>
Date: Mon, 7 May 2007 12:04:45 -0700

At 7:45 PM -0400 5/6/07, Henning Schulzrinne wrote:
>>I'm sorry, nothing in the archive jumps out at me as a concrete proposal.  Could I request a retransmission?
>>
>
>Let me try to be more specific, collecting thoughts across multiple postings:
>
>The goals are two-fold:
>
>We have agreed that no-forward does not affect the proxying of location information by SIP proxies. There is no logical distinction between routing SIP messages and copying a subset of the information to some other protocol, from a privacy perspective. Bits are bits, whether they are in XML or SIP bodies. Thus, even if we ignore the privacy difference between identity-less location and LOs, there are two possible logically consistent rules:

This isn't how all of us see this, Henning.

Imagine for a moment that we had created two headers:  Routing-location:  and Recipient-location:  .  We might have done that in order to allow the routing location
to be at a different level of precision than the location sent to a recipient, or to
disambiguate the two cases in the current location conveyance document
(intended for the end user  and location-based-routing).  If we had, the presence
of a Routing-location:  header certainly would be sufficient indication that the
message sender was willing to have the message routed using location. 
It would be stating, in essence, that the SIP proxy engaged in the location-based
routing was the intended recipient. The absence of that header might also be
sufficient to say that the proxy should not do so, as delving into a
"recipient-location:" header for data when there would be another place for
routing location to go would be more clearly reading a location object
intended for a different recipient. 

That's not the current proposal, which uses the same header for two different use
cases.  Since those use cases involve different intended recipients (the end recipient
and the SIP proxy which might do location-based routing), there is some ambiguity.
Using an explicit parameter for routing location gets us to the state where the
permissions can be disambiguated without having to have two headers. 
Having two headers would do that too, but  it's yet more stuff to carry around.

As you know by now,  some of us do believe that there is an important distinction
between using standard SIP mechanisms to carry the location to an end-user
(case one, for which retransmission=no seems to work for everyone,
since the SIP proxy is just acting to forward the message) and examining the
header and managing the routing based on it (case two, for which some of us
have argued an explicit retransmission="routing-permitted" would be valuable).
Allowing "retransmission=no" to allow location-based routing via whatever
means eliminates the user's ability to distinguish between those and weakens,
at least in my opinion, the user's control over location.

					Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 8 May 2007 16:08:23 -0400

On May 7, 2007, at 3:04 PM, Ted Hardie wrote:

>> location information by SIP proxies. There is no logical  
>> distinction between routing SIP messages and copying a subset of  
>> the information to some other protocol, from a privacy  
>> perspective. Bits are bits, whether they are in XML or SIP bodies.  
>> Thus, even if we ignore the privacy difference between identity- 
>> less location and LOs, there are two possible logically consistent  
>> rules:
>

Which part of the above are you disagreeing with?

> Imagine for a moment that we had created two headers:  Routing- 
> location:  and Recipient-location:  .  We might have done that in  
> order to allow the routing location

I'll refer you back to my 'recipient' discussion. I think we need to  
be more precise when we are talking about recipients, as they are at  
least two types, logical and physical, or, if you like to divide it  
further L3, L7 and L8. L8 is the organizational layer.

For privacy, we seem to have agreed that L3 is not "forwarding",  
although it clearly is not distinguishable purely from a bits-on-the- 
wire perspective. (In all cases, location goes in one interface and  
pops out another [logical] interface.)

L7 is less clear. In IMS, is proxying between my access/roaming  
provider and the destination provider (neither of whom I'm addressing  
directly) retransmission?

I suspect we also agree that a L8 transition has possible privacy  
implications.

> Having two headers would do that too, but  it's yet more stuff to  

As I've tried to point out, the distinction is wholly artificial from  
a privacy perspective and, in almost all cases of practical interest,  
the end user will have to grant routing permission, or, conversely,  
should encrypt it from prying eyes.

That said, I think a use-this-for-routing tag might actually be  
useful for a slightly different reason, based on the multiple- 
location case you mention. The reason it needs to be a header is  
simple, namely location by reference. You really don't want the proxy  
to attempt to resolve a reference and then find that the answer is  
"sorry, not for you". That just adds delay and complexity.

> at least in my opinion, the user's control over location.

Except for the multiple-location case mentioned, I have yet to see  
where this matters in any practical case. As I've said numerous  
times, having a flag where the choices are "no = failure" or "yes =  
no additional privacy" just doesn't seem particularly valuable.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 May 2007 13:36:35 -0700

At 4:08 PM -0400 5/8/07, Henning Schulzrinne wrote:
>As I've tried to point out, the distinction is wholly artificial from a privacy perspective and, in almost all cases of practical interest, the end user will have to grant routing permission, or, conversely, should encrypt it from prying eyes.

And here's the crux of the disagreement; you believe that this distinction
doesn't matter, but I believe (and I think at least Richard believes) that it does.
I also think that it makes a predication about future use cases that is not
justified or justifiable.

>That said, I think a use-this-for-routing tag might actually be useful for a slightly different reason, based on the multiple-location case you mention. The reason it needs to be a header is simple, namely location by reference. You really don't want the proxy to attempt to resolve a reference and then find that the answer is "sorry, not for you". That just adds delay and complexity.
>

If splitting the current header into two headers can get us to group consensus, I'm
all for it.  As I said in my previous message, there are cases where you might give
different locations to the routing infrastructure and the end user so there are additional
justifications here. 

To be clear this would eliminate "routing-query-allowed", add a header and update
at least this language:

 A proxy MAY read the Geolocation header, and the associated body, if
   not S/MIME protected, in transit if present, and MAY use the
   contents of the header to make location-based routing decisions. 

to something like:

 A proxy MAY read the Routing-location header and the associated body and
 MAY use the contents of the header to make location-based routing decisions. 
 A proxy SHOULD NOT read the Recipient-location header and its associated body
 for the purpose of making location-based routing decisions.

We would also need to add advice for proxies adding location (for which header
to add it to).

It's a non-trivial change, but that path forward works, at least in my opinion.

How do other folks feel about making a change like this?

					Ted

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 08 May 2007 17:22:05 -0400

I'm actually a little concerned about the implications for a PSAP. Typically a 
PSAP may hand off an emergency to a specific service: fire, police, or whatever. 
The PSAP has to hand off the location too, or how will dispatch happen? This is 
definitely at the application level.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 May 2007 14:28:52 -0700

At 5:22 PM -0400 5/8/07, Tom-PT Taylor wrote:
>I'm actually a little concerned about the implications for a PSAP. Typically a PSAP may hand off an emergency to a specific service: fire, police, or whatever. The PSAP has to hand off the location too, or how will dispatch happen? This is definitely at the application level.

Tom,
	We've agreed long since  that emergency services are a special
case.  That's why I put "SHOULD NOT" in the replacement text below.  What
a PSAP should do doesn't belong in the SIP location conveyance document
at this point (they've punted that whole discussion to ECRIT).
	Have you any comments that don't relate to that special case?

				Ted

>> MAY use the contents of the header to make location-based routing decisions.  A proxy SHOULD NOT read the Recipient-location header and its associated body

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 8 May 2007 17:38:11 -0400

Again, the problem is that looking at this at the SIP layer yields  
strange results: Even if we ignore emergency services, if I say "no  
retransmission" when calling PizzaHut, does this mean the dispatcher  
can't tell the delivery driver where to deliver my pizza? Or AAA  
can't tell the tow truck driver where to fix my flat tire? Does it  
matter whether the tow truck company uses Skype or XMPP instead of SIP?

Since these are not crypto mechanisms but rather rely on the  
cooperation of all parties, having semantics that actually make some  
common sense would seem to be helpful. If the user inserting the flag  
(and totally clueless about protocols) can't predict who will or will  
not get information or why a call would fail, the whole exercise  
seems kind of pointless from a privacy perspective. It just becomes  
one of these click-to-stop-annoying-me check-off boxes.

Henning

On May 8, 2007, at 5:22 PM, Tom-PT Taylor wrote:

> I'm actually a little concerned about the implications for a PSAP.  
> Typically a PSAP may hand off an emergency to a specific service:  
> fire, police, or whatever. The PSAP has to hand off the location  
> too, or how will dispatch happen? This is definitely at the  
> application level.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 May 2007 14:56:53 -0700

At 5:38 PM -0400 5/8/07, Henning Schulzrinne wrote:
>Again, the problem is that looking at this at the SIP layer yields strange results: Even if we ignore emergency services, if I say "no retransmission" when calling PizzaHut, does this mean the dispatcher can't tell the delivery driver where to deliver my pizza? Or AAA can't tell the tow truck driver where to fix my flat tire? Does it matter whether the tow truck company uses Skype or XMPP instead of SIP?

>Since these are not crypto mechanisms but rather rely on the cooperation of all parties, having semantics that actually make some common sense would seem to be helpful. If the user inserting the flag (and totally clueless about protocols) can't predict who will or will not get information or why a call would fail, the whole exercise seems kind of pointless from a privacy perspective. It just becomes one of these click-to-stop-annoying-me check-off boxes.

I think having it split actually helps that.  The end user can click (or not click)
a box that says "send location to service provider" after clicking (or not clicking)
a separate box that says "use location to route call to a service provider",
and they can select whether to send geo or civic to each one and at what level of
detail.  The semantics are clear there, and they don't depend on the protocol
used by the systems underneath.  Yes, there may be folks who just
click every box, and that's fine.  The point is that it remains under their
control to do so or to make other choices.  And just to close this off before
it starts, yes I believe that UIs can be constructed to manage this and that
default values will work here.  If the intended recipient of a Routing-location:
header is the set of proxies that might do location-based routing, then the
presence of a location in that header gives them all the permissions they
need to do that job.
				Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 8 May 2007 21:27:56 -0400

This does not address my question at all. First, I'm not sure what  
you define as "service provider". If 'service provider' is the pizza  
deliverer as opposed to the call center, this is not too helpful,  
since almost all location-based calls will require the release of  
information to them to be useful.

In almost all cases, the user wants the pizza deliverer to have the  
location information. However, they don't want the location  
information to be passed on to the "affiliates" that deliver singing  
birthday greetings. If you require a flag for just getting the  
service you call for, people will always have to check the flag, thus  
removing their ability to withhold information from third parties.  
Thus, the flag becomes useless as a privacy tool.

As you keep not addressing, the two are not orthogonal. In the LBS  
examples, the call won't get to the service provider if there's no  
routing. (If there's no routing necessary, there's no need for the  
flag, either.) You seem to imply that there's some kind of magic how  
the call can reach the right service provider.

I have to admit that seeing that UI, I would have no idea what  
'service provider' means. I'd probably think of my ISP...

This is why I'm proposing that forwarding only covers release to  
third parties, i.e., those not affiliated with the service requested.  
That's the concept that's in every privacy policy that I've seen, and  
a concept that lawyers and consumers seem to understand.

If we want to have a protocol, we need to have precise semantics for  
propagation. So far, I have not seen a usable definition that is  
actually privacy-relevant as opposed to making arbitrary distinctions  
that have no privacy implications (such as which protocol is being  
used).

Henning

On May 8, 2007, at 5:56 PM, Ted Hardie wrote:

>> strange results: Even if we ignore emergency services, if I say  
>> "no retransmission" when calling PizzaHut, does this mean the  
>> dispatcher can't tell the delivery driver where to deliver my  
>> pizza? Or AAA can't tell the tow truck driver where to fix my flat  
>> tire? Does it matter whether the tow truck company uses Skype or  
>> XMPP instead of SIP?
>
>
>
>> cooperation of all parties, having semantics that actually make  
>> some common sense would seem to be helpful. If the user inserting  
>> the flag (and totally clueless about protocols) can't predict who  
>> will or will not get information or why a call would fail, the  
>> whole exercise seems kind of pointless from a privacy perspective.  
>> It just becomes one of these click-to-stop-annoying-me check-off  
>> boxes.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 8 May 2007 21:35:08 -0400

> justified or justifiable.

Nobody can predict the future, but engineering based on something  
that we can't define and have no current use cases seems like a  
strange way to define a protocol where we expect to have  
interoperable and predictable implementations. The likelihood that  
we'll get it right in that case is pretty slim.

>> simple, namely location by reference. You really don't want the  
>> proxy to attempt to resolve a reference and then find that the  
>> answer is "sorry, not for you". That just adds delay and complexity.
>>
>

My general pet peeve is that no document should have a SHOULD without  
defining when the condition is not met. How would an implementor know?

In general, there are also two error cases to consider:

- What if there's no ;route indicator? Does the call have to fail in  
all circumstances?

We'll probably disagree on this score.

- What if there are two or more?

I'm guessing the proxy gets to pick.

> We would also need to add advice for proxies adding location (for  

These aren't really different headers. I'm guessing what you mean is  
something like this:

Geolocation: cid:something ;route, http://foo.bar

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 May 2007 21:40:35 -0700

At 9:27 PM -0400 5/8/07, Henning Schulzrinne wrote:
>This does not address my question at all. First, I'm not sure what you define as "service provider". If 'service provider' is the pizza deliverer as opposed to the call center, this is not too helpful, since almost all location-based calls will require the release of in
>formation to them to be useful.

Stop.  Read the following sentence carefully:

As currently described, not all calls which will contain the Geolocation header
will route based  on it.

Do you agree with this?
					Ted

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 May 2007 21:47:24 -0700

At 9:35 PM -0400 5/8/07, Henning Schulzrinne wrote:
>Nobody can predict the future, but engineering based on something that we can't define and have no current use cases seems like a strange way to define a protocol where we expect to have interoperable and predictable implementations. The likelihood that we'll get it right in that case is pretty slim.

Henning, the fact that you don't believe in the use cases I've put forward is fine.
People are bound to disagree.  But you are predicting the future by saying that
there never will be a case where it is important for the end user to pass location
to the end recipient with this header but disallow routing based on it.

That's a reach.  Engineering to allow for it now is trivial; preventing it now and
re-introducing later is a pita.

>My general pet peeve is that no document should have a SHOULD without defining when the condition is not met. How would an implementor know?

I was thinking only emergency service got to ignore the SHOULD, but if you want
to make it MUST and let emergency services violate that, I'm fine with that too.

>
>These aren't really different headers. I'm guessing what you mean is something like this:
>

No, I really meant separating it into two different headers.  You could
do it with two Geolocation headers and an indicator of which use case
it is for; frankly, that's a syntax choice about which I don't care a lot.
The semantic of separating the two use cases is what I assumed was
moving us forward.

>>How do other folks feel about making a change like this?

Again, can I ask other folks to chime in here?  Anyone else have strong
views on this path forward?
				Ted

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 9 May 2007 00:46:45 -0500

*Ding Dong*

I will chime in to the effect that I think the wording in 4119 is very
clear on this and that I side with Richard and Ted.

On how we solve it I don't have that strong opinion on whether we change
4119 (I think that 4119 could use some other changes too), or we
introduce a new header I am agnostic. But I don't think that the current
wording in 4119 allows querying of a LoST server by a proxy.

Cheers
James

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Wednesday, 9 May 2007 2:47 PM
> To: Henning Schulzrinne
> Cc: 'GEOPRIV'; Marc Linsner
> >>doesn't matter, but I believe (and I think at least Richard
believes)
> that it does.
> >>I also think that it makes a predication about future use cases that
is
> not
that we
> can't define and have no current use cases seems like a strange way to
> define a protocol where we expect to have interoperable and
predictable
> implementations. The likelihood that we'll get it right in that case
is
> pretty slim.
> 
> Henning, the fact that you don't believe in the use cases I've put
forward
> is fine.
> People are bound to disagree.  But you are predicting the future by
saying
> that
> there never will be a case where it is important for the end user to
pass
> location
> That's a reach.  Engineering to allow for it now is trivial;
preventing it
> now and
> >> A proxy MAY read the Routing-location header and the associated
body
> and
> I was thinking only emergency service got to ignore the SHOULD, but if
you
> want
> >>It's a non-trivial change, but that path forward works, at least in
my
> opinion.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 9 May 2007 08:06:14 -0400

I don't care if the new draft 'updates' 4119, given that 4119 is  
hardly a model of clarity. I care that we not get stuck into  
inventing useless headers, although this seems to be a losing battle.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 9 May 2007 08:48:13 -0400

On May 9, 2007, at 12:40 AM, Ted Hardie wrote:

>> you define as "service provider". If 'service provider' is the  
>> pizza deliverer as opposed to the call center, this is not too  
>> helpful, since almost all location-based calls will require the  
>> release of in

That's certainly correct, but in those cases, a header or declaration  
of any sort is unnecessary.

The issue you keep missing is that of choice. I believe and have  
tried to demonstrate that there are two cases of practical interest:

(1) The URI is a normal SIP destination, which performs no routing.  
No flag of any sort is needed since no proxy is trying to use any  
location information for anything.

(2) The URI is either a service URN or another URI that needs further  
routing. In that case, any flag is useless since the call will fail  
without it. Thus, the flag or indication offers no additional  
privacy, unless you consider call failure privacy.

Let me turn the question around, maybe to clarify your intent:

Do you want an indication that says, basically, "If you want to do  
location-based call routing, please fail the call instead"?

The reason that do-not-distribute is somewhat useful is that the  
assumption was that 'normal' services are possible without it, and  
only 'extra' (but privacy-infringing) services are prevented by  
having it be set to 'no'. This is in line with standard privacy  
policy practices.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 9 May 2007 08:53:55 -0400

On May 9, 2007, at 12:47 AM, Ted Hardie wrote:

> forward is fine.
> saying that
> preventing it now and

I thought the burden of proof for introducing new features is on the  
person introducing those, not the other way around.

I'm sure to cite your argument next time I want a protocol element...

> to make it MUST and let emergency services violate that, I'm fine  

My general complaint is that any document that has a SHOULD must  
qualify that document with a sentence that says something like

An implementation SHOULD do something or other unless [state concrete  
condition that is the exception].

> The semantic of separating the two use cases is what I assumed was

The problem with two fields is that this makes things more  
complicated for the common case that there is one location element  
that is used for both routing and the use of end systems. You'd have  
to have two header fields, for no good reason.

Henning

---

From: Richard Barnes <[email-masked]>
Date: Wed, 09 May 2007 10:42:19 -0400

Henning,

I agree that it's simpler to tag individual locations within a 
Geolocation header, although I would do it a little differently (echoing 
inserted-by),

Geolocation: <cid:[email-masked]>;recipient=server, 
<sip:[email-masked]>;recipient=endpoint

... with the stipulation that if it's marked for one recipient, then the 
other SHOULD NOT read/use it.

1. What is the concrete exception to the SHOULD?
I can't think of any outside the emergency case.  Perhaps it should be a 
MUST, to be overridden by phonebcp (or any other application-specific 
documents).

2. What if there's no ;route (;recipient=server) indicator?
This could be handled as the routing-query-allowed value is handled in 
location-conveyance: If it's not present, then then the value of the 
retransmission-allowed element takes over (and that's default-deny if 
not present).  However, I could probably also be persuaded that 
inclusion in a Geolocation header indicates consent, unless 
de-authorized by ;recipient=endpoint.

3. What if there are two or more?
Yeah, like you say, proxy can pick.  As with other multiple-location 
issues, we probably want to say "don't put this in".  And if we say that 
no tag means consent, then tagged might be preferred over not-tagged.

In any case, these approaches seem appealing because they uses SIP 
markings (headers, URI parameters) for SIP semantics (routing 
permission).  However, by using information in headers, you potentially 
expose it to messing around by proxies.  So you would need to say that a 
proxy MUST NOT modify the value of any existing "recipient" parameter, 
or its presence or absence on any given URI.

With that caveat, though, this seems like a decent compromise.

--Richard

Henning Schulzrinne wrote:
>>> since almost all location-based calls will require the release of in
> That's certainly correct, but in those cases, a header or declaration of 
> any sort is unnecessary.
> 
> The issue you keep missing is that of choice. I believe and have tried 
> to demonstrate that there are two cases of practical interest:
> 
> (1) The URI is a normal SIP destination, which performs no routing. No 
> flag of any sort is needed since no proxy is trying to use any location 
> information for anything.
> 
> without it. Thus, the flag or indication offers no additional privacy, 
> unless you consider call failure privacy.
> 
> 
> assumption was that 'normal' services are possible without it, and only 
> 'extra' (but privacy-infringing) services are prevented by having it be 
> set to 'no'. This is in line with standard privacy policy practices.
> 
> 
> 
> 
> 
>>                     Ted   
> 
>

---

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

> information for anything.

That's not necessarily true.  As you've said before, the standard way 
for a proxy to verify that the R-URI is a PSAP is to use the location in 
a LoST query.  You can imagine similar situations for non-emergency cases.

> unless you consider call failure privacy.

In this case, the UAC has explicitly contradicted itself: It has asked 
for location-based routing, when it is not willing to allow its location 
to be used in that way.  It makes sense for such a request to fail 
(e.g., with a 485/Ambiguous or a new 48X/Privacy-restricted).

This is the correct behavior in non-emergency cases (such as Ted's use 
case), since the user has asked for his location not to be passed 
outside the signaling path, as LoST would cause it to be.  The UAC can 
always retry with different privacy settings.

--Richard

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 9 May 2007 11:30:28 -0400

On May 9, 2007, at 11:06 AM, Richard Barnes wrote:

>> (1) The URI is a normal SIP destination, which performs no  
>> routing. No flag of any sort is needed since no proxy is trying to  
>> use any location information for anything.
>
> That's not necessarily true.  As you've said before, the standard  
> way for a proxy to verify that the R-URI is a PSAP is to use the  
> location in a LoST query.  You can imagine similar situations for  
> non-emergency cases.

Interesting example. You just provided a very good toll bypass  
mechanism: Mark an emergency call as 'don't lookup location', but the  
URL is [email-masked].  What, other than failing the call, do  
you expect the VSP to do in that case?

>
>> (2) The URI is either a service URN or another URI that needs  
>> further routing. In that case, any flag is useless since the call  
>> will fail without it. Thus, the flag or indication offers no  
>> additional privacy, unless you consider call failure privacy.
>
> In this case, the UAC has explicitly contradicted itself: It has  
> asked for location-based routing, when it is not willing to allow  
> its location to be used in that way.  It makes sense for such a  
> request to fail (e.g., with a 485/Ambiguous or a new 48X/Privacy- 
> restricted).
>
> This is the correct behavior in non-emergency cases (such as Ted's  
> use case), since the user has asked for his location not to be  
> passed outside the signaling path, as LoST would cause it to be.   
> The UAC can always retry with different privacy settings.

This kind of works. I just fail to see the practical privacy  
advantage of that. You have yet to identify a case where a call  
succeeds and the privacy is improved by this mechanism.

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 9 May 2007 13:35:01 -0400

On May 9, 2007, at 10:42 AM, Richard Barnes wrote:

> Geolocation header, although I would do it a little differently  
> (echoing inserted-by),
>
> ... with the stipulation that if it's marked for one recipient,  
> then the other SHOULD NOT read/use it.

That seems longer (bad for mobile systems) and has the disadvantage I  
mentioned earlier: for the common case of one location, there will be  
two URLs, both the same. This would yield

Geolocation: uri  --> single URI, use for end system
Geolocation: uri;routable -> routing or end system
Geolocation: uri1;routable, uri2 -> uri1 for routing (and end  
system), uri2 for end system

> I can't think of any outside the emergency case.  Perhaps it should  
> be a MUST, to be overridden by phonebcp (or any other application- 
> specific documents).
>

Since it's a normative change, then the phone-bcp would have to be an  
'Update for RFC LocationConveyance'. Seems a bit strange, but  
obviously can be done. (You can't just say MUST and then have random  
unidentified documents make changes in normative language.)

> This could be handled as the routing-query-allowed value is handled  
> in location-conveyance: If it's not present, then then the value of  
> the retransmission-allowed element takes over (and that's default- 
> deny if not present).  However, I could probably also be persuaded  
> that inclusion in a Geolocation header indicates consent, unless de- 
> authorized by ;recipient=endpoint.

In general, it seems to make sense to have the common option be the  
shorter one. SIP messages are already more than long enough.

> Yeah, like you say, proxy can pick.  As with other multiple- 
> location issues, we probably want to say "don't put this in".  And  
> if we say that no tag means consent, then tagged might be preferred  
> over not-tagged.
>
> permission).  However, by using information in headers, you  
> potentially expose it to messing around by proxies.  So you would  
> need to say that a proxy MUST NOT modify the value of any existing  
> "recipient" parameter, or its presence or absence on any given URI.

Evil proxies will presumably happily ignore the don't-touch-that-body  
prohibition.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 9 May 2007 13:31:36 -0700

At 8:48 AM -0400 5/9/07, Henning Schulzrinne wrote:
>That's certainly correct, but in those cases, a header or declaration of any sort is unnecessary.

Do you think that the header is unnecessary in that case?  So you don't see any
use cases where the Geolocation header will be used to provide the location
only to the end recipient?

>The issue you keep missing is that of choice. I believe and have tried to demonstrate that there are two cases of practical interest:
>
>(1) The URI is a normal SIP destination, which performs no routing. No flag of any sort is needed since no proxy is trying to use any location information for anything.
>
>(2) The URI is either a service URN or another URI that needs further routing. In that case, any flag is useless since the call will fail without it. Thus, the flag or indication offers no additional privacy, unless you consider call failure privacy.
>

Any flag which says "no" will cause it to fail.  A  "yes" or "routing-permitted" would
allow it to go through. 

>Do you want an indication that says, basically, "If you want to do location-based call routing, please fail the call instead"?

More or less.  I want it to say "The location provided here is for the end recipient; if
you want to do location-based call routing, please fail the call."  The user can then
decided if they want to relax the privacy constraints and allow it, or not.

				Ted

---

From: Ted Hardie <[email-masked]>
Date: Wed, 9 May 2007 13:34:41 -0700

At 8:53 AM -0400 5/9/07, Henning Schulzrinne wrote:
>I thought the burden of proof for introducing new features is on the person introducing those, not the other way around.
>

And here I thought the burden of proof for someone changing the semantics
of a settled, published RFC was on the person proposing the change. RFC 4119
is clear on the current semantics, Henning.  You're the one arguing for changing
the meaning of "no" in a published doc.  I'm trying to find a way to get the
semantics you need without borking the ones the WG already agreed on.

>The problem with two fields is that this makes things more complicated for the common case that there is one location element that is used for both routing and the use of end systems. You'd have to have two header fields, for no good reason.

As I said, I'm fine with any syntax which gets to the same semantics.
	
					Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 9 May 2007 16:50:14 -0400

> semantics you need without borking the ones the WG already agreed on.

Since we're now into protocol lawyering, I'll play: The text in 4119  
reads

'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.  When the value of this element is 'yes',
       distributing this Location is permitted (barring an existing out-
       of-band agreement or obligation to the contrary).  By default,  
the
       value MUST be assumed to be 'no'.  Implementations MUST include
       this field, with a value of 'no', if the Rule Maker specifies no
       preference.

'parties' is not defined in RFC 4119, as far as I can tell, as the  
word only appears once. The text certainly makes no distinction based  
on protocols, so that forwarding by SIP is ok, but forwarding by  
another protocol is not. RFC 3693 does not define party in any  
technical terms, either.

The IETF boiler plate uses party in an organizational sense ("invites  
any interested party...").

Wikipedia defines

A party is a person or group of persons that compose a single entity  
which can be identified as one for the purposes of the law.

Again, this makes no distinction based on protocols, or even whether  
this is a single individual. In this case, 'party' could just as well  
be a government agency operating a PSAP or PizzaHut.

Thus, I see no textual basis for your statement.

Henning

---

From: Ted Hardie <[email-masked]>
Date: Wed, 9 May 2007 14:17:41 -0700

At 4:50 PM -0400 5/9/07, Henning Schulzrinne wrote:
>Since we're now into protocol lawyering, I'll play: The text in 4119 reads
>
>      of-band agreement or obligation to the contrary).  By default, the
>'parties' is not defined in RFC 4119, as far as I can tell, as the word only appears once.

Your grep missed this in 2.2.4:

    In general cases, the entity that supplied location information is
   communicated by the subjectAltName of the certificate with which the
   location object is signed; thus, this element is unnecessary.
   'Provided-by' is meaningful in particular cases when the creator of a
   location object wants to designate a particular system or party
   within a complex administrative domain, including situations
   envisioned for providing emergency services in a diverse national
   context.  It might assist, for example, the recipient of a malformed
   or misleading location object in identifying the particular system
   that malfunctioned.

and another use in 6.2 where "party" is being used in the sense the boiler plate
uses it.

>The text certainly makes no distinction based on protocols, so that forwarding by SIP is ok, but forwarding by another protocol is not. RFC 3693 does not define party in any technical terms, either.

>The IETF boiler plate uses party in an organizational sense ("invites any interested party...").
>
>Wikipedia defines
>
>A party is a person or group of persons that compose a single entity which can be identified as one for the purposes of the law.

And this misses one of the other common meanings of "party" , roughly being
"one who participates".  Here's the extremely authoritative only Merriam
Webster definition:

"a person or group participating in an action or affair <a mountain-climbing party> <a party to the transaction>"

>Again, this makes no distinction based on protocols, or even whether this is a single individual. In this case, 'party' could just as well be a government agency operating a PSAP or PizzaHut.
>

As I have pointed out several times, it is my reading that a network element
which acts based on the location is a recipient (or "party to the communication")
from the point of view of location privacy.  A network element that does not,
but passes the location along according to unrelated protocol semantics is not.
Thus, the routers, switches, and location-ignoring SIP proxies are not parties
to the communication of the location; they don't read it, change behaviors
based on it, or *choose* to forward out of the typical flow set by the underlying
protocol.

I have proposed several ways forward here, and you seem stuck trying to
convince me, Richard, and James that the semantics we've discussed don't
make sense.  Can you come to the conclusion that we are obdurate and incapable
of understanding you, and decide whether this is really worth you falling on
your sword over this?  Or can we just make progress on this?

				Ted

---

From: Richard Barnes <[email-masked]>
Date: Wed, 09 May 2007 17:29:43 -0400

Ok, we're back to this:

The difference is in whether the proxy is a Recipient of the LO.  If it 
passes the bits along blindly, without interpreting them, then it has 
not, for privacy purposes, received the LO.  This is why you can pass an 
LO with retransmission-allowed=no through a store-and-forward network 
(be it SIP, email, whatever).

If the proxy reads and acts on the LO, then it becomes a Location 
Recipient, and is bound by the privacy rules in the LO (and possibly, as 
we've discussed, in the SIP header).  Then, if 
retransmission-allowed=no, that indicates that the proxy should not send 
the LO -- or the LI within it -- to another party.  And, as I've 
discussed before, there's some flexibility in "party", but there's no 
sensible definition that allows arbitrary LoST queries.

The trouble with -conveyance is that it allows both UASs and proxies to 
be the recipients of the location, even though the UAC might want to 
send different locations with different privacy rules to these two 
different sets of recipients.  I think indicating destinations (with 
header fields or tags) is a simple way to disambiguate this.

--Richard

Henning Schulzrinne wrote:
> 'parties' is not defined in RFC 4119, as far as I can tell, as the word 
> only appears once. The text certainly makes no distinction based on 
> protocols, so that forwarding by SIP is ok, but forwarding by another 
> protocol is not. RFC 3693 does not define party in any technical terms, 
> either.
> 
> this is a single individual. In this case, 'party' could just as well be 
> a government agency operating a PSAP or PizzaHut.
> 
> ------------------------------------------------------------------------
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 9 May 2007 17:53:02 -0400

I should probably heed Ted's advice, but can't resist: privacy is all  
about distribution and access to information; it has nothing to do  
with processing. According to your logic, it would be perfectly ok to  
multicast the LO to anybody, given that it would only be stored-and- 
forwarded at layer 3. I have to admit that I find the distinction  
between a protocol 'reading' the LO when it does normal SIP protocol  
processing and when it invokes some logic to be a stretch and not  
supported by anything having to do with privacy.

I think the discussion shows that our foundational documents lack  
clarity and motivation, as they don't actually explain the goals and  
provide guidance that corresponds to these goals (presumably, privacy  
from third parties).

Henning

On May 9, 2007, at 5:29 PM, Richard Barnes wrote:

> Ok, we're back to this:
>
> The difference is in whether the proxy is a Recipient of the LO.   
> If it passes the bits along blindly, without interpreting them,  
> then it has not, for privacy purposes, received the LO.  This is  
> why you can pass an LO with retransmission-allowed=no through a  
> store-and-forward network (be it SIP, email, whatever).
>
> Recipient, and is bound by the privacy rules in the LO (and  
> possibly, as we've discussed, in the SIP header).  Then, if  
> retransmission-allowed=no, that indicates that the proxy should not  
> send the LO -- or the LI within it -- to another party.  And, as  
> I've discussed before, there's some flexibility in "party", but  
> there's no sensible definition that allows arbitrary LoST queries.
>
> The trouble with -conveyance is that it allows both UASs and  
> proxies to be the recipients of the location, even though the UAC  
> might want to send different locations with different privacy rules  
> to these two different sets of recipients.  I think indicating  
> destinations (with header fields or tags) is a simple way to  
> disambiguate this.
>
> --Richard

---

From: Richard Barnes <[email-masked]>
Date: Thu, 10 May 2007 10:26:46 -0400

Henning,

I certainly agree that our foundational documents are due for revision. 
  However, until that revision is done, our work needs to be consistent 
with those documents, even the parts we'd like to revise.

As to forwarding at layer 3: This seems like a valid distinction to me. 
  Regardless of whether location is involved, by submitting a message 
for store-and-forward processing, the user implicitly authorizes the 
network to deliver that message to the proper recipients via necessary 
relays.  In SIP, the recipients are UASs and the relays are proxies on 
the signaling path.  This is the extent of the authorization.

What a store-and-forward transmission does not do is authorize 
transmission outside the store-and-forward network, e.g., to LoST 
servers or Google Maps.  This needs to be explicitly authorized (by 
something in the LO or by a tag in the header).

--Richard

Henning Schulzrinne wrote:
> about distribution and access to information; it has nothing to do with 
> processing. According to your logic, it would be perfectly ok to 
> multicast the LO to anybody, given that it would only be 
> stored-and-forwarded at layer 3. I have to admit that I find the 
> distinction between a protocol 'reading' the LO when it does normal SIP 
> protocol processing and when it invokes some logic to be a stretch and 
> not supported by anything having to do with privacy.
> 
>> The difference is in whether the proxy is a Recipient of the LO.  If 
>> it passes the bits along blindly, without interpreting them, then it 
>> has not, for privacy purposes, received the LO.  This is why you can 
>> pass an LO with retransmission-allowed=no through a store-and-forward 
>> network (be it SIP, email, whatever).
>>
>> Recipient, and is bound by the privacy rules in the LO (and possibly, 
>> as we've discussed, in the SIP header).  Then, if 
>> send the LO -- or the LI within it -- to another party.  And, as I've 
>> The trouble with -conveyance is that it allows both UASs and proxies 
>> to be the recipients of the location, even though the UAC might want 
>> to send different locations with different privacy rules to these two

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 10 May 2007 10:49:21 -0400

I've said this before and I'll shut up after this since we have long  
exceeded the point of diminishing returns, but I don't see where the  
goals of privacy or the text of the document support your assertion.

I agree that by giving location to a URI, you authorize the URI to  
perform a service. Thus, if you give your location to  
urn:service:sos, you authorize that service. From a privacy  
perspective, the protocols involved do not matter as long as the same  
'party' is addressed, to quote 4119. After all, I assume you wouldn't  
argue that a transition between UDP and TCP, or IPv4 and IPv6 in mid- 
transit would make a difference; both are likely to occur in a SIP  
call. (Indeed, you could even have, in the 911 I2 model, a transition  
to delivery of location with a completely different protocol. Would  
this require an override?)

Henning

On May 10, 2007, at 10:26 AM, Richard Barnes wrote:

> Henning,
>
> I certainly agree that our foundational documents are due for  
> revision.  However, until that revision is done, our work needs to  
> be consistent with those documents, even the parts we'd like to  
> revise.
>
> As to forwarding at layer 3: This seems like a valid distinction to  
> me.  Regardless of whether location is involved, by submitting a  
> message for store-and-forward processing, the user implicitly  
> authorizes the network to deliver that message to the proper  
> recipients via necessary relays.  In SIP, the recipients are UASs  
> and the relays are proxies on the signaling path.  This is the  
> extent of the authorization.
>

---

From: Matt Lepinski <[email-masked]>
Date: Thu, 10 May 2007 15:50:55 -0400

[Stepping back for a second] From reading this thread I conclude that:

(Please let me know if I'm mis-interpreting the discussion)

1) Everyone agrees with Henning on the following point

> provide guidance that corresponds to these goals (presumably, privacy  

2) Performing exegesis on documents that "lack clarity and motivation" 
is not a productive use of time.

3) No one is strongly supporting the text currently in the -07 version 
of location conveyance which adds the routing-query-allowed element to 
the PIDF-LO specification.

[Personally, I don't like the current text of location-conveyance since 
it solves a SIP-only problem by adding an element to (potentially all) 
PIDF-LO objects]

4) Two reasonable changes have been proposed to the text in 
location-conveyance:

(A) Remove the routing-query-allowed element and process all SIP 
messages as though routing-query-allowed were present and set to "yes". 
That is, by including location in a SIP message the user is implicitly 
providing consent for the location to be used in whatever routing 
queries are needed for the message to reach it's designated destination.

[This approach may require normative changes to 4119. However, whether 
this approach requires changing 4119 can be discussed after we've come 
to consensus on whether this is the perferred approach.]

(B) Remove the routing-query-allowed element and allow a user to mark 
[using some reasonable syntax] a conveyed location as either "intended 
for routing", "intended for the end-point" or "intended for both" (where 
the default behaivor is "intended for both").

[This would add no additional length to the SIP message in the common 
case where the location can be used for either routing or by the 
end-point, but allows the user to explicitly indicate his desires if 
necessary.]

Given my understanding of the discussion, it seems that to move forward 
we need to try reach consensus on whether (A) or (B) is the perferred 
technical choice [which I believe is possible] and postpone theological 
discussions on which there is little hope of reaching consensus.

- Matt Lepinski :->