IETF Review of the RFC 2447bis-05 draft:
iCalendar Message-Based Interoperability Protocol (iMIP)

Reviewer: Reinhold Kainhofer

October 1, 2008

About this review

Since this draft is an update to an already existing standard, I will not comment on its usefulness in general, but rather concentrate on technical details. In particular, I looked at possible contradictions to rfc2445bis-08 and rfc2446bis-07, unclear explanations, formulations that might possibly be misunderstood, and typos.

Quotes from the draft as well as text to be inserted into the draft will be placed in »guillemets« to distinguish them from text in quotations marks in the draft (like all property and method names).

Abstract

  1. Abstract p.2: The second sentence of the abstract is not clear to me: In my understanding, the calendar entries are composed using RFC 2445, but are then wrapped using constructs from the listed MIME RFCs.

  2. Abstract p.3: Insert »the« in »a product of the Calendaring and Scheduling Standards Simplification (calsify) working group.«.

Introduction

  1. There should be some space between the Table of Contents and the headline for this section.

  2. First sentence, p.3: »transport-specific« instead of »transport specific«

MIME Message Format Binding

  1. Sec.2, p.5: I would write »Typically, the originator is the "Organizer" of an event and the respondent is an "Attendee" of the event.« to make it clear that »Typically« also applies to the respondent, since for the REFRESH method the roles might be reversed.

  2. Sec.2.2, p.5: The capitalization of »Authentication«, »Authorization« and »Confidentiality« is inconsistent. I would use lower-case initial letters for all of them.

  3. Sec.2.2.1, p.5: I don't know the English grammar enough to judge this, but is it correct to say »...only the "Organizer" is authorized to modify ... entries they organize.«. In particular, is the plural »they« grammatically correct?

  4. Sec 2.2.1, p.5/6: The last sentence on page 5 says that the "Organizer" must ignore a message from spoof@..., while the last sentence of this section says that it is left to implementations to provide mechanisms to treat the "sent-by". Aren't these two sentences contradicting each other? Also, what exactly is meant by »an iTIP] message from spoof@xyz.example.net«? Section 2 says that the Reply-To header cannot reliably be used to determine the sender, so how can one determine it?

  5. Sec 2.4, p.6: This section says that »The value MUST be the same as the value of the "METHOD" calendar property...«. Section "5.1. Syntax of the Content-Type Header Field" of RFC 2045 on the other hand says that the parameter values of the Content-Type parameters are typically case-sensitive. It should be clarified whether the method parameter for Content-Type is case-insensitive or not. In particular, the example in the middle of page 7 uses »method=request«, while all other examples in the draft use »method=REQUEST«. I don't think it should be case-sensitive, as the enumerated METHOD property values are not case sensitive according to RFC 2445bis, either.

  6. Sec 2.4, p.7: Are the component parameter values case-sensitive? In particular, RFC 2445bis defines the calendar components (VEVENT, VTODO, etc.) only in upper case, so I think the component parameter should be case-sensitive and match exactly the calendar component as it appears in the calendar. The example in the middle of page 7 uses »vevent«.

  7. Sec 2.4, p.7: I suppose the MIME type should be »"multipart/alternative"« rather than »"multiple/alternative"«

  8. Sec 2.4, p.7: Use the plural »CUAs« in »CUAs can use language and ...«. This is done in several places in RFC 2446bis already.

  9. Sec 2.5, p.8: The linebreaking of the example is incorrect.

Security Considerations

  1. Item 1 of the list: A message can also be sent as a REPLY by an "other CU", who was forwarded a REQUEST... In this case, the message should be signed by the "other CU".

  2. Item 1 of the list: The current comment to allow signing by the person sending on their behalf again build down to the question how to determine if that person is allowed to send on the Organizer's or Attendee's behalf.

  3. Item 3 of the list: This item says to ignore the message if it cannot be correlated to an Attendee or Organizer. This, however creates problems with forwarded/delegated calendar components and out-of-sequence replies. In particular, imagine an attendee delegating a VEVENT to user2. If the REPLY of user2 reaches the Organizer prior to the REPLY of user1 delegating to user2, the Organizer will not know anything about the delegation and thus ignore the REPLY of user2 if he follows the advice of this list item...

    This, in turn creates further problems: user2 will not know that the Organizer ignored his message and that he was not added as an ATTENDEE. Consequently, he will not get any REQUEST messages when the VEVENT is changed (e.g. to a different location or a different time) and still assume the original date and location.

  4. In the sentence »and SHOULD ignore the message, unless explicitly overriden by the user.«, it should be clarified that »the user« in this context means the receiving user rather than the sending user (which would make all security void...). Also, there is a typo (»overriden« instead of the correct »overridden«).

  5. The advice in the second-to-last sentence of the section (»One way to achieve this is to reject iMIP messages sent by users other than the "ORGANIZER" or the "ATTENDEE"s.«) makes forwarding and sending on behalf of others impossible (why do we have these actions specified at all, then?) and creates problems with out-of-sequence replies on delegation as explained above.

Examples

  1. Several examples use an "ATTSTAT" parameter for ATTENDEE. This should rather be "PARTSTAT"

  2. All examples use .vcs as the file name extension, while RFC 2445bis defines the default file name extension for iCalendar files to be .ics. This should be changed.

  3. Sec 4.5, p.15: The DUE date is in the wrong format »DUE:19970701T090000-0700«, which should rather be »DUE:19970701T160000Z«.

  4. Sec 4.5, p.15: The STATUS value of the VTODO should be »NEEDS-ACTION« rather than »NEEDS ACTION«.

  5. Sec 4.6, p.16: There are no PROFILE and PROFILE-VERSION properties for VCALENDAR. PROFILE should be changed to METHOD and the PROFILE-VERSION property should be deleted.

Recommended Practices

  1. Sec 5.1, p.17: There should be a comma after »If they are not«.