Subject: [Sip] rethinking data:

From: Andrew Newton <[email-masked]>
Date: Fri, 25 Aug 2006 16:08:56 -0400

Having reviewed the archives on the recent location conveyance discussion, I 
see that I was the only one to raise an objection to the use of a data: URL 
in the Location header.

My objection was based on the fact that it would add unnecessary complexity. 
  Given some more time to think this through, I believe it adds no more 
complexity than the alternative... even much less complexity than the 
alternatives especially if there is no desire to specify its use with XML 
D-Sig.  Of course, the use of this mechanism MUST be restricted specifically 
to emergency scenarios, and only when location is not present in the body.

-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: "James M. Polk" <[email-masked]>
Date: Fri, 25 Aug 2006 17:01:50 -0500

At 04:08 PM 8/25/2006 -0400, Andrew Newton wrote:
>Having reviewed the archives

Andy

Which archives did you review?

There were several voices opposed to it, but maybe not on the Geopriv 
list.  After all, this is a SIP doc...

>on the recent location conveyance discussion, I see that I was the only 
>one to raise an objection to the use of a data: URL in the Location header.
>
>My objection was based on the fact that it would add unnecessary 
>complexity.  Given some more time to think this through, I believe it adds 
>no more complexity than the alternative... even much less complexity than 
>the alternatives especially if there is no desire to specify its use with 
>XML D-Sig.  Of course, the use of this mechanism MUST be restricted 
>specifically to emergency scenarios, and only when location is not present 
>in the body.
>
>-andy
>
>
>Geopriv mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Andrew Newton <[email-masked]>
Date: Fri, 25 Aug 2006 20:21:30 -0400

On Aug 25, 2006, at 6:01 PM, James M. Polk wrote:

> There were several voices opposed to it, but maybe not on the  
> Geopriv list.  After all, this is a SIP doc...

I'm well aware of that fact, James.  However, there was actually very  
little significant discussion on it besides the exchange between  
Henning and myself (there was a post on the SIP list that never made  
it to GEOPRIV that was in favor).  Keep in mind, this was mixed into  
a long and winding thread.

