Internet DRAFT - draft-daboo-imip-headers
draft-daboo-imip-headers
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]
