Document: draft-ietf-calsify-2446bis-08.txt Reviewer: Miguel Garcia Review Date: 2008-11-11 IETF LC End Date: 08-11-18 IESG Telechat date: Summary: The document is ready for publication as a standards track RFC. Comments: The document is clear and well written. I have some comments that you may want to take onboard to improve readability and be a bit more accurate. - I like the numerous tables included in the draft. But I wish they would all have a table number (perhaps a caption too), so that it would be much precise to refer to, e..g, "Table 5" rather than "the table below". It also makes very easy for other drafts (and future RFCs) to refer to "Table n in RFC xxx" rather than "the second table in Section yyy of RFC xxx". - Section 2.1.4: the text reads: 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". I don't understand the "MUST" strength in connection to a fluffy sentence that is subject to interpretation. I would understand that the Organizer MUST unconditionally do an action, or he MUST conditionally do it, whenever the condition is measurable. But this is not the case here, where the condition "will jeopardize the validity of the participation status of Attendees" is totally up to interpretation of the Organizer and therefore, not measurable. Furthermore. It is not possible to test compliance of the MUST strength in a test sequence. - Section 3.2.2. Bad syntax in the sentence: For the "REQUEST" method, multiple "VEVENT" components in a single iCalendar object are only permitted when for components with the same "UID" property. Most likely you need to delete the word "when". - Section 3.2.3: In the first paragraph, there are a couple of "SHOULD" for which I couldn't easily justify an exception for not using a "MUST" strength. I suspect these should be "MUSTs", or the exceptional condition should be hinted. This is the text: The "REPLY" method in a "VEVENT" calendar component is used to respond (e.g., accept or decline) to a "REQUEST" or to reply to a delegation "REQUEST". When used to provide a delegation response, the "Delegator" SHOULD include the calendar address of the "Delegate" on the "DELEGATED-TO" property parameter of the "Delegator's" "ATTENDEE" property. The "Delegate" SHOULD include the calendar address of the "Delegator" on the "DELEGATED-FROM" property parameter of the "Delegate's" "ATTENDEE" property. - I noticed that the examples Section 4 contains quite a lot of normative text. I think an example section is not the best place to write normative text, and this text should be written elsewhere in the normative part. Take as an example Section 4.2.5 on page 79, where there are three instances of "MUST". Of Section 4.2.8, where there are instances of "SHOULD NOT" and "MAY". - RFC 2822 has been obsoleted by RFC 5322. - If you make a new revision of the document, notice that there are new boilerplate rules in force, so you will need to change the boilerplate.