Re: [VCARDDAV] Draft agenda

[Chris Newman <[e-mail]>]

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

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.

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.

ORG-DIRECTORY is interesting, but I'd like an example with an LDAP URL.

Some of these may have security and/or privacy considerations -- the 
PUBLICNOTE is sensitive. The SERVICE or SOCIALPROFILE enables automated 
"friend invite" spam.

> (5 min) draft-george-vcarddav-vcard-extension

I concur with Barry's comment about DEPICTION. I'm not sure how it differs 
from PHOTO.

The SOCIALPROFILE needs to accommodate the "SERVICE" facilities from cab 
extensions.

> (5 min) draft-daboo-vcard-service-type

Looks good to me

> (5 min) draft-cal-resource-schema

There are some attributes that are comma-separated lists that I think 
should be represented as multi-valued attributes in LDAP. LDAP searching 
and indexing works better on multi-valued attributes than on structured 
values. If you want to continue the non-traditional use of comma-separated 
values in LDAP, the document should say why that is done. Given how easy it 
is to turn a comma-list into a multi-value array, I don't consider having 
LDAP differ from vCard a sufficient reason by itself. LDAP has native data 
models as does vCard and they are different in this case. This applies to 
"Categories" and "InventoryList" -- both seems like things one might want 
to search.

The BookingWindow attributes should probably reference RFC 3339 Appendix A 
"Duration" section so implementers have easy access to the syntax/ABNF.

> (5 min) draft-li-vcarddav-vcard-id-property-extensions

looks good to me.

> (5 min) draft-saintandre-vcarddav-thing

looks good to me.

> (5 min) draft-daboo-carddav-directory-gateway

Didn't think about this in too much detail but a cursory read looks good to 
me. If you feel this needs a deep analysis (given I've implemented an LDAP 
client library and LDAP simulator), then I will try to find time to do that.

> (20 min) Charter discussion

There seem to be a number of concrete drafts to review and advance. Seems 
premature to shut down the group and dump this stuff on APPSAWG as long as 
energy exists in this group to continue to look at vcarddav extensions.

		- Chris