Re: Civic Address for V2

Hi Andrei,

> 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.

The reason to do this is to minimize translation to and from the IETF 
format when location travels from one to the other.  It could do this in 
two ways, as an input and as an output.

One source of location for this API will be information provided by 
host's ISP via DHCP or HELD (or another provider that uses IETF 
protocols).  Since there are emerging regulatory requirements in several 
markets for networks to deploy such servers (in order to support 
emergency services), it is not unlikely that this will happen in the 
next few years.  (It's already possible with HELD through the Geode-HELD 
Firefox plugin.)

On the other side, web services using this API could be used to populate 
location databases that are accessed using IETF protocols.  Using 
emergency calling again as an example, the NENA i2 emergency calling 
architecture requires ISPs to maintain databases of location that 
emergency services access access via HELD.  One way a provider might 
maintain this database is to have subscribers install a browser module 
that pulls location through the W3C API and pushes it back to the ISP.

(Obviously, there are non-emergency examples of both cases, but I think 
the point is clear enough)

> 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?

You can have a 1-1 mapping with fewer fields by combining fields 
according to a well-defined algorithm.  For instance, the Austrian 
registry of civic addresses has many more fields then even RFC 5139 
defines, but there's a well-defined translation between the two defined 
in a GEOPRIV document:

It doesn't necessarily have to map the full format, but in that case, 
you have to accept that you lose information when you translate into the 
W3C format (and might want to note this in the spec).


Received on Tuesday, 3 March 2009 00:08:49 UTC