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

RE: vCalendar/vCard commentary



Kenneth:

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

Many of your comments make MUCH sense. Good perspectives...good recommendations. 

The discussion on the vCard progression as a standard is primarily taking place on the IETF ASID mailing list at ietf-asid@xxxxxxxxxx You may find that the vCard discussion gets lost in the traffic on "what should be in LDAPv3" discussion thread.

The discussion on the vCalendar progression as a standard is primarily taking place on the IETF CALSCH mailing list at ietf-calendar@xxxxxxxx

As to your suggested changes...

 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.

 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. 

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

Multiple occurrences of a property ARE allowed. In obvious cases where this may present ambiguity, clarification text was added (e.g., TEL). We may have missed some of these cases. However, your case has an obvious fallback...take the one you like. Multiple occurences can also be grouped (e.g., "A.PHOTO... B.PHOTO..." for two disjoint photographs) to avoid possible ambiguity.

 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.

 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?

 6. The PNG (Portable Network Graphics) format should be directly
supported, as it is the official replacement for GIF. 

Good suggestion. Should be made to the ASID  mailing list too.

 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 possible that "TYPE" is more appropriately a "CATEGORY"; similar to the PIM categories. Or even "DESCRIPTION" rather than "TYPE".

8. The AALARM item should support some type of sequenced audio in
addition to digitized audio. 

Hhmmm...Another good thought.

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

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. In addition, there is discussion about adding the value component that indicates what date/time that the rule was issued. Additionally, there has been discussion that field with the DST-begin and ST-begin be allowed to be a recurrence rule.

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.

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

Hhmm...I thought that we had addressed this with clarification text that indicated that these could be used in complement to define a recurrence set. I will look again at the text.

Cheers.

- - Frank Dawson