Internet Calendaring and Scheduling Core Object Specification (iCalendar)
RFC 5545

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' **)
No email
send info
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' **)
No email
send info
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' **)
No email
send info
  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' **)
No email
send info
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

Comment (2008-12-17)
No email
send info
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.