Re: [VCARDDAV] Last call comments on vcardrev-11

[Simon Perreault <[e-mail]>]

On 2010-05-31 13:38, Cyrus Daboo wrote:
> 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.

I tried to fix that in -12. If you see more of it, please let me know.

> Section 3.2: ANNIVERSARY missing from name = ABNF.

Fixed.

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

Fixed.

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

Fixed.

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

Agreed.

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

Agreed.

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

In ABNF, "b" is case-insensitive. I added text to make it explicit.

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

You mean adding a comment? Done.

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

Changed to "may have only". Isn't that better?

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

Done.

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

Fixed.

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

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.

Agreed.

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

Ok. So we allow the ENCODING parameter to specify base64 encoding.

> We might also need a "VERSION" parameter to
> indicate the expected XML version being generated.

Agreed.

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

It's just to make clear to which par the "Value and parameter MUST
match" comment applies.

The PHOTO property is a bit more involved because it has parameters that
may only be used with a given value type. It's basically the same idea.

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

Yes. This would also allow usage of the "geo" URI scheme.

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

ANNIVERSARY was added to the draft only because many current
implementations have such a non-standard property for specifying the
marriage anniversary. While it seems like a straightforward idea to me,
adding a TYPE parameter would depart from current usage. Figuring out
what type values to allow would amount to figuring out future usage.
Therefore I think it would be better to leave this feature for a future
extension.

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

Added.

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

Done.

> * Section 6.6.6: I still believe we should have "father", "mother",
> "brother" and "sister".

This was discussed before.
http://www.ietf.org/mail-archive/web/vcarddav/current/msg00787.html

The points raised against that proposal were:

- It's English-specific. For example in Hungarian you have 4 words:
"báty", "öcs", "nővér", and "húg".

- There is a lot more genealogy terminology that could be added.

- It's redundant with the SEX property.

> In the case where the value is just text it
> would be better to have the more specific types.

You are of course free to use X-sister and X-brother.

To me, the value being text and this issue seem orthogonal.

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

Fixed.

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

Done.

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

Agreed. Removed all examples but the example.org one.

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

Fixed.

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

I like this a lot. Done.

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

I did both. 8bit has no meaning for a text value, it is always UTF-8. So
I removed that sentence in the encoding section. I also changed the ABNF
to allow text.

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

Done.

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

Done.

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

Done.

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

Done.

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

Done.

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

Absolutely! Fixed.

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

Done.

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

Oversight. Added namespace field to parameters registry.

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

Done.

Whew! Thanks for the review!

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org