Subject: [VCARDDAV] Draft agenda

From: Simon Perreault <[email-masked]>
Date: Thu, 14 Jul 2011 09:09:06 -0400

All,

I couldn't post the draft agenda yesterday because of a technical issue
with the datatracker. Until it is resolved, here's what I intend to propose:

(5 min) Introduction, agenda bashing, document statuses

Proposed work items quick discussion of open issues and future direction:
(5 min) draft-cauchie-vcarddav-oma-cab-extensions
(5 min) draft-george-vcarddav-vcard-extension
(5 min) draft-daboo-vcard-service-type
(5 min) draft-cal-resource-schema
(5 min) draft-li-vcarddav-vcard-id-property-extensions
(5 min) draft-saintandre-vcarddav-thing
(5 min) draft-daboo-carddav-directory-gateway

(20 min) Charter discussion

Basically I think we have two goals:
1. Decide on the future of this WG.
2. Make good use of the time we have together to move those drafts forward.

Comments?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Barry Leiba <[email-masked]>
Date: Thu, 14 Jul 2011 10:46:55 -0400

> with the datatracker. Until it is resolved, here's what I intend to propose:

WFM

Barry

---

From: Chris Newman <[email-masked]>
Date: Tue, 26 Jul 2011 14:57:19 -0400

I may not be able to attend due to the YAM conflict, but I have reviewed 
these documents, so here is my feedback.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 Jul 2011 10:31:22 -0400

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.
>
> 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. 
> 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 
> 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?
> draft-george-vcarddav-vcard-extension, although having a way to 
> distinguish the unique identifier used by that social service seems 
> useful.
>
> 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.
> 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?