W3C home > Mailing lists > Public > public-geolocation@w3.org > March 2009

Re: Civic Address for V2

From: Marc Linsner <mlinsner@cisco.com>
Date: Mon, 02 Mar 2009 18:00:47 -0500
To: Andrei Popescu <andreip@google.com>, Richard Barnes <rbarnes@bbn.com>
CC: Alec Berntson <alecb@windows.microsoft.com>, "public-geolocation@w3.org" <public-geolocation@w3.org>
Message-ID: <C5D1CF4F.11A3F%mlinsner@cisco.com>

I'm curious how you propose to reconcile the differences between this
proposed object and RFC5139?

A client on any IEEE network (Ethernet, 802.11, WiMAX), residential
broadband, enterprise, and any client a router hop away from a 3G/4G network
will be receiving a RFC5139 location object from the network.


On 3/2/09 3:02 PM, "Andrei Popescu" <andreip@google.com> wrote:

> Hi Richard,
> On Fri, Feb 27, 2009 at 6:36 PM, Richard Barnes <rbarnes@bbn.com> wrote:
>> Hi Alec,
>> Thanks for bringing this issue back up.  My $.02:
>>> a.       I propose we use the same fields as the CivicAddressReport in the
>>> Windows 7 Location API.
>> Where on earth did you get that idea? :)
>> I tend to agree with Allan that a representation compatible with RFC 4119
>> (more properly, RFC 5139) would be more universally applicable.
>> I appreciate that some view this as too complex, so there may be value in
>> producing a simplified version.  However, it should be a profile of the IETF
>> format, in that there should be a 1-1 mapping between the two.
> It's great to have RFC 5139 as a reference but, as you mentioned, it
> seems (at least to me) too complex for a Web API. We should look for a
> simplified version and I think Alec's proposal is a great start
> (please also have a look at Gears). What I don't understand is why do
> you say that it should be a profile of the IETF format. I'm not aware
> of any such requirement. Also, if it's a simplified format, how can we
> have a 1-1 mapping to the full format? To me simplified means somewhat
> less fields, right?
> Thanks,
> Andrei
Received on Monday, 2 March 2009 23:01:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:54 UTC