[VCARDDAV] Comments on draft-cauchie-vcarddav-oma-cab-extensions (Was: Draft agenda)

[Alexey Melnikov <[e-mail]>]

Hi Chris,
Thanks for doing such a good review. I found many of the same issues in 
mine and you expressed them very well.

Chris Newman wrote:
> I may not be able to attend due to the YAM conflict, but I have 
> reviewed these documents, so here is my feedback.
>
> --On July 14, 2011 9:09:06 -0400 Simon Perreault 
> <[e-mail]> wrote:
>> (5 min) draft-cauchie-vcarddav-oma-cab-extensions
> Overall, I find this the least refined of this set of extensions. From 
> the document, I do not understand what several of the properties mean. 
> Including CONTENT-STATUS-MAIN, CONTENT-STATUS-UPDATED, and 
> CONTENT-STATUS-TEMPORARY.
Agreed, I found these 3 to be really unclear.
> I gather this is some sort of subscription-based contact update 
> service, but if these attributes are specific to the OMA-CAB spec and 
> related protocol(s) they should probably have an OMA-CAB- prefix. The 
> CONTACT-ID-REF certainly seems to be an OMA-CAB specific reference 
> rather than a generally useful reference.
>
> The CONTACT-LANGUAGE property seems useful, but I don't see how to 
> specify that I can read and speak a language but not write the language.
+1. Another example: how to specify the ability to speak, but not read a 
language?
> The SERVICE property seems vague, I prefer the SOCIALPROFILE name in 
> draft-george-vcarddav-vcard-extension, although having a way to 
> distinguish the unique identifier used by that social service seems 
> useful.
>
> The EXPERTISE property seems fine.
>
> The distinction between HOBBY and INTEREST is a bit subtle, so I think 
> the model used in draft-george-vcarddav-vcard-extension is better.
+1.
> I don't understand PUBLICNOTE or how it might be used or presented in 
> a UI. The example looks like it's going to be used as a presence 
> status or something like that. Seems too vague to be useful.
+1.
> ORG-DIRECTORY is interesting, but I'd like an example with an LDAP URL.
Indeed.

Additionally: does use of a particular URI scheme  implies a particular 
data format? HTTP URIs (for example) don't provide enough information 
about format of the resource by themselves.
> Some of these may have security and/or privacy considerations -- the 
> PUBLICNOTE is sensitive. The SERVICE or SOCIALPROFILE enables 
> automated "friend invite" spam.

Some additional issues:

I would like to see at least statements about whether various properties 
have corresponding registries of allowed values, how unrecognized values 
should be treated (if allowed), etc.

It was not clear to me what was the purpose of the INDEX parameter. This 
issue applied to pretty much any property in the document.

There is the same ABNF error repeated everywhere in the document:

"VALUE=FOO-value"
 and
VALUE=" FOO-value

are not the same thing.

I couldn't understand the exact meaning of the CONTACT-ID-REF parameter. 
The description uses the word "reference", but doesn't say what it means 
in this case.

Definition of the INDEX parameter in section 3.4 is talking about 
"ranges", then says that the syntax is "token", but then uses an integer 
in the ABNF. So which is it?