rfc2445.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,631 行 · 第 1/5 页

        Note: All indented editorial notes, such as this one, are
        intended to provide the reader with additional information. The
        information is not essential to the building of an
        implementation conformant with this memo. The information is
        provided to highlight a particular feature or characteristic of
        the memo.




Dawson & Stenerson          Standards Track                     [Page 6]

RFC 2445                       iCalendar                   November 1998


   The format for the iCalendar object is based on the syntax of the
   [RFC 2425] content type. While the iCalendar object is not a profile
   of the [RFC 2425] content type, it does reuse a number of the
   elements from the [RFC 2425] specification.

2.1 Formatting Conventions

   The mechanisms defined in this memo are defined in prose. Many of the
   terms used to describe these have common usage that is different than
   the standards usage of this memo. In order to reference within this
   memo elements of the calendaring and scheduling model, core object
   (this memo) or interoperability protocol [ITIP] some formatting
   conventions have been used. 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 this memo 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.

   The properties defined by this memo 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 this memo are referred to with lowercase, 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. Enumerated values defined by
   this memo are referred to with capitalized text, either alone or
   followed by the word "value". For example, the "MINUTELY" value can
   be used with the "FREQ" component of the "RECUR" data type to specify
   repeating components based on an interval of one minute or more.











Dawson & Stenerson          Standards Track                     [Page 7]

RFC 2445                       iCalendar                   November 1998


2.2 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 memo, [ICAL], specifies a core
   specification of objects, data types, properties and property
   parameters.

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

   [IMIP] specifies an Internet email binding for [ITIP].

   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.

