Re: [Geopriv] Geopriv L7 LCP: New Requirement

From: Henning Schulzrinne ^lt;hgs@cs.columbia.edu>
Date: Fri Feb 16 2007 - 22:37:29 EST

On Feb 16, 2007, at 10:04 AM, Stark, Barbara wrote:

> I hate to break ranks, but if we could get the user part figured out
> (and I do think we would need some standardization, even if it's
> just a
> BCP), I kind of like this proposed solution. It has a certain
> simplicity
> to it.

I'm not sure if this is along the lines you suggest, but

http://tools.ietf.org/wg/geopriv/draft-schulzrinne-geopriv-
locationref-00.txt

investigated a SIP-based solution in this general space.

>
> Since we've been pushing for these LISs to support LbyR, anyway, and
> this is really just LbyR, I don't see it as being a different
> protocol,
> yet again. This is a protocol we'd expect to be supported by a LIS in
> any case. The only change is that the URI may require careful
> parsing by
> the queried LIS, and the querier LIS needs to support LbyR queries in
> both directions.
>
> When I look at the functions in HELD (and RELO has a subset of these),
> and think through which of those functions would I really need for
> LIS-LIS or OBO, I come up with:
> - ability to request reference -- not needed, since, as pointed out,
> I've already got a perfectly good non-expiring reference; OBO
> querier or
> LIS doesn't need to ask for references to hand off to others, it
> should
> create its own references for that, as appropriate [aside: a
> non-expiring reference and a "LCP" are rather equal in the privacy
> debate from the OBO/LIS-LIS perspective.]
> - ability to assert location -- not needed for OBO or LIS-LIS; only an
> end device should be able to do this, if even that is allowed
> - ability to provide rules/profile for privacy -- not needed for
> OBO or
> LIS-LIS; only the device should be able to do this
> - ability to sign location -- if this is part of PIDF-LO, then this is
> independent of request mechanism
> - ability to request that location be signed -- I think we can assume
> that the location should be signed if it can be signed
> - ability to specify how quickly a response is needed -- this would be
> useful, but it may be possible to design around the issue
> - have I missed anything?
>
> Supporting URI formats other than SIP (e.g., HTTP) would still need to
> be worked. But that format would be common to all LbyR usages.
> This in no way removes the requirement for a device-to-LIS "LCP". I
> haven't read that into the suggestion at all.
>
> So, I think this idea warrants consideration.
> Barbara
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 16 Feb 2007 22:37:29 -0500

This archive was generated by hypermail 2.1.8 : Fri Feb 16 2007 - 22:37:58 EST