[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

vCalendar/vCard commentary

Greetings, all. First a word of introduction: to my knowledge I'm not
affiliated with anyone who has a direct business interest in vCal/Card,
and I am talking here solely as an individual/amateur who is interested in
using these proposed standards as an interchange format for some PDA
interface software that is being developed at an unofficial and amateur

All that given, I'd like to donate some comments I have on reading the
vcal-1.0 standard and the vcard-2.1 standard. These comments are given in
the interest of improving these standards for all, and if I manage to
offend or step on anyones toes, I will apologize and make a polite
retreat. I apologize in advance if I have misread or failed to notice
portions of the standards documents that influence the discussion below. 

In regards to both vCal and vCard:

 1. The "BEGIN:"/"END:" mechanism does not appear to be specified in a
general manner. This could result in parsers only looking for begin tokens
for known object types, and thus badly misinterpreting any interior data
contained in other (to be specified in the future) interior objects.  It
seems that the specification should instead state "BEGIN:xyz" to be
matched by "END:xyz", that nesting rules apply, and that data inside
unknown types may be ignored, but nesting must still be tracked. On a
similar note, it's unclear how encoding mechanisms (especially in X-
items) interact with BEGIN tokens.

 2. In many places multiple types of data are allowed (images, bitmaps,
audio, movies, phone numbers, etc.), but it would put a severe strain on
readers to support all possible types. In the case of a PDA, supporting
more then one of each type is unlikely. Hence, there should be one format
(preferably a common and easily decoded/encoded one) in each grouping that
is marked "preferable", and that compliant writers be recommended to
support data in that format, and that readers should try and support that
format above others. The standard does not need to make an enforcement of
this, but by naming one format, de facto implementations will be more
likely to be compatible. 

 3. It is unclear what readers should do when faced with multiple entries
of a similar nature but different type (say, PHOTO;GIF and PHOTO;JPG). If
it is intended that this be allowed as an alternation system whereby the
writer includes all relevant formats, and the reader is free to pick the
one it is most comfortable with, then the standard should mention this, if
not require this behaviour.

 4. The version number should be specified as the first item after the
"BEGIN:*". Without this, if a subsequent version adds new item encodings,
adds new object types, or otherwise modifies the parsing rules, a classic
parser could get completely confused _before_ reaching the version number
telling it that it does not have the ability to parse the data.

 5. The parameter defaulting mechanism (replacing "X;Y=Z:" with "X;Z:" 
where Z is unambiguous) leads to potential problems in de facto
implementations if the reader is not fully compliant and tries to read
future versions, and if a writer is not fully compliant and includes data
types ("PNG", let's say) not mentioned in the standard. In either case,
the introduction of a new type, either graphics or encoding, cannot be
detected, leading to limited diagnostic capabilities in non-compliant
readers. Consider this non-compliant vCard:


A non-compliant reader that tries to parse this would not be able to
determine that the photo is in PNG format, merely that no format has been
specified for it, and an unknown "PNG" keyword was found. If the fact that
PNG was a type could have been determined, then the options for the reader
are wider: in can alert the user that a PNG format picture is
unacceptable, or it can even try passing the data to any programs that
have registered themselves as supporting the "PNG" format. Similarly, if a
non-compliant reader wants to attempt support for future versions of the
spec, there is no way to recognize future encoding types, due to the same
problem. Without some way of telling that X in "A;B;X:Z" refers to an
encoding type, true diagnostics (in this case aborting the parse) are not
possible in non-compliant readers.

The simplest solution to this (assuming it is viewed as a problem) would
be to limit or remove the parameter defaulting idea, so that any
parameters can be unambiguously decoded, even without reference to a
matching version of the spec. I am not sure how this can be accomplished
in a matter that retains the current brevity. 

 6. The PNG (Portable Network Graphics) format should be directly
supported, as it is the official replacement for GIF. Adding "PNG" as a
graphics type should be sufficient. 

In regards to vCard:

 7. The BDAY item seems limiting. I would suggest this be replaced with a
"IDATE;TYPE=BDAY:" 'important date' item, or something similar. 

In regards to vCalendar:

 8. The AALARM item should support some type of sequenced audio in
addition to digitized audio. (E.g., MID vs. WAV). Sequenced audio is much
more compact, and may well be sufficient for the need. More importantly,
many more PDAs/handhelds have support for tone playback then digital audio

 9. The LANGUAGE parameter description comments that a language type may
not make sense for some items (PHOTO, LOGO, TEL, etc.) I suggest this
comment be removed, as a LANGUAGE parameter may well make sense if the
photo includes text, if the logo includes text or audio, or if the person
at the other end of the telephone connection is not omnilingual. Including
redundant TEL items with a different language parameter for each one would
seem like an important possibility.

 10. The DAYLIGHT parameter is potentially inaccurate or even useless. 
Many places in the world have timezones that change in irregular fashions
through the years, and a single range is often inadaquite to fully
encompass the needed rules. The DAYLIGHT parameter will, at the very
least, be practically useless after one years time, thus reducing the
quality of historical vCards. As no such data can be expected to predict
the political rules to come after it has been written, I suggest that
DAYLIGHT be extended to include a standardized name for the timezone in
question, as the "designations" currently mentioned for standard and
daylight times being are quite inadaquite. ("DST" could be any number of
different places). With this name, the reader is free to look up the
timezone in any more recent databases it has available. Unfortunately I am
not aware of any standarization work that would provide a suitable
resource of official names. I am only aware of the de facto work
encompassed by the timezone package available (at last count) at

 11. The description of the ATTENDEE property does not clarify whether a
vCard object may be directly included inside the vEvent/vTodo object. The
implication of the text is that only an external (URL, most likely) 
reference may be made. Generalizing this to the inclusion of an interior
vCard object would seem sensible. 

 12. The same as #11 applies for LOCATION.

 13. The MALARM property assumes an Internet as that address to be mailed
the "alarm". A question arises as to whether anyone will ever want a
different address type (CIS, AOL, etc.) here. On the other hand, using
internet addresses as canonical addresses has equal merit. You decide
whether this is a problem.

 14. The interaction between RRULE/EXRULE and RDATE/EXDATE does not appear
to be specified. Does one override the other? Are they merged?


Well, that's my list for right now. I apologize for indundating you with
all this text, and I thank anyone who happened to read all the way to the
bottom. I hope these comments will aid in improving these fledgling


Kenneth Albanowski (kjahds@xxxxxxxxxx, CIS: 70705,126)