Re: contact format coordination - next steps

>> and we dropped the
>> "post-office box" and "extended address" sub-fields, which in practice
>> are ill-defined and used by none of the major address book providers
>> we're aware of, preferring instead a single "streetAddress" multi-line
>> field, which is what almost everyone implements anyway and sticks in the
>> third sub-field of adr ("street address").

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

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?
Thanks, js

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

On Thu, Sep 9, 2010 at 4:55 AM, Simon Perreault <simon.perreault@viagenie.ca
> wrote:

> (+vcarddav)
>
> (Just trying to reply to the technical points concerning vCard...)
>
> On 2010-09-08 12:12, Joseph Smarr wrote:
> > For instance, compare the
> > representations of gender in Portable Contacts and the proposed vCard
> XML:
> >
> >     <gender>male</gender>
> >
> >     vs.
> >
> >     <sex><integer>1</integer></sex>
> >
> >
> > I think it's hard to argue that the first version (PoCo) is far more
> > readable and semantically clear.
>
> more readable: Agreed, but who cares? Users are not going to see this.
> more semantically clear: Disagree, the semantics of vCard are very well
> defined.
>
> Note that we had exactly <gender>male</gender> at the beginning and
> gradually changed it to what we have now, for two reasons:
>
> 1. It's better to follow standards. In this case, ISO 5218 applies. It
> says that the term "sex" is preferred, and defines the applicable
> values. Standards are good.
>
> 2. Usage of the <integer> element provides two advantages (which are not
> related to the sex property in particular, but apply at large):
>
>  - It allows using parameter elements which would be siblings of the
> value text-node otherwise, making the parser much simpler.
>
>  - It facilitates extensibility using XML namespaces.
>
> > Similarly, we chose to name the list of mailing address fields
> > "addresses" instead of vCard's anachronistic "adr"
>
> Again, why should anyone care about the names of the elements? Users are
> not going to see this.
>
> > and we dropped the
> > "post-office box" and "extended address" sub-fields, which in practice
> > are ill-defined and used by none of the major address book providers
> > we're aware of, preferring instead a single "streetAddress" multi-line
> > field, which is what almost everyone implements anyway and sticks in the
> > third sub-field of adr ("street address").
>
> This is also available in vCard. ADR is for formatted addresses whereas
> LABEL is for unformatted addresses.
>
> > vCard does not seem to have added
> > many (if any) social networking fields.
>
> Not in vCard *core*. A separate RFC will address this. The draft is here:
> http://tools.ietf.org/html/draft-george-vcarddav-vcard-extension-02
>
> Simon
> --
> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
> STUN/TURN server        --> http://numb.viagenie.ca
> vCard 4.0               --> http://www.vcarddav.org
>
>