Network Working Group G. Klyne
Request for Comments: 3862 Nine by Nine
Category: Standards Track D. Atkins
IHTFP Consulting
August 2004
Network Working Group G. Klyne
Request for Comments: 3862 Nine by Nine
Category: Standards Track D. Atkins
IHTFP Consulting
August 2004
Common Presence and Instant Messaging (CPIM): Message Format
常见状态和即时消息（CPIM）：消息格式
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification.
此备忘录定义了MIME内容类型“Message/CPIM”，这是符合即时消息通用配置文件（CPIM）规范的协议的消息格式。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology and Conventions . . . . . . . . . . . . . . 5
2. Overall Message Structure . . . . . . . . . . . . . . . . . . 5
2.1. Message/CPIM MIME Headers . . . . . . . . . . . . . . . 6
2.2. Message Headers . . . . . . . . . . . . . . . . . . . . 6
2.3. Character Escape Mechanism . . . . . . . . . . . . . . . 8
2.3.1. Escape Mechanism Usage . . . . . . . . . . . . . 8
2.4. Message Content . . . . . . . . . . . . . . . . . . . . 9
3. Message Header Syntax . . . . . . . . . . . . . . . . . . . . 10
3.1. Header Names . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Header Value . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Language tagging . . . . . . . . . . . . . . . . . . . . 10
3.4. Namespaces for Header Name Extensibility . . . . . . . . 11
3.5. Mandatory-to-Recognize Features . . . . . . . . . . . . 13
3.6. Collected Message Header Syntax . . . . . . . . . . . . 14
4. Header Definitions . . . . . . . . . . . . . . . . . . . . . . 16
4.1. The 'From' Header . . . . . . . . . . . . . . . . . . . 16
4.2. The 'To' Header . . . . . . . . . . . . . . . . . . . . 17
4.3. The 'cc' Header . . . . . . . . . . . . . . . . . . . . 18
4.4. The 'DateTime' Header . . . . . . . . . . . . . . . . . 18
4.5. The 'Subject' Header . . . . . . . . . . . . . . . . . . 19
4.6. The 'NS' Header . . . . . . . . . . . . . . . . . . . . 20
4.7. The 'Require' Header . . . . . . . . . . . . . . . . . . 20
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. An Example Message/CPIM Message . . . . . . . . . . . . 21
5.2. An Example Esing MIME multipart/signed . . . . . . . . . 22
6. Application Design Considerations . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7.1. Registration for Message/CPIM Content Type . . . . . . . 24
7.2. Registration for urn:ietf:params:cpim-headers . . . . . 25
8. Internationalization Considerations . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References. . . . . . . . . . . . . . . . . . 26
11.2. Informative References. . . . . . . . . . . . . . . . . 27
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology and Conventions . . . . . . . . . . . . . . 5
2. Overall Message Structure . . . . . . . . . . . . . . . . . . 5
2.1. Message/CPIM MIME Headers . . . . . . . . . . . . . . . 6
2.2. Message Headers . . . . . . . . . . . . . . . . . . . . 6
2.3. Character Escape Mechanism . . . . . . . . . . . . . . . 8
2.3.1. Escape Mechanism Usage . . . . . . . . . . . . . 8
2.4. Message Content . . . . . . . . . . . . . . . . . . . . 9
3. Message Header Syntax . . . . . . . . . . . . . . . . . . . . 10
3.1. Header Names . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Header Value . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Language tagging . . . . . . . . . . . . . . . . . . . . 10
3.4. Namespaces for Header Name Extensibility . . . . . . . . 11
3.5. Mandatory-to-Recognize Features . . . . . . . . . . . . 13
3.6. Collected Message Header Syntax . . . . . . . . . . . . 14
4. Header Definitions . . . . . . . . . . . . . . . . . . . . . . 16
4.1. The 'From' Header . . . . . . . . . . . . . . . . . . . 16
4.2. The 'To' Header . . . . . . . . . . . . . . . . . . . . 17
4.3. The 'cc' Header . . . . . . . . . . . . . . . . . . . . 18
4.4. The 'DateTime' Header . . . . . . . . . . . . . . . . . 18
4.5. The 'Subject' Header . . . . . . . . . . . . . . . . . . 19
4.6. The 'NS' Header . . . . . . . . . . . . . . . . . . . . 20
4.7. The 'Require' Header . . . . . . . . . . . . . . . . . . 20
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. An Example Message/CPIM Message . . . . . . . . . . . . 21
5.2. An Example Esing MIME multipart/signed . . . . . . . . . 22
6. Application Design Considerations . . . . . . . . . . . . . . 22
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7.1. Registration for Message/CPIM Content Type . . . . . . . 24
7.2. Registration for urn:ietf:params:cpim-headers . . . . . 25
8. Internationalization Considerations . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
11.1. Normative References. . . . . . . . . . . . . . . . . . 26
11.2. Informative References. . . . . . . . . . . . . . . . . 27
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification. This is a common message format for CPIM-compliant messaging protocols [26].
此备忘录定义了MIME内容类型“Message/CPIM”，这是符合即时消息通用配置文件（CPIM）规范的协议的消息格式。这是符合CPIM的消息传递协议的通用消息格式[26]。
While being prepared for CPIM, this format is quite general and may be reused by other applications with similar requirements. Application specifications that adopt this as a base format should address the questions raised in section 6 of this document.
在为CPIM准备时，此格式非常通用，可以被具有类似要求的其他应用程序重用。采用此作为基本格式的应用程序规范应解决本文件第6节中提出的问题。
The Common Profile for Instant Messaging (CPIM) [26] specification defines a number of operations to be supported and criteria to be satisfied for interworking between diverse instant messaging protocols. The intent is to allow a variety of different protocols interworking through gateways to support cross-protocol messaging that meets the requirements of RFC 2779 [20].
即时消息通用配置文件（CPIM）[26]规范定义了各种即时消息协议之间互通所需支持的大量操作和满足的标准。其目的是允许各种不同的协议通过网关互通，以支持满足RFC 2779[20]要求的跨协议消息传递。
To adequately meet the security requirements of RFC 2779, a common message format is needed so that end-to-end signatures and encryption may be applied. This document describes a common canonical message format that must be used by any CPIM-compliant message transfer protocol, whereby signatures are calculated for end-to-end security.
为了充分满足RFC 2779的安全要求，需要一种通用的消息格式，以便可以应用端到端签名和加密。本文档描述了任何符合CPIM的消息传输协议都必须使用的通用规范消息格式，据此计算签名以实现端到端安全性。
The design of this message format is intended to enable security to be applied, while itself remaining agnostic about the specific security mechanisms that may be appropriate for a given application. For CPIM instant messaging and presence, specific security protocols are specified by the CPIM instant messaging [26] and CPIM presence [27] specifications.
此消息格式的设计旨在应用安全性，而其本身对于特定应用程序可能适用的特定安全机制仍然不可知。对于CPIM即时消息和状态，具体的安全协议由CPIM即时消息[26]和CPIM状态[27]规范指定。
Also note that the message format described here is not itself a MIME data format, although it may be contained within a MIME object, and may contain MIME objects. See section 2 for more details.
还要注意，这里描述的消息格式本身不是MIME数据格式，尽管它可能包含在MIME对象中，并且可能包含MIME对象。详见第2节。
RFC 2779 requires that an instant message can carry a MIME payload [1][2]; thus some level of support for MIME will be a common element of any CPIM compliant protocol. Therefore it seems reasonable that a common message format should use a RFC2822/MIME-like syntax [9], as protocol implementations must already contain code to parse this.
RFC2779要求即时消息可以携带MIME负载[1][2]；因此，对MIME的某种程度的支持将是任何CPIM兼容协议的常见元素。因此，公共消息格式应该使用类似RFC2822/MIME的语法[9]似乎是合理的，因为协议实现必须已经包含解析该语法的代码。
Unfortunately, using pure RFC2822/MIME can be problematic:
不幸的是，使用纯RFC2822/MIME可能会有问题：
o Irregular lexical structure -- RFC2822/MIME allows a number of optional encodings and multiple ways to encode a particular value. For example, RFC2822/MIME comments may be encoded in multiple ways. For security purposes, a single encoding method must be defined as a basis for computing message digest values. Protocols that transmit data in a different format would otherwise lose information needed to verify a signature.
o 不规则词汇结构——RFC2822/MIME允许许多可选编码和多种方式对特定值进行编码。例如，RFC2822/MIME注释可以以多种方式编码。出于安全目的，必须将单个编码方法定义为计算消息摘要值的基础。以不同格式传输数据的协议将丢失验证签名所需的信息。
o Weak internationalization -- RFC2822/MIME requires header values to use 7-bit ASCII, which is problematic for encoding international character sets. Mechanisms for language tagging in RFC2822/MIME headers [16] are awkward to use and have limited applicability.
o 弱国际化——RFC2822/MIME要求头值使用7位ASCII，这对于编码国际字符集是有问题的。RFC2822/MIME头[16]中的语言标记机制使用起来很笨拙，适用性有限。
o Mutability -- addition, modification or removal of header information. Because it is not explicitly forbidden, many applications that process MIME content (e.g., MIME gateways) rebuild or restructure messages in transit. This obliterates most attempts at achieving security (e.g., signatures), leaving receiving applications unable to verify the data received.
o 易变性——添加、修改或删除标题信息。由于没有明确禁止，许多处理MIME内容的应用程序（如MIME网关）会在传输过程中重建或重构消息。这消除了大多数实现安全性的尝试（例如签名），使接收应用程序无法验证接收到的数据。
o Message and payload separation -- there is not a clear syntactic distinction between message metadata and message content.
o 消息和有效负载分离——消息元数据和消息内容之间没有明确的语法区别。
o Limited extensibility. (X-headers are problematic because they may not be standardized; this leads to situations where a header starts out as experimental but then finds widespread application, resulting in a common usage that cannot be standardized.)
o 有限的可扩展性。（X-header是有问题的，因为它们可能没有标准化；这会导致这样的情况：一个header最初是实验性的，但后来得到广泛应用，导致无法标准化的常见用法。）
o No support for structured information (text string values only).
o 不支持结构化信息（仅限文本字符串值）。
o Some processors impose line length limitations.
o 一些处理器对行长度进行限制。
The message format defined by this memo overcomes some of these difficulties by having a simplified syntax that is generally compatible with the format accepted by RFC2822/MIME parsers and having a stricter syntax. It also defines mechanisms to support some desired features not covered by the RFC2822/MIME format specifications.
本备忘录定义的消息格式通过简化语法克服了其中一些困难，简化语法通常与RFC2822/MIME解析器接受的格式兼容，并且具有更严格的语法。它还定义了支持RFC2822/MIME格式规范中未涵盖的某些所需功能的机制。
This specification aims to satisfy the following goals:
本规范旨在满足以下目标：
o a securable end-to-end format for a message (a canonical message format to serve as a basis for signature calculation, rather than specified security mechanisms).
o 消息的安全端到端格式（作为签名计算基础的规范消息格式，而不是指定的安全机制）。
o independence of any specific application
o 任何特定应用程序的独立性
o capability of conveying a range of different address types
o 传输一系列不同地址类型的能力
o assumption of an 8-bit clean message-transfer protocol
o 8位干净消息传输协议的假设
o evolvable: extensible by multiple parties
o 可演化：可由多方扩展
o a clear separation of message metadata from message content
o 消息元数据与消息内容的清晰分离
o a simple, regular, easily parsed syntax
o 一种简单、规则、易于解析的语法
o a compact, low-overhead format for simple messages
o 用于简单消息的紧凑、低开销格式
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 BCP 14, RFC 2119 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[4]中的描述进行解释。
NOTE: Comments like this provide additional nonessential information about the rationale behind this document. Such information is not needed for building a conformant implementation, but may help those who wish to understand the design in greater depth.
注：此类评论提供了有关本文件背后的基本原理的其他非必要信息。构建一致性实现不需要这些信息，但可以帮助那些希望更深入地理解设计的人。
The CPIM message format encapsulates arbitrary MIME message content, together with message- and content-related metadata. This can optionally be signed or encrypted using MIME security multiparts in conjunction with an appropriate security scheme.
CPIM消息格式封装了任意MIME消息内容以及与消息和内容相关的元数据。可以选择使用MIME安全多部分和适当的安全方案对其进行签名或加密。
A Message/CPIM object is a two-part entity, where the first part contains the message metadata and the second part is the message content. The two parts are separated from the enclosing MIME header fields and also from each other by blank lines. The message metadata header information obeys more stringent syntax rules than the MIME message content headers that may be carried within the message.
消息/CPIM对象是一个由两部分组成的实体，其中第一部分包含消息元数据，第二部分是消息内容。这两个部分与封闭的MIME头字段分开，也通过空行彼此分开。消息元数据头信息遵守比消息中可能携带的MIME消息内容头更严格的语法规则。
A complete message looks something like this:
完整的消息如下所示：
m: Content-type: Message/CPIM
s:
h: (message-metadata-headers)
s:
e: (encapsulated MIME message-body)
m: Content-type: Message/CPIM
s:
h: (message-metadata-headers)
s:
e: (encapsulated MIME message-body)
The end of the message body is defined by the framing mechanism of the protocol used. The tags 'm:', 's:', 'h:', 'e:', and 'x:' are not part of the message format and are used here to indicate the different parts of the message, thus:
消息体的结尾由所用协议的帧机制定义。标记“m:”、“s:”、“h:”、“e:”和“x:”不是消息格式的一部分，在此处用于指示消息的不同部分，因此：
m: MIME headers for the overall message s: a blank separator line h: message headers e: encapsulated MIME object containing the message content x: MIME security multipart message wrapper
m:整个消息的MIME头s:空白分隔行h:消息头e:包含消息内容的封装MIME对象x:MIME安全多部分消息包装器
The message MIME headers identify the message as a CPIM-formatted message.
消息MIME头将消息标识为CPIM格式的消息。
The only required MIME header is:
唯一需要的MIME头是：
Content-type: Message/CPIM
内容类型：消息/CPIM
Other MIME headers may be used as appropriate for the message transfer environment.
其他MIME头可以根据消息传输环境的需要使用。
Message headers carry information relevant to the end-to-end transfer of the message from sender to receiver. Message headers MUST NOT be modified, reformatted or reordered in transit, but in some circumstances they MAY be examined by a CPIM message transfer protocol.
消息头携带与消息从发送方到接收方的端到端传输相关的信息。消息头在传输过程中不得修改、重新格式化或重新排序，但在某些情况下，它们可能会被CPIM消息传输协议检查。
The message headers serve a similar purpose to RFC 2822 message headers in email [9], and have a similar but restricted allowable syntax.
消息头的用途与电子邮件[9]中的RFC 2822消息头类似，并且具有类似但受限的允许语法。
The basic header syntax is:
基本标头语法为：
Key: Value
关键词：价值
where "Key" is a header name and "Value" is the corresponding header value.
其中，“键”是标题名称，“值”是对应的标题值。
The following considerations apply:
以下注意事项适用：
o The entire header MUST be contained on a single line. The line terminator is not considered part of the header value.
o 整个标题必须包含在一行中。行终止符不被视为标头值的一部分。
o Only one header per line. Multiple headers MUST NOT be included on a single line.
o 每行只有一个标题。一行中不能包含多个标题。
o Processors SHOULD NOT impose any line-length limitations.
o 处理器不应施加任何行长度限制。
o There MUST NOT be any whitespace at the beginning or end of a line.
o 行首或行尾不得有任何空格。
o UTF-8 character encoding [13] MUST be used throughout.
o 必须始终使用UTF-8字符编码[13]。
o The character sequence CR,LF (13,10) MUST be used to terminate each line.
o 字符序列CR，LF（13,10）必须用于终止每一行。
o The header name contains only US-ASCII characters (see section 3.1 and section 3.6 for the specific syntax).
o 标题名称仅包含US-ASCII字符（具体语法见第3.1节和第3.6节）。
o The header MUST NOT contain any control characters (0-31). If a header value needs to represent control characters then the escape mechanism described below MUST be used.
o 标题不得包含任何控制字符（0-31）。如果标头值需要表示控制字符，则必须使用下面描述的转义机制。
o There MUST be a single space character (32) following the header name and colon.
o 标题名称和冒号后面必须有一个空格字符（32）。
o Multiple headers using the same key (header name) are allowed. (Specific header semantics may dictate only one occurrence of any particular header.)
o 允许使用相同键（标题名称）的多个标题。（特定标题语义可能只指示任何特定标题的一次出现。）
o Header names MUST match exactly (i.e., "From:" and "from:" are different headers).
o 标题名称必须完全匹配（即，“发件人：”和“发件人：”是不同的标题）。
o If a header name is not recognized or not understood, the header should be ignored. But see also the "Require:" header (section 4.7).
o 如果未识别或未理解标头名称，则应忽略该标头。但也可参见“要求：”标题（第4.7节）。
o Interpretation (e.g., equivalence) of header values is dependent on the particular header definition. Message processors MUST preserve all octets of all headers (both name and value) exactly.
o 标题值的解释（例如，等效性）取决于特定标题定义。消息处理器必须准确地保留所有头（名称和值）的所有八位字节。
o Message processors MUST NOT change the order of message headers.
o 消息处理者不得更改消息头的顺序。
Examples:
示例：
To: Pooh Bear <im:pooh@100akerwood.com>
From: <im:piglet@100akerwood.com>
DateTime: 2001-02-02T10:48:54-05:00
To: Pooh Bear <im:pooh@100akerwood.com>
From: <im:piglet@100akerwood.com>
DateTime: 2001-02-02T10:48:54-05:00
This mechanism MUST be used to code control characters in a header, having Unicode code points in the range U+0000 to U+001f or U+007f. (Rather than invent something completely new, the escape mechanism has been adopted from that used by the Java programming language.)
此机制必须用于对标头中的控制字符进行编码，其Unicode代码点的范围为U+0000到U+001f或U+007f。（转义机制不是发明全新的东西，而是采用了Java编程语言使用的转义机制。）
Note that the escape mechanism is applied to a UCS-2 character, NOT to the octets of its UTF-8 coding. Mapping from/to UTF-8 coding is performed without regard for escape sequences or character coding. (The header syntax is defined so that octets corresponding to control characters other than CR and LF do not appear in the output.)
请注意，转义机制应用于UCS-2字符，而不是UTF-8编码的八位字节。执行从UTF-8编码到UTF-8编码的映射时，不考虑转义序列或字符编码。（标题语法的定义使得与CR和LF以外的控制字符相对应的八位字节不会出现在输出中。）
An arbitrary UCS-2 character is escaped using the form:
任意UCS-2字符使用以下形式转义：
\uxxxx
\uxxx
where:
哪里：
\ is U+005c (backslash)
u is U+0075 (lower case letter U)
xxxx is a sequence of exactly four hexadecimal digits
(0-9, a-f or A-F) or
(U+0030-U+0039, U+0041-U+0046, or U+0061-0066)
\ is U+005c (backslash)
u is U+0075 (lower case letter U)
xxxx is a sequence of exactly four hexadecimal digits
(0-9, a-f or A-F) or
(U+0030-U+0039, U+0041-U+0046, or U+0061-0066)
The hexadecimal number 'xxxx' is the UCS code-point value of the escaped character.
十六进制数字“xxxx”是转义字符的UCS代码点值。
Further, the following special sequences introduced by "\" are used:
此外，使用“\”引入的以下特殊序列：
\\ for \ (backslash, U+005c) \" for " (double quote, U+0022) \' for ' (single quote, U+0027) \b for backspace (U+0008) \t for tab (U+0009) \n for linefeed (U+000a) \r for carriage return (U+000d)
\\对于\（反斜杠，U+005c）\“for”（双引号，U+0022）\'for'（单引号，U+0027）\b对于退格（U+0008）\t对于制表符（U+0009）\n对于换行符（U+000a）\r对于回车符（U+000d）
When generating messages conformant with this specification:
生成符合本规范的消息时：
o The special sequences listed above MUST be used to encode any occurrence of the following characters that appear anywhere in a header: backslash (U+005c), backspace (U+0008), tab (U+0009), linefeed (U+000a) or carriage return (U+000d).
o 必须使用上面列出的特殊序列对出现在标题中任何位置的以下字符进行编码：反斜杠（U+005c）、反空格（U+0008）、制表符（U+0009）、换行符（U+000a）或回车符（U+000d）。
o The special sequence \" MUST be used for any occurrence of a double quote (U+0022) that appears within a string delimited by double quotes.
o 特殊序列\“必须用于出现在由双引号分隔的字符串中的双引号（U+0022）的任何情况。
o The special sequence \' MUST be used for any occurrence of a single quote (U+0027) that appears within a string delimited by single quotes.
o 特殊序列\'必须用于出现在由单引号分隔的字符串中的任何单引号（U+0027）。
o Single- or double-quote characters that delimit a string value MUST NOT be escaped.
o 不能转义分隔字符串值的单引号或双引号字符。
o The general escape sequence \uxxxx MUST be used for any other control character (U+0000 to U+0007, U+000b to U+000c, U+000e to U+001f or u+007f) that appears anywhere in a header.
o 常规转义序列\uxxx必须用于头中任何位置出现的任何其他控制字符（U+0000到U+0007、U+000b到U+000c、U+000e到U+001f或U+007f）。
o All other characters MUST NOT be represented using an escape sequence.
o 不得使用转义序列表示所有其他字符。
When processing a message based on this specification, the escape sequence usage described above MUST be recognized.
当根据本规范处理消息时，必须识别上述转义序列用法。
Further, any other occurrence of an escape sequence described above SHOULD be recognized and treated as an occurrence of the corresponding Unicode character.
此外，应识别上述转义序列的任何其他出现，并将其视为相应Unicode字符的出现。
Any backslash ('\') character SHOULD be interpreted as introducing an escape sequence. Any unrecognized escape sequence SHOULD be treated as an instance of the character following the backslash character. An isolated backslash that is the last character of a header SHOULD be ignored.
任何反斜杠（“\”）字符都应解释为引入转义序列。任何无法识别的转义序列都应视为反斜杠字符后面的字符的实例。应忽略作为标题最后一个字符的独立反斜杠。
The final section of a Message/CPIM is the MIME-encapsulated message content, which follows standard MIME formatting rules [1][2].
消息/CPIM的最后一部分是MIME封装的消息内容，它遵循标准MIME格式规则[1][2]。
The MIME content headers MUST include at least a Content-Type header. The content may be any MIME type.
MIME内容头必须至少包含一个内容类型头。内容可以是任何MIME类型。
Example:
例子：
e: Content-Type: text/plain; charset=utf-8
e: Content-ID: <1234567890@foo.com>
e:
e: This is my encapsulated text message content
e: Content-Type: text/plain; charset=utf-8
e: Content-ID: <1234567890@foo.com>
e:
e: This is my encapsulated text message content
A header contains two parts, a name and a value, separated by a colon character (':') and single space (32). It is terminated by the sequence CR,LF (13,10).
标头包含两部分，一个名称和一个值，由冒号字符（“：”）和单个空格（32）分隔。它由序列CR，LF（13,10）终止。
Headers use UTF-8 character encoding throughout, per RFC 3629 [13].
根据RFC 3629[13]，报头始终使用UTF-8字符编码。
NOTE: in the descriptions that follow, header field names and other specified text values MUST be used exactly as given, using exactly the indicated upper- and lower- case letters. In this respect, the ABNF usage differs from RFC 2234 [6].
注意：在下面的描述中，标题字段名和其他指定的文本值必须完全按照给定的方式使用，使用的是指定的大写和小写字母。在这方面，ABNF的用法不同于RFC 2234[6]。
The header name is a sequence of US-ASCII characters, excluding control, SPACE or separator characters. Use of the character "." in a header name is reserved for a namespace prefix separator.
标题名称是US-ASCII字符序列，不包括控制字符、空格或分隔符。在头名称中使用字符“.”是为命名空间前缀分隔符保留的。
Separator characters are:
分隔符字符包括：
SEPARATORS = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / DQUOTE
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP
SEPARATORS = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / DQUOTE
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP
NOTE: The range of allowed characters was determined by examination of HTTP and RFC 2822 header name formats and choosing the more restricted. The intent is to allow CPIM headers to follow a syntax that is compatible with the allowed syntax for both RFC 2822 [9] and HTTP [18] (including HTTP-derived protocols such as SIP [21]).
注意：允许的字符范围是通过检查HTTP和RFC 2822标头名称格式并选择更严格的格式来确定的。其目的是允许CPIM头遵循与RFC 2822[9]和HTTP[18]允许的语法兼容的语法（包括HTTP派生协议，如SIP[21]）。
A header value has a structure defined by the corresponding header specification. Implementations that use a particular header must adhere to the format and usage rules thus defined when creating or processing a message containing that header.
标头值具有由相应标头规范定义的结构。使用特定头的实现必须遵守在创建或处理包含该头的消息时定义的格式和使用规则。
The other general constraints on header formats MUST also be followed (one line, UTF-8 character encoding, no control characters, etc.)
还必须遵循头格式的其他一般约束条件（单行、UTF-8字符编码、无控制字符等）
Full internationalization of a protocol requires that a language can be indicated for any human-readable text [15][7].
协议的完全国际化要求可以为任何人类可读文本指示一种语言[15][7]。
A message header may indicate a language for its value by including ';lang=tag' after the header name and colon, where 'tag' is a language identifying token per RFC 3066 [10].
消息头可以通过包含“；”来表示其值的语言；lang=tag'位于标题名和冒号之后，其中“tag”是根据RFC 3066[10]识别标记的语言。
Example:
例子：
Subject:;lang=fr Objet de message
Subject:;lang=fr Objet de message
If the language parameter is not applied a header, any human-readable text is assumed to use the language identified as 'i-default' [7].
如果语言参数未应用于标题，则假定任何人类可读文本使用标识为“i-default”的语言[7]。
NOTE: This section defines a framework for header extensibility whose use is optional. If no header extensions are allowed by an application then these structures may never be used.
注意：本节定义了一个头部可扩展性框架，该框架的使用是可选的。如果应用程序不允许头扩展，那么这些结构可能永远不会被使用。
An application that uses this message format is expected to define the set of headers that are required and allowed for that application. This section defines a header extensibility framework that can be used with any application.
使用此消息格式的应用程序应定义该应用程序所需和允许的头集。本节定义了可用于任何应用程序的头扩展性框架。
The extensibility framework is based on that provided for XML [22] by XML namespaces [23]. All headers are associated with a "namespace", which is in turn associated with a globally unique URI.
可扩展性框架基于XML名称空间[23]为XML[22]提供的框架。所有的头都与一个“名称空间”相关联，该名称空间又与一个全局唯一的URI相关联。
Within a particular message instance, header names are associated with a particular namespace through the presence or absence of a namespace prefix, which is a leading part of the header name followed by a period ("."); e.g.,
在特定消息实例中，头名称通过名称空间前缀的存在或不存在与特定名称空间相关联，名称空间前缀是头名称的前导部分，后跟句点（“.”）；例如。，
prefix.header-name: header-value
prefix.header-name：头值
Here, 'prefix' is the header name prefix, 'header-name' is the header name within the namespace associated with 'prefix', and 'header-value' is the value for this header.
这里，“prefix”是头名称前缀，“header name”是与“prefix”关联的命名空间中的头名称，“header value”是此头的值。
header-name: header-value
标题名称：标题值
In this case, the header name prefix is absent, and the given 'header-name' is associated with a default namespace.
在本例中，缺少标头名称前缀，并且给定的“标头名称”与默认命名空间相关联。
The Message/CPIM media type registration designates a default namespace for any headers that are not more explicitly associated with any namespace. In most cases, this default namespace is all that is needed.
Message/CPIM media type registration为没有更明确地与任何命名空间关联的任何标头指定默认命名空间。在大多数情况下，只需要这个默认名称空间。
A namespace is identified by a URI. In this usage, the URI is used simply as a globally unique identifier, and there is no requirement that it can be used for any other purpose. Any legal globally unique URI MAY be used to identify a namespace. (By "globally unique", we mean constructed according to some set of rules so that it is reasonable to expect that nobody else will use the same URI for a different purpose.) A URI used as an identifier MUST be a full absolute-URI, per RFC 2396 [8]. (Relative URIs and URI-references containing fragment identifiers MUST NOT be used for this purpose.)
命名空间由URI标识。在这种用法中，URI仅用作全局唯一标识符，不要求它可用于任何其他用途。可以使用任何合法的全局唯一URI来标识命名空间。（所谓“全局唯一性”，我们指的是根据一组规则构造的，这样就可以合理地预期没有其他人会将相同的URI用于不同的目的。）根据RFC 2396[8]，用作标识符的URI必须是完全绝对URI。（包含片段标识符的相对URI和URI引用不得用于此目的。）
Within a specific message, an 'NS' header is used to declare a namespace prefix and associate it with a URI that identifies a namespace. Following that declaration, within the scope of that message, the combination of namespace prefix and header name indicates a globally unique identifier for the header (consisting of the namespace URI and header name).
在特定消息中，“NS”标头用于声明命名空间前缀并将其与标识命名空间的URI关联。在该声明之后，在该消息的范围内，名称空间前缀和头名称的组合表示头的全局唯一标识符（由名称空间URI和头名称组成）。
For example:
例如：
NS: MyFeatures <mid:MessageFeatures@id.foo.com>
MyFeatures.WackyMessageOption: Use-silly-font
NS: MyFeatures <mid:MessageFeatures@id.foo.com>
MyFeatures.WackyMessageOption: Use-silly-font
This defines a namespace prefix 'MyFeatures' associated with the namespace identifier 'mid:MessageFeatures@id.foo.com'. Subsequently, the prefix indicates that the WackyMessageOption header name referenced is associated with the identified namespace.
这定义了与命名空间标识符“mid:MessageFeatures@id.foo.com'. 随后，前缀表示引用的WackyMessageOption标头名称与标识的命名空间相关联。
A namespace prefix declaration MUST precede any use of that prefix.
命名空间前缀声明必须在使用该前缀之前。
With the exception of any application-specific predefined namespace prefixes (see section 6), a namespace prefix is strictly local to the message in which it occurs. The actual prefix used has no global significance. This means that the headers:
除了任何特定于应用程序的预定义名称空间前缀（请参见第6节）之外，名称空间前缀严格地位于发生它的消息的本地。实际使用的前缀没有全局意义。这意味着标题：
xxx.name: value yyy.name: value
xxx.name:value yyy.name:value
in two different messages may have exactly the same effect if namespace prefixes 'xxx' and 'yyy' are associated with the same namespace URI. Thus the following have exactly the same meaning:
如果名称空间前缀“xxx”和“yyy”与相同的名称空间URI相关联，则两条不同的消息可能具有完全相同的效果。因此，以下内容具有完全相同的含义：
NS: acme <http://id.acme.widgets/wily-headers/>
acme.runner-trap: set
NS: acme <http://id.acme.widgets/wily-headers/>
acme.runner-trap: set
and
和
NS: widget <http://id.acme.widgets/wily-headers/>
widget.runner-trap: set
NS: widget <http://id.acme.widgets/wily-headers/>
widget.runner-trap: set
A 'NS' header without a header prefix name specifies a default namespace for subsequent headers; that is a namespace that is associated with header names not having a prefix. For example:
没有标头前缀名称的“NS”标头为后续标头指定默认命名空间；这是一个与没有前缀的头名称关联的命名空间。例如：
NS: <http://id.acme.widgets/wily-headers/>
runner-trap: set
NS: <http://id.acme.widgets/wily-headers/>
runner-trap: set
has the same meaning as the previous examples.
与前面的示例具有相同的含义。
This framework allows different implementers to create extension headers without the worry of header name duplication; each defines headers within their own namespace.
该框架允许不同的实现者创建扩展头，而无需担心头名称重复；每个都在自己的名称空间中定义头。
Sometimes it is necessary for the sender of a message to insist that some functionality is understood by the recipient. By using the mandatory-to-recognize indicator, a sender is notifying the recipient that it MUST understand the named header or feature in order to properly understand the message.
有时，邮件的发送者必须坚持要求收件人理解某些功能。通过使用强制识别指示符，发送方通知接收方必须理解指定的标题或功能才能正确理解邮件。
A header or feature is indicated as being mandatory-to-recognize by a 'Require:' header. For example:
标题或功能被“Require:”标题指示为必须识别。例如：
Require: MyFeatures.VitalMessageOption MyFeatures.VitalMessageOption: Confirmation-requested
要求：MyFeatures.VitalMessageOption MyFeatures.VitalMessageOption：请求确认
Multiple required header names may be listed in a single 'Require' header, separated by commas.
在单个“Require”标题中可以列出多个必需的标题名称，并用逗号分隔。
NOTE: Indiscriminate use of 'Require:' headers could harm interoperability. It is suggested that any implementer who defines required headers also publish the header specifications so other implementations can successfully interoperate.
注意：不加区分地使用'Require:'头可能会损害互操作性。建议定义所需头的任何实现者也发布头规范，以便其他实现能够成功地进行互操作。
The 'Require:' header MAY also be used to indicate that some non-header semantics must be implemented by the recipient, even when it does not appear as a header. For example:
“Require:”头也可以用来表示收件人必须实现某些非头语义，即使它不显示为头。例如：
Require: Locale.MustRenderKanji
要求：Locale.MustRenderKanji
might be used to indicate that message content includes characters from the Kanji repertoire, which must be rendered for proper understanding of the message. In this case, the header name is just a token (using header name syntax and namespace association) that indicates some desired behaviour.
可能用于指示消息内容包括汉字库中的字符，为了正确理解消息，必须呈现这些字符。在本例中，头名称只是一个标记（使用头名称语法和名称空间关联），它指示一些所需的行为。
The following description of message header syntax uses ABNF, per RFC 2234 [6]. Most of this syntax can be interpreted as defining UCS character sequences or UTF-8 octet sequences. Alternate productions at the end allow for either interpretation.
根据RFC 2234[6]，以下消息头语法说明使用ABNF。大多数这种语法可以解释为定义UCS字符序列或UTF-8八位字节序列。结尾处的替代作品允许任何一种解释。
NOTE: Specified text values MUST be used as given, using exactly the indicated upper- and lower-case letters. In this respect, the ABNF usage here differs from RFC 2234 [6].
注意：指定的文本值必须按给定值使用，使用的是所示的大写和小写字母。在这方面，ABNF的用法不同于RFC 2234[6]。
Collected syntax:
收集的语法：
Header = Header-name ":" *( ";" Parameter ) SP Header-value CRLF
Header=标头名称“：”*（“；”参数）SP标头值CRLF
Header-name = [ Name-prefix "." ] Name
Name-prefix = Name
Header-name = [ Name-prefix "." ] Name
Name-prefix = Name
Parameter = Lang-param / Ext-param
Lang-param = "lang=" Language-tag
Ext-param = Param-name "=" Param-value
Param-name = Name
Param-value = Token / Number / String
Parameter = Lang-param / Ext-param
Lang-param = "lang=" Language-tag
Ext-param = Param-name "=" Param-value
Param-name = Name
Param-value = Token / Number / String
Header-value = *HEADERCHAR
Header-value = *HEADERCHAR
Name = 1*NAMECHAR
Token = 1*TOKENCHAR
Number = 1*DIGIT
String = DQUOTE *( Str-char / Escape ) DQUOTE
Str-char = %x20-21 / %x23-5B / %x5D-7E / UCS-high
Escape = "\" ( "u" 4(HEXDIG) ; UCS codepoint
/ "b" ; Backspace
/ "t" ; Tab
/ "n" ; Linefeed
/ "r" ; Return
/ DQUOTE ; Double quote
/ "'" ; Single quote
/ "\" ) ; Backslash
Name = 1*NAMECHAR
Token = 1*TOKENCHAR
Number = 1*DIGIT
String = DQUOTE *( Str-char / Escape ) DQUOTE
Str-char = %x20-21 / %x23-5B / %x5D-7E / UCS-high
Escape = "\" ( "u" 4(HEXDIG) ; UCS codepoint
/ "b" ; Backspace
/ "t" ; Tab
/ "n" ; Linefeed
/ "r" ; Return
/ DQUOTE ; Double quote
/ "'" ; Single quote
/ "\" ) ; Backslash
Formal-name = 1*( Token SP ) / String
URI = <defined as absolute-URI by RFC 2396>
Language-tag = <defined by RFC 3066>
Formal-name = 1*( Token SP ) / String
URI = <defined as absolute-URI by RFC 2396>
Language-tag = <defined by RFC 3066>
; Any UCS character except CTLs, or escape HEADERCHAR = UCS-no-CTL / Escape
; 除CTL以外的任何UCS字符，或转义HEADERCHAR=UCS无CTL/转义
; Any US-ASCII char except ".", CTLs or SEPARATORS:
NAMECHAR = %x21 / %x23-27 / %x2a-2b / %x2d
/ %x5e-60 / %x7c / %x7e
/ ALPHA / DIGIT
; Any US-ASCII char except ".", CTLs or SEPARATORS:
NAMECHAR = %x21 / %x23-27 / %x2a-2b / %x2d
/ %x5e-60 / %x7c / %x7e
/ ALPHA / DIGIT
; Any UCS char except CTLs or SEPARATORS:
TOKENCHAR = NAMECHAR / "." / UCS-high
; Any UCS char except CTLs or SEPARATORS:
TOKENCHAR = NAMECHAR / "." / UCS-high
SEPARATORS = "(" / ")" / "<" / ">" / "@" ; 28/29/3c/3e/40
/ "," / ";" / ":" / "\" / DQUOTE ; 2c/3b/3a/5c/22
/ "/" / "[" / "]" / "?" / "=" ; 2f/5b/5d/3f/3d
/ "{" / "}" / SP ; 7b/7d/20
CTL = <Defined by RFC 2234 -- %x0-%x1f, %x7f>
CRLF = <Defined by RFC 2234 -- CR, LF>
SP = <defined by RFC 2234 -- %x20>
DIGIT = <defined by RFC 2234 -- '0'-'9'>
HEXDIG = <defined by RFC 2234 -- '0'-'9', 'A'-'F', 'a'-'f'>
ALPHA = <defined by RFC 2234 -- 'A'-'Z', 'a'-'z'>
DQUOTE = <defined by RFC 2234 -- %x22>
SEPARATORS = "(" / ")" / "<" / ">" / "@" ; 28/29/3c/3e/40
/ "," / ";" / ":" / "\" / DQUOTE ; 2c/3b/3a/5c/22
/ "/" / "[" / "]" / "?" / "=" ; 2f/5b/5d/3f/3d
/ "{" / "}" / SP ; 7b/7d/20
CTL = <Defined by RFC 2234 -- %x0-%x1f, %x7f>
CRLF = <Defined by RFC 2234 -- CR, LF>
SP = <defined by RFC 2234 -- %x20>
DIGIT = <defined by RFC 2234 -- '0'-'9'>
HEXDIG = <defined by RFC 2234 -- '0'-'9', 'A'-'F', 'a'-'f'>
ALPHA = <defined by RFC 2234 -- 'A'-'Z', 'a'-'z'>
DQUOTE = <defined by RFC 2234 -- %x22>
To interpret the syntax in a general UCS character environment, use the following productions:
要在通用UCS字符环境中解释语法，请使用以下产品：
UCS-no-CTL = %x20-7e / UCS-high
UCS-high = %x80-7fffffff
UCS-no-CTL = %x20-7e / UCS-high
UCS-high = %x80-7fffffff
To interpret the syntax as defining UTF-8 coded octet sequences, use the following productions:
要将语法解释为定义UTF-8编码的八位字节序列，请使用以下结果：
UCS-no-CTL = UTF8-no-CTL
UCS-high = UTF8-multi
UTF8-no-CTL = %x20-7e / UTF8-multi
UTF8-multi = %xC0-DF %x80-BF
/ %xE0-EF %x80-BF %x80-BF
/ %xF0-F7 %x80-BF %x80-BF %x80-BF
/ %xF8-FB %x80-BF %x80-BF %x80-BF %x80-BF
/ %xFC-FD %x80-BF %x80-BF %x80-BF %x80-BF %x80-BF
UCS-no-CTL = UTF8-no-CTL
UCS-high = UTF8-multi
UTF8-no-CTL = %x20-7e / UTF8-multi
UTF8-multi = %xC0-DF %x80-BF
/ %xE0-EF %x80-BF %x80-BF
/ %xF0-F7 %x80-BF %x80-BF %x80-BF
/ %xF8-FB %x80-BF %x80-BF %x80-BF %x80-BF
/ %xFC-FD %x80-BF %x80-BF %x80-BF %x80-BF %x80-BF
NOTE: the above syntax comes from an older version of UTF-8, and is included for compatibility with UTF-8 software based on the earlier specifications. Applications generating this message format SHOULD generate UTF-8 that matches the more restricted specification in RFC 3629 [13].
注意：上述语法来自较旧版本的UTF-8，并且包含在其中是为了与基于早期规范的UTF-8软件兼容。生成此消息格式的应用程序应生成符合RFC 3629[13]中更严格规范的UTF-8。
This specification defines a core set of headers that are available for use by applications: an application specification must indicate the headers that may be used, those that must be recognized and those that must appear in any message (see section 6).
本规范定义了一组可供应用程序使用的核心标头：应用程序规范必须指明可能使用的标头、必须识别的标头以及必须出现在任何消息中的标头（参见第6节）。
The header definitions that follow fall into two categories:
以下标题定义分为两类：
a) those that are part of the CPIM format extensibility framework, and
a) 属于CPIM格式扩展性框架的一部分，以及
b) those that have been based on similar headers in RFC 2822 [9], specified here with corresponding semantics.
b) 基于RFC 2822[9]中类似标题的，在这里用相应的语义指定。
Header names and syntax are described without a namespace qualification, and the associated namespace URI is listed as part of the header specification. Any of the namespace associations already mentioned (implied default namespace, explicit default namespace or implied namespace prefix or explicit namespace prefix declaration) may be used to identify the namespace.
标题名称和语法在描述时没有名称空间限定，并且相关的名称空间URI作为标题规范的一部分列出。已经提到的任何名称空间关联（隐含默认名称空间、显式默认名称空间或隐含名称空间前缀或显式名称空间前缀声明）都可用于标识名称空间。
all headers defined here are associated with the namespace uri <urn:ietf:params:cpim-headers:>, which is defined according to [12].
此处定义的所有头都与命名空间uri<urn:ietf:params:cpim headers:>关联，该命名空间uri是根据[12]定义的。
NOTE: Header names and other text MUST be used as given, using exactly the indicated upper- and lower-case letters. In this respect, the ABNF usage here differs from RFC 2234 [6].
注意：标题名称和其他文本必须按照给定的方式使用，使用所示的大写和小写字母。在这方面，ABNF的用法不同于RFC 2234[6]。
Indicates the sender of a message.
指示邮件的发件人。
Header name: From
标题名称：从
Namespace URI:
<urn:ietf:params:cpim-headers:>
Namespace URI:
<urn:ietf:params:cpim-headers:>
Syntax: (see also section 3.6)
语法：（另见第3.6节）
From-header = "From" ": " [ Formal-name ] "<" URI ">"
; "From" is case-sensitive
From-header = "From" ": " [ Formal-name ] "<" URI ">"
; "From" is case-sensitive
Description: Indicates the sender or originator of a message.
描述：表示邮件的发件人或原始发件人。
If present, the 'Formal-name' identifies the person or "real world" name for the originator.
如果存在，“正式名称”标识发起人的个人或“真实世界”名称。
The URI indicates an address for the originator.
URI表示发起者的地址。
Examples:
示例：
From: Winnie the Pooh <im:pooh@100akerwood.com>
From: Winnie the Pooh <im:pooh@100akerwood.com>
From: <im:tigger@100akerwood.com>
From: <im:tigger@100akerwood.com>
Specifies an intended recipient of a message.
指定邮件的预期收件人。
Header name: To
标题名称：至
Namespace URI:
<urn:ietf:params:cpim-headers:>
Namespace URI:
<urn:ietf:params:cpim-headers:>
Syntax: (see also section 3.6)
语法：（另见第3.6节）
To-header = "To" ": " [ Formal-name ] "<" URI ">"
; "To" is case-sensitive
To-header = "To" ": " [ Formal-name ] "<" URI ">"
; "To" is case-sensitive
Description: Indicates the recipient of a message.
描述：表示邮件的收件人。
If present, the 'Formal-name' identifies the person or "real world" name for the recipient.
如果存在，“正式名称”标识收件人的个人或“真实世界”名称。
The URI indicates an address for the recipient.
URI表示收件人的地址。
Multiple recipients may be indicated by including multiple 'To' headers.
可以通过包含多个“收件人”标题来指示多个收件人。
Examples:
示例：
To: Winnie the Pooh <im:pooh@100akerwood.com>
To: Winnie the Pooh <im:pooh@100akerwood.com>
To: <im:tigger@100akerwood.com>
To: <im:tigger@100akerwood.com>
Specifies a non-primary recipient ("courtesy copy") for a message.
指定邮件的非主要收件人（“礼节副本”）。
Header name: cc
标题名称：cc
Namespace URI:
<urn:ietf:params:cpim-headers:>
Namespace URI:
<urn:ietf:params:cpim-headers:>
Syntax: (see also section 3.6)
语法：（另见第3.6节）
Cc-header = "cc" ": " [ Formal-name ] "<" URI ">"
; "cc" is case-sensitive
Cc-header = "cc" ": " [ Formal-name ] "<" URI ">"
; "cc" is case-sensitive
Description: Indicates a courtesy copy recipient of a message.
描述：表示邮件的礼节性副本收件人。
If present, the 'Formal-name' identifies the person or "real world" name for the recipient.
如果存在，“正式名称”标识收件人的个人或“真实世界”名称。
The URI indicates an address for the recipient.
URI表示收件人的地址。
Multiple courtesy copy recipients may be indicated by including multiple 'cc' headers.
可以通过包含多个“抄送”标题来指示多个礼节性副本收件人。
Examples:
示例：
cc: Winnie the Pooh <im:pooh@100akerwood.com>
cc: Winnie the Pooh <im:pooh@100akerwood.com>
cc: <im:tigger@100akerwood.com>
cc: <im:tigger@100akerwood.com>
Specifies the date and time a message was sent.
指定发送消息的日期和时间。
Header name: DateTime
标题名称：日期时间
Namespace URI:
<urn:ietf:params:cpim-headers:>
Namespace URI:
<urn:ietf:params:cpim-headers:>
Syntax: (see also section 3.6)
语法：（另见第3.6节）
DateTime-header = "DateTime" ": " date-time
; "DateTime" is case-sensitive
DateTime-header = "DateTime" ": " date-time
; "DateTime" is case-sensitive
(where the syntax of 'date-time' is a profile of ISO8601 [24] defined in "Date and Time on the Internet" [11])
（其中“日期-时间”的语法是“互联网上的日期和时间”[11]中定义的ISO8601[24]的概要文件）
Description: The 'DateTime' header supplies the date and time at which the sender sent the message.
说明：“DateTime”标题提供发件人发送邮件的日期和时间。
One purpose of the this header is to provide for protection against a replay attack, by allowing the recipient to know when the message was intended to be sent. The value of the date header is the senders's current time when the message was transmitted, using ISO 8601 [24] date and time format as profiled in "Date and Time on the Internet: Timestamps" [11].
此标头的一个目的是提供防止重播攻击的保护，允许收件人知道消息的发送时间。日期头的值是发送人发送消息时的当前时间，使用“Internet上的日期和时间：时间戳”[11]中描述的ISO 8601[24]日期和时间格式。
Example:
例子：
DateTime: 2001-02-01T12:16:49-05:00
DateTime: 2001-02-01T12:16:49-05:00
Contains a description of the topic of the message.
包含消息主题的说明。
Header name: Subject
标题名称：主题
Namespace URI:
<urn:ietf:params:cpim-headers:>
Namespace URI:
<urn:ietf:params:cpim-headers:>
Syntax: (see also section 3.6)
语法：（另见第3.6节）
Subject-header = "Subject" ":" [ ";" Lang-param ] SP *HEADERCHAR
; "Subject" is case-sensitive
Subject-header = "Subject" ":" [ ";" Lang-param ] SP *HEADERCHAR
; "Subject" is case-sensitive
Description: The 'Subject' header supplies the sender's description of the topic or content of the message.
描述：“主题”标题提供发件人对邮件主题或内容的描述。
The sending agent should specify the language parameter if it has any reasonable knowledge of the language used by the sender to indicate the message subject.
如果发送代理对发送方用于指示邮件主题的语言有任何合理的了解，则应指定语言参数。
Example:
例子：
Subject:;lang=en Eeyore's feeling very depressed today
Subject:;lang=en Eeyore's feeling very depressed today
Declare a local namespace prefix.
声明本地命名空间前缀。
Header name: NS
标题名称：NS
Namespace URI:
<urn:ietf:params:cpim-headers:>
Namespace URI:
<urn:ietf:params:cpim-headers:>
Syntax: (see also section 3.6)
语法：（另见第3.6节）
NS-header = "NS" ": " [ Name-prefix ] "<" URI ">"
; "NS" is case-sensitive
NS-header = "NS" ": " [ Name-prefix ] "<" URI ">"
; "NS" is case-sensitive
Description: Declares a namespace prefix that may be used in subsequent header names. See section 3.4 for more details.
描述：声明可在后续标头名称中使用的命名空间前缀。详见第3.4节。
Example:
例子：
NS: MyAlias <mid:MessageFeatures@id.foo.com>
MyAlias.MyHeader: private-extension-data
NS: MyAlias <mid:MessageFeatures@id.foo.com>
MyAlias.MyHeader: private-extension-data
Specify a header or feature that must be implemented by the receiver for correct message processing.
指定接收者必须实现的标头或功能，以便正确处理消息。
Header name: Require
标题名称：Require
Namespace URI:
<urn:ietf:params:cpim-headers:>
Namespace URI:
<urn:ietf:params:cpim-headers:>
Syntax: (see also section 3.6)
语法：（另见第3.6节）
Require-header = "Require" ": " Header-name *( "," Header-name )
; "Require" is case-sensitive
Require-header = "Require" ": " Header-name *( "," Header-name )
; "Require" is case-sensitive
Description: Indicates a header or feature that must be implemented or understood by the receiver for correct message processing. See section 3.5 for more details.
描述：表示接收方必须实现或理解的标题或功能，以便正确处理消息。详见第3.5节。
Note that the required header or feature does not have to be used in the message, but for brevity it is recommended that an implementation does not issue the 'Required' header for unused features.
请注意，消息中不必使用必需的标头或功能，但为简洁起见，建议实现不为未使用的功能发出“必需”标头。
Example:
例子：
Require: MyAlias.VitalHeader
要求：MyAlias.VitalHeader
The examples in the following sections use the per-line tags below to indicate different parts of the overall message format:
以下各节中的示例使用下面的每行标记来指示整个消息格式的不同部分：
m: MIME headers for the overall message s: a blank separator line h: message headers e: encapsulated MIME object containing the message content x: MIME security multipart message wrapper
m:整个消息的MIME头s:空白分隔行h:消息头e:包含消息内容的封装MIME对象x:MIME安全多部分消息包装器
The following examples also assume <urn:ietf:params:cpim-headers:> is the implied default namespace for the application.
下面的示例还假设<urn:ietf:params:cpim headers:>是应用程序的隐含默认名称空间。
The following example shows a Message/CPIM message:
以下示例显示了一条消息/CPIM消息：
m: Content-type: Message/CPIM
s:
h: From: MR SANDERS <im:piglet@100akerwood.com>
h: To: Depressed Donkey <im:eeyore@100akerwood.com>
h: DateTime: 2000-12-13T13:40:00-08:00
h: Subject: the weather will be fine today
h: Subject:;lang=fr beau temps prevu pour aujourd'hui
h: NS: MyFeatures <mid:MessageFeatures@id.foo.com>
h: Require: MyFeatures.VitalMessageOption
h: MyFeatures.VitalMessageOption: Confirmation-requested
h: MyFeatures.WackyMessageOption: Use-silly-font
s:
e: Content-type: text/xml; charset=utf-8
e: Content-ID: <1234567890@foo.com>
e:
e: <body>
e: Here is the text of my message.
e: </body>
m: Content-type: Message/CPIM
s:
h: From: MR SANDERS <im:piglet@100akerwood.com>
h: To: Depressed Donkey <im:eeyore@100akerwood.com>
h: DateTime: 2000-12-13T13:40:00-08:00
h: Subject: the weather will be fine today
h: Subject:;lang=fr beau temps prevu pour aujourd'hui
h: NS: MyFeatures <mid:MessageFeatures@id.foo.com>
h: Require: MyFeatures.VitalMessageOption
h: MyFeatures.VitalMessageOption: Confirmation-requested
h: MyFeatures.WackyMessageOption: Use-silly-font
s:
e: Content-type: text/xml; charset=utf-8
e: Content-ID: <1234567890@foo.com>
e:
e: <body>
e: Here is the text of my message.
e: </body>
In order to secure a Message/CPIM, an application or implementation may use RFC 1847 [14], and some appropriate security protocols (e.g., S/MIME [19] or openPGP [17]), and cryptographic scheme.
为了保护消息/CPIM，应用程序或实现可以使用RFC 1847[14]和一些适当的安全协议（例如，S/MIME[19]或openPGP[17]）以及加密方案。
Using S/MIME [19] and pkcs7, the above message would look like this:
使用S/MIME[19]和pkcs7，上述消息如下所示：
x: Content-Type: multipart/signed; boundary=next;
micalg=sha1;
protocol=application/pkcs7-signature
x:
x: --next
m: Content-Type: Message/CPIM
s:
h: From: MR SANDERS <im:piglet@100akerwood.com>
h: To: Dopey Donkey <im:eeyore@100akerwood.com>
h: DateTime: 2000-12-13T13:40:00-08:00
h: Subject: the weather will be fine today
h: Subject:;lang=fr beau temps prevu pour aujourd'hui
h: NS: MyFeatures <mid:MessageFeatures@id.foo.com>
h: Require: MyFeatures.VitalMessageOption
h: MyFeatures.VitalMessageOption: Confirmation-requested
h: MyFeatures.WackyMessageOption: Use-silly-font
s:
e: Content-type: text/xml; charset=utf-8
e: Content-ID: <1234567890@foo.com>
e:
e: <body>
e: Here is the text of my message.
e: </body>
x: --next
x: Content-Type: application/pkcs7-signature
x:
x: (signature stuff)
:
x: --next--
x: Content-Type: multipart/signed; boundary=next;
micalg=sha1;
protocol=application/pkcs7-signature
x:
x: --next
m: Content-Type: Message/CPIM
s:
h: From: MR SANDERS <im:piglet@100akerwood.com>
h: To: Dopey Donkey <im:eeyore@100akerwood.com>
h: DateTime: 2000-12-13T13:40:00-08:00
h: Subject: the weather will be fine today
h: Subject:;lang=fr beau temps prevu pour aujourd'hui
h: NS: MyFeatures <mid:MessageFeatures@id.foo.com>
h: Require: MyFeatures.VitalMessageOption
h: MyFeatures.VitalMessageOption: Confirmation-requested
h: MyFeatures.WackyMessageOption: Use-silly-font
s:
e: Content-type: text/xml; charset=utf-8
e: Content-ID: <1234567890@foo.com>
e:
e: <body>
e: Here is the text of my message.
e: </body>
x: --next
x: Content-Type: application/pkcs7-signature
x:
x: (signature stuff)
:
x: --next--
As defined, the 'Message/CPIM' content type uses a default namespace URI 'urn:ietf:params-cpim-headers:', and does not define any other implicit namespace prefixes. Applications that have different requirements should define and register a different MIME media type, specify the required default namespace URI and define any implied namespace prefixes as part of the media type specification.
根据定义，“Message/CPIM”内容类型使用默认命名空间URI“urn:ietf:params CPIM headers:”，并且不定义任何其他隐式命名空间前缀。具有不同要求的应用程序应定义并注册不同的MIME媒体类型，指定所需的默认命名空间URI，并将任何隐含的命名空间前缀定义为媒体类型规范的一部分。
Applications using this specification must also specify:
使用本规范的应用程序还必须指定：
o all headers that must be recognized by implementations of the application
o 应用程序实现必须识别的所有标头
o any headers that must be present in all messages created by that application.
o 由该应用程序创建的所有消息中必须存在的任何标头。
o any headers that may appear more than once in a message, and how they are to be interpreted (e.g., how to interpret multiple 'Subject:' headers with different language parameter values).
o 消息中可能出现多次的任何标题，以及如何解释这些标题（例如，如何解释具有不同语言参数值的多个“主题：”标题）。
o Security mechanisms and crytography schemes to be used with the application, including any mandatory-to-implement security provisions.
o 与应用程序一起使用的安全机制和加密方案，包括实施安全规定的任何强制性措施。
The goal of providing a definitive message format to which security mechanisms can be applied places some constraints on the design of applications that use this message format:
提供可应用安全机制的最终消息格式的目标对使用此消息格式的应用程序的设计提出了一些限制：
o Within a network of message transfer agents, an intermediate gateway MUST NOT change the Message/CPIM content in any way. This implies that headers cannot be changed or reordered, transfer encoding cannot be changed, languages cannot be changed, etc.
o 在消息传输代理网络中，中间网关不得以任何方式更改消息/CPIM内容。这意味着头不能更改或重新排序，传输编码不能更改，语言不能更改，等等。
o Because Message/CPIM messages are immutable, any transfer agent that wants to modify the message should create a new Message/CPIM message with the modified header and with the original message as its content. (This approach is similar to real-world bill-of-lading handling, where each person in the chain attaches a new sheet to the message. Then anyone can validate the original message and see what has changed and who changed it by following the trail of amendments. Another metaphor is including the old message in a new envelope.)
o 由于Message/CPIM消息是不可变的，因此任何想要修改消息的传输代理都应该创建一个新的消息/CPIM消息，其中包含修改后的标头和原始消息作为其内容。（这种方法类似于现实世界中的提单处理，即链中的每个人都在邮件上附加一张新的表单。然后，任何人都可以验证原始邮件，并通过跟踪修改来查看更改的内容和更改者。另一个比喻是将旧邮件包含在新信封中。）
In chosing security mechanisms for an applications, the following IAB survey documents may be helpful:
在为应用程序选择安全机制时，以下IAB调查文件可能会有所帮助：
o Security Mechanisms for the Internet [28]
o 互联网安全机制[28]
o A Survey of Authentication Mechanisms [29].
o 认证机制综述[29]。
This memo calls for two new IANA registrations:
此备忘录要求两个新的IANA注册：
o A new MIME content-type value, Message/CPIM, per RFC 2048 [3]. The registration template can be found in section 7.1 below.
o 根据RFC 2048[3]，新的MIME内容类型值Message/CPIM。注册模板见下文第7.1节。
o A new IANA URN sub-namespace, urn:ietf:params:cpim-headers:, per RFC 3553 [12]. The registration template can be found in section 7.2 below.
o 根据RFC 3553[12]，新的IANA URN子命名空间URN:ietf:params:cpim headers:。注册模板见下文第7.2节。
To: ietf-types@iana.org
致：ietf-types@iana.org
Subject: Registration of MIME media type Message/CPIM
主题：注册MIME媒体类型消息/CPIM
MIME media type name: message
MIME媒体类型名称：消息
MIME subtype name: CPIM
MIME子类型名称：CPIM
Required parameters: (None)
所需参数：（无）
Optional parameters: (None)
可选参数：（无）
Encoding considerations: Intended to be used in 8-bit clean environments, with non-transformative encoding (8-bit or binary, according to the content contained within the message; the CPIM message headers can be handled in an 8-bit text environment).
编码注意事项：用于8位清洁环境，采用非转换编码（8位或二进制，根据消息中包含的内容；CPIM消息头可在8位文本环境中处理）。
This content type could be used with a 7-bit transfer environment if appropriate transfer encoding is used. NOTE that for this purpose, enclosed MIME content MUST BE treated as opaque data and encoded accordingly. Any encoding must be reversed before any enclosed MIME content can be accessed.
如果使用适当的传输编码，此内容类型可以与7位传输环境一起使用。请注意，为此目的，必须将封闭的MIME内容视为不透明数据并进行相应编码。在访问任何封闭的MIME内容之前，必须反转任何编码。
Security considerations: The content may contain signed data, so any transfer encoding MUST BE exactly reversed before the content is processed.
安全注意事项：内容可能包含签名数据，因此在处理内容之前，必须完全反转任何传输编码。
See also the security considerations for email messages (RFC 2822 [9]).
另请参见电子邮件的安全注意事项（RFC 2822[9]）。
Interoperability considerations: This content format is intended to be used to exchange possibly-secured messages between different instant messaging protocols. Very strict adherence to the message format (including whitespace usage) may be needed to achieve interoperability.
互操作性注意事项：此内容格式旨在用于在不同即时消息协议之间交换可能安全的消息。为了实现互操作性，可能需要非常严格地遵守消息格式（包括空格使用）。
Published specification: RFC 3862
已发布规范：RFC 3862
Applications which use this media type: Instant messaging
使用此媒体类型的应用程序：即时消息
Additional information: The default namespace URI associated with this content-type is 'urn:ietf:params:cpim-headers:'. (See RFC 3862 for further details.)
其他信息：与此内容类型关联的默认命名空间URI为“urn:ietf:params:cpim headers:”。（详见RFC 3862。）
See also the Common Profile for Instant Messaging (CPIM) [26].
另请参见即时消息（CPIM）的通用配置文件[26]。
Person & email address to contact for further information:
G. Klyne, <GK-IETF@ninebynine.org>
Person & email address to contact for further information:
G. Klyne, <GK-IETF@ninebynine.org>
Intended usage: LIMITED USE
预期用途：有限用途
Author/Change controller: IETF
作者/变更控制员：IETF
Registry name: cpim-headers
注册表名：cpim头
Specification: RFC 3862. Additional values may be defined by standards track RFCs that update or obsolete RFC 3862.
规格：RFC3862。其他值可由更新或废弃RFC 3862的标准跟踪RFC定义。
Repository:
http://www.iana.org/assignments/cpim-headers
Repository:
http://www.iana.org/assignments/cpim-headers
Index value: The index value is a CPIM message header name, which may consist of a sequence from a restricted set of US-ASCII characters, as defined above.
索引值：索引值是一个CPIM消息头名称，它可能由一组受限制的US-ASCII字符组成，如上所述。
URN Formation: The URI for a header is formed from its name by:
URN形成：标头的URI由其名称通过以下方式形成：
a) replacing any non-URN characters (as defined by RFC 2141 [5]) with the corresponding '%hh' escape sequence (per RFC 2396 [8]); and
a) 将任何非URN字符（由RFC 2141[5]定义）替换为相应的“%hh”转义序列（根据RFC 2396[8]）；和
b) prepending the resulting string with 'urn:ietf:params:cpim-headers:'.
b) 使用“urn:ietf:params:cpim头：”作为结果字符串的前缀。
Thus, the URI corresponding to the CPIM message header 'From:' would be 'urn:ietf:params:cpim-headers:From'. The URI corresponding to the (putative) CPIM message header 'Top&Tail' would be 'urn:ietf:params:cpim-headers:Top%26Tail'.
因此，与CPIM消息头“From:”对应的URI将是“urn:ietf:params:CPIM headers:From”。与（假定的）CPIM消息头“Top&Tail”对应的URI将是“urn:ietf:params:CPIM头：Top%26Tail”。
Message headers use UTF-8 character encoding throughout; hence, they can convey the full UCS-4 (Unicode [30], ISO/IEC 10646 [25]) character repertoire.
消息头始终使用UTF-8字符编码；因此，它们可以传递完整的UCS-4（Unicode[30]、ISO/IEC 10646[25]）字符集。
Language tagging is provided for message headers using the "Lang" parameter (section 3.3).
使用“Lang”参数为消息头提供语言标记（第3.3节）。
Message content is any MIME-encapsulated content, and normal MIME content internationalization considerations apply.
消息内容是任何MIME封装的内容，一般的MIME内容国际化注意事项适用。
The Message/CPIM format is designed with security in mind. In particular it is designed to be used with MIME security multiparts for signatures and encryption. To this end, Message/CPIM messages must be considered immutable once created.
消息/CPIM格式的设计考虑到了安全性。特别是，它设计用于MIME安全多部分签名和加密。为此，消息/CPIM消息在创建后必须视为不可变。
Because Message/CPIM messages are binary messages (due to UTF-8 encoding), if they are transmitted across non-8-bit-clean transports then the transfer agent must tunnel the entire message. Changing the message data encoding is not an option. This implies that the Message/CPIM must be encapsulated by the message transfer system and unencapsulated at the receiving end of the tunnel.
由于消息/CPIM消息是二进制消息（由于UTF-8编码），因此如果它们通过非8位干净传输进行传输，则传输代理必须对整个消息进行隧道传输。更改消息数据编码不是一个选项。这意味着消息/CPIM必须由消息传输系统封装，并在隧道的接收端取消封装。
The resulting message must not have data loss due to the encoding and unencoding of the message. For example, an application may choose to apply the MIME base64 content-transfer-encoding to the Message/CPIM object to meet this requirement.
生成的消息不得因消息的编码和取消编码而丢失数据。例如，应用程序可以选择将MIME base64内容传输编码应用于消息/CPIM对象以满足此要求。
The authors thank the following for their helpful comments: Harald Alvestrand, Walter Houser, Leslie Daigle, Mark Day, Brian Raymor.
作者感谢以下几位作者的有益评论：哈拉尔·阿尔韦斯特朗、沃尔特·豪泽、莱斯利·戴格尔、马克·戴、布赖恩·雷莫尔。
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[1] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[2] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[3] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[3] Freed，N.，Klensin，J.，和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP 13，RFC 2048，1996年11月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[5] 护城河，R.，“瓮语法”，RFC 21411997年5月。
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[6] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[7] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[7] Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[8] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[10] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[10] Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[11] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[11] Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 33392002年7月。
[12] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, June 2003.
[12] Mealling，M.，Masinter，L.，Hardie，T.，和G.Klyne，“注册协议参数的IETF URN子名称空间”，BCP 73，RFC 35532003年6月。
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[13] Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[14] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[14] Galvin，J.，Murphy，S.，Crocker，S.，和N.Freed，“MIME的安全多部分：多部分/签名和多部分/加密”，RFC 1847，1995年10月。
[15] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Crispin, M., and P. Svanberg, "The Report of the IAB Character Set Workshop held 29 February - 1 March, 1996", RFC 2130, April 1997.
[15] Weider，C.，Preston，C.，Simonsen，K.，Alvestrand，H.，Atkinson，R.，Crispin，M.，和P.Svanberg，“1996年2月29日至3月1日举行的IAB字符集研讨会的报告”，RFC 21301997年4月。
[16] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[16] Freed，N.和K.Moore，“MIME参数值和编码字扩展：字符集、语言和连续体”，RFC 22311997年11月。
[17] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[17] Callas，J.，Donnerhacke，L.，Finney，H.，和R.Thayer，“OpenPGP消息格式”，RFC2440，1998年11月。
[18] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[18] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[19] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[19] Ramsdell，B.，编辑，“S/MIME版本3消息规范”，RFC 2633，1999年6月。
[20] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[20] Day，M.，Aggarwal，S.，Mohr，G.，和J.Vincent，“即时消息传递/存在协议要求”，RFC 2779，2000年2月。
[21] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[21] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[22] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C Recommendation xml, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[22] Bray，T.，Paoli，J.，Sperberg McQueen，C.，和E.Maler，“可扩展标记语言（XML）1.0（第二版）”，W3C推荐XML，2000年10月<http://www.w3.org/TR/2000/REC-xml-20001006>.
[23] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C Recommendation xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>.
[23] Bray，T.，Hollander，D.，和A.Layman，“XML中的名称空间”，W3C建议XML名称，1999年1月<http://www.w3.org/TR/REC-xml-names>.
[24] International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, June 1988.
[24] 国际标准化组织，“数据元和交换格式-信息交换-日期和时间的表示”，ISO标准8601，1988年6月。
[25] International Organization for Standardization, "Information Technology - Universal Multiple-octet coded Character Set (UCS) - Part 1: Architecture and Basic Multilingual Plane", ISO Standard 10646-1, May 1993.
[25] 国际标准化组织，“信息技术-通用多八位编码字符集（UCS）-第1部分：体系结构和基本多语言平面”，ISO标准10646-11993年5月。
[26] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[26] 彼得森，J.，“即时通讯（CPIM）的通用配置文件”，RFC3860，2004年8月。
[27] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[27] 彼得森，J.，“在场的共同概况（CPP）”，RFC 3859，2004年8月。
[28] Bellovin, S., Kaufman, C., and J. Schiller, "Security Mechanisms for the Internet", RFC 3631, December 2003.
[28] Bellovin，S.，Kaufman，C.，和J.Schiller，“互联网的安全机制”，RFC 36312003年12月。
[29] Rescorla, E., "A Survey of Authentication Mechanisms", Work in Progress, March 2004.
[29] Rescorla，E.，“认证机制的调查”，正在进行的工作，2004年3月。
[30] The Unicode Consortium, "The Unicode Standard, Version 4.0", Addison-Wesley, Boston, MA. ISBN 0-321-18578-1, April 2003, <http://www.unicode.org/unicode/standard/versions/ enumeratedversions.html#Unicode_4_0_0>.
[30] Unicode联盟，“Unicode标准，版本4.0”，马萨诸塞州波士顿市Addison Wesley。ISBN 0-321-18578-11903年4月<http://www.unicode.org/unicode/standard/versions/ enumeratedversions.html#Unicode_4_0_0>。
Graham Klyne Nine by Nine
格雷厄姆·克莱恩九乘九
EMail: GK-IETF@ninebynine.org
URI: http://www.ninebynine.net/
EMail: GK-IETF@ninebynine.org
URI: http://www.ninebynine.net/
Derek Atkins IHTFP Consulting 6 Farragut Ave Somerville, MA 02144 USA
德里克·阿特金斯IHTFP咨询公司美国马萨诸塞州萨默维尔法拉古特大道6号，邮编：02144
Phone: +1 617 623 3745
EMail: derek@ihtfp.com, warlord@alum.mit.edu
Phone: +1 617 623 3745
EMail: derek@ihtfp.com, warlord@alum.mit.edu
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。