Re: Civic Address for V2

I can put mine in IDL so we have it as a reference? I'll do that later today.


On Tue, Mar 10, 2009 at 7:51 AM, Doug Turner <> wrote:
> Does someone have a proposal IDL of the full civic address with "human
> readable names?"  (instead of A2, "county").  I saw Andrei's reduced form
> proposal, but didn't see anything that was a complete civic address.
> Doug
> On Mar 10, 2009, at 7:20 AM, Henning Schulzrinne wrote:
>> Most cases won't need all the fields, but having them will allow more
>> applications and avoid the hackery and guestimes I talked about. Just as an
>> example, having a separate building name field is quite useful on campus for
>> friend-finder applications ("who is in the same building?"). In some other
>> cases, we may only have limited precision (e.g., county-level for
>> IP-address-to-location services). I admit that I find it hard to believe
>> that somebody doesn't understand "building name", "floor", "street suffix"
>> or some of the other fields proposed. The more obscure fields, such as the
>> street branch system, will only apply regionally, so developers that don't
>> care about Indonesia can ignore them, but they do make the system capable of
>> handling more than just US and European addresses.
>> Henning
>> On Mar 9, 2009, at 2:44 PM, Doug Turner wrote:
>>> Hello Henning,
>>> I do not think we have any use cases that require comparing addresses for
>>> equality.  We clearly did not for the v1 addressing (coords).  I tend to
>>> think that civic addressing comparison is out of scope.  For example, if two
>>> UAs pass back an address for the same place, I do not think that we should
>>> make any guarantees that the data the UA pass back to the requesting site is
>>> the same.  In fact, I do not think that the addresses need to be the same
>>> between different runs of the same UA.  The reason for this is that UAs
>>> might use different back-ends for determining the actual location of the UA.
>>>  Maybe the first geolocation request uses WiFi->location, and the second
>>> request uses a user defined position, or what have you.
>>> Secondly, we are not designing this API for someone like your or me or
>>> anyone on this mailing list that can understand thirty+ fields, have no
>>> problem looking up extensive documentation, and enjoy digging through
>>> mailing list for rationale on the way things are they way they are..
>>>  Rather, the API must be designed for the web at large.  I think we should
>>> design the simple-to-use over a can-do-everything-everyone-every-wanted
>>> address for v2.
>>> Keep in mind, that one could always create a civic address spec that
>>> leverages the geolocation specification and implementations.  For example,
>>> you could add a separate civicAddress to the position object in a future
>>> specification.

Received on Tuesday, 10 March 2009 15:13:11 UTC