So, here we have another thread.  And it would be easy for those  
opposed (or for) to stand up and be counted (and offer an  
explanation, too... after all, we don't vote in the IETF).

-andy

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Sat, 26 Aug 2006 02:43:53 +0200

Andy,

A data: URI enables the following use case: location-by-value inserted by a 
proxy.
Especially for emergency cases, location-by-value is good to have: less 
delay (no additional de-reference) and less ways in which things can fail. 
Although I'm not particularly keen on the syntax defined for data: URIs, I 
think the use case and benefits it enables are worthwhile

Regards,

Jeroen

----- Original Message ----- 
From: "Andrew Newton" <[email-masked]>
To: "James M. Polk" <[email-masked]>
Cc: "GEOPRIV" <[email-masked]>; "IETF SIP List" <[email-masked]>
Sent: Saturday, August 26, 2006 2:21 AM
Subject: [Sip] Re: [Geopriv] rethinking data:

> little significant discussion on it besides the exchange between  Henning 
> and myself (there was a post on the SIP list that never made  it to 
> GEOPRIV that was in favor).  Keep in mind, this was mixed into  a long and 
> winding thread.
>
> So, here we have another thread.  And it would be easy for those  opposed 
> (or for) to stand up and be counted (and offer an  explanation, too... 
> after all, we don't vote in the IETF).
>
> -andy
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 25 Aug 2006 19:50:16 -0500

Tsk. Once more, then, into the breach...

I vote in FAVOR of location reference. Protocols definition is an
engineering activity - protocol features are provided for practical
purposes and should not be added or excluded as a projection of
ideologies.

Practical benefits of location reference:
* The literal location does not need to be transmitted in band. Where
the eventual recipient and de-referencer is the only party the "owner"
of location cares to provide disclosure to, then the reference mechanism
achieves this. Particularly useful where the owner is not in a peer
signaling relationship with the de-referencer. E.g. a VoIP emergency
caller and a VPC.

* The location reference form is immutable and generic (i.e. a URI - and
my view that a generic URI is perfectly adequate has also been
expressed). So, no matter what eventual modifications, extensions, or
additions are made to the manner in which the PIDF-LO is formed, the
conveyance path need not be concerned about backward incompatibility.
Adaption is limited to the actual end-user of the location information.

* Where the location owner is not in a peer signaling relationship with
the location user (e.g. a VoIP emergency caller and a VPC), the location
reference can be permitted to be valid for a period of time allowing,
for example, the retrieval of location updates during the period of that
session.

* As a counter-response - no the location reference is not less secure.
Losing privacy of location information means losing the information at
the device or in transit. Loss of a literal location object means the
location is lost in one step. Loss of a reference still requires the
unauthorized party to successfully breach the authentication and
authorization barrier at the referenced server. Location by reference
provides superior privacy.

* The DSIG solution for DHCP/LLDP-MED contributed by Rosen et al
recently does not address the temporal component. Brian should state the
signature also needs to provide an expiry-time component. Else the
signed LO can be replayed at any time in the future from anywhere by the
original recipient. Expiry time semantics are somewhat awkward. Since
de-referencing is an instantaneous process, the location server can
apply temporal rules directly without the need to encode them in the
location object itself.

I think that's a more than compelling list of benefits of using location
reference. Arguments suggesting it allows network operators to charge
for location are not relevant - nor appropriate to the engineering
process. The market will decide that - and clearly the option of
providing literal location is not obviated by the presence of the option
to use location by reference.

Cheers,
Martin

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Saturday, 26 August 2006 10:22 AM
> To: James M. Polk
> Cc: GEOPRIV; IETF SIP List
> Subject: Re: [Geopriv] rethinking data:
> 
> 

------------------------------------------------------------------------------------------------
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: Fri, 25 Aug 2006 21:04:30 -0400

I thought we had long ago agreed that both by-value and by-reference  
have their benefits and drawbacks. Why are we re-opening this debate?  
Are you suggesting that we remove all by-value usage of LOs? Do you  
think you can get WG consensus on this?

I won't rebut the statements below point-by-point. Suffice it to say  
that the problem is that the arguments in favor of reference shape- 
shift, as they actually encompass multiple forms (with retriever  
authorization, possession-only, among others), and conveniently claim  
the benefits of the union of them, while admitting only to the  
drawbacks of the intersection. This is not helpful for an  
enlightening debate.

However, given that we've gone through this now at least a dozen  
times, I don't see the point of rehashing the same debate again.  
Maybe the chair(s) can ask, if this is indeed necessary, for  
consensus on the first line of this message and declare such debates  
as not helpful?

Henning

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 25 Aug 2006 21:17:34 -0500

Beats me Henning (and not that I understand the shape-shifting allusion
either).

Andy just said

"So, here we have another thread.  And it would be easy for those
opposed (or for) to stand up and be counted (and offer an explanation,
too... after all, we don't vote in the IETF)."

So I responded in the spirit of the request as someone who is for
reference conveyance.

Don't know where you'd get the idea I wanted by-value removed. That'd be
silly.

Cheers,
Martin

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, 26 August 2006 11:05 AM
> To: Dawson, Martin
> Subject: Re: [Sip] RE: [Geopriv] rethinking data:
>

---

From: Andrew Newton <[email-masked]>
Date: Fri, 25 Aug 2006 23:14:25 -0400

> Don't know where you'd get the idea I wanted by-value removed.  

Martin,

I have to confess that I read your message in much the same way  
Henning did.  In fact, I was about to reply with "Why do you believe  
the data: URL is to the exclusion of any other URL type?"  Thanks for  
clearing this up.

I was speaking specifically about the usage of the data: URL.

-andy

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 25 Aug 2006 23:40:18 -0500

Ah - I see. Well put it all back in the box then. :)

Cheers,
Martin

> Sent: Saturday, 26 August 2006 1:14 PM
> To: Dawson, Martin
> Cc: Henning Schulzrinne; GEOPRIV; IETF SIP List
explanation,