Subject: [VCARDDAV] Splitting ADR

From: <[email-masked]>
Date: Thu, 26 Mar 2009 02:02:30 +0100

Hi there,
during lunch Cyrus told me that splitting ADR in 4.0 has been discussed already.
I can't seen to find the related thread on the mailing list.
Could someone re-cap the major points about the why the did not happen?
Thank you.

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

---

From: Simon Perreault <[email-masked]>
Date: Wed, 25 Mar 2009 18:07:15 -0700

> during lunch Cyrus told me that splitting ADR in 4.0 has been discussed

I do not recall this discussion.

Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: <[email-masked]>
Date: Thu, 26 Mar 2009 02:31:28 +0100

Hi Simon,
if that's the case, let me trigger the discussion with this mail.

I propose that we get rid of the current syntax (the semi-colon-delimited value) as it is not very flexible. We do this for the sake of XML syntax already:
     <adr>
       <ext>Suite 625</ext>
       <street>2600 boul. Laurier</street>
       <locality>Quebec</locality>
       <region>QC</region>
       <postal>G1V 4W1</postal>
       <country>Canada</country>
     </adr>
so it would not be hard to do it in the plain text version.

Different countries have different addressing schemes.
Also, it would be nice to have it in an easily extensible fashion.

Any thoughts on this?
Thank you.

>-----Original Message-----
>From: ext Simon Perreault [mailto:[email-masked]] 
>Sent: 26 March, 2009 03:07
>To: Ordogh Zoltan (Nokia-D-MSW/Tampere)
>Cc: [email-masked]
>Subject: Re: [VCARDDAV] Splitting ADR
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 25 Mar 2009 18:39:18 -0700

[email-masked] wrote:
> I propose that we get rid of the current syntax (the semi-colon-delimited value) as it is not very flexible.

Some arguments against this proposal:

- Keeping the old syntax has the advantage of backward compatibility.
The WG has declined changing things just for the sake of changing things
(e.g. property names).

- The address model is mostly fixed as it reflects what's in X.520.

- Extensibility can already be achieved using parameters.

- The WG is chartered to update vCard preserving the general syntax. If
we were free to change syntax at will, we'd end up with something
looking like XML.

- How would this affect CardDAV?

Simon

---

From: <[email-masked]>
Date: Thu, 26 Mar 2009 02:58:12 +0100

Hi Simon,

>> I propose that we get rid of the current syntax (the 
>semi-colon-delimited value) as it is not very flexible.
>
>The WG has declined changing things just for the sake of 
>changing things (e.g. property names).

I think we are way past worrying about backwards compatibility - I am not even sure it was a design goal in the first place - at least it is not mentioned in the charter.

>- The address model is mostly fixed as it reflects what's in X.520.

That's ok, I have no problem with that, but there is a need for extensibility - and that means working around the limitations imposed by X.520.

>- Extensibility can already be achieved using parameters.

That's true of course, but it does not imply that have to keep the old syntax.

>
>- The WG is chartered to update vCard preserving the general 
>syntax. If we were free to change syntax at will, we'd end up 
>with something looking like XML.

I just sent another email about this - waiting for the flame. I have a fire extinguisher here ;-)

>- How would this affect CardDAV?

The pieces of the address field would still exist - truly, in a different form, but that should not be a problem, since the information can be still extracted. Therefore, I am not sure that it affect CardDAV. Cyrus?

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 25 Mar 2009 19:02:33 -0700

Hi [email-masked],

> Could someone re-cap the major points about the why the did not happen?

I believe at some time in the past I suggested use of the civic location 
work done by geopriv as an alternative, more modern, format for ADR. That 
may have been on slides for the BOF and discussed there.

I still believe we need a more modern format here, but the issue of 
backwards compatibility is important.

-- 
Cyrus Daboo

---

From: Mark Paterson <[email-masked]>
Date: Thu, 26 Mar 2009 11:18:55 -0400

Yep,

This issue was raised in the OMA DS contribution that was presented at 
the CalConnect vCard workshop ages ago and it was represented to the 
IETF gang in Philadelphia.

"Problem #6: Proper format for addresses not sufficiently defined"

It's been discussed a few times and I think if there was a postal 
address RFC we could refer to like we do for email addresses, telephone 
numbers, etc.. people would probably go for it but in the absence of 
such a thing, existing the conversations have tended to bog down since 
we don't want to get into being the people defining this grand new 
address scheme :-)

There are certainly efforts elsehwhere such as the civic location work 
done by geopriv that you mention below but there isn't anything like RFC 
3966 which made it easy to say telephone number values should adhere to 
the RFC.

I continue to agree that a more modern format would be good here.

Thanks,
Mark

