Re: Civic address representation in v2

Hey Lars Erik,

Glad to provide some input.  First, you're correct about RFC numbers:  
RFC 5139 [1] is the latest address specification.  More properly, the  
overall list of civic address element types is maintained as an IANA  
registry [2]

I actually think that the current address structure in the working  
draft maps pretty well to a subset of the RFC 5139 syntax:

country ~ country
region ~ A1
county ~ A2
city ~ A3
street ~ POD + RD + STS + PRD
streetNumber ~ HNO + HNS
premises ~ NAM
postalCode ~ PC

This leaves a couple of problems.  First, it's clearly not a  
reversible transform with the concatenation, unless you add some  
additional constraints on how those elements are put together.   
Second, you are restricted to western-style addresses, so you'll have  
trouble covering parts of Japan and China (e.g., "4 Rue Rabelais" vs.  
"7-2, Marunouchi 2-Chome Chiyoda-ku"; concepts like -ku and -chome are  
supported by the additional heirarchical elements A4-A6).   
Nonetheless, not a bad start.

If you want to append a more proper RFC 5139 object, it seems a little  
silly to use JSON in a string rather than just a JSO -- a JavaScript  
Object.  The logical format is just a list of type-value pairs, where  
the type names are from the IANA registry [2] and the values are  
strings.  This maps naturally onto a javascript object with a bunch of  
optional string fields, and it seems like you could define it mostly  
by reference to RFC 5139 or the IANA registry.


[1] <>
[2] <>

On Nov 20, 2009, at 3:29 AM, Lars Erik Bolstad wrote:

> Hi Richard,
> The Address interface attributes in the editor's draft of v2 [1] are  
> based on a proposed mapping of RFC4119 fields, where some of the  
> 4119 fields are combined into the additionalInformation attribute.  
> [2] At the recent f2f meeting we revisited this discussion and  
> concluded that we'd like to have some input from you on this. You  
> can find the relevant meeting minutes here:
> First of all, it seems that RFC5139 is the one we should be looking  
> at, and not 4119. Is that correct?
> The current proposal is to expose the "raw" RFC5139/4119 civic  
> address data in the additionalInformation attribute as a string  
> containing a JSON object.
> What are your thoughts on this?
> Thanks,
> Lars Erik
> [1]
> [2]

Received on Friday, 20 November 2009 14:14:53 UTC