[VCARDDAV] Comments on wiki review, was Re: vcardrev+xml next steps

[Cyrus Daboo <[e-mail]>]

Hi Tantek,

--On October 10, 2010 8:53:34 AM -0700 Tantek Çelik 
<[e-mail]> wrote:

> I've written up my section by section feedback for vCard4 draft 13
> here with short descriptions of the specific and actionable issues and
> alternate text to the current text as well:
>
> [1] https://wiki.mozilla.org/VCard4#draft_13_section_by_section_review

Below are my comments on specific sections you commented on (not all of 
them but the ones I care about most):

Section 5.4 PREF: a preference for properties that appear multi times is 
vital. Many people nowadays have multiple email addresses, IMs etc. There 
needs to be a way to specify an order.

Section 5.8 CALSCALE: see my reply to Rohit's comment on this. I believe 
there is a valid use case for this and there are clients that allow 
entering dates in other calendar scales by virtue of OS locale changes.

Section 5.12: the need for VERSION is specific to the XML property. An 
alternative would be to call it XML-VERSION to clarify its only use is on 
that property.

Section 6.1.4 KIND: as noted in my reply to your general points, I believe 
this should be kept.

Section 6.1.5 XML: the XML property is required to allow XML data 
extensions (ones not in the vcard XML namespace) to be transported intact 
in vCard text format. I believe we should keep this.

Section 6.2.2 N: I would be OK with a change back to the original N format.

Section 6.2.6 DDAY: as I have mentioned previous, the anniversary of a 
person's death is an important date in some cultures. This is not strictly 
a "genealogy" use case. That said, I do like your idea of allowing a 
"checkbox" option. That could trivially be done by allowing a boolean value 
in addition to date-time and text. I think that would be better than 
placing some special meaning on a particular text value.

Section 6.3.1 ADR: I think your recommendations are fine.

Section 6.4.1 TEL: I believe it makes sense to keep this as-is. tel: URIs 
have so many benefits over "free form" text entry that we should mandate 
their use from now on.

Section 6.6.5 MEMBER: I disagree. Many contact apps have the concept of a 
"group" and it should be possible to represent those in vCard too.

Section 6.6.6 RELATED: I disagree - this should be part of the base spec. 
Many contact apps allow specifying relationships to cards of family 
members, co-workers etc.

new Property ACCOUNT: not convinced we should have this right now. There is 
work going on to define an acct URI for example, that could be used for 
this.

Section 6.9 calendar props: I disagree - calendar information, in 
particular freebusy URLs are commonly included in contact apps that are 
part of PIM systems (once that including email, contacts and calendar into 
one). As a big proponent of trying to make internet calendaring and 
scheduling more ubiquitous I would strongly urge that we keep these.

Section 7 Sync: the issue of whether this should be a separate document or 
not came up in the past and the WG decided to keep it in the core. This new 
feature is in fact one of the key requirements for the v4 update so I 
strongly urge we keep this.



-- 
Cyrus Daboo