2.3 International Considerations

   In the rest of this document, descriptions of characters are of the
   form "character name (codepoint)", where "codepoint" is from the US-
   ASCII character set. The "character name" is the authoritative
   description; (codepoint) is a reference to that character in US-ASCII
   or US-ASCII compatible sets (for example the ISO-8859-x family, UTF-
   8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character set
   is used, appropriate code-point from that character set MUST be
   chosen instead. Use of non-US-ASCII-compatible character sets is NOT
   recommended.

3  Registration Information

   The Calendaring and Scheduling Core Object Specification is intended
   for use as a MIME content type. However, the implementation of the
   memo is in no way limited solely as a MIME content type.

3.1 Content Type

   The following text is intended to register this memo as the MIME
   content type "text/calendar".

     To: [e-mail]

     Subject: Registration of MIME content type text/calendar.

     MIME media type name: text

     MIME subtype name: calendar



Dawson & Stenerson          Standards Track                     [Page 8]

RFC 2445                       iCalendar                   November 1998


3.2 Parameters

   Required parameters: none

   Optional parameters: charset, method, component and optinfo

   The "charset" parameter is defined in [RFC 2046] for other body
   parts. It is used to identify the default character set used within
   the body part.

   The "method" parameter is used to convey the iCalendar object method
   or transaction semantics for the calendaring and scheduling
   information. It also is an identifier for the restricted set of
   properties and values that the iCalendar object consists of. The
   parameter is to be used as a guide for applications interpreting the
   information contained within the body part. It SHOULD NOT be used to
   exclude or require particular pieces of information unless the
   identified method definition specifically calls for this behavior.
   Unless specifically forbidden by a particular method definition, a
   text/calendar content type can contain any set of properties
   permitted by the Calendaring and Scheduling Core Object
   Specification. The "method" parameter MUST be the same value as that
   specified in the "METHOD" component property in the iCalendar object.
   If one is present, the other MUST also be present.

   The value for the "method" parameter is defined as follows:

        method  = 1*(ALPHA / DIGIT / "-")
        ; IANA registered iCalendar object method

   The "component" parameter conveys the type of iCalendar calendar
   component within the body part. If the iCalendar object contains more
   than one calendar component type, then multiple component parameters
   MUST be specified.

   The value for the "component" parameter is defined as follows:

        component       = ("VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY"
                        / "VTIMEZONE" / x-name / iana-token)

   The "optinfo" parameter conveys optional information about the
   iCalendar object within the body part. This parameter can only
   specify semantics already specified by the iCalendar object and that
   can be otherwise determined by parsing the body part. In addition,
   the optional information specified by this parameter MUST be
   consistent with that information specified by the iCalendar object.
   For example, it can be used to convey the "Attendee" response status
   to a meeting request. The parameter value consists of a string value.



Dawson & Stenerson          Standards Track                     [Page 9]

RFC 2445                       iCalendar                   November 1998


   The parameter can be specified multiple times.

   This parameter MAY only specify semantics already specified by the
   iCalendar object and that can be otherwise determined by parsing the
   body part.

   The value for the "optinfo" parameter is defined as follows:

        optinfo = infovalue / qinfovalue

        infovalue       = iana-token / x-name

        qinfovalue      = DQUOTE (infovalue) DQUOTE

3.3 Content Header Fields

   Optional content header fields: Any header fields defined by [RFC
   2045].

3.4 Encoding Considerations

   This MIME content type can contain 8bit characters, so the use of
   quoted-printable or BASE64 MIME content-transfer-encodings might be
   necessary when iCalendar objects are transferred across protocols
   restricted to the 7bit repertoire. Note that a text valued property
   in the content entity can also have content encoding of special
   characters using a BACKSLASH character (US-ASCII decimal 92)
   escapement technique. This means that content values can end up
   encoded twice.

3.5 Security Considerations

   SPOOFING - - In this memo, the "Organizer" is the only person
   authorized to make changes to an existing "VEVENT", "VTODO",
   "VJOURNAL" calendar component and redistribute the updates to the
   "Attendees". An iCalendar object that maliciously changes or cancels
   an existing "VEVENT", "VTODO" or "VJOURNAL" or "VFREEBUSY" calendar
   component might be constructed by someone other than the "Organizer"
   and sent to the "Attendees". In addition in this memo, other than the
   "Organizer", an "Attendee" of a "VEVENT", "VTODO", "VJOURNAL"
   calendar component is the only other person authorized to update any
   parameter associated with their "ATTENDEE" property and send it to
   the "Organizer". An iCalendar object that maliciously changes the
   "ATTENDEE" parameters can be constructed by someone other than the
   real "Attendee" and sent to the "Organizer".






Dawson & Stenerson          Standards Track                    [Page 10]

RFC 2445                       iCalendar                   November 1998


   PROCEDURAL ALARMS - - An iCalendar object can be created that
   contains a "VEVENT" and "VTODO" calendar component with "VALARM"
   calendar components. The "VALARM" calendar component can be of type
   PROCEDURE and can have an attachment containing some sort of
   executable program. Implementations that incorporate these types of
   alarms are subject to any virus or malicious attack that might occur
   as a result of executing the attachment.

   ATTACHMENTS - - An iCalendar object can include references to Uniform
   Resource Locators that can be programmed resources.

   Implementers and users of this memo should be aware of the network
   security implications of accepting and parsing such information. In
   addition, the security considerations observed by implementations of
   electronic mail systems should be followed for this memo.

3.6 Interoperability Considerations

   This MIME content type is intended to define a common format for
   conveying calendaring and scheduling information between different
   systems. It is heavily based on the earlier [VCAL] industry
   specification.

3.7 Applications Which Use This Media Type

   This content-type is designed for widespread use by Internet
   calendaring and scheduling applications. In addition, applications in
   the workflow and document management area might find this content-
   type applicable. The [ITIP] and [IMIP] Internet protocols directly
   use this content-type also. Future work on an Internet calendar
   access protocol will utilize this content-type too.

3.8 Additional Information

   This memo defines this content-type.

3.9 Magic Numbers

   None.

3.10 File Extensions

   The file extension of "ics" is to be used to designate a file
   containing (an arbitrary set of) calendaring and scheduling
   information consistent with this MIME content type.






Dawson & Stenerson          Standards Track                    [Page 11]

RFC 2445                       iCalendar                   November 1998


   The file extension of "ifb" is to be used to designate a file
   containing free or busy time information consistent with this MIME
   content type.

   Macintosh file type codes: The file type code of "iCal" is to be used
   in Apple MacIntosh operating system environments to designate a file
   containing calendaring and scheduling information consistent with
   this MIME media type.

   The file type code of "iFBf" is to be used in Apple MacIntosh
   operating system environments to designate a file containing free or
   busy time information consistent with this MIME media type.

3.11 Contact for Further Information:

   Frank Dawson
   6544 Battleford Drive
   Raleigh, NC 27613-3502
   919-676-9515 (Telephone)
   919-676-9564 (Data/Facsimile)
   [e-mail] (Internet Mail)

   Derik Stenerson
   One Microsoft Way
   Redmond, WA  98052-6399
   425-936-5522 (Telephone)
   425-936-7329 (Facsimile)
   [e-mail] (Internet Mail)

3.12 Intended Usage

   COMMON