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

RE: vCalendar/vCard commentary

On Mon, 20 Jan 1997, Frank Dawson wrote:

> Appreciate the health-warning on the comments, but no ill-effects found
> in your comments! 

Glad to hear it.

>  1. The "BEGIN:"/"END:" mechanism does not appear to be specified in a
> general manner. 
> Good point. A more general syntax is addressed in the vCard work in
> IETF-ASID documents about a MIME directory content based on the MIME
> multipart/related type. 

This seems like an odd direction -- MIME isn't really a part of vCard. I
was thinking more on the lines of having the spec simply alert
implementors that interior objects of any type may be included at any
point. The YACC code in the SDK and the EBNF in the documentation implies
that only "BEGIN:VCARD" will be accepted in vCards, etc. This strongly
prevents someone from adding something new as an interior object. Simply
generalizing the rules so that _any_ BEGIN:foo will be accepted and
matched by END:foo would fix the problem. 

>  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. 
> Certainly, it is not expected that *every* media type be supported.
> Based on the implementations todate, I am not convinced that there are
> too many types.

It's not so much a case of too many possible types as too many _likely_
types.  An Apple implementation might generate LOGOs in "PICT" format, for
simplicity, and a Windows implementation WMFs. Both of these format are
complex composite formats that are closely tied to manipulation routines
in the originating OS. Both would be practically useless to something like
a PDA, or indeed the opposite OS. Neither are _interchange_ formats, which
GIF, PNG, and JPG actually are.

>  4. The version number should be specified as the first item after the
> "BEGIN:*". 
> The properties are not intended to be ordered any further than the
> BEGIN:xyz scoping. This maybe an instance where an ordering might be
> helpful. However, I am not convinced that this is a big hit on a parser
> that will have to be fairly tolerant of many other "gotchas" in a data
> stream and be able to resynchronize on a property subsequent to the one
> that it does not recognize. 

As far as I can see, this is a poor assumption. The idea of a version
field is to account for unforseen changes in the format. Presumably an
unforseen change could prevent acceptable parsing of the data.

The requirement could be that if a version property is included, it must
come directly after a BEGIN: statement. 

>  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...
> Good point. This was a doubled-edged opportunity to make the syntax
> lighter-weight for small footprint environments. For the case you
> specify, wouldn't the implementation know it is parsing an
> unknown/future version and be more tolerant with its errors fallback? 

Presumably, but by not being able to decide what parameter the value
belongs to, intelligent decoding is hampered. Consider the non-compliant
   PHOTO;QED: ... data ...
   PHOTO;GIF;BASE64: ... data ...

Without further information, there is no way to tell whether "QED" is a
graphics type or an encoding type. If the former, intelligent recovery is
possible (search for external utilities that can handle the format, or
look for alternative image types), but if the latter the parser probably
should abort. But only an abort is possible since the unknown type cannot
be categorized.

Again, this is similar to the version problem: the unforseen future is
being pushed into the future -- always a dangerous tack.

I can't see a simple solution for this one. If you put back the
information that has been lost, you lose the brevity of the compact

Perhaps the system could be redesigned to use shortcuts: "E" is specified
as an alias for "ENCODING-TYPE", "T" for "TYPE". If no parameter is given,
it is assumed to be the same as the previous one. Thus:


(Hmm. I may have just reinvented X.500 addressing.)

>  7. The BDAY item seems limiting. I would suggest this be replaced with a
> "IDATE;TYPE=BDAY:" 'important date' item, or something similar.
> Good suggestion. Suggest making this to IETF-ASID mailing list. It is
> ssible that "TYPE" is more appropriately a "CATEGORY"; similar to the
> PIM categories. Or even "DESCRIPTION" rather than "TYPE". 

CATEGORY might work, though TYPE would do as well.

> 9. The LANGUAGE parameter description comments that a language type may
> not make sense for some items (PHOTO, LOGO, TEL, etc.) 
> The clarification text about LANGUAGE was included in a latter release
> based on some discussion from a number of vendors that this property
> would be useless with some properties. Can't please everyone... 

Oops. Oh well, I think I'll leave that one alone. :-)

> 10. The DAYLIGHT parameter is potentially inaccurate or even useless. 
> Many places in the world have timezones that change in irregular fashions...
> Nothing to prevent DAYLIGHT from being specified more than once for each
> year that it changes. This is similar to the database that you reference
> at the NIH web site.

The problem here is that this only deals with historical rules. Once a
vCard is more then a year old (at most) the timezone rules included will
cease to be of any real use. Only via a perpetually updated database (like
the one at the NIH site) can time zones properly be tracked. 

> In addition, there is discussion about adding the value component that
> indicates what date/time that the rule was issued.

Yes, that would at least allow intelligent use of the data.

> Additionally, there has been discussion that field with the DST-begin
> and ST-begin be allowed to be a recurrence rule. 

Again, same problem. While this might be able to cope with historical and
current rules, there is no way it can deal with futures changes. (Some
places still even proclaim DST each year instead of having fixed rules). 

The only rational solution I can see is a naming schema whereby a timezone
name included on the vCard can be looked up in current reference material
by the reader. Unfortunately, as I said, I'm not aware of any such naming

I'm not trying to take this all out on vCard, I'd just love to see
something get it _right_, for a change. But if it doesn't, it will hardly
be in bad company. :-) 

> 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)...
> Yep...using the URL or CID/MID the values for ATTENDEE and LOCATION
> could be a vCard. 

You missed my point: can a vCard be _directly_ included in the vEvent
object? I'm talking about something like this:


This would be directly equivalent to the AGENT property in vCards. It
would seem that this usage would be desirable if you wanted to ship the
entire contents of a meeting in go. 


Anyhow, thanks for your return comments. I'll check out the other lists
you mentioned.

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