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

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

On Jul 25, 2006, at 3:29 PM, Marc Linsner wrote:

> Do I believe location-by-reference will happen?  Probably, but making
> assumptions about the mechanism now is quite premature.

Perhaps nothing will save us.  We've had by-value since step one, and  
now by-value take 2 is being proposed.

-andy

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

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 25 Jul 2006 15:29:13 -0400

In-line..... 

> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 1:38 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Geopriv] Consensus on changes to location-conveyance
> 
> I have put out a number of emails on proposed changes to 
> location conveyance.  Some of them have sparked a number of 
> comments.  My summary of consensus on these issues is:
> 
> 1. We proposed to explicitly disallow use of a Data URI, 
> which would allow specification of a Location-by-value in a 
>l

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 25 Jul 2006 15:29:13 -0400

In-line..... 

> header.  There was a lot of list traffic on this, currently 
> in the state where Keith asked for a real use case for it.  
> So far, we don't see a use case that cannot be provided by 
> location-by-reference in a header.  If we don't get a good 
> use case, I think consensus is to disallow location-by-value 
> in a header.
> 

I see a problem here.  Location-by-reference is nothing more than 'magic
happens here'!  Please point to a wg item documenting the
location-by-reference mechanism.  How can you state the
location-by-reference will cover all the use cases that the Data URI would
when location-by-reference hasn't even been defined anywhere?  You're
loading up the magic with a lot of assumptions.  Location-by-reference is an
individual submission as a solution to a set of requirements that haven't
been fleshed-out in geopriv.  

I believe that Henning/Hannes also recognized this issue, hence the
suggestion of a Data URI.  Dismissing this suggestion based on an already
accepted non-existent mechanism seems like getting the cart before the
horse.

..........snip

> 6. We proposed to allow sip/sips and pres: in the location 
> header.  I later speculated that if we allow this, it forms a 
> simple way to do location-by-reference, and we could 
> eliminate the raw HTTP(S) Get proposal, with the parameter 
> and registry entirely.  There was some list traffic in favor 
> of this.  Martin Thompson is skeptical that SIP Presence 
> Subscribe/Notify is actually allowed as a geopriv "using 
> protocol".  Several of think that it is.  If we don't get any 
> more comments on this proposal, we will allow sip/sips and 
> pres, not have any
> http(s) resolution text, and not propose a parameter and 
> accompanying registry.

I certainly think it's more prudent to define the dereferencing mechanism
prior to making claims about the protocol.

-Marc-

> 
> If this does not reflect your position, please speak up now.
> 

 header.  There was a lot of list traffic on this, currently 
> in the state where Keith asked for a real use case for it.  
> So far, we don't see a use case that cannot be provided by 
> location-by-reference in a header.  If we don't get a good 
> use case, I think consensus is to disallow location-by-value 
> in a header.
> 

I see a problem here.  Location-by-reference is nothing more than 'magic
happens here'!  Please point to a wg item documenting the
location-by-reference mechanism.  How can you state the
location-by-reference will cover all the use cases that the Data URI would
when location-by-reference hasn't even been defined anywhere?  You're
loading up the magic with a lot of assumptions.  Location-by-reference is an
individual submission as a solution to a set of requirements that haven't
been fleshed-out in geopriv.  

I believe that Henning/Hannes also recognized this issue, hence the
suggestion of a Data URI.  Dismissing this suggestion based on an already
accepted non-existent mechanism seems like getting the cart before the
horse.

..........snip

> 6. We proposed to allow sip/sips and pres: in the location 
> header.  I later speculated that if we allow this, it forms a 
> simple way to do location-by-reference, and we could 
> eliminate the raw HTTP(S) Get proposal, with the parameter 
> and registry entirely.  There was some list traffic in favor 
> of this.  Martin Thompson is skeptical that SIP Presence 
> Subscribe/Notify is actually allowed as a geopriv "using 
> protocol".  Several of think that it is.  If we don't get any 
> more comments on this proposal, we will allow sip/sips and 
> pres, not have any
> http(s) resolution text, and not propose a parameter and 
> accompanying registry.

I certainly think it's more prudent to define the dereferencing mechanism
prior to making claims about the protocol.

-Marc-

> 
> If this does not reflect your position, please speak up now.
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 25 Jul 2006 11:18:43 -0700

