Re: [VCARDDAV] Last call on vCard extensions from OMA CAB

[Cyrus Daboo <[e-mail]>]

Hi,
My feedback (sorry it is late):

Major:

- There is no mention of i18n issues. In particular all the freeform text 
properties need to support LANGUAGE and ALTID parameters, and follow the 
behaviors of those defined in 6350. Basically, all the properties defined 
in this spec must follow similar syntax to TITLE and ROLE defined in 6350, 
since they are similar in nature to those. Please see the 6350 ABNF for the 
TITLE and ROLE parameters and make sure similar parameters are included - 
though I think there is an open question as to whether a TYPE parameter 
should be allowed on the new properties. For example, in my vCard I might 
want to put:

EXPERTISE;TYPE=home;LEVEL=beginner:kids soccer coach
EXPERTISE;TYPE=work;LEVEL=expert:Python programmer

So I think TYPE is valuable to have on the new properties.

- ORG-DIRECTORY - why is this a property as opposed to a parameter on the 
6350 ORG property? If it remains a property then it needs to have similar 
parameters to ORG defined on it (at least TYPE, PREF, PID and ALTID). Maybe 
also LANGUAGE if the URI points to a web page that might have localized 
variants?

- INDEX - who is responsible for making sure INDEX is specified 
consistently across a set of properties? What happens if two properties 
have the same INDEX value? What if some properties have INDEX and others do 
not - what is the default value? Are negative values (or zero) allowed?

- LEVEL - should allow for ' / iana-token / x-name' as value options and 
should define a registry of values.


Minor:

- §2.1,2.2,2.3 Value type - change 'A single string value.' to 'A single 
text value.'


Nits:

- §1.1, ¶3: change 'managed' to 'manages'

- §2.1, might be better phrasing Purpose this way:

    To specify a field of expertise for the object that the vCard refers to.


-- 
Cyrus Daboo