iCalendar Transport-Independent Interoperability Protocol (iTIP)
draft-ietf-calsify-2446bis-10
Yes
(Lisa Dusseault)
No Objection
(Cullen Jennings)
(Jari Arkko)
(Magnus Westerlund)
(Ron Bonica)
(Ross Callon)
(Tim Polk)
Note: This ballot was opened for revision 10 and is now closed.
Lisa Dusseault Former IESG member
Yes
Yes
()
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2009-09-20)
Unknown
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.
Alexey Melnikov Former IESG member
(was Discuss)
No Objection
No Objection
(2009-10-04)
Unknown
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)
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
(2009-09-23)
Unknown
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
Jari Arkko Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(2009-09-22)
Unknown
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).
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
(2009-09-22)
Unknown
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/
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
()
Unknown