At 1:38 PM -0400 7/25/06, Rosen, Brian wrote:
>4. We proposed to explicitly allow hop-by-hop TLS security for location
>when the endpoint wished to allow routing based on location.  We further
>proposed to interpret "Do not Distribute" flags as allowing sending of
>the location to the routing database (LoST for example).  Hannes pointed
>out that there was a proposal to allow two Location headers, one of
>which could be used for routing and another for onward forwarding to the
>recipient.  Hannes' message seemed to agree that "Do not distribute"
>would allow sending of the location to the routing-by-location database,
>but would obligate the proxy that did that to remove the location before
>it forwarded the message.  There were no other messages on this thread.

Actually, I commented on the same problem, though it may have been
connected to one of the related threads; here's the text of that message:

>At 5:23 PM -0400 7/19/06, Brian Rosen wrote:
>>NOTE: THIS MESSAGE IS COPIED TO SIP AND ECRIT, IF YOU REPLY, SEND IT ONLY TO
>>GEOPRIV
>>However, this opens up the issue of geopriv privacy concerns because the
>>sender does not know the identity of the element (proxy) that will route the
>>call using LoST.  It may be that the UAC itself does this, but it may be
>>some other intermediary.
>>
>>If the identity of the intermediary is not known, then protecting the
>>location information becomes more difficult, because we cannot encrypt using
>>keying material from the intended recipient.
>
>Just to mention this, it appears to also rule out the idea of encrypting
>with the user's key, since there is no way of knowing whether the "intended
>recipient" has that key material either.  Intended recipient is actually
>a bit of a problematic term here, since it's really the on-path network elements
>which consume the information.  They aren't the intended recipient of
>the communication, they are the recipients of the signaling (of which location
>is now a part).
>
>This is a bit confusing because it seems to be possible to include a
>"re-transmission allowed"  rule with a value of "no" (intended to be
>consumed by the "intended recipient" of the underlying communication),
>while still wanting to allow the location to be passed along the path.
>
>>In fact, we would need to use
>>hop-by-hop security, with transitive trust.  This is what the emergency case
>>does, but it also allows no channel security if necessary (usually meaning,
>>try it with TLS and if that fails, try again without TLS).
>
>While I certainly encourage hop-by-hop security, I don't think it really
>meets the geopriv privacy concerns.  I think you  have to have some way of
>expressing "re-transmission for routing permitted" (and likely retention
>limited), since that is a separate statement.
>
>Just typing aloud here, but could we come up with a way to use an
>external ruleset to express this?  With an embedded cid, that would
>not actually require dereferencing.
>					Ted
>

>We conclude that allowing hop-by-hop security for location based routing
>is acceptable, and Do Not Distribute DOES allow forwarding to a routing
>database, but requires that the proxy doing the location based route to
>remove the location it uses for that purpose.

To reiterate this, I do not believe that this is sufficient; I think you have to
have some way of saying "re-transmission for routing permitted" before
you meet the geopriv privacy concerns.

>5. We proposed to create a parameter and a registry to distinguish
>multiple ways to dereference a location where HTTP(S) was the transport.
>Resolution of this issue depends on resolution of issue 6.

I believe that an HTTP GET of a PIDF-LO object is a reasonable baseline.
Saying that other mechanisms should update this document with their
dereferencing mechanisms if they could be confused with the baseline
seems to me to be sufficient.  I'm not sure a registry is needed.  In practice,
I don't think we would hit the interoperability problems often. These days,
extensions to HTTP commonly use different  mime types to indicate the special
handling, and I expect anyone creating a more feature-rich dereferencing
mechanism built on HTTP would not end up using pidf-lo.  

That means the "uri confusion" aspects of the discussion are probably not
that severe.  The only issue is if someone supports only the more feature-rich
alternative and not a baseline GET of the pidf-lo.  I think we should
discourage that, by establishing a real baseline.

Note also that HTTP URIs don't indicate the HTTP Method directly; often they
support multiple methods (e.g. HEAD and GET).

>6. We proposed to allow sip/sips and pres: in the location header.  I
>later speculated that if we allow this, it forms a simple way to do
>location-by-reference, and we could eliminate the raw HTTP(S) Get
>proposal, with the parameter and registry entirely.  There was some list
>traffic in favor of this.  Martin Thompson is skeptical that SIP
>Presence Subscribe/Notify is actually allowed as a geopriv "using
>protocol".  Several of think that it is.  If we don't get any more
>comments on this proposal, we will allow sip/sips and pres, not have any
>http(s) resolution text, and not propose a parameter and accompanying
>registry.