Cyrus Daboo wrote:
> I believe at some time in the past I suggested use of the civic 
> location work done by geopriv as an alternative, more modern, format 
> for ADR. That may have been on slides for the BOF and discussed there.
>

-- 

Oracle Email Signature Logo
Mark Paterson | Product Manager, UC & Mobile Services | 514.905.8649
Oracle Server Technologies - Collaboration
600 Blvd. de Maisonneuve West, Suite 1900, Montreal, Quebec, H3A 3J2

---

From: Joseph Smarr <[email-masked]>
Date: Thu, 26 Mar 2009 09:07:07 -0700

FWIW when we looked at updating adr for Portable Contacts, it was clear that
essentially no major implementations of vCard actually use the first two
fields ("po box" and "extended address") and they all just do ;;street
address\neven multi line;city;state;zip;country (i.e. skip the first two
fields and put the entire address in the 3rd field). This makes sense since
most UI for entering addresses doesn't break out those first two fields, so
how are the apps supposed to guess at how to populate them. So in PoCo we
explicitly got rid of those first two fields and made "streetAddress" the
"full, potentially multi-line street address", which reflects what we
actually see in the wild.

So I'd love to see vCard 4.0 do the same thing. Those old fields are
confusing and not helpful and not properly used as is, IMO. You could keep
slots there for backwards-compatibility, but say they're deprecated and
shouldn't be used or something.

Thanks, js

2009/3/26 Mark Paterson <[email-masked]>

> Yep,
>
> This issue was raised in the OMA DS contribution that was presented at the
> CalConnect vCard workshop ages ago and it was represented to the IETF gang
> in Philadelphia.
>
> It's been discussed a few times and I think if there was a postal address
> RFC we could refer to like we do for email addresses, telephone numbers,
> etc.. people would probably go for it but in the absence of such a thing,
> existing the conversations have tended to bog down since we don't want to
> get into being the people defining this grand new address scheme :-)
>
> There are certainly efforts elsehwhere such as the civic location work done
> by geopriv that you mention below but there isn't anything like RFC 3966
> which made it easy to say telephone number values should adhere to the RFC.
>
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>
>

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 26 Mar 2009 09:15:45 -0700

Hi Joseph,

--On March 26, 2009 9:07:07 AM -0700 Joseph Smarr <[email-masked]> wrote:

> FWIW when we looked at updating adr for Portable Contacts, it was clear
> that essentially no major implementations of vCard actually use the first
> two fields ("po box" and "extended address") and they all just do
> ;;street address\neven multi line;city;state;zip;country (i.e. skip the
> first two fields and put the entire address in the 3rd field). This makes
> sense since most UI for entering addresses doesn't break out those first
> two fields, so how are the apps supposed to guess at how to populate
> them. So in PoCo we explicitly got rid of those first two fields and made
> "streetAddress" the "full, potentially multi-line street address", which
> reflects what we actually see in the wild.
>  
> confusing and not helpful and not properly used as is, IMO. You could
> keep slots there for backwards-compatibility, but say they're deprecated
> and shouldn't be used or something.
>  

Again, I think people should look at the more detailed format in 
<http://tools.ietf.org/html/rfc4119> and 
<http://tools.ietf.org/html/rfc5139>. Those allow for a much richer 
description of addresses that map to "real world" use of addresses across 
multiple locales. Whilst this results in a lot more fields, it does allow 
for accurate representation of addresses, whereas the current formats 
require users to shoehorn their real addresses into the fixed fields.

-- 
Cyrus Daboo

---

From: Joseph Smarr <[email-masked]>
Date: Thu, 26 Mar 2009 09:20:16 -0700

I appreciate the aspirational goal of finer-grained addresses being
represented, but I guess my point is if you look at the major address book
apps today (Outlook etc.), they only have one street-address field, so
practically speaking, they won't be able to divide it all up. And when you
specify all those extra slots, it creates confusion on the part of would-be
implementors about how to read/write what's out there. So maybe the
best-of-both-worlds scenario is to have a single street-address fields and
*also* some extra (redundant but more specific) fields to include in
addition if you happen to have more fine-grained info on the address? It's
just that right now it looks like if someone fills in a street address with
a PO Box or apartment number, it's the responsibility of the vCard generator
to recognize that and chop up the street address to stick it in those
different fields. And I think that's an unreasonable requirement, which
empirically has not been followed so far.

Thanks, js

On Thu, Mar 26, 2009 at 9:15 AM, Cyrus Daboo <[email-masked]> wrote:

> Again, I think people should look at the more detailed format in <
> http://tools.ietf.org/html/rfc4119> and <
> http://tools.ietf.org/html/rfc5139>. Those allow for a much richer