iCalendar Message-Based Interoperability Protocol (iMIP)
RFC 6047

Note: This ballot was opened for revision 11 and is now closed.

(Peter Saint-Andre) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) (was Discuss) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2010-09-09)
No email
send info
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.

(David Harrington) No Objection

(Russ Housley) No Objection

(Tim Polk) (was Discuss) No Objection

Comment (2010-09-08)
No email
send info
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.

(Dan Romascanu) No Objection

Comment (2010-09-09 for -)
No email
send info
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.

(Robert Sparks) No Objection

Comment (2010-09-07 for -)
No email
send info
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.

(Sean Turner) (was Discuss) No Objection

Comment (2010-09-07)
No email
send info
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 

Alexey Melnikov Recuse