I share some of Martin's skepticism here, but I won't fall on my sword
if the WG goes in this direction.

Thanks for the clear set of issues and opportunity to comment,
				
					Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Tue, 25 Jul 2006 11:18:43 -0700

Actually, I commented on the same problem, though it may have been
connected to one of the related threads; here's the text of that message:

>This is a bit confusing because it seems to be possibllien.qualcomm.com ([129.46.51.59])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1G5Tax-0000Jo-Lj; Tue, 25 Jul 2006 16:33:37 -0400
Date: Tue, 25 Jul 2006 13:33:31 -0700
To: "Rosen, Brian" <[email-masked]>, <[email-masked]>
From: Ted Hardie <[email-masked]>
Cc: [email-masked]
Subject: [Sip] RE: [Geopriv] Consensus on changes to location-conveyance

At 2:45 PM -0400 7/25/06, Rosen, Brian wrote:
>Summarizing, you think hop-by-hop security (TLS) is acceptable when the
>location is sent for the purposes of location based routing, but you are
>not in favor of defining "retransmission=no" to permit sending the
>location to the routing database (e.g. LoST).  You want a more explicit
>permission.

Yes.

>I don't think a cid: with a ruleset is acceptable, as it would not
>permit location by reference added by a proxy to specify this.

Fair enough.

>If this is the consensus, I think we would have to add a bit to the PIDF
>to explicitly control this behavior.

I think an extension that says "retransmission for routing=yes" is the cleanest
way to go.

>Why do you think we must specify an HTTP dereference procedure in this
>document?  What is the purpose when the SIP based method is available?
>We had believed we had to have SOME method of dereferencing to make
>location-by-reference meaningful in the document.  If we have one sip
>based method, we meet the requirement.  Having more options, especially
>completely new HTTP based protocols IN THIS DOCUMENT seems unnecessary
>and unwise.  For example, if we define such a protocol, it becomes a
>geopriv "using protocol" and needs an explicit analysis against the
>geopriv criteria.

I don't think we have to do it in this document, but I read your previous
message as a statement of consensus about the HTTP dereference mechanisms
that have been discussed.   I don't agree with that statement, since I think the
HTTP discussions somewhat over-thought the potential problems.  In particular, a
lot of the discussion was around the idea that http://dereference.example.org/foo-pidf-lo
might mean lots of different things, depending on what http meant.  There are
already ways to deal with that; none of them are perfect (see, for example,
the discussion in draft-reschke-webdav-mount-05.txt and its appendix A for a similar
problem in a different context), but they can work, especially if you set a baseline
approach.

				regards,
					Ted Hardie

>Brian
>> From: Ted Hardie [mailto:[email-masked]]
>> Sent: Tuesday, July 25, 2006 2:19 PM
>> To: Rosen, Brian; [email-masked]
>> Cc: [email-masked]
>> Subject: Re: [Geopriv] Consensus on changes to location-conveyance
>>
>> >4. We proposed to explicitly allow hop-by-hoe to include a

				
					Ted Hardie

---

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

Hi Brian,

I guess you are only talking about the current Location Conveyance 
document.

Rosen, Brian wrote:
> I have put out a number of emails on proposed changes to location
> conveyance.  Some of them have sparked a number of comments.  My summary
> of consensus on these issues is:
> 
> 1. We proposed to explicitly disallow use of a Data URI, which would
> allow specification of a Location-by-value in a header.  There was a lot
> of list traffic on this, currently in the state where Keith asked for a
> real use case for it.  So far, we don't see a use case that cannot be
> provided by location-by-reference in a header.  If we don't get a good
> use case, I think consensus is to disallow location-by-value in a
> header.

I don't agree with your statements but I am (in the meanwhile) convinced 
that we need to cover this in a separate document.

> 
> 2. Dereferencing location-by-reference.  We had initially proposed to
> document a process to use a raw HTTP(S) Get to dereference.  There was a
> lot of discussion, and then I made a new proposal, see item 6. 
> 
> 3. We proposed to allow a Reason header with a 424 Bad Location
> response.  This seems to be acceptable to the WG.  Geopriv will create
> and populate the registry in a separate draft.
> 

Ok.

> http(s) resolution text, and not propose a parameter and accompanying

I disagree with location-by-reference being added to the document (or 
suggest to get it removed from the document).

Ciao
Hannes

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