Network Working Group C. Daboo Internet-Draft Apple Intended status: Standards Track May 18, 2015 Expires: November 19, 2015 An Email Header for Improved iMIP Interoperability draft-daboo-imip-headers-00 Abstract This document defines a new email message header to improve interoperability when the iCalendar Message-Based Interoperability Protocol (iMIP) is being used to send scheduling messages. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 19, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Daboo Expires November 19, 2015 [Page 1] Internet-Draft iMIP Email Header May 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 3. iMIP-Content-ID Email Message Header . . . . . . . . . . . . 3 3.1. Formal Definition . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Appendix A. Example of Common iMIP Message Structures . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction The iCalendar [RFC5545] specification defines a standard way to describe calendar data. The iTIP [RFC5546] specification defines a transport independent messaging protocol for scheduling messages based on iCalendar. The iMIP [RFC6047] specification defines how the iTIP protocol can be used over an email [RFC5322] transport by "attaching" iCalendar parts to an email message. Whilst iMIP has been in use for quite some time, there continue to be problems with interoperability between different implementations. In particular, many implementations are sensitive to the exact "structure" of the email message parts. Some clients expect specific headers to be present, or to have specific values (e.g., a "Content- Disposition" header with a value "attachment"). What this means is that an iMIP message sent from one client to another often goes unrecognized as an iMIP message, and the calendar data is never processed as a scheduling message. In some cases, clients generate multiple iCalendar attachments, with different "Content-Type" header values in order to have a greater chance of their message being processed correctly. This specification addresses these problems by introducing a new email message header that can be used by clients to clearly identify that an email message is in fact an iMIP message, as well as clearly identify which part within the email message corresponds to the iCalendar data to be processed as an iMIP message. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and Daboo Expires November 19, 2015 [Page 2] Internet-Draft iMIP Email Header May 2015 "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. iMIP-Content-ID Email Message Header When a client generates an iMIP email message it includes an "iMIP- Content-ID" header field in the MIME part corresponding to the iCalendar data used for scheduling. There MUST be only one iCalendar part with that header present. The client then includes an "iMIP- Content-ID" header in the top-level email message headers, setting the value of that header to the value used for the "iMIP-Content-ID" header associated with the iCalendar data part. A mail user agent that is capable of processing iMIP messages can do the following: 1. If a top-level "iMIP-Content-ID" message header is present, the mail user agent can parse the message body and extract the iCalendar data in the message sub-part with the matching "iMIP- Content-ID" header value. This can then be handed off to the appropriate calendar user agent for processing as an iTIP message. If an "iMIP-Content-ID" header is present at the top- level of the message, but no matching iCalendar data is found, then the email message MUST be processed as if the "iMIP-Content- ID" header were not present. 2. If an "iMIP-Content-ID" header is not present at the top-level of the message, then the client SHOULD look for the presence of that header in a message sub-part and apply the following rules: A. If a single "iMIP-Content-ID" is present in a sub-part of the message and the associated part is a valid iCalendar iMIP message, then the iCalendar data can be handed off to the appropriate calendar user agent for processing as an iTIP message. B. In all other cases (including multiple "iMIP-Content-ID" headers present in different sub-parts), the email message MUST be processed as if the "iMIP-Content-ID" header were not present. The key benefit of this approach is that it allows mail user agents (and automated email processing/filtering systems like SIEVE [RFC5228]) to quickly and clearly identify incoming iMIP messages, without the need to do an in-depth examination of the MIME structure of the message to look for suitable iCalendar attachments. In addition, the presence of this header will not impact current Daboo Expires November 19, 2015 [Page 3] Internet-Draft iMIP Email Header May 2015 processing of iMIP messages and thus provides a backwards compatible, incremental upgrade to a more reliable mechanism. 3.1. Formal Definition The "iMIP-Content-ID" header field is specified as follows using Augmented Backus-Naur Form [RFC5234], with additional terms from [RFC5322]: imip-content-id = "iMIP-Content-ID:" msg-id 4. Security Considerations Email message security typically does not cover top-level message headers in signed or encrypted email data. It is therefore possible for an attacker to add, modify or remove an "iMIP-Content-ID" header in the top-level message headers. Such an attack can be mitigated by using a technology such as DomainKeys Identified Mail (DKIM) [RFC6376], and it is RECOMMENDED that the "iMIP-Content-ID" header be included as one of the signed header fields. 5. IANA Considerations The IANA is asked to register the new header field, using the template as follows, in accordance with [RFC3864]. Header field name: iMIP-Content-ID Applicable protocol: mail Status: standard Author/Change controller: IETF Specification document(s): This document Related information: iMIP [RFC6047] 6. Acknowledgments Thanks to the following for feedback: Ken Murchison. This specification originated from discussions at a Calendaring and Scheduling Consortium interoperability event. Daboo Expires November 19, 2015 [Page 4] Internet-Draft iMIP Email Header May 2015 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009. [RFC5546] Daboo, C., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, December 2009. [RFC6047] Melnikov, A., "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 6047, December 2010. [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011. 7.2. Informative References [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering Language", RFC 5228, January 2008. Appendix A. Example of Common iMIP Message Structures TBD Author's Address Daboo Expires November 19, 2015 [Page 5] Internet-Draft iMIP Email Header May 2015 Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino , CA 95014 USA Email: cyrus@daboo.name URI: http://www.apple.com/ Daboo Expires November 19, 2015 [Page 6]