Re: RE: [Geopriv] rethinking data:
Henning Schulzrinne <[email protected]>
| Newsgroups | gmane.ietf.sip,gmane.ietf.geopriv |
|---|---|
| Message-ID | <[email protected]> |
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 On Aug 25, 2006, at 8:50 PM, Dawson, Martin wrote: > 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 > _______________________________________________ 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