\documentclass[a4paper,11pt]{article} \usepackage[pdftex]{hyperref} \usepackage{url} \usepackage{geometry} \usepackage[english]{babel} \usepackage{enumitem} \usepackage{hyperlatex} \setcounter{htmldepth}{0} \texonly{ \geometry{left=2cm,right=2cm,bottom=2.5cm} \hypersetup{ colorlinks=true, pdftitle=IETF Review of the RFC 2446bis-07 (iTIP) draft, pdfauthor=Reinhold Kainhofer } } % Title Page \title{\textbf{IETF Review of the RFC 2447bis-05 draft:\\iCalendar Message-Based Interoperability Protocol (iMIP)}} \texonly{ \author{Reviewer: Reinhold Kainhofer, \url{reinhold@kainhofer.com}} } \htmlonly{ \author{Reviewer: \xlink{Reinhold Kainhofer}{mailto:reinhold@kainhofer.com}} \htmltitle{IETF Review of the RFC 2447bis-05 (iMIP) draft} } \date{October 1, 2008} \newcommand{\rfcquote}[1]{\texorhtml{\guillemotright}{\xmlent{raquo}}{#1}\texorhtml{\guillemotleft}{\xmlent{laquo}}} \htmlonly{ \renewcommand{\pagebreak}{} } \begin{document} \maketitle \texonly{ \tableofcontents } % \texonly{ % \pagebreak % } \section*{About this review} \addcontentsline{toc}{section}{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 \rfcquote{guillemets} to distinguish them from text in quotations marks in the draft (like all property and method names). \section*{Abstract} \addcontentsline{toc}{section}{Abstract} \begin{enumerate} \item 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. \item Abstract p.3: Insert \rfcquote{the} in \rfcquote{a product of the Calendaring and Scheduling Standards Simplification (calsify) working group.}. \end{enumerate} \section{Introduction} \begin{enumerate}[resume] \item There should be some space between the Table of Contents and the headline for this section. \item First sentence, p.3: \rfcquote{transport-specific} instead of \rfcquote{transport specific} \end{enumerate} \section{MIME Message Format Binding} \begin{enumerate}[resume] \item Sec.2, p.5: I would write \rfcquote{Typically, the originator is the "Organizer" of an event and the respondent is an "Attendee" of the event.} to make it clear that \rfcquote{Typically} also applies to the respondent, since for the REFRESH method the roles might be reversed. \item Sec.2.2, p.5: The capitalization of \rfcquote{Authentication}, \rfcquote{Authorization} and \rfcquote{Confidentiality} is inconsistent. I would use lower-case initial letters for all of them. \item Sec.2.2.1, p.5: I don't know the English grammar enough to judge this, but is it correct to say \rfcquote{...only the "Organizer" is authorized to modify ... entries \textit{they} organize.}. In particular, is the plural \rfcquote{they} grammatically correct? \item 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 \rfcquote{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? \item Sec 2.4, p.6: This section says that \rfcquote{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 \rfcquote{method=request}, while all other examples in the draft use \rfcquote{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. \item 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 \rfcquote{vevent}. \item Sec 2.4, p.7: I suppose the MIME type should be \rfcquote{"multipart/alternative"} rather than \rfcquote{"multiple/alternative"} \item Sec 2.4, p.7: Use the plural \rfcquote{CUAs} in \rfcquote{CUAs can use language and ...}. This is done in several places in RFC 2446bis already. \item Sec 2.5, p.8: The linebreaking of the example is incorrect. \end{enumerate} \section{Security Considerations} \begin{enumerate}[resume] \item 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 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 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. \item In the sentence \rfcquote{and SHOULD ignore the message, unless explicitly overriden by the user.}, it should be clarified that \rfcquote{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 (\rfcquote{overriden} instead of the correct \rfcquote{overridden}). \item The advice in the second-to-last sentence of the section (\rfcquote{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. \end{enumerate} \section{Examples} \begin{enumerate}[resume] \item Several examples use an "ATTSTAT" parameter for ATTENDEE. This should rather be "PARTSTAT" \item 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. \item Sec 4.5, p.15: The DUE date is in the wrong format \rfcquote{DUE:19970701T090000-0700}, which should rather be \rfcquote{DUE:19970701T160000Z}. \item Sec 4.5, p.15: The STATUS value of the VTODO should be \rfcquote{NEEDS-ACTION} rather than \rfcquote{NEEDS ACTION}. \item 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. \end{enumerate} \section{Recommended Practices} \begin{enumerate}[resume] \item Sec 5.1, p.17: There should be a comma after \rfcquote{If they are not}. \end{enumerate} \end{document}