IETF Review of the RFC 2447bis-05 draft:
iCalendar Message-Based Interoperability Protocol (iMIP)
October 1, 2008
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 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.
- Abstract p.3: Insert »the« in »a product of the
Calendaring and Scheduling Standards Simplification (calsify) working group.«.
-
There should be some space between the Table of Contents and
the headline for this section.
- First sentence, p.3: »transport-specific« instead of »transport specific«
-
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.
- 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.
- 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?
- 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?
- 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.
- 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«.
- Sec 2.4, p.7: I suppose the MIME type should be »"multipart/alternative"« rather than »"multiple/alternative"«
- 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.
- Sec 2.5, p.8: The linebreaking of the example is incorrect.
-
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".
- 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.
- 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.
- 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«).
- 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.
-
Several examples use an "ATTSTAT" parameter for ATTENDEE. This should rather be "PARTSTAT"
- 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.
- Sec 4.5, p.15: The DUE date is in the wrong format »DUE:19970701T090000-0700«, which should rather be »DUE:19970701T160000Z«.
- Sec 4.5, p.15: The STATUS value of the VTODO should be »NEEDS-ACTION« rather than »NEEDS ACTION«.
- 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.
-
Sec 5.1, p.17: There should be a comma after »If they are not«.