rfc2445.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 1,587 行 · 第 1/5 页
TXT
1,587 行
All numeric and hexadecimal values used in this memo are given in
decimal notation.
All names of properties, property parameters, enumerated property
values and property parameter values are case-insensitive. However,
all other property values are case-sensitive, unless otherwise
stated.
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: ietf-types@uninett.no
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:
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?