[VCARDDAV] Last call comments on vcardrev-11

[Cyrus Daboo <[e-mail]>]

Hi,
Below are my last call comments on the main draft. Many are editorial in 
nature, and some are more substantive - the later are prefixed with a "*".

---

General comment: inconsistent capitalization. e.g. Section 5.6 has '"type" 
parameter' and 'TYPE parameter'. We should use one style of capitalization 
and quotation throughout. No doubt the RFC editor would catch this but we 
can help than out a little by fixing it ourselves.

Section 3.2: ANNIVERSARY missing from name = ABNF.

Section 3.2: calscale-param missing from param = ABNF.

Section 4.3.2 change "Midnight" to "The midnight hour".

Section 5: For consistency the GEO and TZ parameters should be defined in 
this section.

* Section 5.2: This talks about "Content-Transfer-Encoding" which comes 
from MIME. But there is no reference. I don't think we should be talking 
about how vCards are MIME encoded - the MIME specs take care of that. Plus 
HTTP (e.g. CardDAV uses Transfer-Encoding as its header). Probably best to 
generalize the text here to simply mention that a "transport encoding" may 
be applied to the whole vcard and that is independent of any "ENCODING" 
used for property values. I would also like to see an explicit reference to 
the appropriate MIME spec for the "base64" mention.

Section 5.2: The "b" parameter value should be case-insensitive. We need to 
explicitly state that or use "b"/"B".

Section 5.4: The ABNF should probably be defined in terms of a "positive 
integer between 1 and 100".

Section 5.5: Change "only may have" to "only have".

Section 5.5: Add "positive" in front of "integer" and "integers".

Section 5.6: Change "in case the" to "in the case that".

* Section 5.6: The restriction on "work" and "home" usage related to 
presence and value of "KIND" seems a little odd. What is more, it does not 
use RFC2119 key words so it is not clear if this is a "real" requirement or 
not. This needs to be better defined, or the restriction should be removed.

* Section 6.1.5: "group" should not be restricted to a group of "people". 
For example, I might want a group for all the locations in a particular 
building.

* Section 6.1.6: So we need to allow for binary content in addition to 
text. Point being that newer versions of XML do allow for control 
characters in the XML - but vCard does not allow control characters. So a 
base64 encoding would be needed to handle that. 
(http://tools.ietf.org/html/draft-daboo-et-al-icalendar-in-xml-04 also has 
the same problem). We might also need a "VERSION" parameter to indicate the 
expected XML version being generated.

Section 6.2.5 & 6.2.6: Not wrong, but I do not understand why the -param 
ABNF definitions are split into two. The PHOTO property ABNF uses a 
different style of syntax element grouping to achieve the same kind of 
thing.

* Section 6.2.7 & 6.2.8 - BIRTH/DEATH: since we can represent locations via 
a vCard we should allow a reference to a vCard via a URI as a value type 
for these two properties.

* Section 6.2.9: Can we not restrict ANNIVERSARY to just marriage? For 
example, for an organization I might want to specify the date of 
incorporation or founding etc. Ideally there would be a TYPE parameter on 
this property that could have pre-defined types like "marriage", 
"founding", "incorporation", "purchase".

Section 6.4.1: "textphone" is not listed in the type-param-tel = ABNF.

Section 6.5.1: Change "DST" to "daylight savings time". Change "in may 
regions" to "in many regions". Change "offset entirely" to "overall offset".

* Section 6.6.6: I still believe we should have "father", "mother", 
"brother" and "sister". In the case where the value is just text it would 
be better to have the more specific types.

Section 6.6.6: Change "sometimes on" to "sometimes act on".

Section 6.6.6: Remove: 'starting with "X-"'.

Section 6.7.9: Should not use "real" names in the example domains. Just use 
the example.org one by itself.

Section 6.8.2: Change: "a value outside of this MIME entity" to "an 
external value".

* Section 6.8.2: Why is the TYPE parameter not allowed with a URI value? 
e.g. PHOTO, LOGO and SOUND all allow TYPE with a URI value. Actually the 
example in Section 8 uses TYPE=work. So what should type be? A MIME type, 
or work/home indicator. And why can TYPE be either of those? iCalendar uses 
FMTTYPE for the MIME type parameter, I think we should take the opportunity 
with this revision to fix the overloading of the TYPE parameter. Lets add 
FMTTYPE as the MIME type parameter.

* Section 6.8.2: The Encoding section talks about a "text value" where the 
encoding is "8bit", but the only value types defined are binary and URI. Is 
value=text allowed (and I think it should be because some key formats are 
text based)? If so, the ABNF needs adjusting, otherwise the Encoding text 
needs to be adjusted.

Section 6.9.1: Change: "To specify the URI for a user's busy time in a 
vCard object." to "To specify the URI for the busy time associated with the 
object that the vCard represents."

Section 6.9.1 (and elsewhere): Please add informative reference to RFC 5545 
for occurrences of "iCalendar".

Section 6.9.1: "last six weeks" - realistically the range of busy time 
returned is implementation defined. Plus it would not be the "last" six 
weeks, but rather the "next" six weeks. So change "last six weeks" to "next 
few weeks or months". Also remove "users's" - this can apply to resources 
too.

Section 6.9.2: Change "location" to "calendar user address [RFC5545]". 
Change "an event request" to "a scheduling request [RFC5546]". Change 
"user" to "user or resource".

Section 6.9.3: Change: "To specify the URI for a user's calendar in a vCard 
object." to "To specify the URI for a calendar associated with the object 
that the vCard represents."

* Section 9: 5th bullet: I am not sure URL is the right property to refer 
to. I think SOURCE is better. SOURCE should point to a "definitive" source 
for the data in the vCard.

* Section 10.1: (as per previous email) please add a "version" parameter to 
the MIME type to make content negotiation easier with CardDAV.

* Section 10.2.4: why aren't VND- parameters allowed?

Section A.3: add XML and CLIENTPIDMAP as new properties.



-- 
Cyrus Daboo