'''Common Presence and Instant Messaging (CPIM): Message Format''' - Network Working Group - Request for Comments: 3862 - Category: Standards Track - G. Klyne - Nine by Nine - D. Atkins - IHTFP Consulting - August 2004 * 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. * Copyright Notice > Copyright (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) 仕様に適合するプロトコルのメッセージ書式である [CODE(MIME)[Message/CPIM]] MIME 内容型を定義します。 * Table of Contents > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Terminology and Conventions . . . . . . . . . . . . . . 5 2. Overall Message Structure . . . . . . . . . . . . . . . . . . 5 2.1. Message/CPIM MIME Headers . . . . . . . . . . . . . . . 6 2.2. Message Headers . . . . . . . . . . . . . . . . . . . . 6 2.3. Character Escape Mechanism . . . . . . . . . . . . . . . 8 2.3.1. Escape Mechanism Usage . . . . . . . . . . . . . 8 2.4. Message Content . . . . . . . . . . . . . . . . . . . . 9 3. Message Header Syntax . . . . . . . . . . . . . . . . . . . . 10 3.1. Header Names . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Header Value . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Language tagging . . . . . . . . . . . . . . . . . . . . 10 3.4. Namespaces for Header Name Extensibility . . . . . . . . 11 3.5. Mandatory-to-Recognize Features . . . . . . . . . . . . 13 3.6. Collected Message Header Syntax . . . . . . . . . . . . 14 4. Header Definitions . . . . . . . . . . . . . . . . . . . . . . 16 4.1. The 'From' Header . . . . . . . . . . . . . . . . . . . 16 4.2. The 'To' Header . . . . . . . . . . . . . . . . . . . . 17 4.3. The 'cc' Header . . . . . . . . . . . . . . . . . . . . 18 4.4. The 'DateTime' Header . . . . . . . . . . . . . . . . . 18 4.5. The 'Subject' Header . . . . . . . . . . . . . . . . . . 19 4.6. The 'NS' Header . . . . . . . . . . . . . . . . . . . . 20 4.7. The 'Require' Header . . . . . . . . . . . . . . . . . . 20 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. An Example Message/CPIM Message . . . . . . . . . . . . 21 5.2. An Example Esing MIME multipart/signed . . . . . . . . . 22 6. Application Design Considerations . . . . . . . . . . . . . . 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7.1. Registration for Message/CPIM Content Type . . . . . . . 24 7.2. Registration for urn:ietf:params:cpim-headers . . . . . 25 8. Internationalization Considerations . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.1. Normative References. . . . . . . . . . . . . . . . . . 26 11.2. Informative References. . . . . . . . . . . . . . . . . 27 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30 * 1. Introduction > 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) 仕様に適合するプロトコルのメッセージ書式である [CODE(MIME)[Message/CPIM]] MIME 内容型を定義します。これは CPIM に従うメッセージ・プロトコルの共通メッセージ書式です。 > 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章に挙げた問いに言及するべきであります。 ** 1.1. Motivation > 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) 仕様は、 対応している処理の数々と異なる即席メッセージ・プロトコルの間の相互ネットワーク化のために満足するべき基準を定義しています。 その意図は、種々の異なるプロトコルが [[RFC 2779]] の要件に合致するプロトコル交差メッセージ処理に対応する関門を通じて相互ネットワーク化できるようにすることであります。 > 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 即席メッセージ仕様と CPIM 在席仕様が特定の保安プロトコルを規定しています。 > 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 データ書式ではないことにも注意して下さい。 ** 1.2. Background > 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 積荷を運搬できることを要求しています。 従って何らかの水準での MIME 対応がすべての CPIM に従うプロトコルの共通要素となります。従って、 プロトコル実装は既に [[RFC 2822]]・MIME の構文を解析する符号を含んでいるはずですから、 RFC 2822・MIME に似た構文を使うことはもっともに思えます。 > Unfortunately, using pure RFC2822/MIME can be problematic: 残念ながら純粋な RFC 2822・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. 不規則な字句構造: RFC 2822・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. 国際化の弱さ: RFC 2822・MIME は頭値に7ビット ASCII を使う必要がありまして、国際符号化文字集合の符号化には問題があります。 RFC 2822・MIME 頭の言語札付けの仕組みは酷いものでありまして、 応用可能性に限界があります。 > - 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. 変わりやすさ: 加えて、頭情報の修正や削除です。 これは陽に禁じられていませんから、 MIME 内容を処理する多くの応用 (例えば MIME 関門) が転送するメッセージを再構築・再構造化します。 これでは受信した応用が受信したデータを健勝することができず、 安全を護ろうとする試み (例えば署名) をほとんど無意味化してしまいます。 > - o Message and payload separation -- there is not a clear syntactic distinction between message metadata and message content. メッセージと積荷の分離: メッセージのメタデータとメッセージ内容の構文的区別が明確ではありません。 > - 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.) 限られた拡張可能性。 ([CODE(822)[X-]] 頭は標準化することができないので問題があります。 実験的に使い始めた頭が広く使われるようになっても、 共通の使用法を標準化できないという結果になります。) > - o No support for structured information (text string values only). 構造化情報に対応していない (文字列値のみ)。 > - o Some processors impose line length limitations. 行長制限を課す処理器がある。 > 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. このメモで定義するメッセージ書式は、 通常 RFC 2822・MIME の解析器が受入れる書式と互換の単純な構文を持ち、 より厳密な構文を持つことによりこのうちの幾つかの問題を克服しています。 また、 RFC 2822・MIME 書式仕様が被覆していない幾つかの望まれる機能にも対応しています。 ** 1.3. Goals > 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 independence of any specific application - o capability of conveying a range of different address types - o assumption of an 8-bit clean message-transfer protocol - o evolvable: extensible by multiple parties - o a clear separation of message metadata from message content - o a simple, regular, easily parsed syntax - o a compact, low-overhead format for simple messages - どの特定の応用とも独立 - 異なる番地型の範囲を運搬するん能力 - 8ビット安全なメッセージ転送プロトコルを仮定 - 発展可能: 複数の当事者により拡張可能 - メッセージのメタデータをメッセージ内容から明確に分離 - 単純で規則正しく簡単に解析可能な構文 - 単純なメッセージ用に簡潔で頭上の小さい書式 ** 1.4. Terminology and Conventions > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [4]. この文書の強調した鍵語は [[BCP 14]], [[RFC 2119]] に記述されているように解釈します。 > 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. 備考: このような注釈はこの文書の裏にある根拠についての追加の非本質的な情報を提供します。 この情報は適合実装を構築するために必要ではありませんが、 設計をより深く理解したい人の助けにはなるかもしれません。 * 2. Overall Message Structure > 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 メッセージ内容をメッセージや内容に関連したメタデータと一緒にカプセル化します。 CPIM メッセージは任意選択で 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. [CODE(MIME)[Message/CPIM]] 物体は2つの部分の実体で、 最初の部分はメッセージのメタデータを含み、2つ目の部分はメッセージの内容をです。 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) > 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: メッセージ本体の終了は使用するぷ戸と凝るの枠付け機構により定義されます。 札 [SAMP[m:]]、[SAMP[s:]]、[SAMP[h:]]、[SAMP[e:]]、[SAMP[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 :[CODE[m]]:メッセージ全体の MIME 頭 :[CODE[s]]:空の分離行 :[CODE[h]]:メッセージ頭 :[CODE[e]]:メッセージ内容を含む埋め込まれた MIME 物体 :[CODE[x]]:MIME 保安多部分メッセージ包み子 ** 2.1. Message/CPIM MIME Headers > The message MIME headers identify the message as a CPIM-formatted message. メッセージ MIME 頭はメッセージが CPIM 書式メッセージであることを識別します。 > The only required MIME header is: 必須の MIME 頭は > [PRE(MIME)[ Content-type: Message/CPIM ]PRE] だけです。 > Other MIME headers may be used as appropriate for the message transfer environment. 他の MIME 頭もメッセージ転送環境に応じて使って構いません。 ** 2.2. Message Headers > 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. メッセージ頭は電子メイルの RFC 2822 メッセージ頭欄と同様の目的を担いますが、 認められる構文は似ているものの制限されています。 > The basic header syntax is: 頭の基本の構文は > [PRE(CPIM)[ [VAR[Key]]: [VAR[Value]] ]PRE] > where "Key" is a header name and "Value" is the corresponding header value. で、ここで [VAR[Key]] は頭名、 [VAR[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 Only one header per line. Multiple headers MUST NOT be included on a single line. 一行の一つの頭だけです。複数の頭を一つの行に含めては'''なりません'''。 > - o Processors SHOULD NOT impose any line-length limitations. - o There MUST NOT be any whitespace at the beginning or end of a line. - o UTF-8 character encoding [13] MUST be used throughout. - o The character sequence CR,LF (13,10) MUST be used to terminate each line. - o The header name contains only US-ASCII characters (see section 3.1 and section 3.6 for the specific syntax). - 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. - 処理器はいかなる行長制限も課す'''べきではありません'''。 - 行のはじめや終わりに空白を置いては'''なりません'''。 - UTF-8 文字符号化を全体を通じて使用しなければ'''なりません'''。 - 文字列 [CODE(char)[CR]],[CODE(char)[LF]] ([CODE(char)[13]],[CODE(char)[10]]) を各行の終端として使用しなければ'''なりません'''。 - 頭名は US-ASCII 文字のみを含みます。 - 頭は制御文字 ([CODE(char)[0]]〜ODE(char)[31]]) を含んでは'''なりません'''。 頭値が制御文字を表現する必要がある時は後述の逃避機構を使用しなければ'''なりません'''。 > - o There MUST be a single space character (32) following the header name and colon. - o Multiple headers using the same key (header name) are allowed. (Specific header semantics may dictate only one occurrence of any particular header.) - o Header names MUST match exactly (i.e., "From:" and "from:" are different headers). - 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 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 Message processors MUST NOT change the order of message headers. - 頭名とコロンの後には一つ間隔文字 ([CODE(char)[32]]) がなければ'''なりません'''。 - 同じ鍵 (頭名) を使った複数の頭は認めます。 (特定の頭の意味は特定の頭の一つの存在にのみ指示できます。) - 頭名は正確に一致しなければ'''なりません''' (つまり [SAMP(CPIM)[From:]] と [SAMP(CPIM)[from:]] は異なる頭です)。 - 頭名が認識できないか理解できない場合は、 その頭を無視するべきです。しかし [CODE(CPIM)[Require:]] 頭も参照して下さい。 - 頭値の解釈 (例えば等価性) は特定の頭の定義に依存します。 メッセージ処理器はすべての頭 (名前と値両方) のすべてのオクテットを正確に保存しなければ'''なりません'''。 - メッセージ処理器はメッセージ頭の順序を変えては'''なりません'''。 > Examples: [PRE(CPIM)[ To: Pooh Bear From: DateTime: 2001-02-02T10:48:54-05:00 ]PRE] ** 2.3. Character Escape Mechanism > This mechanism MUST be used to code control characters in a header, having Unicode code points in the range U+0000 to U+001f or U+007f. (Rather than invent something completely new, the escape mechanism has been adopted from that used by the Java programming language.) この機構は頭で Unicode 符号位置が [CODE(char)[U+0000]] 〜 [CODE(char)[U+001F]] の範囲か [CODE(char)[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 符号化との写像は逃避列や文字符号化を気にせず行います。 (頭構文は [CODE(char)[CR]] と [CODE(char)[LF]] 以外の制御文字に対応するオクテットが出力に出現しないように定義されていません。) > An arbitrary UCS-2 character is escaped using the form: 任意の UCS-2 文字はは > \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) ,[CODE[\]] ,は [CODE(char)[U+005C]] (逆斜線) ,[CODE[u]] ,は [CODE(char)[U+0075]] (小文字 U) ,[CODE[[VAR[xxxx]]]],は丁度4つの16進数字 ([CODE(char)[0]]〜[CODE(char)[9]], [CODE(char)[a]]〜[CODE(char)[f]], [CODE(char)[A]]〜[CODE(char)[F]]) または ([CODE(char)[U+0030]]〜[CODE(char)[U+0039]], [CODE(char)[U+0041]]〜[CODE(char)[U+0046]], [CODE(chaR)[U+0061]]〜[CODE(char)[U+0066]]) の列 > The hexadecimal number 'xxxx' is the UCS code-point value of the escaped character. 十六進数 [VAR[xxxx]] は逃避する文字の UCS 符号位置値です。 > Further, the following special sequences introduced by "\" are used: 更に、 [CODE(char)[\]] から始まる次の特殊列を使います。 > , \\ ,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) *** 2.3.1. Escape Mechanism Usage > 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). 前述の特殊列は、逆斜線 ([CODE(char)[U+005C]]), タブ ([CODE(char)[U+0009]]), 改行 ([CODE(char)[U+000A]]), 復帰 ([CODE(char)[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. 特殊列 [CODE(CPIM)[\"]] は二重引用符で区切られた文字列中に二重引用符 ([CODE(char)[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. 特殊列 [CODE(CPIM)[\']] は単一引用符で区切られた文字列中に単一引用符 ([CODE(char)[U+0027]]) が出現する時には常に使わなければ'''なりません'''。 > - o Single- or double-quote characters that delimit a string value MUST NOT be escaped. 文字列値を区切る単一引用符や二重引用符は逃避しては'''なりません'''。 > - 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. 一般逃避列 [CODE(CPIM)[￥u[VAR[xxxx]]]]はその他の制御文字 ([CODE(char)[U+0000]]〜[CODE(char)[U+0007]], [CODE(char)[U+000B]]〜[CODE(char)[U+000C]], [CODE(char)[U+000E]]〜[CODE(char)[U+001F]], [CODE(char)[U+007F]]) が頭に出現する時に使用しなければ'''なりません'''。 > - o All other characters MUST NOT be represented using an escape sequence. 他のすべての文字は逃避列を使って表現しては'''なりません'''。 > 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. すべての逆斜線 ([CODE(char)[\]]) 文字は逃避列のはじめと解釈する'''べきです'''。 すべての認識できない逃避列は逆斜線に続く文字の実現値として扱う'''べきです'''。 頭の最後の文字である孤立した逆斜線は無視する'''べきです'''。 ** 2.4. Message Content > The final section of a Message/CPIM is the MIME-encapsulated message content, which follows standard MIME formatting rules [1][2]. [CODE(MIME)[Message/CPIM]] の最後の章は MIME カプセル化メッセージ内容で、 MIME 標準書式付け規則に従います。 > The MIME content headers MUST include at least a Content-Type header. The content may be any MIME type. MIME 内容頭は最低 [CODE(MIME)[[[Content-Type]]]] 頭を含まなければ'''なりません'''。 内容はどんな MIME 型でも構いません。 > Example: [PRE(CPIM)[ e: Content-Type: text/plain; charset=utf-8 e: Content-ID: <1234567890@foo.com> e: e: This is my encapsulated text message content ]PRE] * 3. Message Header Syntax > 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). 頭は、名前と値の2つの部分を含みまして、これをコロン文字 ([CODE(char)[:]]) と1つの間隔 ([CODE(char)[32]]) で分離します。 頭は [CODE(char)[CR]],[CODE(char)[LF]] ([CODE(char)[13]],[CODE(char)[10]]) 列で終端します。 > Headers use UTF-8 character encoding throughout, per RFC 3629 [13]. 頭は [[RFC 3629]] による UTF-8 文字符号化を使います。 > NOTE: in the descriptions that follow, header field names and other specified text values MUST be used exactly as given, using exactly the indicated upper- and lower- case letters. In this respect, the ABNF usage differs from RFC 2234 [6]. 備考: 以後の説明では、頭欄名と他の指定文字列値は正確に与えられた通り、 そのままの大文字・小文字を使って使用しなければ'''なりません'''。 この点で、 ABNF の使用法が [[RFC 2234]] とは異なります。 [INS[ 訳注: NOTE は背景参考情報とか書いておきながらこんな大事なことを。 ]INS] ** 3.1. Header Names > 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 文字から制御文字、 [CODE(char)[SPACE]] と分離子文字を除外したものの列です。頭名での文字 [CODE(char)[.]] の使用は名前空間接頭辞分離子に予約します。 > 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 と HTTP (それに [[SIP]] のような HTTP 派生プロトコル) の全部で認められる構文と互換とすることであります。 ** 3.2. Header Value > A header value has a structure defined by the corresponding header specification. Implementations that use a particular header must adhere to the format and usage rules thus defined when creating or processing a message containing that header. 頭値は対応する頭仕様により定義された構造を持ちます。 特定の頭を使う実装者は、その頭を含むメッセージを作成したり処理したりする時に書式と用法の規則に従わなければなりません。 > The other general constraints on header formats MUST also be followed (one line, UTF-8 character encoding, no control characters, etc.) 頭の書式の一般的な制約 (一行、 UTF-8 文字符号化、 制御文字なし、など) にも従わなければ'''なりません'''。 ** 3.3. Language tagging > Full internationalization of a protocol requires that a language can be indicated for any human-readable text [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]. メッセージ頭は頭名とコロンの後に [CODE(CPIM)[;lang=[VAR[tag]]]] を含めることでその値の言語を示せます。ここで [VAR[tag]] は [[RFC 3066]] による言語識別字句です。 > Example: [PRE(CPIM)[ Subject:;lang=fr Objet de message ]PRE] > If the language parameter is not applied a header, any human-readable text is assumed to use the language identified as 'i-default' [7]. 言語引数が頭に適用されなければ、 人間可読文は [CODE(lang)[[[i-default]]]] で識別される言語を使うと仮定します。 ** 3.4. Namespaces for Header Name Extensibility > 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名前空間]]が [[XML]] に提供しているものを基にしています。すべての頭は[DFN[[[名前空間]]]]に関連付けられます。 この名前空間の方は大域固有の [[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., 特定のメッセージ実現値の中で、頭名は名前空間接頭辞の存在または不存在により特定の名前空間と関連付けられます。 名前空間接頭辞は、頭名の前の部分で、後に句点 ([CODE(char)[.]]) が続きます。例: > 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. ここで、 [SAMP[prefix]] は頭名接頭辞で、 [SAMP[header-name]] は [SAMP[prefix]] に関連付けられた名前空間中の頭名で、 [SAMP[header-value]] はこの頭の値です。 > header-name: header-value > In this case, the header name prefix is absent, and the given 'header-name' is associated with a default namespace. この場合は、頭名接頭辞は存在せず、 与えられた [SAMP[header-name]] は[[既定名前空間]]に関連付けられます。 > 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. [CODE(MIME)[Message/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 を名前空間識別に使うことができます。 ([Q[大域固有]]とは、他の誰かが同じ URI を異なる目的に使わないであろうと期待するに十分な何らかの規則の集合に従って構築されたことを意味します。) 識別子として使う URI は [[RFC 2396]] による完全な [CODE(ABNF)[[[absolute-URI]]]] でなければ'''なりません'''。 (総体 URI や[[素片識別子]]を含む [[URI参照]]をこの目的に使っては'''なりません'''。) > Within a specific message, an 'NS' header is used to declare a namespace prefix and associate it with a URI that identifies a namespace. Following that declaration, within the scope of that message, the combination of namespace prefix and header name indicates a globally unique identifier for the header (consisting of the namespace URI and header name). [CODE(CPIM)[NS]] 頭は、特定のメッセージ中で名前空間接頭辞を宣言し、 それに名前空間を識別する URI を関連付けます。 その宣言に従い、そのメッセージの適用範囲内において、 名前空間接頭辞と頭名の組合せが頭の大域固有識別子 (名前空間 URI と頭名から成ります。) を示します。 > For example: [PRE(CPIM)[ NS: MyFeatures MyFeatures.WackyMessageOption: Use-silly-font ]PRE] > 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. これは名前空間識別子 [SAMP(URI)[mid:MessageFeatures@id.foo.com]] とそれに関連付けられた名前空間接頭辞 [SAMP[MyFeatures]] を定義します。従って、 [SAMP[MyFeatures.WackyMessageOption]] は [SAMP[WackyMessageOption]] を名前空間 [SAMP(URI)[mid:MessageFeatures@id.foo.com]] に関連付けることを示します。 > 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: 応用規定の定義済み名前空間接頭辞の例外を除き、 名前空間接頭辞はその出現するメッセージに厳密に局所なものです。 実際に使用する接頭辞に大域的な意味はありません。 つまり、異なる2つのメッセージの > 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つの頭は、名前空間接頭辞 [SAMP[xxx]] と [SAMP[yyy]] が同じ名前空間 URI に関連付けられていればまったく同じ効果を持ちます。 従って > [PRE(CPIM)[ NS: acme acme.runner-trap: set ]PRE] > and と > [PRE(CPIM)[ NS: widget widget.runner-trap: set ]PRE} は同じ意味です。 > 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: 頭接頭辞名なしの [CODE(CPIM)[NS]] 頭は以後の頭の既定名前空間を指定します。 既定名前空間とは接頭辞を持たない頭名が関連付けられる名前空間です。 > [PRE(CPIM)[ NS: runner-trap: set ]PRE] > 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. この枠組みは異なる実装が頭名の重複の心配をせずに拡張頭を作成することを認めます。 それぞれが自分の名前空間に頭を定義すれば良いのです。 ** 3.5. Mandatory-to-Recognize Features > 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: 頭や機能は、 [CODE(CPIM)[[[Require]]:]] 頭で認識強制であることを示します。 例: > [PRE(CPIM)[ Require: MyFeatures.VitalMessageOption MyFeatures.VitalMessageOption: Confirmation-requested ]PRE] > Multiple required header names may be listed in a single 'Require' header, separated by commas. 複数の必須頭名を1つの [CODE(CPIM)[Require]] 頭に読点で分離して列挙して構いません。 > NOTE: Indiscriminate use of 'Require:' headers could harm interoperability. It is suggested that any implementer who defines required headers also publish the header specifications so other implementations can successfully interoperate. 参考: 無闇矢鱈と [CODE(CPIM)[Require:]] 頭を使うと相互運用性に害が出るやもしれません。 要求頭を定義する実装者は頭の仕様を出版して他の実装とうまく相互運用できるようにするよう提案します。 > The 'Require:' header MAY also be used to indicate that some non-header semantics must be implemented by the recipient, even when it does not appear as a header. For example: [CODE(CPIM)[Require:]] 頭は、受信者が実装しなければならない頭以外の意味も、 頭として出現しなくても示すために使って'''構いません'''。 例: > [PRE(CPIM)[ Require: Locale.MustRenderKanji ]PRE] > 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. はメッセージ内容が漢字レパートリの文字を含んでおり、 メッセージを適切に理解するためにはレンダリングしなければならないことを示すために使うことができるでしょう。 この場合、頭名は望まれる振舞いを示す (頭名構文と名前空間関連付けを使った) 単なる字句です。 ** 3.6. Collected Message Header Syntax > 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]] を使います。この構文のほとんどは 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]. 備考: 指定文字列値は、大文字・小文字も正確に与えられた通り使わなければ'''なりません'''。 この点で RFC 2234 とここでの ABNF の用法は異なります。 > Collected syntax: 構文集成: > 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 = Language-tag = ; Any UCS character except CTLs, or escape HEADERCHAR = 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 = CRLF = SP = DIGIT = HEXDIG = ALPHA = DQUOTE = > 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 符号化オクテット列を定義すると解釈するには、 次の生成規則を使って下さい。 > 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]] のより制限された仕様に一致する UTF-8 を生成する'''べきです'''。 * 4. Header Definitions > 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). この仕様書は応用が使用することのできる頭の中核集合を定義します。 応用仕様は、使用しても良い頭、認識しなければならない頭、 すべてのメッセージに出現しなければならない頭を示さなければなりません。 > The header definitions that follow fall into two categories: これからの頭定義は2つの分野に分けることができます。 > - a) those that are part of the CPIM format extensibility framework, and - b) those that have been based on similar headers in RFC 2822 [9], specified here with corresponding semantics. - CPIM 書式の拡張可能性の枠組みの一部のもの - RFC 2822 の同様の頭に基づき、 ここで対応する意味を規定するもの > 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 , which is defined according to [12]. ここで定義する頭はすべて [[RFC 3553]] に従って定義された名前空間 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]. 備考: 頭名と他の文章は与えられた通りの大文字・小文字を使わなければ'''なりません'''。 この点で、 RFC 2234 とここでの ABNF の用法は異なります。 ** 4.1. The 'From' Header > Indicates the sender of a message. メッセージの層深謝を示します。 Header name: From Namespace URI: Syntax: (see also section 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. [CODE(ABNF)[Formal-name]] は存在すれば、 発信者の人物または[Q[実世界]]名を識別します。 > The URI indicates an address for the originator. URI は発信者の番地を示します。 Examples: From: Winnie the Pooh From: ** 4.2. The 'To' Header > Specifies an intended recipient of a message. メッセージの想定受信者を指定します。 Header name: To Namespace URI: Syntax: (see also section 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. [CODE(ABNF)[Formal-name]] は、受信者の人物か[Q[実世界]]名を識別します。 > The URI indicates an address for the recipient. URI は受信者の番地を示します。 > Multiple recipients may be indicated by including multiple 'To' headers. 複数の [CODE(CPIM)[To]] を含めることにより複数の受信者を示しても構いません。 Examples: To: Winnie the Pooh To: ** 4.3. The 'cc' Header > Specifies a non-primary recipient ("courtesy copy") for a message. メッセージの非一次的受信者 ([Q[丁寧複写]]) を指定します。 Header name: cc Namespace URI: Syntax: (see also section 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. [CODE(ABNF)[Formal-name]] は存在すれば受信者の人または [Q[実世界]]名を識別します。 > The URI indicates an address for the recipient. URI は受信者の番地を示します。 > Multiple courtesy copy recipients may be indicated by including multiple 'cc' headers. 複数の丁寧複写受信者は複数の [CODE(CPIM)[cc]] 頭を含めることで示すことができます。 Examples: cc: Winnie the Pooh cc: ** 4.4. The 'DateTime' Header > Specifies the date and time a message was sent. メッセージが送られた日付と時刻を指定します。 Header name: DateTime Namespace URI: Syntax: (see also section 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]) ここで、 [CODE(ABNF)[date-time]] の項分は [[ISO 8601]] のプロファイルで [CITE[インターネットの日付と時刻]] ([[RFC 3339]]) で定義されたものです。 > : Description: The 'DateTime' header supplies the date and time at which the sender sent the message. [CODE(CPIM)[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]. この頭の一つの目的は、受信者がメッセージの送られることを意図していたのがいつか知ることができるようにすることで再生攻撃からの防護を提供することです。 日付頭の値はメッセージを転送した時の送信者の現在時刻を ISO 8601 の日付と時刻の書式の [CITE[インターネットの日付と時刻: 時刻印]] のプロファイルを使って表したものです。 Example: DateTime: 2001-02-01T12:16:49-05:00 ** 4.5. The 'Subject' Header > Contains a description of the topic of the message. メッセージの主題の記述を含みます。 Header name: Subject Namespace URI: Syntax: (see also section 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. [CODE(CPIM)[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 ** 4.6. The 'NS' Header > Declare a local namespace prefix. 局所名前空間接頭辞を宣言します。 Header name: NS Namespace URI: Syntax: (see also section 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. 以後の頭名で使うことができる名前空間接頭辞を宣言します。 Example: NS: MyAlias MyAlias.MyHeader: private-extension-data ** 4.7. The 'Require' Header > Specify a header or feature that must be implemented by the receiver for correct message processing. 受信者が正しいメッセージ処理のために実装していなければならない頭や機能を指定します。 Header name: Require Namespace URI: Syntax: (see also section 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. 受信者が正しくメッセージを処理するために実装・理解しなければならない頭や機能を示します。 > 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. 必須の頭や機能はメッセージ中で使用する必要はありませんが、 簡潔性のため、実装は使用していない機能の [CODE(CPIM)[Required]] 頭を発行しないことを推奨します。 Example: Require: MyAlias.VitalHeader * 5. Examples > 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 > :[CODE[m]]:メッセージ全体の MIME 頭 :[CODE[s]]:空白分離行 :[CODE[h]]:メッセージ頭 :[CODE[e]]:メッセージ内容を含んだカプセル化 MIME 物体 :[CODE[x]]:MIME 保安多部分メッセージ包み子 > The following examples also assume is the implied default namespace for the application. 以後の例は を応用の暗示既定名前空間として仮定します。 ** 5.1. An Example Message/CPIM Message > The following example shows a Message/CPIM message: 次の例は [CODE(MIME)[Message/CPIM]] メッセージを示します。 > m: Content-type: Message/CPIM s: h: From: MR SANDERS h: To: Depressed Donkey 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 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: e: Here is the text of my message. e: ** 5.2. An Example Esing MIME multipart/signed > 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. [CODE(MIME)[Message/CPIM]] の保安のため、 応用や実装は [[RFC 1847]] と適当な保安プロトコル (例えば [[S/MIME]] や [[OpenPGP]]) と暗号化方式を使って構いません。 > Using S/MIME [19] and pkcs7, the above message would look like this: S/MIME と [[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 h: To: Dopey Donkey 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 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: e: Here is the text of my message. e: x: --next x: Content-Type: application/pkcs7-signature x: x: (signature stuff) : x: --next-- * 6. Application Design Considerations > 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. 定義の通り、 [CODE(MIME)[Message/CPIM]] 内容型は既定名前空間 URI を使い、 他の暗示名前空間接頭辞は定義しません。 異なる要件を持つ応用は、異なる MIME 媒体型を定義・登録するべきです。 必要な既定名前空間 URI を規定し、 暗示名前空間接頭辞を媒体型仕様の一部として定義して下さい。 > Applications using this specification must also specify: この仕様書を使用する応用は、 > - o all headers that must be recognized by implementations of the application - o any headers that must be present in all messages created by that application. - 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 Security mechanisms and crytography schemes to be used with the application, including any mandatory-to-implement security provisions. - その応用の実装が認識しなければならないすべての頭 - その応用で作成されたメッセージすべてに存在しなければならない頭 - メッセージに複数回出現しても良い頭と、 それをどう解釈するか (例えば、異なる言語引数値の複数の [CODE(CPIM)[Subject:]] 頭をどう解釈するか) - 応用と併用する保安機構と暗号化方式を、 実装必須の保安設備を含めて を規定しなければなりません。 > 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 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.) - メッセージ転送エージェントのネットワーク中で、 中間関門は [CODE(MIME)[Message/CPIM]] 内容をいかなる形でも変更しては'''なりません'''。 これは頭を変更したり並べ替えたりできなかったり、 転送符号化を変更できなかったり、言語を変更できなかったりなどなどすることを意味します。 - [CODE(MIME)[Message/CPIM]] メッセージは不変ですから、 メッセージを修正したいと思う転送エージェントは修正したい頭と元のメッセージを内容にした新しい [CODE(MIME)[Message/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 A Survey of Authentication Mechanisms [29]. * 7. IANA Considerations > 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 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. - 新しい MIME 内容型値 [CODE(MIME)[Message/CPIM]]。 [[RFC 2048]] により、登録雛形は次の7.1節にあります。 - 新しい IANA [[URN]] 名前亜空間 [CODE(URI)[urn:ietf:params:cpim-headers:]]。 [[RFC 3553]] により、登録雛形は後の7.2節にあります。 ** 7.1. Registration for Message/CPIM Content Type To: ietf-types@iana.org Subject: Registration of MIME media type Message/CPIM MIME media type name: message MIME subtype name: 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 内容に access することができるようになる前に符号化を戻さなければなりません。 > : 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]). 電子メイル・メッセージの保安関係も参照して下さい。 > : 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 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.) この内容型に関連付けられている既定名前空間は です。 See also the Common Profile for Instant Messaging (CPIM) [26]. Person & email address to contact for further information: G. Klyne, Intended usage: LIMITED USE Author/Change controller: IETF ** 7.2. Registration for urn:ietf:params:cpim-headers Registry name: cpim-headers Specification: RFC 3862. Additional values may be defined by standards track RFCs that update or obsolete RFC 3862. Repository: http://www.iana.org/assignments/cpim-headers > : Index value: The index value is a CPIM message header name, which may consist of a sequence from a restricted set of US-ASCII characters, as defined above. 索引値は CPIM メッセージ頭名で、先に定義した通り US-ASCII 文字の制限された集合の文字の列から成ります。 > : URN Formation: The URI for a header is formed from its name by: 頭の URI は名前から次のように形成します。 > = a) replacing any non-URN characters (as defined by RFC 2141 [5]) with the corresponding '%hh' escape sequence (per RFC 2396 [8]); and = b) prepending the resulting string with 'urn:ietf:params:cpim-headers:'. = 非 URN 文字を対応する [CODE(URI)[%[VAR[HH]]]] 逃避列に置換する = 結果の文字列の前に [CODE(URI)[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 メッセージ頭 [SAMP(CPIM)[From:]] に対応する URI は [SAMP(URI)[urn:ietf:params:cpim-headers:From]] となります。 (推定) CPIM メッセージ頭 [SAMP(CPIM)[Top&Tail]] に対応する URI は [SAMP(URI)[urn:ietf:params:cpim-headers:Top%26Tail]] になります。 * 8. Internationalization Considerations > 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, ISO/IEC 10646) の文字レパートリを完全に運搬できます。 > Language tagging is provided for message headers using the "Lang" parameter (section 3.3). メッセージ頭の言語札付けも [CODE(CPIM)[[[Lang]]]] 引数を使って提供しています。 > Message content is any MIME-encapsulated content, and normal MIME content internationalization considerations apply. メッセージ内容は任意の MIME カプセル化内容で、 通常の MIME 内容国際化の考慮が適用されます。 * 9. Security Considerations > 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. [CODE(MIME)[Message/CPIM]] 書式は保安を念頭に設計されています。 特に、 MIME 保安多部分を署名と暗号化に使うよう設計しています。 このため、一度 [CODE(MIME)[Message/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. [CODE(MIME)[Message/CPIM]] メッセージは (UTF-8 符号化により) バイナリ・メッセージですから、非8ビット安全輸送路を通して転送しようとしますと、 転送エージェントはメッセージ全体をトンネルしなければなりません。 メッセージ・データ符号化は選択肢にありません。 これはつまり [CODE(MIME)[Message/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. 結果のメッセージに符号化と復号によるデータの損失があってはなりません。 例えば、応用はこの要件を満たすために [CODE(MIME)[Message/CPIM]] 物体に MIME [[Base64]] 内容転送符号化を適用することを選ぶことができます。 * 10. Acknowledgements > The authors thank the following for their helpful comments: Harald Alvestrand, Walter Houser, Leslie Daigle, Mark Day, Brian Raymor. 著者は次の皆様の有用なご助言に感謝致します。 Harald Alvestrand, Walter Houser, Leslie Daigle, Mark Day, Brian Raymor * 11. References ** 11.1. Normative References [1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [3] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Moats, R., "URN Syntax", RFC 2141, May 1997. [6] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [7] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [9] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [10] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [11] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [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. [13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. ** 11.2. Informative References [14] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [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. [16] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. [17] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [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. [19] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [20] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000. [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. [22] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C Recommendation xml, October 2000, . [23] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C Recommendation xml-names, January 1999, . [24] International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, June 1988. [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. [26] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004. [27] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004. [28] Bellovin, S., Kaufman, C., and J. Schiller, "Security Mechanisms for the Internet", RFC 3631, December 2003. [29] Rescorla, E., "A Survey of Authentication Mechanisms", Work in Progress, March 2004. [30] The Unicode Consortium, "The Unicode Standard, Version 4.0", Addison-Wesley, Boston, MA. ISBN 0-321-18578-1, April 2003, . * 12. Authors' Addresses 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 Phone: +1 617 623 3745 EMail: derek@ihtfp.com, warlord@alum.mit.edu * 13. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. 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. * メモ Klyne & Atkins Standards Track [Page 30]