[要約] RFC 3862は、Common Presence and Instant Messaging（CPIM）のメッセージフォーマットに関する仕様です。このRFCの目的は、CPIMメッセージの標準化と相互運用性の向上です。
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）The Internet Society（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.
このメモは、インスタントメッセージング（CPIM）仕様の共通プロファイルに準拠するプロトコルのメッセージ形式であるMIMEコンテンツタイプ 'message/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].
このメモは、インスタントメッセージング（CPIM）仕様の共通プロファイルに準拠するプロトコルのメッセージ形式であるMIMEコンテンツタイプ 'message/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では、インスタントメッセージがMIMEペイロードを運ぶことができます[1] [2];したがって、MIMEのある程度のサポートは、CPIM準拠のプロトコルの一般的な要素になります。したがって、プロトコルの実装には既にこれを解析するためのコードを含む必要があるため、一般的なメッセージ形式ではRFC2822/MIMEのような構文[9]を使用する必要があると合理的と思われます。
Unfortunately, using pure RFC2822/MIME can be problematic: 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.
残念ながら、純粋なRFC2822/MIMEの使用には問題があります。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-Headersは標準化されていない可能性があるため問題があります。これは、ヘッダーが実験的に開始され、その後広範囲に適用される状況につながり、標準化できない一般的な使用法につながります。）
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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オブジェクトは2部構成のエンティティで、最初の部分にはメッセージメタデータが含まれ、2番目の部分はメッセージコンテンツです。2つの部分は、囲まれたマイムヘッダーフィールドから、また空白の行で互いに分離されています。メッセージメタデータヘッダー情報は、メッセージ内で携帯できる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：メッセージ/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：メッセージ全体のMIMEヘッダーS：A Blank Separator Line 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 1行に1つのヘッダーのみ。複数のヘッダーを単一の行に含めないでください。
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 同じキー（ヘッダー名）を使用した複数のヘッダーが許可されています。（特定のヘッダーセマンティクスは、特定のヘッダーの1つの発生のみを決定する場合があります。）
o Header names MUST match exactly (i.e., "From:" and "from:" are different headers).
o ヘッダー名は正確に一致する必要があります（つまり、 "from：" and "："は異なるヘッダーです）。
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
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 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.)
エスケープメカニズムは、UTF-8コーディングのオクテットではなく、UCS-2文字に適用されることに注意してください。エスケープシーケンスや文字コーディングに関係なく、UTF-8コーディングからのマッピングは実行されます。（Header構文は、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)
The hexadecimal number 'xxxx' is the UCS code-point value of the escaped character.
16進数「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)
\\ 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ラインフィード（u 000a）\ rキャリッジリターン（u 000d）\ r
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 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 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.
さらに、上記のエスケープシーケンスのその他の発生は、対応するユニコード文字の発生として認識され、扱う必要があります。
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フォーマットルール[1] [2]に従うMIMEカプセル化メッセージコンテンツです。
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
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）で区切られた名前と値の2つの部分が含まれています。シーケンスCR、LF（13,10）によって終了します。
Headers use UTF-8 character encoding throughout, per RFC 3629 [13].
ヘッダーは、RFC 3629ごとに、UTF-8文字エンコードを使用します[13]。
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
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]の両方の許可された構文と互換性のある構文に従うことを許可することです（SIP [21]などのHTTP由来プロトコルを含む）。
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 = tag」を含めることにより、その値の言語を示すことができます。ここで、「タグ」はRFC 3066ごとにトークンを識別する言語です[10]。
Example:
例：
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 [22]がXMLネームスペース[23]に提供するものに基づいています。すべてのヘッダーは「名前空間」に関連付けられており、グローバルにユニークな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：header-value
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は完全な絶対尿でなければなりません。、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
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.
これは、名前空間識別子に関連付けられた名前空間プレフィックス「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：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:
2つの異なるメッセージは、名前空間プレフィックス「xxx」と「yyy」が同じ名前空間URIに関連付けられている場合、まったく同じ効果がある場合があります。したがって、以下にはまったく同じ意味があります。
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
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
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 [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 = header-name "：" *（ ";" parameter）sp header-value 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
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
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文字、またはヘッダーチャー= ucs-no-ctl / escape
; 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
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
To interpret the syntax as defining UTF-8 coded octet sequences, use the following productions:
構文をUTF-8コード化されたOctetシーケンスを定義するものとして解釈するには、次のプロダクションを使用します。
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:
続くヘッダー定義は、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].
ここで定義されているすべてのヘッダーは、名前空間uri <urn：ietf：params：cpim-headers：>に関連付けられています。これは[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
ヘッダー名：from
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
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: <im:tigger@100akerwood.com>
Specifies an intended recipient of a message.
メッセージの意図された受信者を指定します。
Header name: To
ヘッダー名：to
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
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: <im:tigger@100akerwood.com>
Specifies a non-primary recipient ("courtesy copy") for a message.
メッセージに対して非プリマリー受信者（「Courtesyコピー」）を指定します。
Header name: cc
ヘッダー名：CC
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
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: <im:tigger@100akerwood.com>
Specifies the date and time a message was sent.
メッセージが送信された日付と時刻を指定します。
Header name: DateTime
ヘッダー名：DateTime
Namespace URI:
<urn:ietf:params:cpim-headers:>
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.
説明：「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].
このヘッダーの目的の1つは、受信者がメッセージの送信を意図した時期を知ることができるようにすることにより、リプレイ攻撃に対する保護を提供することです。日付ヘッダーの値は、「インターネット上の日時：タイムスタンプ」[11]でプロファイルされているISO 8601 [24]の日付と時刻形式を使用して、メッセージが送信されたときの送信者の現在の時刻です。
Example:
例：
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:>
Syntax: (see also section 3.6)
構文：（セクション3.6も参照）
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
Declare a local namespace prefix.
ローカルネームスペースのプレフィックスを宣言します。
Header name: NS
ヘッダー名：ns
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
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
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:>
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：メッセージ全体のMIMEヘッダーS：A Blank Separator Line 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>
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.
定義されているように、「メッセージ/CPIM」コンテンツタイプは、デフォルトの名前空間uri 'urnを使用します。異なる要件を持つアプリケーションは、異なる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 メッセージ/CPIMメッセージは不可能であるため、メッセージを変更したい転送エージェントは、変更されたヘッダーと元のメッセージをコンテンツとして新しいメッセージ/CPIMメッセージを作成する必要があります。（このアプローチは、現実世界のレーディング請求書に似ています。チェーン内の各人がメッセージに新しいシートを添付します。その後、誰でも元のメッセージを検証して、トレイルをたどることで誰が変更したかを確認できます。修正の。別の比phorは、古いメッセージを新しい封筒に含めることです。）
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:
このメモでは、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.
o RFC 2048あたりの新しいMIMEコンテンツタイプの値、メッセージ/CPIM [3]。登録テンプレートは、以下のセクション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-headers：、RFC 3553 [12]。登録テンプレートは、以下のセクション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.
相互運用性の考慮事項：このコンテンツ形式は、異なるインスタントメッセージングプロトコル間で担保されている可能性のあるメッセージを交換するために使用することを目的としています。相互運用性を実現するには、メッセージ形式（Whitespaceの使用を含む）を非常に厳密に順守する必要がある場合があります。
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>
Intended usage: LIMITED USE
意図された使用法：使用されています
Author/Change controller: IETF
著者/変更コントローラー：IETF
Registry name: cpim-headers
レジストリ名：cpim-headers
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
リポジトリ：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) 非回行文字（RFC 2141 [5]で定義されている）を対応する「％HH」エスケープシーケンス（RFC 2396 [8]ごと）に置き換える;そして
b) prepending the resulting string with 'urn:ietf:params:cpim-headers:'.
b) 結果の文字列を「urn：ietf：params：cpim-headers：」で準備します。
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 'from'は 'urn：ietf：params：cpim-headers：from'。（推定）CPIMメッセージヘッダー「Top＆Tail」に対応するURIは、「urn：ietf：params：cpim-headers：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）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年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）パート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] Freed、N.、Klensin、J。、およびJ. Postel、「多目的インターネットメール拡張機能（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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[5] Moats、R。、「urn構文」、RFC 2141、1997年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）：Generic Syntax」、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。and C. Newman、「インターネット上の日時：タイムスタンプ」、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.、Hardie、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] Galvin、J.、Murphy、S.、Crocker、S.、およびN. Freed、「Mimeのセキュリティマルチパート：MultiPart/Signed and MultiPart/暗号化」、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 "、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] Freed、N。およびK. Moore、「MIMEパラメーター値とエンコードされた単語拡張機能：文字セット、言語、および継続」、RFC 2231、1997年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メッセージ形式」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[19] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[19] Ramsdell、B.、ed。、「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：SESSION INTIATION Protocol"、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（2番目のED）」、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-Names、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 Standard 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 Standard 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.、Kaufman、C。、およびJ. Schiller、「インターネットのセキュリティメカニズム」、RFC 3631、2003年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 Consortium、「Unicode Standard、バージョン4.0」、Addison-Wesley、ボストン、マサチューセッツ州。ISBN 0-321-18578-1、2003年4月、<http://www.unicode.org/unicode/standard/versions/ enumeratedversions.html＃unicode_4_0>。
Graham Klyne Nine by Nine
Graham Klyne Nine by Nine
EMail: GK-IETF@ninebynine.org
URI: http://www.ninebynine.net/
Derek Atkins IHTFP Consulting 6 Farragut Ave Somerville, MA 02144 USA
Derek Atkins IHTFP Consulting 6 Farragut Ave Somerville、MA 02144 USA
Phone: +1 617 623 3745
EMail: derek@ihtfp.com, warlord@alum.mit.edu
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。