iCalendar Transport-Independent Interoperability Protocol (iTIP)
RFC 5546
Note: This ballot was opened for revision 10 and is now closed.
(Lisa Dusseault) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Adrian Farrel) No Objection
Comment (2009-09-20 for -)
No email
send info
send info
Looks like you cleared up the issue raised in Erratum 1709. (http://www.rfc-editor.org/errata_search.php?eid=1709) You might ask your AD to close the Erratum record.
(Russ Housley) No Objection
Comment (2009-09-22 for -)
No email
send info
send info
The Gen-ART Review by Vijay K. Gurbani posted on 16-Sep-2009 points out two nits: 1) S6.1.4 is about eavesdropping and not data integrity, right? But the misuse suffered by a cleartext iCalendar object is given both treatments: lack of privacy and loss of data integrity. A simple suggestion would be to remove "and/or changed" from S6.1.4, and have a new paragraph as follows: Data Integrity The iCalendar object is constructed with human-readable clear text. Any information contained in an iCalendar object may be changed by unauthorized persons while the object is in transit. 2) Acknowledgments: s/S.Silverberg/S. Silverberg/
(Cullen Jennings) No Objection
Alexey Melnikov (was Discuss) No Objection
Comment (2009-10-04)
No email
send info
send info
3.2.2.3. Delegating an Event to another CU In response to the request, the "Delegate" MUST send a "REPLY" method to the "Organizer" and optionally, to the "Delegator". The "REPLY" method SHOULD include the "ATTENDEE" property with the "DELEGATED- FROM" parameter value The SHOULD sounds a bit too weak here. of the "Delegator's" calendar address. 5.1.1. Event-Related Fallbacks +----------------+--------------------------------------------------+ | Method | Fallback | +----------------+--------------------------------------------------+ | PUBLISH | Required | | REQUEST | PUBLISH | | REPLY | Required | | ADD | Required if recurrences supported, otherwise | | | reply with a REQUEST-STATUS "2.8;Success, | | | repeating event ignored. Scheduled as a single | | | component." and schedule as a single component. | | CANCEL | Required | | REFRESH | Required | | COUNTER | Reply with "Not Supported" | | DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs, | | | otherwise reply with "Not Supported" | +----------------+--------------------------------------------------+ This table is not very clear which requirements apply to Organizer and which requirements apply to Attendees. (Similar comment about other tables)
(Tim Polk) (was No Record, Discuss) No Objection
(Dan Romascanu) No Objection
Comment (2009-09-23 for -)
No email
send info
send info
The OPS-DIR review by Menachem Dodge brought up the following issues and nits: 1. This document obsoletes RFC 2446. The modifications are listed in Appendix A – "Differences from RFC 2446". It would be useful to have text that discusses any possible interworking issues that may occur between implementations of this document and implementations of RFC 2446. 2. It would be helpful to have an abbreviations section to refer to as needed, or to exapnd acronyms at first occurence. Example: CS - Calendar Service CU - Calendar User 3. A few minor corrections: a. Page 9: Section 1.4 Methods Within the table for the method COUNTER. "objecy" OLD -> COUNTER | The Counter method is used by an "Attendee" to negotiate a change in an iCalendar objecy. SUGGESTED -> COUNTER | The Counter method is used by an "Attendee" to negotiate a change in an iCalendar object. b. Page 53 OLD -> The "Organizer" is MUST send a "CANCEL" SUGGESTED -> The "Organizer" MUST send a "CANCEL
(Robert Sparks) No Objection
Comment (2009-09-22 for -)
No email
send info
send info
Section 5.2.1 recommends holding onto CANCEL messages that can't be correlated to a REQUEST when they arrive (because of reordering on store-and-forward transports perhaps). The security considerations section should discuss when to stop doing this (bad-guys can make up a lot of CANCELs). Something similar to the flood mitigation discussed in 6.2.2 paragraph 2 would work. The first paragraph of 6.2.2 recommends that CUs be given the choice to honor an Organizer change. I think it would be useful guidance to implementers to point out here that if individual CUs in that set make different choices, future changes by _either_ of the resulting Organizers will not be accepted by all of the CUs. The protocol will not malfunction (as far as I can tell), but the original set of CUs may end up attending two different meetings. (Implementers could, in turn, provide guidance to users making that choice or to let Organizers know that their attempt to make a change was not wholly accepted).