Let's call it option C (for Compromise).
Richard - sorry - I can't buy into the "offsets are generally small" argument. That assumption is fraught in the context of defining a general framework. It's a bad thing to create convention that readily communicates precision in excess of accuracy.
Cheers,
Martin
-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Thomson, Martin
Sent: Friday, 9 April 2010 10:16 AM
To: James M. Polk; althomso; geopriv@ietf.org
Subject: Re: [Geopriv] Consensus request: Relative location and encoding options
Thanks James, that's pretty much what I've been proposing.
> I think it should like this:
>
> Civic: USA->Florida->Miami->BuildingA->Floor4
> Relative: (ref=) Elevator->offset
>
> where the reference <element> is identified, and everything in the
> relative part is separately indicated to ensure there is no confusion.
>
> This both reduces the data to its minimum set, and for
> interoperability - only what's understood will be used, with the
> possibility that the recipient doesn't understand this extension,
> meaning they don't understand the whole "Relative" part, leaving that
> entity to believe the target is on <Floor>4</Floor>. We just have to
> have firm text saying the target must be within x distance of floor
> 4. An easy example of somewhere outside floor 4 that still needs to
> be valid is a parking lot outside the building, or a window cleaner
> hanging outside the windows of floor 4.
>
> James
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
