Internet Calendaring and Scheduling Core Object Specification (iCalendar)
Note: This ballot was opened for revision 10 and is now closed.
(Chris Newman) Discuss
Discuss (2008-12-18 for -** No value found for 'p.get_dochistory.rev' **)
While this is a significant improvement over the original specification, I believe it still has many areas where it is unclear how to implement certain things, areas where the specification is inconsistent, areas where I'm there are interoperability issues and areas where it is unclear what features are mandatory-to-implement in order to have a compliant implementation of this specification. I believe this needs a revision focused on improvements in these areas. I'll include my review in the "IESG comments" field as it contains many non-discuss level issues that I feel may still be worth improvement.
Comment (2008-12-18 for -** No value found for 'p.get_dochistory.rev' **)
General: "local time" This term is used without being well defined. From my reading, "local time" is defined as any time which is not UTC or a fixed offset from UTC. It includes both specified local time (with a TZID) and floating local time (with no TZID). I believe the document would be much clearer if it distinguished these two cases consistently, perhaps by using separate terms (e.g., "specified local time" and "floating local time") consistently. I'm also concerned that the document is a bit lax about use of "floating local time". The cases where it usefully interoperates (2008-01-01T00:00:00 repeating annually is the only one that comes to mind) for multiple users are so few. Section 3.1.3 What is image/basic? Section 3.2 (in general) This section presents a lot of property parameters. But this gives me no idea of what a compliant implementation of iCalendar MUST or SHOULD do with the parameters to be compliant with this specification. Some of them are clearly fine to ignore (e.g., DIR=) while some of them will cause interoperability problems if not rendered to the end-user (e.g., DELEGATED-*). If the goal is to improve interoperability, I'd like to know what is expected of a complaint implementation for an iCalendar object for each of these parameters. Perhaps if we had statements like: Original Event Generation: OPTIONAL Event Reply Generation: OPTIONAL Event Reply Processing: MANDATORY to copy to original event UI Rendering: MANDATORY Where, for example, if it says "UI Rendering" then an implementation which renders events to a user is compliant with this specification if it does what's said there. This would make it clearer what a minimal implementation must do to interoperate. 3.2.7. Inline Encoding The example does not seem to be a valid JPG image preamble. 3.2.8. Format Type I don't understand how media type parameters can be distinguished from additional iCalendar property parameters. The ABNF seems ambiguous in context. Please explain. Section 3.2.19 > ... An > individual "VTIMEZONE" calendar component MUST be specified for > each unique "TZID" parameter value specified in the iCalendar > object. What happens if the TZID is one recognized by the system (perhaps because it begins with a "/"), and the system has a newer version of the rules for that VTIMEZONE element. What takes precedence? I would presume whichever ruleset is newer as that's most likely to achieve the intent of the human user. But the specification should make this clear. > The use of local time in a DATE-TIME or TIME value without the > "TZID" property parameter is to be interpreted as a local time > value, regardless of the existence of "VTIMEZONE" calendar > components in the iCalendar object. I do not understand what "local time value" means. Which local time? The local time of the system that generated the event? The local time of the system processing the event? How is this useful? How could this possibly interoperate? Section 3.3.10 In section 2 you say: > Note: All indented editorial notes, such as this one, are intended > to provide the reader with additional information. The > information is not essential to the building of an implementation and in this section you use "MUST" in a note. That's inconsistent. Either it's not a note or it makes no normative statements. I haven't finished my review yet, but I'm going to send this much out now to get discussions started.
(Lisa Dusseault) Yes
Alexey Melnikov (was Discuss) Yes
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lars Eggert) No Objection
Comment (2008-12-16 for -** No value found for 'p.get_dochistory.rev' **)
Section 3.2.6., paragraph 5: > Description: This parameter can be specified on properties with a > CAL-ADDRESS value type. The parameter specifies a reference to > the directory entry associated with the calendar user specified by > the property. The parameter value SHOULD be a CID [RFC2392], DATA > [RFC2397], FILE [RFC1738], FTP [RFC1738], HTTP [RFC2616], HTTPS > [RFC2818], LDAP [RFC4516], or MID [RFC2392] URI. The URI > parameter value MUST be specified in a quoted-string. What's the status of "file://" and "ftp://|? RFC1738 was obsoleted, and while "telnet://" and "gopher://" have been resurrected (RFC 4248, RFC 4266), I couldn't locate an RFC that did the same for these two. (Making this a comment, since I won't be on the call and I don't want to block.)
(Pasi Eronen) (was Discuss) No Objection
(Russ Housley) No Objection
Comment (2008-12-12 for -** No value found for 'p.get_dochistory.rev' **)
This minor error was caught in the Gen-ART Review by Gonzalo Camarillo: OLD: This property SHOULD not be used to alter the interpretation of NEW: This property SHOULD NOT be used to alter the interpretation of
(Cullen Jennings) No Objection
(Tim Polk) No Objection
(Dan Romascanu) No Objection
Comment (2008-12-17 for -** No value found for 'p.get_dochistory.rev' **)
I support Magnus's DISCUSS based on Lars's comment about the reference to RFC1738.
(Mark Townsley) No Objection
(David Ward) No Objection
Magnus Westerlund (was Discuss) No Objection
The ABNF is not formally correct: There are some multi-line rules containing empty lines, like calprops and many of the other <x>props rules. I understand that this is for readability however, it is against the ABNF rules. I guess most text editors and the XML to RFC tool are against you in that they will strip the white spaces on the empty lines. Maybe try to get the RFC-editor to ensure that there are white spaces on the empty lines within rules.