Fields in ADR

On 2010-09-09 10:12, Joseph Smarr wrote:
>> This is also available in vCard. ADR is for formatted addresses
> whereas LABEL is for unformatted addresses.
> 
> Simon-I think you missed my point here. Even within the *structured*
> address, one of the "known bugs" in vCard 3 is the fact that they use 3
> different sub-fields just for the street address (pobox,
> extended-address, and street-address), but nobody knows what those first
> two fields are for, nobody uses them, no UIs expose them separately, and
> they create a lot of ambiguity and confusion. I'm all for maintaining
> backwards compatibility where you can, but I'd strongly urge you to say
> "these first two fields are deprecated and should no longer be used,
> just put the full street address in the street-address field". 

Got it, I understand now.

> So for instance, the following address in vCard:
> 
> ADR;TYPE=WORK:;;1300 Crittenden Lane\nSuite 300;Mountain View;CA;94043;USA
> LABEL;TYPE=WORK:1300 Crittenden Lane\nSuite 300\nMountain View, CA 94043 USA
> 
> Would look like this in PoCo:
> 
> "addresses": [
>   {
>     "type": "work,
>     "streetAddress": "1300 Crittenden Lane\nSuite 300",
>     "locality": "Mountain View",
>     "region": "CA",
>     "postalCode": "94043",
>     "country": "USA",
>     "formatted": "1300 Crittenden Lane\nSuite 300\nMountain View, CA 94043"
>   }  
> ]
> 
> and like this in vCard XML:
> 
> <adr>
>   <parameters><type>work</type></parameters>
>   <pobox/>
>   <ext/>
>   <street><text>1300 Crittenden Lane\nSuite 300</text></street>
>   <locality><text>Mountain View</text></locality>
>   <region><text>CA</text></region>
>   <code><text>94043</text></code>
>   <country><text>USA</text></country>
> </adr>
> <label>
>   <parameters><type>work</type></parameters>
>   <text>1300 Crittenden Lane\nSuite 300\nMountain View, CA 94043</text>
> </label>
> 
> Make sense? Any objections?

Makes sense to me, although I'd prefer to just drop the fields entirely.

The only potential objection I see would be "we're trying to follow
X.520", but that seems pretty weak since ADR right now is some kind of
blend of what they call "Geographical Attributes" and "Postal
Addressing", and some X.520 fields are missing too.

So I personally would have no objection in removing those two fields.

If the working group agrees, I'll remove them.

> PS: Do you know if there's any way in vCard to say "this 'adr' and this
> 'label' correspond to the same physical address?". Just saying "they
> both have type=work" isn't really sufficient since you might work out of
> multiple offices, say, or have a second vacation home.

Very good observation! There is no such way. We need one.

> In PoCo, we chose
> to combine them by having a "formatted" value for the unstructured
> address alongside the structured counterparts. This is very useful for
> "round-tripping" complex addresses with programs like Outlook that let
> you edit both the structured and unstructured versions of the same address.

How would the working-group feel about merging ADR and LABEL to solve
this issue? LABEL would simply be an additional field in ADR, much like
in PoCo.

(How would these changes affect the last call status of the draft?)

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

Received on Thursday, 9 September 2010 14:27:41 UTC