\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 2446bis-07 draft:\\iCalendar Transport-Independent Interoperability Protocol (iTIP)}} \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 2446bis-07 (iTIP) draft} } \date{September 7, 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, unclear explanations, formulations that might possibly be misunderstood, and typos. The page-breaking of the draft is also not ideal, but I suppose this will be fixed in the final release, so I will not further comment on it. Even though several of the issues I found were already detailled in Lisa Dusseault's review, I will still list them here. I will go through the whole draft section by section, mixing comments of different types, like errors, unclear formulations, other suggestions and questions I still have, etc. I will use one item per issue I found, even when I found multiple issues in a section. This will make it easier to discuss the issues. Quotes from the draft and rfc2445bis as well as text to be inserted into the draft will be placed in \rfcquote{guillemets} to destinguish them from text in quotations marks in the draft (like all property and method names). \section*{General observations} \addcontentsline{toc}{section}{General observations} \begin{enumerate} \item The capitalization of \rfcquote{event} is inconsistent throughout the draft. Sometimes, \rfcquote{Event} is used inside a sentence, at other times \rfcquote{event} is used. \end{enumerate} \section{Introduction and overview} \begin{enumerate}[resume] \item Abstract (p.1): \rfcquote{calendar systems} should be replaced by \rfcquote{calendaring systems} to prevent any possible confusion. iTIP is only about the Gregorian calendar system. \item Sec.~1.3 (p.6): This draft also describes forwarding, where there is a third role involved, namely "Other CUs". Also, when delegating, the delegate is not an \rfcquote{"Attendee" asked to participate by the "Organizer"}, so it does not strictly fulfill the definition of the Attendee role of section 1.3., either. \item Sec.~1.3 (p.7): The definition of the Attendee uses \rfcquote{participate}, which does not make sense for to-dos. \item Sec.~1.4 (p.7): In the REQUEST Description: Change \rfcquote{Meeting Requests} to \rfcquote{Meeting requests} \item Sec.~1.4 (p.8): Why are Attendees not allowed to PUBLISH a group event? \end{enumerate} \section{Interoperability Models} \begin{enumerate}[resume] \item Sec.~2.1.1 (p.9): \rfcquote{When an "Organizer" issues the initial entry, "Attendee" status is unknown.} The Organizer might have had other communication with the Attendee and already know the status from other means than iTIP. I would insert the word \rfcquote{typically} before \rfcquote{unknown}. \item Sec.~2.1.4 (p.10f): This section heavily refers to the rules for incrementing the "SEQUENCE" number in [I\_D.ietf-calsify-rfc2445bis]. However, rfc2445bis-08 only says: \rfcquote{It is monotonically incremented by the "Organizer's" CUA each time the "Organizer" makes a significant revision to the calendar component.} The rest of the rules was removed from rfc2445bis in rfc2445bis-08, but has not been added to rfc2446bis. I propose to remove all references to rfc2445bis in this section and instead paste the rules into rfc2446bis: \begin{verbatim} The "SEQUENCE" property is used by the "Organizer" to indicate revisions to the calendar component. When the "Organizer" makes changes to one of the following properties, the sequence number MUST be incremented: * "DTSTART" * "DTEND" * "DURATION" * "DUE" * "RDATE" * "RRULE" * "EXDATE" * "STATUS" In addition, changes made by the "Organizer" to other properties MAY also require the sequence number to be incremented. The "Organizer" CUA MUST increment the sequence number whenever it makes changes to properties in the calendar component that the "Organizer" deems will jeopardize the validity of the participation status of the "Attendees". For example, changing the location of a meeting from one location to another distant location could effectively impact the participation status of the "Attendees". Depending on the METHOD, the "SEQUENCE" property MUST follow these rules in the context of iTIP: * For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property value is incremented according to the rules stated above. * The "SEQUENCE" property value MUST be incremented each time the ... [rest is taken as found in rfc2446bis-07] ... \end{verbatim} \item \label{SEQUENCE_MultipleUID}Sec.~2.1.5 (p.11/12): From this description, it appears to me that all calendar components with the same UID also need to have the SEQUENCE incremented simultaneously (i.e. if the Organizer changes just one occurrence from a recurring sequence, he must increase the SEQUENCE not only of that particular VEVENT, but also of the VEVENT containing the RRULE). This was not clear to me from rfc2445bis and is never clearly spelled out. In particular, rfc2445bis says on page 142 that \rfcquote{SEQUENCE defines the revision sequence number of the calendar component within a sequence of revisions} and defines calendar component on pages 52ff as any VEVENT, VTODO, VJOURNAL, etc. inside the VCALENDAR. In particular, a VEVENT with an RRULE and another VEVENT with the same UID, but using RECURRENCE-ID to modify one single instance of the recurrence, are actually two calendar components, as far as I understand the wording. The description of SEQUENCE can then be understood that both can have different SEQUENCE numbers... This should probably be clarified in rfc2445bis. If, however, it is possible for the two components to have different SEQUENCE numbers, then items 3. and 4. of the list in section 2.1.5 need to be changed from \rfcquote{UID} to \rfcquote{UID and RECURRENCE-ID}. \item Sec.~2.1.5 (p.12): \rfcquote{Hence, CUAs must persist} should rather be \rfcquote{Hence, CUAs MUST persist} \item Sec.~2.1.5 (p.12): I don't understand what is meant with the sentence \rfcquote{Furthermore, for each "ATTENDEE" property of a component CUAs must persist the "SEQUENCE" and "DTSTAMP" property values associated with the "Attendee's" response.} First, I don't understand the meaning: Does this mean that the Organizer's CUA needs to store for each Attendee the last SEQUENCE number, to which the Attendee has responded? In this case, I don't understand the reason behind it. Or does it mean that the Attendee's CUA needs to preserve the SEQUENCE of his/her last response, so that it's possible to decide whether a response to a new REQUEST from the Organizer is needed. In that case, I don't think that sentence is needed, either, because it is stated in the draft already that only the Organizer is allowed to make changes to a component. Also, which CUAs are meant: The CUA of the Organizer or of the Attendee? \end{enumerate} \section{Application Protocol Elements} \begin{enumerate}[resume] \item Sec.~3 (p.12, methods table): From the VJOURNAL column, it seems to me that CANCEL and ADD can also be used change components that were PUBLISHed, not only REQUESTed ones. This is never clearly spelled out, in particular not for VEVENT and VTODO. \item All the restriction tables in this chapter list the VALARM component parallel to VEVENT, VTODO, VJOURNAL and VFREEBUSY. I regard this as quite unfortunate, because VALARM is not a top-level calendar component, but can only appear inside other components. As the description of the tables says that component properties are indented, I think it would make sense to also indent VALARM, which is a component component. \item \label{DTSTART_Absent}Several of the constraint tables for VEVENT in chapter 3 either disallow DTSTART at all or allow DTSTART to be absent from a component. In particular, the VEVENT REFRESH (Sec.~3.2.6, p.28) and DECLINECOUNTER (Sec.~3.2.8, p.31) tables disallow DTSTART at all, while VEVENT CANCEL (Sec.~3.2.5, p.27), allow \rfcquote{0 or 1} DTSTART. In contrast, rfc2445bis (Sec.~3.6.1, p.54) REQUIRES DTSTART to be present in all VEVENT components, so that e.g. the contents of a REFRESH are NOT VALID iCalendar! Notice, that this restriction in rfc2445bis was not in rfc2445, but was added during the update to rfc2445bis. \end{enumerate} \subsection{Common Component Restriction Tables} \begin{enumerate}[resume] \item Sec.~3.1.2 (p.14, VTIMEZONE table): This table states that RRULE and RDATE MUST NOT both be present at the same time. rfc2445bis does not have such a restriction, so that some VTIMEZONE objects, which are valid in rfc2445bis, cannot be used for group scheduling. I propose to remove that restriction. \end{enumerate} \subsection{Methods for VEVENT Calendar Components} \begin{enumerate}[resume] \item Sec.~3.2 (p.15, methods table, REQUEST): \rfcquote{Event requests} instead of \rfcquote{Event Requests}. Also, I think it should be \rfcquote{MAY degrade} instead of \rfcquote{may degrade}. \item Sec.~3.2.1 (p.16): I have never understood why a PUBLISHed event MUST NOT have any Attendees. In particular, I think it might be useful for several types of published events to contain Attendees and their participation status: panel discussions, hearings, etc. \item \label{REQUEST_privacy_all_attendees}Sec.~3.2.2 (p.16ff): Is there any requirement that the VEVENT REQUEST sent out to one particular Attendee MUST/SHOULD contain all other Attendees? Cf. in particular Sec.~3.2.5 (see issue \ref{CANCEL_privacy_all_attendees}), which states that a cancelled event MUST include all Attendees. In my opinion, there should not be such a requirement, mainly for privacy reasons. The attendees' email addresses are explicitly listed in the ATTENDEE property, so I don't regard it a good idea that all attendees automatically learn about the email addresses of all other attendees, which might be well-known persons and quite reluctant to give out their private contact details. In any case, a sentence should be inserted clarifying whether all attendees MUST/SHOULD be given in the VEVENT, or whether it is possible to send individual requests to each attendee containing only the one ATTENDEE property for this particular person. \item Sec.~3.2.2 (p.17): The paragraph after the list is not true for delegated and forwarded events. In particular, in both cases the recipients are not the "Attendees", but "Other CUs". \item Sec.~3.2.2.3 (p.21): In the second-to-last paragraph, there is a spurious " between method and SHOULD. \item Sec.~3.2.2.3 (p.20/21): The delegator forwards the REQUEST to the delegate, including the delegate as a new ATTENDEE. The delegator also sends a REPLY to the Organizer with the DELEGATED-TO parameter set. However, it is not clear to me whether the REPLY to the organizer MUST/SHOULD also contain the delegate as a new ATTENDEE or not. As the comment in Sec.~4.2.5 says this is a MUST, it should be added here, too, since here is the section where delegating is actually defined. The examples -- helpful as they are -- should not include any new requirements not described before. \item Sec.~3.2.2.4 (p.21): In the last sentence, it should read \rfcquote{... incremented and the value of ...}. \item Sec.~3.2.2.4 (p.21): The last sentence says that \rfcquote{the "ORGANIZER" property has been changed to the \emph{calendar address} of the new "Organizer".} However, rfc2445bis defines the calendar address as only the URI and does not include property parameters like CN, which should clearly be changed, too. I think it would suffice to simply say \rfcquote{and the value of the "ORGANIZER" property has been changed to the new "Organizer".} \item Sec.~3.2.2.6 (p.21): There is one step missing in the description: The Attendee forwards to the uninvited CU, but there is no mentioning of how the Organizer learns of this. \item \label{TODO_Forwarding_OrganizerResponse} Sec.~3.2.2.6 (p.21): How does the uninvited CU find out whether the Organizer added him/her or not. The draft only says that the Organizer MAY send a CANCEL if he rejects the new Attendee. However, if he does not, then the uninvited Attendee has no way of knowing whether he was added or not. A sentence should be added clarifying this situation. Should the uninvited CU simply send a REFRESH to the organizer? If he does not get a response there either, he can deduce that he was not added (see Sec.~6.1.6). \item Sec.~3.2.2.6 (p.22): The last sentence says that the Attendee MUST NOT make changes to the VEVENT property set. However, this would not prohibit changes to other calendar components, like VTIMEZONE, VALARM, etc. I don't think such changes should be allowed, either. \item Sec.~3.2.3 (p.22): Should \rfcquote{An "Attendee" can include} rather be \rfcquote{An "Attendee" MAY include}? \item \label{VEVENT_NotChanged} Sec.~3.2.3 (p.23): This section says that the optional properties listed in the table MUST NOT be changed. However, the rest of the draft and the comments in the table make it clear that some required parameters (DTSTAMP, UID, ORGANIZER) MUST also NOT be changed. \item Sec.~3.2.3 (p.24): The table lists VALARM as \rfcquote{0}. If the original REQUEST contained a VALARM, shouldn't it be included in the REPLY, too? \item \label{ADD_Explanation} Sec.~3.2.5 (p.24f): I don't understand how ADD should work exactly. rfc2445bis says that an instance of an event is identified by the UID and the RECURRENCE-ID. If we don't allow a RECURRENCE-ID, how does the resulting sequence of events look in iCalendar notation (i.e. what would the Organizer send in response to a REFRESH)? I suppose it would work to add the additional date as an RDATE or a second RRULE, but only if none of the other properties is different from the original event. Sec.~4.4.7 gives an example of this case (but since it does not point out that an RDATE was added, it is very hard to figure out how the ADD was handled). If some properties are different for a single ADDed event, this can still be represented as an added RDATE and a second VEVENT using RECURRENCE-ID to specify the added instance. However, if an ADD message tries to add a recurring event with some property values different from the original (already recurring) event, then I simply don't see how this can be represented in iCalendar. RECURRENCE-ID;RANGE=THISANDFUTURE can not be used, because the change should only apply to the instances of one RRULE, not of both. An example of this problem is the first example in Sec.~4.4.7: The original RRULE recurs on TU in \rfcquote{The White Room}. The ADD message adds a second rule on TH, but the location is now \rfcquote{The usual conference room} (see also issue \ref{ADD_Recurrence}). I don't see how these two combined can be properly represented in the same event in iCalendar. The example says that they are equivalent to the REQUEST given in Sec.~4.4.7, but that REQUEST seems to ignore the different LOCATION property value of the ADD. I think it should be clarified, how such colliding messages should be handled. In particular, do all other property values except DTSTART, RDATE and RRULE have to coincide with the original REQUEST? If not, we should clarify how that case can be handled (i.e. either discard all information from the ADD, which does not coincide? Or try to merge them as much as possible? Or simply disallow adding recurring events to an already recurring event with different properties.) The same clarification is needed for VTODO (p.47) \item Sec.~3.2.5 (p.26): The first sentence talks about sending a notice \rfcquote{to the "Attendees"}. To me it is not clear if this means sending a CANCEL message to ALL Attendees (even when just uninviting one Attendee) or only to the affected (i.e. uninvited) Attendees. Both would make sense... The same goes for VTODO on p.47. \item Sec.~3.2.5 (p.26): In the ATTENDEE comment in the table, \rfcquote{from} is missing in \rfcquote{being removed from the event.} \item \label{CANCEL_privacy_all_attendees}Sec.~3.2.5 (p.26): Why is it a MUST that all Attendees have to be included if the whole event is cancelled? The STATUS property already tells the CU(A) whether the whole event was cancelled or only some Attendees uninvited. Can't a CUA also send out individual CANCEL messages to each of the Attendees with only that one Attendee included in the VEVENT? This would prevent privacy issues, because sending out the email addresses of all Attendees is not always desirable (see also issue \ref{REQUEST_privacy_all_attendees}). The same holds for VTODO (p.49) \item Sec.~3.2.5 (p.27): The description of STATUS in the table is badly worded (Isn't this a contradiction: MUST be set to CANCELLED, and MUST NOT be present, if ....). I propose to change the first part of the description to \begin{verbatim} MUST be set to CANCELLED to cancel the entire event. \end{verbatim} \item Sec.~3.2.6 (p.28): I think DTSTAMP and ORGANIZER also MUST be the same value as in the original REQUEST... \item \label{REC-ID_VTIMEZONE_required}Sec.~3.2.6 (p.29): Since RECURRENCE-ID is a date-time value, it might include a reference to a time zone. In this case, a VTIMEZONE is REQUIRED (instead of the current \rfcquote{0}) \item Sec.~3.2.7 (p.29, first paragraph): The COUNTER is used not only for counter proposals to the event description! I would simply delete \rfcquote{description} so the sentence reads \rfcquote{... a counter proposal to the event.} \item Sec.~3.2.7 (p.30): The SEQUENCE value MUST NOT be changed from the original event. I would include this in the comment for SEQUENCE (it is mentioned in the examples in Sec.~4.2.4, though). \item Sec.~3.2.7 (p.30): In the comment for STATUS, remove the space before CANCELLED. \item Sec.~3.2.7 (p.31): At the end of this section, it should be clarified how the Organizer reacts to the COUNTER. Declining it is clear, but if he accepts it, does he have to send out a new REQUEST to all Attendees or can he simply do nothing, too? In particular, if an Attendee sends a COUNTER with significant changes and does not receive a DECLINECOUNTER, can he assume that the Organizer has accepted it or does he have to treat it like receiving a DECLINECOUNTER? How does he learn about it other than sending a REFRESH? \item Sec.~3.2.8 (p.32): VTIMEZONE is required if the RECURRENCE-ID contains a reference to a timezone! (like issue \ref{REC-ID_VTIMEZONE_required}). \end{enumerate} \subsection{Methods for VFREEBUSY Components} \begin{enumerate}[resume] \item Sec.~3.3 (p.32): The third paragraph says that the VFREEBUSY MUST include the ATTENDEE in this case, while the PUBLISH table in Sec.~3.3.1 expressively forbid this. \item Sec.~3.3 (p.33): This section says \rfcquote{However, two different busy time periods MAY overlap}, while the restriction table in REPLY (sec 3.33, p.36) says that they MUST NOT overlap. \item Sec.~3.3 (p.33): Shouldn't it be a SHOULD in \rfcquote{"FREEBUSY" properties should be sorted...}? \item Sec.~3.3 (p.33): The paragraph starting with \rfcquote{Since events may span a day boundary...} is confusing at best. The free/busy periods do not necessarily coincide with events, so this is no argument. Also, the following sentence sounds a bit out of order, since it clarifies the REQUEST method. Instead of giving such a lengthy example (talking about "Individuals" not supporting busy time requests, while in fact their CUAs don't support it), wouldn't it be simpler to reformulate the whole paragraph? I propose to append \begin{verbatim} Busy time periods may also span a day boundary.\end{verbatim} to the previous paragraph and remove the rest of the paragraph, since it deals with a fallback and only explains what the methods fallback table in Sec.~5.1.2 already says much better. \item Sec.~3.3.1 (p.33): Should it really be \rfcquote{...to provide a message for sending unsolicited...} or should it rather be \rfcquote{... to provide a method for sending unsolicited...}? \item Sec.~3.3.1 (p.33): Shouldn't it be \rfcquote{The "ORGANIZER" property MUST be specified...}? \item Sec.~3.3.2 (p.35): The comment for ATTENDEE sounds wrong. What is it supposed to mean? \item Sec.~3.3.3 (p.36): Remove the parentheses in the comment for ATTENDEE and URL. \item Sec.~3.3.3 (p.36): Remove \rfcquote{Multiple instances are allowed.} in the FREEBUSY comment, since \rfcquote{0+} already says this. \item Sec.~3.3.3 (p.36): Why is the sorting a MUST for PUBLISH, while the introduction in Sec.~3.3 only speaks of SHOULD? \item Sec.~3.3.3 (p.36): Add comment for UID (like for VEVENT): \rfcquote{MUST be the UID of the original REQUEST} \end{enumerate} \subsection{Methods for VTODO Components} \begin{enumerate}[resume] \item All restriction tables list the PRIORITY property as required for to-dos, while rfc2445bis does not mention any such restriction. I don't think PRIORITY is important enough to warrant a MUST in iTIP. \item Sec.~3.4.1 (p.38): Why are Attendees forbidden with PUBLISH? \item Sec.~3.4.1 (p.39), Sec.~3.4.2 (p.41), Sec.~3.4.4 (p.47), Sec.~3.4.7 (p.53) and Sec.~3.4.8 (p.55): In the STATUS comment, it should be IN-PROCESS (delete space), similarly it should be NEEDS-ACTION (insert hyphen) \item Sec.~3.4.2 (p.39): Only the meaning of REQ-PARTICIPANT is explained. Are other values allowed? If so, what do they mean in connection with to-dos? \item Sec.~3.4.2.2 (p.42): If the REQUEST is only used to "reconfirm" the to-do, do the Attendees still have to REPLY, even if nothing has changed? Or should they simply use the value of their RSVP ATTENDEE parameter to decide? \item Sec.~3.4.2.3 (p.42): Why can't a to-do be delegated to the Organizer? \item Sec.~3.4.2.4 (p.43): Same as \ref{TODO_Forwarding_OrganizerResponse} for VEVENT. \item Sec.~3.4.3 (p.44): What exactly is an \rfcquote{unsuccessful "VTODO" calendar component "REQUEST" method}? \item Sec.~3.4.3 (p.43): The same comment about properties that MUST NOT be changed should be inserted as for VEVENT (issue \ref{VEVENT_NotChanged}) on p.23 right before the table. \item Sec.~3.4.3 (p.44f): The UID comment should be moved to the ATTENDEE property, which it actually describes, and ATTENDEE should be changed from \rfcquote{1+} to \rfcquote{1} (see also the VEVENT REPLY table on p.23). The new UID comment should be \rfcquote{MUST be the UID of the original REQUEST} \item Sec.~3.4.3 (p.45): If the VTODO in the REQUEST contained a VALARM, should this not be included in the REPLY, too? \item Sec.~3.4.5 (p.48): \rfcquote{When a VTODO is cancelled} Does this mean only when the whole VTODO (with all its recurrence instances) is cancelled, or does it mean whenever a CANCEL is sent, in particular also when only a single ATTENDEE is unassigned? The same holds for VEVENT (p.26). \item Sec.~3.4.5 (p.52): Since the RECURRENCE-ID is a date-time, it can include a reference to a timezone. In this case, a VTIMEZONE is REQUIRED. \item Sec.~3.4.7 (p.52): The second sentence of the first paragraph is redundant, since the first sentence already says that the counterproposal is submitted to the Organizer. \item Sec.~3.4.7 (p.52): If the counterproposal only contains some minor modifications (e.g. correcting typos in the description), does the Organizer still have to send the REQUEST to all Attendees and set RSVP=TRUE? \item Sec.~3.4.7 (p.52): Remove the \rfcquote{;} after "ATTENDEE" property \item Sec.~3.4.7 (p.53): In the comment for RECURRENCE-ID remove the spurious \rfcquote{3.5} \item Sec.~3.4.8 (p.55): What does the comment for ATTENDEE mean? Does it mean that in a DECLINECOUNTER the Organizer has to insert all original Attendees? \end{enumerate} \subsection{Methods for VJOURNAL Components} \begin{enumerate}[resume] \item Sec.~3.5.1 (p.57): What is the \rfcquote{original SEQUENCE number} in the comment for SEQUENCE for a PUBLISH of a VTODO? I would delete that first sentence. \item Sec.~3.5.3 (p.61): VJOURNAL does not allow ATTENDEE, so the presence should be changed to \rfcquote{0} from \rfcquote{0+}. \end{enumerate} \subsection{Status Replies} \begin{enumerate}[resume] \item Sec.~3.6 (p.62, item 2. A. and B.) I propose to exchange rules A. and B., delete the last sentence from the current B., and start the current A. with \rfcquote{Otherwise, if any one component}. This makes the logic much clearer. \item Sec.~3.6 (p.62ff, column \rfcquote{Offending Data}): The comments in the \rfcquote{Offending Data} column speak about specifying the offending data, but don't make it clear where to specify it. I suppose the idea is to give the offending data in the extdata part of the status message, right? Maybe this could be clarified in a sentence before the table. \item Sec.~3.6 (p.64, Code 5.0): What does the Return Status Description \rfcquote{Request MAY supported.} mean? (It is grammatically wrong, too.) In particular, the Offending Data column speaks about the METHOD (should be written in all-capitals) property \end{enumerate} \subsection{Implementation Considerations} \begin{enumerate}[resume] \item Sec.~3.7.1 (p.65): In the second paragraph it should be \rfcquote{discrete} instead of \rfcquote{discreet} \item Sec.~3.7.1 (p.66): In the last paragraph of this section it should be \rfcquote{or to-do has been made} (instead of \rfcquote{has be made}) \item Sec.~3.7.1 (p.66): The last three sentences of this section (discussing RECURRENCE-ID) are plain wrong. In particular, they are in contradiction to Sec.~3.8.4.4 of rfc2445bis: The RECURRENCE-ID is always the start date of the original recurrence instance, even after the change has been made. As an example, take an event recurring each Monday at 9:00. One of these meetings is moved to 12:00 and its LOCATION is changed. Even after the change has been propagated to the Attendees, the RECURRENCE-ID of that event will still be YYYYMMDDT090000, otherwise the recurrence rule would generate an additional event at 09:00 and a RECURRENCE-ID of YYYYMMDDT120000 does not appear in the recurrence set either. This is clearly explained in rfc2445bis (Sec.~3.8.4.4, p.116) using the Friday to Thursday change. The RECURRENCE-ID stays on the original date. \item Sec.~3.7.3 (p.67): This draft allows clients to completely ignore X-Tokens. Granted, for REPLY, REFRESH etc. there is no advantage in preserving them (because the Attendee's CUA doesn't handle them anyway and the Organizer already has their value), but when delegating or forwarding calendar components, the Other CU might be interested in the X-Tokens, because his CUA might know how to handle them. \end{enumerate} \section{Examples} \subsection{Published Event Examples} \begin{enumerate}[resume] \item Sec.~4.1 (p.67): In the first paragraph, change \rfcquote{e- mailing} to \rfcquote{e-mailing} (remove space) and replace \rfcquote{and posting} by \rfcquote{or posting} to make it clearer that this enumeration is not exhaustive and PUBLISH can be used in other ways, too. \end{enumerate} \subsection{Group Event Examples} \begin{enumerate}[resume] \item Sec.~4.2 (p.71): In the table change \rfcquote{tentative} to \rfcquote{TENTATIVE}. According to rfc2445bis Sec.~3.1 and 3.2 enumerated property values are case-insensitive, but rfc2445bis and rfc2446bis consistently uses all-capitals for enumerated parameter values. \item Sec.~4.2.1 (p.72): The explanation details the default value for PARTSTAT and when it can be left out, but does not mention that the same also holds for CUTYPE=INDIVIDUAL, which could also be left out in the example \item Sec.~4.2.1 (p.72): The DTSTART and DTEND coincide. Sec.~3.8.2.2 of rfc2445bis says that the DTEND MUST be later in time than DTSTART! Also, how much sense does a Conference of 0 seconds make? \item Sec.~4.2.2 (p.73) and Sec.~4.2.4 (p.76): As explained in issue \ref{DTSTART_Absent} above, rfc2445bis REQUIRES DTSTART to be present in a VEVENT, while the REPLY, REFRESH and DECLINECOUNTER methods defined in this draft forbit it. These examples are not valid iCalendar objects as specified by rfc2445bis. The same holds of course for all further REPLY, REFRESH and DECLINECOUNTER examples. \item Sec.~4.2.4 (p. 74f): The description says that the given counter-proposal also changes the location, but the LOCATION property value is the same in the REQUEST and the COUNTER. \item Sec.~4.2.4 (p.75): The counter-proposal contains the DTSTAMP property twice. According to the restrictions table in Sec.~3.2.7 and the VEVENT definition in Sec.~3.6.1 on page 54 of rfc2445bis this is not allowed. \item Sec.~4.2.5 (p.76): The second to fourth items of the list should be further indented, since they are actually subitems of the first list item. \item Sec.~4.2.5 (p.76): The last item in the list actually contradicts what is said in Sec.~3.2.2.3 (p.20), namely that the delegator MUST add an "ATTENDEE" property describing the Delegate to the REQUEST that he sends to the Delegate. Thus, he definitely MUST NOT send a copy of the original REQUEST, but rather a slightly modified one. \item Sec.~4.2.10 (p.82): In the table replace \rfcquote{Remove an "B" as} by \rfcquote{Remove "B" as}. \item Sec.~4.2.10 (p.82): In the table it is not clear to me whether it is a requirement for the Organizer to send the updated event to the remaining Attendees after B was cancelled or not. The table describes just one cause of action, but from the definitions in Chapter 3, it is also not clear to me whether the Organizer MAY/SHOULD/MUST send a new REQUEST to all remaining Attendees after one Attendee was cancelled. \end{enumerate} \subsection{Busy Time Examples} \begin{enumerate}[resume] \item Sec.~4.3 (p.84): Before \rfcquote{Individual A publishes busy time for one week}, a subsection header \rfcquote{4.3.1 Publish Busy Time} should be inserted for consistency (all other METHODS have their own subsection) \item Sec.~4.3 (p.85): The description of the example says that busy time for one week was published, but the period specified by DTSTART and DTEND actually is only 6 days! Furthermore, the VFREEBUSY contains FREEBUSY property values that start way beyond the DTEND. rfc2445bis says in Sec.~3.6.4 on p.63 that for published busy time the \rfcquote{DTSTART and DTEND properties specify an inclusive time window that surrounds the busy time information}. In other words, all FREEBUSY periods MUST be inside the interval specified by DTSTART and DTEND. \end{enumerate} \subsection{Recurring Event and Time Zone Examples} \begin{enumerate}[resume] \item \label{RRULE_INTERVAL} Sec.~4.4.1 (p.87): The description says that this event is for a weekly phone conference, but the RRULE uses INTERVAL=20, which means that the event recurs every 20 weeks! The correct RRULE would be \begin{verbatim} RRULE:FREQ=WEEKLY;COUNT=20;WKST=SU;BYDAY=TU\end{verbatim} I blame this on the ambiguous formulation in rfc2445bis: In Sec.~3.3.10 on p.40 it says \rfcquote{The INTERVAL rule part contains a positive integer representing how often the recurrence rule repeats.} Of course, it is supposed to be interpreted in the sense "in which intervals the r.r. repeats", but can admittedly also be read as "how many times the r.r. repeats". Apparently this was not clear to the person who included this example in rfc2446. \item Sec.~4.4.1 (p.88): The paragraph describing the representation of the times in different time zones contains several issues / confusions: \begin{enumerate} \item The time zone difference for Attendee "b" is expressed as the offset from PDT, while the time zone difference for Attendee "c" is given as the offset from UTC, which makes comparing these two times much harder. \item In the explicit time listings below, "GMT" is used instead of "UTC". \item JST is 9 hours ahead of UTC, not 8 hours as claimed here. \item On November 11, 1997, San Jose is no longer in PDT, but in PST. \item On Wed, September 10, 1997, San Jose is still in PDT, not in PST as claimed. \item The representation of the exception dates in the other time zones are calculated wrong: 14:00 PDT on Sept 9 is NOT 23:00 GMT (=UTC), but rather 23:00 CEST or 21:00 UTC. Similarly, 14:00 PST (=UTC-8) on Oct 28 is 22:00 UTC or 23:00 CET or 07:00 JST (UTC+9), not 06:00 JST! \end{enumerate} I would give all times offsets relative to PDT and list the local time zones and all local times mentioned together with their shift from UTC. In the list of exceptions, I would also list the PDT/PST date/times first, as they are the real exception dates, the representation in UTC and JST just helps the user to understand the issues with time zones. All in all, I think that paragraph should be: \begin{verbatim} The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT (UTC-7). "Attendee" B@example.fr is in France where the local time on this date is 9 hours ahead of PDT or 23:00 CEST (UTC+2). "Attendee" C@example.jp is in Japan where local time is 16 hours ahead of PDT or Wednesday, July 2 at 06:00 JST (UTC+9). The event repeats weekly on Tuesdays (in PST/PDT). The "RRULE" property results in 20 instances. The last instance falls on Tuesday, November 11, 1997 2:00pm PST. The "RDATE" property adds another instance: WED, 10-SEP-1997 2:00 PM PDT. There are also two exception dates to the recurrence rule. The first one is: TUE, 09-SEP-1997 14:00 PDT (UTC-7) TUE, 09-SEP-1997 23:00 CEST (UTC+2) WED, 10-SEP-1997 06:00 JST (UTC+9) and the second is: TUE, 28-OCT-1997 14:00 PST (UTC-8) TUE, 28-OCT-1997 23:00 CET (UTC+1) WED, 29-OCT-1997 07:00 JST (UTC+9) \end{verbatim} \item \label{ADD_Recurrence} Sec.~4.4.7 (p.93f): It would be very helpful if the comments included an explanation how the added times are added to the original VEVENT. In particular, a single event is added by adding its DTSTART as an RDATE to the original event, possibly with another VEVENT using RECURRENCE-ID to modify some of its properties if the properties of the ADD differed from the original event. Similarly, another recurring event can be added by either modifying the existing RRULE or adding a second RRULE (however, rfc2445bis deprecates the use of two RRULEs for a calendar component!). However, it is not clear how one should proceed if the added recurring event differs from the original event (e.g. has a different LOCATION like the second example of this section). As explained in \ref{ADD_Explanation}, the second example adds another recurrence rule to an event with an already existing recurrence rule, but the added event has a different LOCATION than the original event. The PUBLISH example, which is claimed to be equal to the REQUEST and the subsequent ADD, however, ignores this changed LOCATION property value and only uses the LOCATION property value of the original event. It should be clarified if changed property values in the ADD should really be ignored or not. If not, this case with an added recurrence needs to be explained further (whether and how it can be represented in iCalendar at all!). \item Sec.~4.4.9 (p.100): The REPLY contains a REQUEST-STATUS with status code 3.0 and one with code 2.8. However, the previous explanation of REQUEST-STATUS in Sec.~3.6 expressively forbids any non-3.x code if a 3.x code is already present. Thus, the 2.8 code entry should be deleted from the event. \end{enumerate} \subsection{Group To-do Examples} \begin{enumerate}[resume] \item Sec.~4.5.1 (p.102): The STATUS property value should be NEEDS-ACTION (Hyphen is missing; enumerated property values are case-insensitive, still I think we should use all-capitals consistently) \item Sec.~4.5.6 (p.104): The STATUS property value should be IN-PROCESS rather than the invalid IN-PROGRESS \item Sec.~4.5.7 (p.105): Time zones cannot be given as -0700, so I think DTSTART and DUE should be \begin{verbatim} DTSTART:19980101T170000Z DUE:19980103T170000Z\end{verbatim} Additionally, the STATUS property value should be NEEDS-ACTION (hyphen missing) \item Sec.~4.5.7.2 (p.105): This section talks about how recurrence works in general for to-dos, which would much better belong in rfc2445bis rather than rfc2446bis. So I think this whole section should be moved to rfc2445bis. Also, this section speaks of the due date specified in a "REQUEST", while of course the same holds true for PUBLISH, ADD, COUNTER, etc., too. It is not even specific to iTIP, but rather a general issue in iCalendar. The reference to REQUEST should at least be deleted. \end{enumerate} \subsection{Journal Examples} \begin{enumerate}[resume] \item Sec.~4.6 (p. 106): The example is missing the REQUIRED DTSTAMP property. \end{enumerate} \subsection{Other Examples} \begin{enumerate}[resume] \item Sec.~4.7.1 (p.107): In the describing text the UID value is line-broken, which should not happen. \item \label{UID_space} Sec.~4.7.1 (p.107): While rfc2445bis allows spaces in the UID, it's not clear to me whether those spaces are actually part of the UID. In particular, are the following two UID property lines equivalent? \begin{verbatim} UID:guid-1-1234@example.com UID: guid-1-1234@example.com \end{verbatim} rfc2445bis defines the UID in Sec.~3.8.4.7 to be of text type, which allows spaces, but is quiet on how UIDs should be compared. Reading rfc2445bis strictly, everything after the colon is part of the UID, so that the two lines above are NOT equivalent. The space should proably be deleted from this example, but rfc2445bis should also clarify this case whether spaces are allowed in UIDs and whether leading/trailing spaces should be ignored. \item Sec.~4.7.2 (p.107): The second sentence speaks about the case when \rfcquote{an "Organizer" sends a request}, which is an unfortunate wording, because it applies not only to the REQUEST method, but to any iTIP message sent. I would replace \rfcquote{a request} by \rfcquote{an iTIP message}. \item Sec.~4.7.2 (p.107): In the explanation for case (1), the case where the SEQUENCE number was incremented by 1 is not a problem and does not mean that the Attendee missed a message or is receiving an out-of-sequence message. Rather is the default case when the Organizer modifies a calendar component: He will increase the SEQUENCE number by 1 and send out a new REQUEST to the Attendees. Thus this case should be not be covered by this case. If the CU receives a REQUEST where the SEQUENCE number is 1 larger than his current version and the RECURRENCE-ID can not be found in his calendar component, that's a worse case, since apparently he received all changes, which do, however, not contain that specific recurrence instance. Only for the CANCEL method the problem arises as described in case (2). \item Sec.~4.7.2 (p.108): In the explanation for case (3), I think the Attendee SHOULD/MUST send a response with the status code \rfcquote{2.8; Success, repeating event ignored. Scheduled as a single component}. If he should not send such a reply (since he has probably already sent it when he received the original REQUEST that sets the recurrence), it should be mentioned here explicitly. \item Sec.~4.7.2 (p.108): The table and the example cover only case (2), so it should either be moved to the text for (2) or the text above the table should explicitly mention that it covers case (2). \end{enumerate} \section{Application Protocol Fallbacks} \begin{enumerate}[resume] \item Between an \rfcquote{Ignore} and some following text in all the tables, the punctuation should be consistent. In some places there is a \rfcquote{,} after the \rfcquote{Ignore}, in some places a period \rfcquote{.} and in some places the text continues after only a space \rfcquote{ }. \item Sec.~5.1.1 (p. 110): If a CUA does not support recurrences, it cannot handle ADD by default. There should be a fallback for this case, probably to insert the ADDed event as a separate component and replying with status code \rfcquote{2.8; Success, repeating event ignored. Scheduled as a single component}. \item Sec.~5.1.1 (p.110): PRODID and VERSION are REQUIRED for rfc2445bis support, which rfc2446bis relies upon. Still, I agree it does not hurt if a CUA ignores PRODID and/or VERSION, so this can be left unchanged, too. I just wanted to point out that it's already a requirement for rfc2445bis. \item Sec.~5.1.1 (p.111), Sec.~5.1.3 (p.113) and Sec.~5.1.4 (p.116): In the ATTENDEE properties, remove \rfcquote{EVENT-}, \rfcquote{VTODO - } and \rfcquote{JOURNAL - }, since there is no method "EVENT-REQUEST" and the fact that this is for events is clear from the section header anyway. If you think it should be left in, it should at least be changed to \rfcquote{REQUEST for events} etc. \item Sec.~5.1.1 (p.111) and Sec.~5.1.3 (p.114): In the ATTENDEE properties, change \rfcquote{is not implemented} to the correct \rfcquote{is implemented}. \item Sec.~5.1.1 (p.111): In the fallbacks for other calendar methods, there is no requirement to reply with \rfcquote{Not Supported} if the ATTENDEE property is not supported. Why is it a requirement for events? \item Sec.~5.1.1 (p.111): Why is DESCRIPTION required? If an event has a SUMMARY, one can safely ignore the DESCRIPTION. On the other hand, many events I have seen have only a SUMMARY (which can be ignored according to the table), but no DESCRIPTION. It would make sense to me to treat SUMMARY and DESCRIPTION similarly. \item Sec.~5.1.1 (p.111): I think the ORGANIZER property can only be ignored for PUBLISH, but not for any of the other methods, since that's the address where required replies must be sent to. \item Sec.~5.1.1 (p.111): In the fallback for RRULE, change "DTStart" to "DTSTART", since the formatting conventions at the beginning of the draft say that all property names are in capitals. \item Sec.~5.1.2 (p.112): Shouldn't there be a fallback for the case where the ATTENDEE property is not supported? \item Sec.~5.1.2 (p.112): Why is DURATION support required for VFREEBUSY, when it is not required for VEVENT and VTODO? \item Sec.~5.1.3 (p.113) and Sec.~5.1.4 (p.116): RECURRENCE-ID should be changed to \rfcquote{Required if RRULE is implemented}, like it is for VEVENT. \item Sec.~5.2.2 (p.117): This section talks only of delegation, but completely ignores that a REQUEST can be forwarded to another CU, who then replies to the Organizer. Additionally, the last sentence poses a possible privacy issue: If the CUA implements the first strategy lined out in the second-to-last sentence (\rfcquote{accept the reply}) and treats the REPLY as a REFRESH, it might automatically send the current version of an event to a person, who is not authorized to have that information. \end{enumerate} \section{Security Considerations} \begin{enumerate}[resume] \item Sec.~6.1.5 (p.118): Why is this a "MAY" and not "may"? \item Sec.~6.2 (p.118): Remove one of the duplicated \rfcquote{is subject}. \item Sec.~6.2.2 (p.119): Procedure alarms were deprecated in rfc2445bis, so the sentence about their security issues can be deleted from rfc2446bis. \end{enumerate} \section{IANA Considerations} No comments. \section {Acknowledgments} No comments. \section{Normative References} No comments. \appendix \section{Appendices} No comments. \section*{Issues in rfc2445bis-08} \addcontentsline{toc}{section}{Issues in rfc2445bis-08} \setcounter{enumi}{1} \begin{enumerate} \item Sec.~"3.6.1. Event Component" (p.54): Either make the DTSTART optional in rfc2445bis again or make it REQUIRED in the REPLY, REFRESH and DECLINECOUNTER methods in rfc2446bis (currently, it MUST NOT be present for these methods). \item Sec.~"3.6.5. Time Zone Component" (p.71): The text above the example says that this is an example of a time zone using the RDATE property. The example, however, does not contain any RDATE. \item Sec.~"3.8.7.4. Sequence Number" (p.142): It should be clarified whether the SEQUENCE number is supposed to be the same for all different components with the same UID (but differing in their use of RECURRENCE-ID to identify particular instances of a recurring sequence) or whether they can have different SEQUENCE numbers (see also issue \ref{SEQUENCE_MultipleUID} above). \item Sec.~"3.3.10. Recurrence Rule" (p.40): As discussed in issue \ref{RRULE_INTERVAL} for Sec.~4.4 above, the description of INTERVAL can possibly be misunderstood. The next sentence explains it better, but it also only uses an interval of 1. Furthermore, anyone who misunderstood the first, ambiguous sentence will not be corrected by that second sentence. I propose to change the first sentence to: \begin{verbatim} The INTERVAL rule part contains a positive integer representing at which intervals the recurrence rule repeats.\end{verbatim} Furthermore, I would add one more sentence to that paragraph: \begin{verbatim} A value of "2" means for example every other day for a DAILY rule, etc.\end{verbatim} This explains the use of INTERVAL much better than the default value of "1". \item Sec.~"3.8.4.7. Unique Identifier" (p.120f): As detailled in issue \ref{UID_space} above, it should be clarified how spaces in a UID property value should be handled. In particular, are they allowed at all? Are leading or trailing spaces to be ignored when looking for or comparing UIDs? \end{enumerate} \end{document}