RE: [Geopriv] rethinking data:

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 protected]]
> Sent: Saturday, 26 August 2006 10:22 AM
> To: James M. Polk
> Cc: GEOPRIV; IETF SIP List
> Subject: Re: [Geopriv] rethinking data:
> 
> 
> On Aug 25, 2006, at 6:01 PM, James M. Polk wrote:
> 
> > 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...
> 
> 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
> 
> _______________________________________________
> Geopriv mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
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]

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