iCalendar Message-Based Interoperability Protocol (iMIP)
RFC 6047
Yes
No Objection
Recuse
Note: This ballot was opened for revision 11 and is now closed.
Lars Eggert No Objection
(Peter Saint-Andre; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
Section 1 This binding document provides the transport specific information necessary to convey iCalendar Transport-independent Interoperability Protocol (iTIP) [iTIP] over Internet email (using MIME) as defined in [RFC-5322] and [RFC-2045]. What is a "binding document"? I think the document "specifies a binding". But I don't think that the document is itself binding.
(Dan Romascanu; former steering group member) No Objection
Formatting comment - the Table of Contents does not fully match the document - page numbers are not accurate, Appendices missing, the last two sections listed in the table are actually no longer in the document, the capitalization of some of the sections does not correspond to the one in the document.
(David Harrington; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Ralph Droms; former steering group member) (was Discuss) No Objection
(Robert Sparks; former steering group member) No Objection
From the writeup, this is intended to Obsolete 2447 - please add the Obsoletes: line in the header.
There's some text in the "Status of this Memo" section indicating the intent at one point was to
take iMIP to Draft with this document (" A revised version of this draft document will be submitted to the RFC editor as a Draft Standard for the Internet Community. ") Just to double-check - it's being process for recycling at Proposed Standard at the moment, not for moving to Draft.
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
1) Sec 2.1: Should htere be a pointer to [iCAL] after text/multipart (you don't find out until the IANA section that that's where it's from): OLD: A MIME entity containing content information formatted according to this document will be referenced as a "text/calendar" content type. NEW: A MIME entity containing content information formatted according to this document will be referenced as a "text/calendar" content type [iCAL]. 2) Sec 2.1.1: Should the must be MUST in the following: That is, the "Organizer" must ignore an [iTIP] message from spoof@xyz.example.net that declines a meeting invitation for b@example.com. 3) In Sec 2.2.2, the last sentence is confusing to me. Aren't you really trying to say unauthenticated messages may not be reliable? OLD: Authenticating an unsigned message may not be reliable. NEW: Unauthenticated messages (i.e., unsigned messages) may not be reliable. 4) To align with 2.2.2, change 2.2.3 to explicitly call out multipart/encrypted: OLD: To ensure confidentiality using iMIP implementations should utilize encryption compliant with [RFC-1847]. NEW: To ensure confidentiality using iMIP implementations should utilize "multipart/signed" from [RFC-1847]. Note that if DISCUSS #1 is agreed then the r/should/MUST. 5) Sec 2.2.3 (for clarity): OLD: The protocol does not restrict ... NEW: iMIP does not restrict ... 6) Sec 2.4 bullet #1: Shouldn't we add a reference after multipart/mixed to RFC 2046: OLD: Note 1: A MIME message containing multiple iCalendar objects with different method values MUST be further encapsulated with a "multipart/mixed" MIME entity. NEW: Note 1: A MIME message containing multiple iCalendar objects with different method values MUST be further encapsulated with a "multipart/mixed" MIME entity [RFC-2046]. 7) Sec 2.4: Add reference to RFC 2046: OLD: ... scheduling message (i.e., "multipart/alternative"). NEW: ... scheduling message (i.e., "multipart/alternative" [RFC-2046]). 8) Sec 3: Provide pointer back to 2.2.2 and 2.2.3: OLD: Compliant applications MUST support signing and encrypting text/calendar body parts using a mechanism based on Security Multiparts for MIME [RFC-1847] to facilitate the authentication of the originator of the iCalendar object. NEW: Compliant applications MUST support signing and encrypting text/calendar body parts using a mechanism based on Security Multiparts for MIME [RFC-1847] to facilitate the authentication of the originator of the iCalendar object (see Section 2.2.2 and 2.2.3). 9) Sec 3 bullet 1 (for clarity): replace: who signed the email message with who signed the text/calendar body part
(Stewart Bryant; former steering group member) No Objection
(Tim Polk; former steering group member) (was Discuss) No Objection
The Security Considerations text should be updated to reflect any changes that result from the discuss points above. Specifically, this specification will inherit many of the security considerations in pkix, s/mime and/or pgp if the changes suggested are accepted and implemented.
(Alexey Melnikov; former steering group member) Recuse