rfc2447.txt

RFC 的详细文档！

Network Working Group                                         F. Dawson
Request for Comments: 2447                                        Lotus
Category: Standards Track                                    S. Mansour
                                                               Netscape
                                                          S. Silverberg
                                                              Microsoft
                                                          November 1998


           iCalendar Message-Based Interoperability Protocol
                                 (iMIP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   This document, [iMIP], specifies a binding from the iCalendar
   Transport-independent Interoperability Protocol (iTIP) to Internet
   email-based transports. Calendaring entries defined by the iCalendar
   Object Model [iCAL] are composed using constructs from [RFC-822],
   [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].

   This document is based on discussions within the Internet Engineering
   Task Force (IETF) Calendaring and Scheduling (CALSCH) working group.
   More information about the IETF CALSCH working group activities can
   be found on the IMC web site at http://www.imc.org, the IETF web site
   at http://www.ietf.org/html.charters/calsch-charter.html. Refer to
   the references within this document for further information on how to
   access these various documents.












Dawson, et. al.             Standards Track                     [Page 1]

RFC 2447                          iMIP                     November 1998


Table of Contents

 1 INTRODUCTION........................................................2
  1.1 RELATED MEMOS ...................................................2
  1.2 FORMATTING CONVENTIONS ..........................................3
  1.3 TERMINOLOGY .....................................................4
 2 MIME MESSAGE FORMAT BINDING.........................................4
  2.1 MIME MEDIA TYPE .................................................4
  2.2 SECURITY ........................................................4
    2.2.1 Authorization ...............................................4
    2.2.2 Authentication ..............................................5
    2.2.3 Confidentiality .............................................5
  2.3 [RFC-822] ADDRESSES .............................................5
  2.4 CONTENT TYPE ....................................................5
  2.5 CONTENT-TRANSFER-ENCODING .......................................6
  2.6 CONTENT-DISPOSITION .............................................6
 3 SECURITY CONSIDERATIONS.............................................7
 4 EXAMPLES............................................................8
  4.1 SINGLE COMPONENT WITH AN ATTACH PROPERTY ........................8
  4.2 USING MULTIPART ALTERNATIVE FOR LOW FIDELITY CLIENTS ............8
  4.3 SINGLE COMPONENT WITH AN ATTACH PROPERTY AND INLINE ATTACHMENT ..9
  4.4 MULTIPLE SIMILAR COMPONENTS ....................................10
  4.5 MULTIPLE MIXED COMPONENTS ......................................11
  4.6 DETAILED COMPONENTS WITH AN ATTACH PROPERTY ....................13
 5 RECOMMENDED PRACTICES..............................................14
  5.1 USE OF CONTENT AND MESSAGE IDS .................................14
 6 BIBLIOGRAPHY.......................................................15
 7 AUTHORS' ADDRESSES.................................................16
 8 FULL COPYRIGHT STATEMENT...........................................18

1 Introduction

   This binding document provides the transport specific information
   necessary convey iCalendar Transport-independent Interoperability
   Protocol (iTIP) over MIME as defined in [RFC-822] and [RFC-2045].

1.1 Related Memos

   Implementers will need to be familiar with several other memos that,
   along with this memo, form a framework for Internet calendaring and
   scheduling standards.

   This document, [iMIP], specifies an Internet email binding for iTIP.

   [iCAL] - specifies a core specification of objects, data types,
   properties and property parameters;





Dawson, et. al.             Standards Track                     [Page 2]

RFC 2447                          iMIP                     November 1998


   [iTIP] - specifies an interoperability protocol for scheduling
   between different implementations;

   This memo does not attempt to repeat the specification of concepts or
   definitions from these other memos. Where possible, references are
   made to the memo that provides for the specification of these
   concepts or definitions.

1.2 Formatting Conventions

   The mechanisms defined in this memo are defined in prose. In order to
   refer to elements of the calendaring and scheduling model, core
   object or interoperability protocol defined in [iCAL] and [iTIP] some
   formatting conventions have been used.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   document are to be interpreted as described in [RFC-2119].

   Calendaring and scheduling roles are referred to in quoted-strings of
   text with the first character of each word in upper case. For
   example, "Organizer" refers to a role of a "Calendar User" within the
   scheduling protocol defined by [iTIP].

   Calendar components defined by [iCAL] are referred to with
   capitalized, quoted-strings of text. All calendar components start
   with the letter "V". For example, "VEVENT" refers to the event
   calendar component, "VTODO" refers to the to-do calendar component
   and "VJOURNAL" refers to the daily journal calendar component.

   Scheduling methods defined by [iTIP] are referred to with
   capitalized, quoted-strings of text. For example, "REQUEST" refers to
   the method for requesting a scheduling calendar component be created
   or modified, "REPLY" refers to the method a recipient of a request
   uses to update their status with the "Organizer" of the calendar
   component.

   Properties defined by [iCAL] are referred to with capitalized,
   quoted-strings of text, followed by the word "property". For example,
   "ATTENDEE" property refers to the iCalendar property used to convey
   the calendar address of a calendar user.

   Property parameters defined by [iCAL] are referred to with lower
   case, quoted-strings of text, followed by the word "parameter". For
   example, "value" parameter refers to the iCalendar property parameter
   used to override the default data type for a property value.





Dawson, et. al.             Standards Track                     [Page 3]

RFC 2447                          iMIP                     November 1998


1.3 Terminology

   The email terms used in this memo are defined in [RFC-822] and [RFC-
   2045]. The calendaring and scheduling terms used in this memo are
   defined in [iCAL] and [iTIP].

2 MIME Message Format Binding

   This section defines the message binding to the MIME electronic mail
   transport.

   The sections below refer to the "originator" and the "respondent" of
   an iMIP message. Typically, the originator is the "Organizer" of an
   event.  The respondent is an "Attendee" of the event.

   The [RFC-822] "Reply-To" header typically contains the email address
   of the originator or respondent of an event. However, this cannot be
   guaranteed as Mail User Agents (MUA) are not required to enforce iMIP
   semantics.

2.1 MIME Media Type

   A MIME entity containing content information formatted according to
   this document will be referenced as a "text/calendar" content type.
   It is assumed that this content type will be transported through a
   MIME electronic mail transport.

2.2 Security

   This section addresses several aspects of security including
   Authentication, Authorization and Confidentiality. Authentication and
   confidentiality can be achieved using [RFC-1847] that specifies the
   Security Multiparts for MIME. This framework defines new content
   types and subtypes of multipart: signed and encrypted. Each contains
   two body parts: one for the protected data and another for the
   control information necessary to remove the protection.

2.2.1 Authorization

   In [iTIP] messages, only the "Organizer" is authorized to modify or
   cancel calendar entries they organize. That is, [e-mail] is not
   allowed to modify or cancel a meeting that was organized by
   [e-mail]. Furthermore, only the respondent has the authorization
   to indicate their status to the "Organizer". That is, the "Organizer"
   must ignore an [iTIP] message from [e-mail] that declines a
   meeting invitation for [e-mail].





Dawson, et. al.             Standards Track                     [Page 4]

RFC 2447                          iMIP                     November 1998


   Implementations of iMIP SHOULD verify the authenticity of the creator
   of an iCalendar object before taking any action. The methods for
   doing this are presented later in this document.

   [RFC-1847] Message flow in iTIP supports someone working on behalf of
   a "Calendar User" through use of the "sent-by" parameter that is
   associated with the "ATTENDEE" and "ORGANIZER" properties. However,
   there is no mechanism to verify whether or not a "Calendar User" has
   authorized someone to work on their behalf. It is left to
   implementations to provide mechanisms for the "Calendar Users" to
   make that decision.

2.2.2 Authentication

   Authentication can be performed using an implementation of [RFC-1847]
   "multipart/signed" that supports public/private key certificates.
   Authentication is possible only on messages that have been signed.
   Authenticating an unsigned message may not be reliable.

2.2.3 Confidentiality

   To ensure confidentiality using iMIP implementations should utilize
   [RFC-1847]-compliant encryption. The protocol does not restrict a
   "Calendar User Agent" (CUA) from forwarding iCalendar objects to
   other users or agents.

2.3 [RFC-822] Addresses

   The calendar address specified within the "ATTENDEE" property in an
   iCalendar object MUST be a fully qualified, [RFC-822] address
   specification for the corresponding "Organizer" or "Attendee" of the
   "VEVENT" or "VTODO".

   Because [iTIP] does not preclude "Attendees" from forwarding
   "VEVENTS" or "VTODOS" to others, the [RFC-822] "Sender" value may not
   equal that of the "Organizer". Additionally, the "Organizer" or
   "Attendee" cannot be reliably inferred by the [RFC-822] "Sender" or
   "Reply-to" values of an iMIP message. The relevant address MUST be
   ascertained by opening the "text/calendar" MIME body part and
   examining the "ATTENDEE" and "ORGANIZER" properties.

2.4 Content Type

   A MIME body part containing content information that conforms to this
   document MUST have an [RFC-2045] "Content-Type" value of
   "text/calendar". The [RFC-2045] "Content-Type" header field must also
   include the type parameter "method". The value MUST be the same as
   the value of the "METHOD" calendar property within the iCalendar



Dawson, et. al.             Standards Track                     [Page 5]

RFC 2447                          iMIP                     November 1998


   object.  This means that a MIME message containing multiple iCalendar
   objects with different method values must be further encapsulated
   with a "multipart/mixed" MIME entity. This will allow each of the
   iCalendar objects to be encapsulated within their own "text/calendar"
   MIME entity.

   A "charset" parameter MUST be present if the iCalendar object
   contains characters that are not part of the US-ASCII character set.
   [RFC-2046] discusses the selection of an appropriate "charset" value.

   The optional "component" parameter defines the iCalendar component
   type contained within the iCalendar object.

   The following is an example of this header field with a value that
   indicates an event message.

        Content-Type:text/calendar; method=request; charset=UTF-8;
              component=vevent

   The "text/calendar" content type allows for the scheduling message
   type to be included in a MIME message with other content information
   (i.e., "multipart/mixed") or included in a MIME message with a
   clear-text, human-readable form of the scheduling message (i.e.,
   "multipart/alternative").

   In order to permit the information in the scheduling message to be
   understood by MIME user agents (UA) that do not support the
   "text/calendar" content type, scheduling messages SHOULD be sent with
   an alternative, human-readable form of the information.

2.5 Content-Transfer-Encoding

   Note that the default character set for iCalendar objects is UTF-8. A
   transfer encoding SHOULD be used for iCalendar objects containing any
   characters that are not part of the US-ASCII character set.

2.6 Content-Disposition

   The handling of a MIME part should be based on its [RFC-2045]
   "Content-Type". However, this is not guaranteed to work in all
   environments. Some environments handle MIME attachments based on
   their file type or extension. To operate correctly in these
   environments, implementations may wish to include a "Content-
   Disposition" property to define a file name.







Dawson, et. al.             Standards Track                     [Page 6]