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
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コンテンツタイプ「メッセージ/ 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
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コンテンツタイプ「メッセージ/ 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.
RFC 2779 [2] [1]インスタントメッセージは、MIMEペイロードを運ぶことができることを必要とします。このようにMIMEのサポートのいくつかのレベルは、任意のCPIM準拠プロトコルの共通要素であろう。したがって、プロトコルの実装が既にこれを解析するためのコードを含んでいなければならないような共通のメッセージフォーマットは、[9] RFC2822 / MIMEのような構文を使用する必要があることを合理的と思われます。
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-ヘッダは問題であり、これはヘッダは、実験として始まるが、その後に標準化することができない一般的な使用をもたらす、広範囲の用途を見出す状況につながります。）
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
8ビットクリーンメッセージ転送プロトコルのO仮定
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 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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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メッセージフォーマットが一緒にmessage-およびコンテンツ関連メタデータと共に、任意の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オブジェクトは最初の部分は、メッセージメタデータを含み、第2の部分はメッセージの内容である二部エンティティです。二つの部分は空白行によって互いからも封入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：コンテンツタイプ：メッセージ/ CPIM S：H：（メッセージ・メタデータ・ヘッダ）S：E：（カプセル化されたMIMEメッセージボディ）
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：空白区切り線h：MIMEセキュリティマルチパートメッセージラッパー：メッセージコンテンツXを含むカプセル化されたMIMEオブジェクト：メッセージが電子をヘッダーメッセージ全体のための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.
文字列CR O、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@100akerwood.com>から<イム：piglet@100akerwood.com>日時：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.)
この機構は、U + 001F又はU + 007Fの範囲U + 0000にUnicodeコードポイントを有する、ヘッダ内の制御文字を符号化するために使用されなければなりません。 （完全に新しい何かを発明するのではなく、エスケープ・メカニズムは、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.)
エスケープメカニズムではなく、そのUTF-8コーディングのオクテットに、UCS-2文字に適用されることに注意してください。 /からUTF-8コード化へのマッピングは、エスケープシーケンスまたは文字の符号化に関係なく行われます。 （CRやLF以外の文字を制御するために、対応するオクテットが出力に現れないようにヘッダのシンタックスが定義されます。）
An arbitrary UCS-2 character is escaped using the form:
任意のUCS-2文字は、フォームを使用してエスケープされます。
\uxxxx
\ uXXXXという
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)
\であるU + 005C（バックスラッシュ）UはU + 0075（小文字U）でxxxxは正確に4桁の16進数（0-9、AFまたはAF）の配列であるか、（U + 0030-U + 0039、U + 0041 -U + 0046、または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）バックスペースのために（単一引用符、U + 0027）\ bの（U + 0008） 'の' \ "のために"（二重引用符、U + 0022）\ \トン（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を\ uXXXXというは、任意の他の制御文字を使用しなければなりません（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コンテンツヘッダは、少なくともContent-Typeヘッダを含まなければなりません。コンテンツは、任意の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の。文字セット= UTF-8 E：のContent-ID：<1234567890@foo.com> E：E：これは私のカプセル化されたテキストメッセージの内容であります
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の使用[6] RFC 2234と異なります。
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
セパレータ= "（" / "）" / "<" / ">" / "@" / "" / ";" / "：" / "\" / 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]と（例えば、SIP [21]としてHTTP由来のプロトコルを含む）HTTP [18]と互換性のある構文に従うことができるようにすることです。
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.)
ヘッダフォーマットの他の一般的な制約も従わなければなりません（1行など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 =タグ」「タグは、」RFC 3066あたりのトークンを識別する言語であるヘッダ名とコロンの後、[10]。
Example:
例：
Subject:;lang=fr Objet de message
件名:; LANG = ENメッセージ件名
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-デフォルト」として識別された言語を使用することが想定される[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名：ヘッダ値
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.
ここで、「プレフィックス」は、ヘッダ名の接頭辞、「ヘッダ名は」「プレフィックス」、及び「ヘッダ値」に関連付けられた名前空間内のヘッダ名がこのヘッダの値であるです。
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.
メッセージ/ CPIMメディアタイプの登録は、より明示的に任意の名前空間に関連付けられていない任意のヘッダーのデフォルトの名前空間を指定します。ほとんどの場合、このデフォルトの名前空間が必要とされているすべてのです。
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を使用しないことを期待するのは合理的であるように、「グローバルに一意」とは、我々はいくつかのルールセットに基づいて構成を意味します。）URIを識別子として使用すると、フル絶対URIでなければなりません、RFC 2396あたりの[8]。 （断片識別子を含む相対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 <半ば：MessageFeatures@id.foo.com> MyFeatures.WackyMessageOption：使用-愚かなフォント
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.
これは、名前空間接頭辞名前空間識別子「：MessageFeatures@id.foo.com半ばに関連付けられて」「MyFeatures」を定義します。続いて、接頭辞は、参照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：値yyy.name：値
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トラップ：セット
and
そして
NS: widget <http://id.acme.widgets/wily-headers/> widget.runner-trap: set
NS：ウィジェット<のhttp：//id.acme.widgets/wily-headers/> widget.runnerトラップ：セット
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/>ランナートラップ：セット
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: 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.
複数必要なヘッダ名は、カンマで区切られた、単一の「要求」ヘッダに記載されていることができます。
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.
注：ヘッダーは相互運用性に悪影響を及ぼす可能性：「必要」の無差別使用。他の実装がうまく相互運用できるように必要なヘッダを定義する任意の実装はまた、ヘッダの仕様を公開することが示唆されます。
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: 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あたり、ABNFを使用する[6]。この構文のほとんどは、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の使用[6] RFC 2234と異なります。
Collected syntax:
収集された構文：
Header = Header-name ":" *( ";" Parameter ) SP Header-value CRLF
ヘッダー=ヘッダー名「：」*（「;」パラメータ）SPヘッダー値CRLF
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
パラメータ=ラング-PARAM / EXT-PARAMラング-のparam = "LANG =" 言語タグEXT-PARAM = Paramの名 "=" Paramの値のParam名=名前のParam値=トークン/数/文字列
Header-value = *HEADERCHAR
ヘッダー値= * 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トークン= 1 * TOKENCHAR数= 1 * DIGITストリング= DQUOTE *（STR-チャー/エスケープ）DQUOTE STR-チャー=％x20-21 /％x23-5B /％x5D-7E / UCS-高エスケープ= "\"（ "U" 4（HEXDIG）; UCSコードポイント/ "B"、バックスペース/ "T";タブ/ "n" は、改行/ "R";戻り/ DQUOTE;二重引用符/ "'";シングル見積もり / "\" ） ;バックスラッシュ
Formal-name = 1*( Token SP ) / String URI = <defined as absolute-URI by RFC 2396> Language-tag = <defined by RFC 3066>
<RFC 2396により絶対URIとして定義>正式名= 1 *（トークンSP）/文字URI = <RFC 3066によって定義>言語タグ=
; Any UCS character except CTLs, or escape HEADERCHAR = UCS-no-CTL / Escape
; CTLを除く任意のUCS文字、またはHEADERCHAR = UCS-NO-CTL /エスケープをエスケープ
; Any US-ASCII char except ".", CTLs or SEPARATORS: NAMECHAR = %x21 / %x23-27 / %x2a-2b / %x2d / %x5e-60 / %x7c / %x7e / ALPHA / DIGIT
;除く任意のUS-ASCIIの文字、CTLをまたはセパレータ ""：NAMECHAR =％X21 /％x23-27 /％X2A-2B /％x2d /％x5e-60 /％のx7c /％のx7e / ALPHA / DIGIT
; Any UCS char except CTLs or SEPARATORS: TOKENCHAR = NAMECHAR / "." / UCS-high
; CTLをまたはセパレータを除く任意のUCSの文字：TOKENCHAR = NAMECHAR / "" / UCS-高
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>
セパレータ= "（" / "）" / "<" / ">" / "@"。 29分の28 / 3C / 3E / 40 / "" / ";" / "：" / "\" / DQUOTE。 2C / 3B / 3A / 5C / 22 / "/" / "[" / "]" / "？" / "="; 2F / 5B / 5D / 3F / 3D / "{" / "}" / SP。図7b / 7D / 20 CTL = <RFC 2234によって定義されてい - ％x0-％X1F、％x7f> CRLF = <RFC 2234によって定義されてい - CR、LF> SP = <RFC 2234によって定義される - ％X20> DIGIT = = < 'F' RFC 2234によって定義される - '0' - '9'、 'A' - - 'F'、 '> ALPHA HEXDIG = < - - '0' '9' RFC 2234によって定義> <RFC 2234によって定義される - 'A' - 'Z'、 'A' - 'Z'> DQUOTE = <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-高UCS-高=％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
x20-7e / UTF8マルチUTF8マルチ=％XC0-DF％のX80-BF /％xE0-EF％のUCS-NO-CTL = UTF8-NO-CTL UCS-高= UTF8マルチUTF8-NO-CTL =％ありません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のソフトウェアとの互換性のために含まれています。このメッセージ形式を生成するアプリケーションは、UTF-8 RFC 3629でより制限の仕様に一致する[13]を生成する必要があります。
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:
2つのカテゴリに分類され従うヘッダ定義：
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].
<：IETF：paramsは：CPIM-ヘッダー：URN>、[12]に従って定義されるここで定義されたすべてのヘッダは、名前空間URIに関連付けられています。
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の使用[6] RFC 2234と異なります。
Indicates the sender of a message.
メッセージの送信者を示します。
Header name: From
ヘッダー名：から
Namespace URI: <urn:ietf:params:cpim-headers:>
名前空間URI：<壷：IETF：のparams：CPIM-ヘッダ：>
Syntax: (see also section 3.6)
構文：（また、セクション3.6を参照してください）
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>
投稿者：くまのプーさん<イム：pooh@100akerwood.com>
From: <im:tigger@100akerwood.com>
From：<イム：tigger@100akerwood.com>
Specifies an intended recipient of a message.
メッセージの意図された受信者を指定します。
Header name: To
ヘッダー名：へ
Namespace URI: <urn:ietf:params:cpim-headers:>
名前空間URI：<壷：IETF：のparams：CPIM-ヘッダ：>
Syntax: (see also section 3.6)
構文：（また、セクション3.6を参照してください）
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：くまのプーさん<イム：pooh@100akerwood.com>
To: <im:tigger@100akerwood.com>
宛先：<イム：tigger@100akerwood.com>
Specifies a non-primary recipient ("courtesy copy") for a message.
メッセージの非プライマリ受信者（「礼儀コピー」）を指定します。
Header name: cc
ヘッダー名：CC
Namespace URI: <urn:ietf:params:cpim-headers:>
名前空間URI：<壷：IETF：のparams：CPIM-ヘッダ：>
Syntax: (see also section 3.6)
構文：（また、セクション3.6を参照してください）
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.
複数の礼儀コピーの受信者は、複数の「CC」ヘッダを含むことによって示すことができます。
Examples:
例：
cc: Winnie the Pooh <im:pooh@100akerwood.com>
CC：くまのプーさん<イム：pooh@100akerwood.com>
cc: <im:tigger@100akerwood.com>
CC：<イム：tigger@100akerwood.com>
Specifies the date and time a message was sent.
メッセージが送信された日付と時刻を指定します。
Header name: DateTime
ヘッダー名：日時
Namespace URI: <urn:ietf:params:cpim-headers:>
名前空間URI：<壷：IETF：のparams：CPIM-ヘッダ：>
Syntax: (see also section 3.6)
構文：（また、セクション3.6を参照してください）
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])
（「日時」の構文はISO8601のプロファイルである。ここで、[24]「インターネット上の日付と時刻」で定義されている[11]）
Description: The 'DateTime' header supplies the date and time at which the sender sent the message.
説明：「日時」ヘッダは、送信者がメッセージを送信した日時を供給する。
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].
このヘッダの1つの目的は、メッセージが送信されることを意図していたとき、受信者が知っているようにすることによって、リプレイ攻撃に対する保護を提供することです。日付ヘッダの値はにプロファイルとしてISO 8601 [24]日付と時刻の形式を使用して、メッセージが送信された送信者の現在時刻である「インターネット上日付と時刻：タイムスタンプ」[11]。
Example:
例：
DateTime: 2001-02-01T12:16:49-05:00
日時：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:>
名前空間URI：<壷：IETF：のparams：CPIM-ヘッダ：>
Syntax: (see also section 3.6)
構文：（また、セクション3.6を参照してください）
Subject-header = "Subject" ":" [ ";" Lang-param ] SP *HEADERCHAR ; "Subject" is case-sensitive
被験者ヘッダー=「被験者」「：」[「;」ラング-PARAM] SP * HEADERCHAR。 「対象」は、大文字と小文字が区別され
Description: The 'Subject' header supplies the sender's description of the topic or content of the message.
説明： 'Subjectのヘッダーは、メッセージのトピックやコンテンツの送信者の説明を提供します。
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
件名：; LANG = ENイーヨー今日は非常に落ち込ん
Declare a local namespace prefix.
ローカル名前空間接頭辞を宣言します。
Header name: NS
ヘッダー名：NS
Namespace URI: <urn:ietf:params:cpim-headers:>
名前空間URI：<壷：IETF：のparams：CPIM-ヘッダ：>
Syntax: (see also section 3.6)
構文：（また、セクション3.6を参照してください）
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 <半ば：MessageFeatures@id.foo.com> MyAlias.MyHeader：プライベート・拡張データ
Specify a header or feature that must be implemented by the receiver for correct message processing.
正しいメッセージ処理のために受信機によって実装されなければならないヘッダや機能を指定します。
Header name: Require
ヘッダー名：必須
Namespace URI: <urn:ietf:params:cpim-headers:>
名前空間URI：<壷：IETF：のparams：CPIM-ヘッダ：>
Syntax: (see also section 3.6)
構文：（また、セクション3.6を参照してください）
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：空白区切り線h：MIMEセキュリティマルチパートメッセージラッパー：メッセージコンテンツXを含むカプセル化されたMIMEオブジェクト：メッセージが電子をヘッダーメッセージ全体のためのMIMEヘッダ
The following examples also assume <urn:ietf:params:cpim-headers:> is the implied default namespace for the application.
<：IETF：骨壷のparams：CPIM-ヘッダー：>は、以下の例も想定したアプリケーションのための暗黙のデフォルトの名前空間です。
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：コンテンツタイプ：メッセージ/ CPIM S：H：から：MR SANDERS <IM：piglet@100akerwood.com> H：TO：落ち込んロバ<IM：eeyore@100akerwood.com> H：日時：2000-12-13T13 ：40：00-08：00時間：件名：天気の良い日になります今日時間：件名：; LANG = FRボー・タンprevu注ぐaujourd'huiさh：NS：MyFeatures <半ば：MessageFeatures@id.foo.com> H ：必要：MyFeatures.VitalMessageOptionさh：MyFeatures.VitalMessageOption：確認-要求時間：MyFeatures.WackyMessageOption：使用-愚かなフォントS：E：コンテンツタイプ：text / xmlでは、文字セット= UTF-8 E：のContent-ID：<1234567890@foo.com> E：E：<身体> E：ここに私のメッセージのテキストです。 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--
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.
、およびその他の暗黙の名前空間接頭辞を定義していない「：IETF：：のparams - CPIM-ヘッダ壷」定義されているように、「メッセージ/ CPIMのコンテンツタイプは、デフォルトの名前空間URIを使用しています。定義と異なる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.)
メッセージ/ CPIMメッセージは不変であるので、O、メッセージを変更したい任意の移動剤は、修飾されたヘッダと、そのコンテンツとして元のメッセージを新しいメッセージ/ 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].
認証メカニズムの調査[29] O。
This memo calls for two new IANA registrations:
このメモは、2件の新しい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.
[3] RFC 2048あたり、新しいMIMEコンテンツタイプ値、メッセージ/ CPIM O。登録テンプレートは、以下のセクション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新しいIANA URNサブ名前空間、URN：IETF：paramsは：CPIM-ヘッダ:, RFC 3553あたり[12]。登録テンプレートは、以下のセクション7.2に記載されています。
To: 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ビットまたはバイナリ; CPIMメッセージヘッダは、8ビットのテキスト環境で取り扱うことができる）、非変革エンコーディングと、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は「：IETF：骨壷のparams：CPIM-ヘッダ：」。 （詳細については、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>
人と詳細のために連絡する電子メールアドレス：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.
仕様：RFC 3862.追加の値が規格によって定義されてもよいがRFCにその更新または廃止されたRFC 3862を追跡します。
Repository: http://www.iana.org/assignments/cpim-headers
リポジトリ：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.
インデックス値：インデックス値が上記で定義した通り、US-ASCII文字の制限されたセットからの配列からなってもよいCPIMメッセージヘッダ名です。
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
[5]）に対応する '％HH' エスケープシーケンスと（RFC 2396ごとにRFC 2141によって定義されるA）（以外のURNの文字を置き換える[8]）。そして
b) prepending the resulting string with 'urn:ietf:params:cpim-headers:'.
B） '：IETF：paramsは：CPIM-ヘッダー：URN' と結果の文字列を付加。
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メッセージヘッダに対応するURIは '：IETF：paramsは：CPIM-ヘッダー：からURN' であろう。 '：IETF：paramsは：CPIM-ヘッダー：URNトップ％26Tail'（推定）CPIMメッセージヘッダ 'トップ＆テール' に対応するURIがあろう。
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（ユニコード[30]、ISO / IEC 10646 [25]）文字レパートリーを搬送することができます。
Language tagging is provided for message headers using the "Lang" parameter (section 3.3).
言語タグを「ラング」パラメータ（セクション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.
得られたメッセージは、メッセージの符号化及びunencodingに起因するデータの損失があってはなりません。例えば、アプリケーションは、この要件を満たすために、メッセージ/ CPIMオブジェクトにMIME BASE64のコンテンツ転送符号化を適用することを選択することができます。
The authors thank the following for their helpful comments: Harald Alvestrand, Walter Houser, Leslie Daigle, Mark Day, Brian Raymor.
ハラルドAlvestrand、ウォルター・ハウザー、レスリーDaigle氏、マーク・デイ、ブライアンRaymor：作者は彼らの役に立つコメントを次のように感謝します。
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[1]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[2]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年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]解放され、N.、Klensin、J.、およびJ.ポステル、 "多目的インターネットメール拡張（MIME）パート4：登録手順"、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[5]堀、R.、 "URN構文"、RFC 2141、1997年5月を。
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[6]クロッカー、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.、BCP 18、RFC 2277 "文字セットと言語のIETF方針"、1998年1月。
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[8]バーナーズ=リー、T.、フィールディング、R.、およびL. Masinter、 "統一資源識別子（URI）：一般的な構文"、RFC 2396、1998年8月。
[9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9]レズニック、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.ニューマン、 "インターネット上の日付と時刻：タイムスタンプ"、RFC 3339、2002年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.、ハーディー、T.、およびG. Klyne、 "登録プロトコル・パラメータのためのIETF URNサブ名前空間"、BCP 73、RFC 3553、2003年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]ガルビン、J.、マーフィー、S.、クロッカー、S.、およびN.フリード、 "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]ウイダー、C.、プレストン、C.、シモンセン、K.、Alvestrand、H.、アトキンソン、R.、クリスピン、M.、およびP. Svanberg、「ワークショップを設定IAB文字の報告は2月29日に開催 - 1996" 年3月1日、RFC 2130、1997年4月。
[16] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[16]解放され、N.とK.ムーア、 "MIMEパラメータ値およびエンコードされたWordの機能拡張：文字セット、言語、および継続の"、RFC 2231、1997年11月。
[17] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[17]カラス、J.、Donnerhacke、L.、フィニー、H.、およびR.セイヤー、 "OpenPGPのメッセージフォーマット"、RFC 2440、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.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、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日目、M.、アガルワル、S.、モール、G.、およびJ.ヴィンセント、 "インスタントメッセージング/プレゼンスプロトコル要件"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、C.、およびE. MALER、 "拡張マークアップ言語（XML）1.0（第2版）"、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]ブレイ、T.、オランダ、D.、およびA.素人、 "XMLで名前空間"、W3C勧告XML-名、1999年1月、<http://www.w3.org/TR/REC-xml-名前>。
[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-1、1993年5月。
[26] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[26]ピーターソン、J.、 "インスタントメッセージングのための共通プロファイル（CPIM）"、RFC 3860、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.、カウフマン、C.、およびJ.シラー、 "インターネットのセキュリティメカニズム"、RFC 3631、2003年12月。
[29] Rescorla, E., "A Survey of Authentication Mechanisms", Work in Progress, March 2004.
[29]レスコラ、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規格、バージョン4.0"、アディソン・ウェズリー、ボストン、MA。 ISBN 0-321-18578-1、2003年4月、<http://www.unicode.org/unicode/standard/versions/ enumeratedversions.html＃Unicode_4_0_0>。
Graham Klyne Nine by Nine
ナインにより、グラハムKlyneナイン
EMail: GK-IETF@ninebynine.org URI: http://www.ninebynine.net/
電子メール：GK-IETF@ninebynine.org URI：http://www.ninebynine.net/
Derek Atkins IHTFP Consulting 6 Farragut Ave Somerville, MA 02144 USA
デレク・アトキンスIHTFPコンサルティング6ファラガットアベニューサマービル、MA 02144 USA
Phone: +1 617 623 3745 EMail: derek@ihtfp.com, warlord@alum.mit.edu
電話：+1 617 623 3745 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。