RFC3862 日本語訳
3862 Common Presence and Instant Messaging (CPIM): Message Format. G.Klyne, D. Atkins. August 2004. (Format: TXT=56133 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Klyne
Request for Comments: 3862 Nine by Nine
Category: Standards Track D. Atkins
IHTFP Consulting
August 2004
Klyneがコメントのために要求するワーキンググループG.をネットワークでつないでください: 3862 9時9分前のカテゴリ: 2004年8月に相談する標準化過程D.アトキンスIHTFP
Common Presence and Instant Messaging (CPIM): Message Format
一般的な存在とインスタントメッセージング(CPIM): メッセージ・フォーマット
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This memo defines the MIME content type 'Message/CPIM', a message format for protocols that conform to the Common Profile for Instant Messaging (CPIM) specification.
このメモはタイプ'メッセージ/CPIM'というMIME内容(Instant Messaging(CPIM)仕様のためのCommon Profileに従うプロトコルのためのメッセージ・フォーマット)を定義します。
Klyne & Atkins Standards Track [Page 1] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[1ページ]: メッセージ・フォーマット2004年8月
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 動機. . . . . . . . . . . . . . . . . . . . . . . 3 1.2。 バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . 3 1.3。 目標. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4。 用語とコンベンション. . . . . . . . . . . . . . 5 2。 総合的なメッセージ構造. . . . . . . . . . . . . . . . . . 5 2.1。 メッセージ/CPIMはヘッダー. . . . . . . . . . . . . . . 6 2.2をまねます。 メッセージヘッダー. . . . . . . . . . . . . . . . . . . . 6 2.3。 キャラクター逃避機制. . . . . . . . . . . . . . . 8 2.3.1。 メカニズム用法. . . . . . . . . . . . . 8 2.4から逃げてください。 メッセージ内容. . . . . . . . . . . . . . . . . . . . 9 3。 メッセージヘッダー構文. . . . . . . . . . . . . . . . . . . . 10 3.1。 ヘッダー名. . . . . . . . . . . . . . . . . . . . . . 10 3.2。 ヘッダー値. . . . . . . . . . . . . . . . . . . . . . 10 3.3。 .103.4にタグ付けをする言語。 ヘッダーのための名前空間は伸展性. . . . . . . . 11 3.5を命名します。 認識するために義務的な特徴. . . . . . . . . . . . 13 3.6。 集まっているメッセージヘッダー構文. . . . . . . . . . . . 14 4。 ヘッダー定義. . . . . . . . . . . . . . . . . . . . . . 16 4.1。 'From'ヘッダー. . . . . . . . . . . . . . . . . . . 16 4.2。 'To'ヘッダー. . . . . . . . . . . . . . . . . . . . 17 4.3。 'cc'ヘッダー. . . . . . . . . . . . . . . . . . . . 18 4.4。 'DateTime'ヘッダー. . . . . . . . . . . . . . . . . 18 4.5。 '受けることがある'ヘッダー. . . . . . . . . . . . . . . . . . 19 4.6。 'ナノ秒'ヘッダー. . . . . . . . . . . . . . . . . . . . 20 4.7。 '必要'ヘッダー. . . . . . . . . . . . . . . . . . 20 5。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1。 例のメッセージ/CPIMメッセージ. . . . . . . . . . . . 21 5.2。 Example Esing MIME複合の/は.226にサインしました。 アプリケーション設計問題. . . . . . . . . . . . . . 22 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . 23 7.1。 メッセージ/CPIMの満足しているタイプ. . . . . . . 24 7.2のための登録。 つぼ:ietf:paramsのための登録: cpim-ヘッダー.258。 国際化問題. . . . . . . . . . . . . 26 9。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 26 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 26 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.1。 引用規格。 . . . . . . . . . . . . . . . . . 26 11.2. 有益な参照。 . . . . . . . . . . . . . . . . 27 12. 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 29 13。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 30
Klyne & Atkins Standards Track [Page 2] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[2ページ]: メッセージ・フォーマット2004年8月
1. Introduction
1. 序論
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内容(Instant Messaging(CPIM)仕様のためのCommon Profileに従うプロトコルのためのメッセージ・フォーマット)を定義します。 これは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で引き起こされた疑問を記述するべきです。
1.1. Motivation
1.1. 動機
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].
Instant Messaging(CPIM)[26]仕様のためのCommon Profileは、さまざまのインスタントメッセージングプロトコルの間の織り込むために満たされるために多くの支持されるべき操作と評価基準を定義します。 意図はゲートウェイを通して織り込むさまざまな異なったプロトコルがRFC2779[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.
適切にRFC2779に関するセキュリティ必要条件を満たすのに、一般的なメッセージ・フォーマットが必要であるので、その終わりから終わりに、署名と暗号化は適用されるかもしれません。 このドキュメントはどんな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を見てください。
1.2. Background
1.2. バックグラウンド
RFC 2779 requires that an instant message can carry a MIME payload [1][2]; thus some level of support for MIME will be a common element of any CPIM compliant protocol. Therefore it seems reasonable that a common message format should use a RFC2822/MIME-like syntax [9], as protocol implementations must already contain code to parse this.
RFC2779は、インスタントメッセージがMIMEペイロード[1][2]を運ぶことができるのを必要とします。 したがって、MIMEのための何らかのサポート水準がどんなCPIM対応することのプロトコルの一般的な原理にもなるでしょう。 したがって、一般的なメッセージ・フォーマットがMIMEのRFC2822/ような構文[9]を使用するべきであるのは妥当に思えます、プロトコル実現が既にこれを分析するコードを含まなければならないとき。
Unfortunately, using pure RFC2822/MIME can be problematic:
残念ながら、純粋なRFC2822/MIMEを使用するのは問題が多い場合があります:
Klyne & Atkins Standards Track [Page 3] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[3ページ]: メッセージ・フォーマット2004年8月
o Irregular lexical structure -- RFC2822/MIME allows a number of
optional encodings and multiple ways to encode a particular value.
For example, RFC2822/MIME comments may be encoded in multiple
ways. For security purposes, a single encoding method must be
defined as a basis for computing message digest values. Protocols
that transmit data in a different format would otherwise lose
information needed to verify a signature.
o 不規則な語彙構造--RFC2822/MIMEは多くの任意のencodingsと特定の値をコード化する複数の方法を許容します。 例えば、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を使用するためにヘッダー値を必要とします。(国際的な人物セットをコード化するのに、ASCIIは問題が多いです)。 RFC2822/MIMEでヘッダー[16]にタグ付けをする言語のためのメカニズムは、使用するために無器用であり、適用性を制限しました。
o Mutability -- addition, modification or removal of header
information. Because it is not explicitly forbidden, many
applications that process MIME content (e.g., MIME gateways)
rebuild or restructure messages in transit. This obliterates most
attempts at achieving security (e.g., signatures), leaving
receiving applications unable to verify the data received.
o 無常--ヘッダー情報の添加、変更または取り外し。 それが明らかに禁じられないので、MIME内容(例えば、MIMEゲートウェイ)を処理する多くのアプリケーションが、トランジットにおけるメッセージを再建するか、または再構築します。 データについて確かめることができないアプリケーションが受けた受信を残して、これは安定を得ることへのほとんどの試み(例えば、署名)を抹消します。
o Message and payload separation -- there is not a clear syntactic
distinction between message metadata and message content.
o メッセージとペイロード分離--メッセージメタデータとメッセージ内容の間には、明確な構文の区別がありません。
o Limited extensibility. (X-headers are problematic because they
may not be standardized; this leads to situations where a header
starts out as experimental but then finds widespread application,
resulting in a common usage that cannot be standardized.)
o 株式会社伸展性。 (彼らが標準化されないかもしれないので、X-ヘッダーは問題が多いです; これはヘッダーが実験的であるとして始めますが、広範囲の法則に当たる状況に通じます、標準化できない一般的な用法をもたらして。)
o No support for structured information (text string values only).
o 構造化された情報(テキスト文字列値専用)のサポートがありません。
o Some processors impose line length limitations.
o いくつかのプロセッサが行長制限を課します。
The message format defined by this memo overcomes some of these difficulties by having a simplified syntax that is generally compatible with the format accepted by RFC2822/MIME parsers and having a stricter syntax. It also defines mechanisms to support some desired features not covered by the RFC2822/MIME format specifications.
このメモで定義されたメッセージ・フォーマットは、一般に、RFC2822/MIMEパーサで受け入れる形式と互換性がある簡易型の構文を持っていて、より厳しい構文を持っていることによって、これらの困難のいくつかを克服します。 また、それは、RFC2822/MIME書式仕様でカバーされなかったいくつかの必要な特徴を支持するためにメカニズムを定義します。
1.3. Goals
1.3. 目標
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 メッセージ(指定されたセキュリティー対策よりむしろ署名計算の基礎として役立つ正準なメッセージ・フォーマット)のための終わりから終わりへの手に入れられる形式。
Klyne & Atkins Standards Track [Page 4] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[4ページ]: メッセージ・フォーマット2004年8月
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 簡単なメッセージのためのコンパクトで、低いオーバーヘッドの形式
1.4. Terminology and Conventions
1.4. 用語とコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [4].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[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.
以下に注意してください。 このようなコメントは原理の追加不要不急な情報をこのドキュメントの後ろに供給します。 そのような情報は、conformant実現を組み込むのに必要ではありませんが、より大きい深さでデザインを理解したがっている人を助けるかもしれません。
2. Overall Message Structure
2. 総合的なメッセージ構造
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.
Message/CPIM物は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)
m: 文書内容: メッセージ/CPIM s: h: (メッセージメタデータヘッダー) s: e: (要約のMIMEメッセージ本体)
Klyne & Atkins Standards Track [Page 5] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[5ページ]: メッセージ・フォーマット2004年8月
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:
メッセージ本体の先は使用されるプロトコルの縁どりメカニズムによって定義されます。 'タグは以下の通りです'は以下の通り、'、'、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: 総合的なメッセージsのためのMIMEヘッダー: 空白の区切り線h: メッセージヘッダーe: メッセージ内容xを含む要約のMIME物: MIMEのセキュリティの複合メッセージ包装紙
2.1. Message/CPIM MIME Headers
2.1. メッセージ/CPIM 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ヘッダーはメッセージ転送環境に適宜使用されるかもしれません。
2.2. Message Headers
2.2. メッセージヘッダー
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.
メッセージヘッダーは、中の2822個のメッセージヘッダーが[9]をメールするRFCに同様の目的に勤めて、同様の、しかし、部外秘な許容できる構文を持っています。
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 単線の上に全体のヘッダーを保管しなければなりません。 線ターミネータはヘッダー価値の一部であると考えられません。
Klyne & Atkins Standards Track [Page 6] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[6ページ]: メッセージ・フォーマット2004年8月
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 プロセッサSHOULD NOTはどんな行長制限も課します。
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 [13]をコード化するのを使用しなければならないUTF-8キャラクタ。
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 ヘッダー名は米国-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:」と「以下」は異なったヘッダーです)。
o If a header name is not recognized or not understood, the header
should be ignored. But see also the "Require:" header (section
4.7).
o ヘッダー名が認識されないか、または理解されていないなら、ヘッダーは無視されるべきです。 しかし、また、「以下を必要としてください」を見てください。 ヘッダー(セクション4.7)。
o Interpretation (e.g., equivalence) of header values is dependent
on the particular header definition. Message processors MUST
preserve all octets of all headers (both name and value) exactly.
o ヘッダー値の解釈(例えば、等価性)は特定のヘッダー定義に依存しています。 メッセージプロセッサはまさにすべてのヘッダー(名前と値の両方)のすべての八重奏を保存しなければなりません。
o Message processors MUST NOT change the order of message headers.
o メッセージプロセッサはメッセージヘッダーの注文を変えてはいけません。
Examples:
例:
To: Pooh Bear <im:pooh@100akerwood.com>
From: <im:piglet@100akerwood.com>
DateTime: 2001-02-02T10:48:54-05:00
To: くまのプーさんのクマ<、不-、: pooh@100akerwood.com 、gt;、From: <、不-、: piglet@100akerwood.com 、gt;、DateTime: 2001-02-02T10: 48:54-05:00
Klyne & Atkins Standards Track [Page 7] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[7ページ]: メッセージ・フォーマット2004年8月
2.3. Character Escape Mechanism
2.3. キャラクター逃避機制
This mechanism MUST be used to code control characters in a header, having Unicode code points in the range U+0000 to U+001f or U+007f. (Rather than invent something completely new, the escape mechanism has been adopted from that used by the Java programming language.)
ヘッダーで制御文字をコード化するのにこのメカニズムを使用しなければなりません、範囲のU+001fへのU+0000か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コード化までのマッピングはエスケープシーケンスへの尊敬もキャラクタコード化なしで実行されます。 (ヘッダー構文が定義されるので、CRとLF以外の制御文字に対応する八重奏は出力に現れません。)
An arbitrary UCS-2 character is escaped using the form:
任意のUCS-2キャラクタフォームを使用することで逃げられます:
\uxxxx
\uxxxx
where:
どこ:
\ is U+005c (backslash)
u is U+0075 (lower case letter U)
xxxx is a sequence of exactly four hexadecimal digits
(0-9, a-f or A-F) or
(U+0030-U+0039, U+0041-U+0046, or U+0061-0066)
または\によるU+005c(バックスラッシュ)uがU+0075(小文字U)xxxxがまさに4つの16進数字(0-9、a-fまたはA-F)の系列であるということであるということである。(U+0041U+0030U+0039、U+0046、または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)
''(ただ一つの引用文、U+0027)\bの「(引用文を倍にしてください、U+0022)\'「\(バックスラッシュ、U+005c)\の\\」、バックスペースキー、ラインフィードのためのタブ(U+0009)\nの(U+0008)\t、(復帰のためのU+000a)\r、'、」(U+000d)
2.3.1. Escape Mechanism Usage
2.3.1. 逃避機制用法
When generating messages conformant with this specification:
この仕様でメッセージconformantを発生させるとき:
o The special sequences listed above MUST be used to encode any
occurrence of the following characters that appear anywhere in a
header: backslash (U+005c), backspace (U+0008), tab (U+0009),
linefeed (U+000a) or carriage return (U+000d).
o ヘッダーでどこでも現れる以下のキャラクタのどんな発生もコード化するのに上に記載された特別な系列を使用しなければなりません: バックスラッシュ(U+005c)、バックスペースキーを押して印字位置を一字分戻ってください、そして、(U+0008)(U+0009)、ラインフィードにタブを付けてください。(U+000a)か復帰(U+000d)。
Klyne & Atkins Standards Track [Page 8] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[8ページ]: メッセージ・フォーマット2004年8月
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 ヘッダーでどこでも現れるいかなる他の制御文字(U+0007へのU+0000、U+000cへのU+000b、U+001fへのU+000eまたはu+007f)にも一般的なエスケープシーケンス\uxxxxを使用しなければなりません。
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.
さらに、エスケープシーケンスのいかなる他の発生も上で認識されて、対応するユニコード文字の発生として扱われたSHOULDについて説明しました。
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.
どんなバックスラッシュ('\')キャラクタSHOULD、いてください。エスケープシーケンスを紹介しながら、解釈されます。 どんな認識されていないエスケープシーケンスSHOULD、もバックスラッシュキャラクタに続いて、キャラクタの例として扱われてください。 それはヘッダーSHOULDの最後のキャラクタです。孤立しているバックスラッシュ、無視されます。
2.4. Message Content
2.4. メッセージ内容
The final section of a Message/CPIM is the MIME-encapsulated message content, which follows standard MIME formatting rules [1][2].
Message/CPIMの最後のセクションはMIMEで要約されたメッセージ内容です。(そのメッセージ内容は標準のMIME形式規則[1][2]に続きます)。
The MIME content headers MUST include at least a Content-Type header. The content may be any MIME type.
MIME内容ヘッダーは少なくともコンテントタイプヘッダーを入れなければなりません。 内容はどんなMIMEの種類であるかもしれません。
Example:
例:
e: Content-Type: text/plain; charset=utf-8
e: Content-ID: <1234567890@foo.com>
e:
e: This is my encapsulated text message content
e: コンテントタイプ: テキスト/平野。 charset=utf-8 e: コンテントID: <1234567890@foo.com>e: e: これは私の要約のテキストメッセージ内容です。
Klyne & Atkins Standards Track [Page 9] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[9ページ]: メッセージ・フォーマット2004年8月
3. Message Header Syntax
3. メッセージヘッダー構文
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つの部品、名前、および値を含んでいる、(':'、)、そして、シングルスペース(32)。 それは系列CR、LF(13、10)によって終えられます。
Headers use UTF-8 character encoding throughout, per RFC 3629 [13].
ヘッダーはあらゆる点でRFC3629[13]単位でUTF-8キャラクタコード化を使用します。
NOTE: in the descriptions that follow, header field names and other specified text values MUST be used exactly as given, using exactly the indicated upper- and lower- case letters. In this respect, the ABNF usage differs from RFC 2234 [6].
以下に注意してください。 続く記述ヘッダーフィールド名と他の指定されたテキスト値がちょうど与えるように使用されているに違いありません、まさに示された上側の、そして、低いケース手紙を使用して。 この点で、ABNF用法はRFC2234[6]と異なっています。
3.1. Header Names
3.1. ヘッダー名
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.
コントロール、SPACEまたは分離符キャラクタを除いて、ヘッダー名は米国-ASCII文字の系列です。 」 . 」 コネをキャラクタに使用してください。「ヘッダー名は名前空間接頭語分離符のために予約されます。
Separator characters are:
分離符キャラクタは以下の通りです。
SEPARATORS = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / "\" / DQUOTE
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP
「分離符は「」 (「/」)」 /「<」 /">"/"@"/」、/」と等しいです」 / ":" 「/「」 \/ DQUOTE /」/」/「[「/」]」/“?" /が/と「等しい」、「「/」」 /SP
NOTE: The range of allowed characters was determined by examination of HTTP and RFC 2822 header name formats and choosing the more restricted. The intent is to allow CPIM headers to follow a syntax that is compatible with the allowed syntax for both RFC 2822 [9] and HTTP [18] (including HTTP-derived protocols such as SIP [21]).
以下に注意してください。 許容キャラクタの範囲は形式と、より選ぶのが制限したHTTPとRFC2822ヘッダー名の試験で決定しました。 意図はCPIMヘッダーがRFC2822[9]とHTTP[18]の両方において、許容構文と互換性がある構文に従うのを許容することです。(SIP[21])などのHTTPで派生しているプロトコルを含んでいます。
3.2. Header Value
3.2. ヘッダー値
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キャラクタコード化、制御文字がありませんなど)
3.3. Language tagging
3.3. 言語タグ付け
Full internationalization of a protocol requires that a language can be indicated for any human-readable text [15][7].
プロトコルの完全な国際化は、どんな人間読み込み可能なテキスト[15][7]のためにも言語を示すことができるのを必要とします。
Klyne & Atkins Standards Track [Page 10] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[10ページ]: メッセージ・フォーマット2004年8月
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=タグ'のために言語を示すかもしれません。そこでは、'タグ'がRFC3066[10]あたりの象徴を特定する言語です。
Example:
例:
Subject:;lang=fr Objet de message
Subject:; lang=fr Objet deメッセージ
If the language parameter is not applied a header, any human-readable text is assumed to use the language identified as 'i-default' [7].
言語パラメタが適用されたaヘッダーでないなら、どんな人間読み込み可能なテキストも'i-デフォルト'[7]として特定された言語を使用すると思われます。
3.4. Namespaces for Header Name Extensibility
3.4. ヘッダー名前伸展性のための名前空間
NOTE: This section defines a framework for header extensibility whose use is optional. If no header extensions are allowed by an application then these structures may never be used.
以下に注意してください。 このセクションは使用が任意であるヘッダー伸展性のために枠組みを定義します。 ヘッダー拡大が全くアプリケーションで許されていないなら、これらの構造は決して使用されないかもしれません。
An application that uses this message format is expected to define the set of headers that are required and allowed for that application. This section defines a header extensibility framework that can be used with any application.
このメッセージ・フォーマットを使用するアプリケーションがそのアプリケーションのために必要であり、許容されているヘッダーのセットを定義すると予想されます。 このセクションはどんなアプリケーションと共にも使用できるヘッダー伸展性枠組みを定義します。
The extensibility framework is based on that provided for XML [22] by XML namespaces [23]. All headers are associated with a "namespace", which is in turn associated with a globally unique URI.
伸展性枠組みはXML名前空間[23]によってXML[22]に提供されたそれに基づいています。 すべてのヘッダーが「名前空間」に関連しています。(それは、順番にグローバルにユニークなURIに関連づけられます)。
Within a particular message instance, header names are associated
with a particular namespace through the presence or absence of a
namespace prefix, which is a leading part of the header name followed
by a period ("."); e.g.,
特定のメッセージ例の中では、ヘッダー名が存在を通した特定の名前空間か期間までに従われたヘッダー名の主役である名前空間接頭語の欠如に関連している、(「」、)、。 例えば
prefix.header-name: header-value
prefix.header-名前: ヘッダー値
Here, 'prefix' is the header name prefix, 'header-name' is the header name within the namespace associated with 'prefix', and 'header- value' is the value for this header.
ここで、'接頭語'は接頭語というヘッダー名です、そして、'ヘッダー名'は'接頭語'に関連している名前空間の中のヘッダー名です、そして、'ヘッダー値'はこのヘッダーのための値です。
header-name: header-value
ヘッダー名: ヘッダー値
In this case, the header name prefix is absent, and the given 'header-name' is associated with a default namespace.
この場合、接頭語というヘッダー名は欠けています、そして、与えられた'ヘッダー名'はデフォルト名前空間に関連しています。
The Message/CPIM media type registration designates a default namespace for any headers that are not more explicitly associated with any namespace. In most cases, this default namespace is all that is needed.
登録がどんなヘッダーのためにもより明らかにデフォルト名前空間を指定しないMessage/CPIMメディアタイプはどんな名前空間とも交際しました。 多くの場合、このデフォルト名前空間は必要であるすべてです。
Klyne & Atkins Standards Track [Page 11] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[11ページ]: メッセージ・フォーマット2004年8月
A namespace is identified by a URI. In this usage, the URI is used simply as a globally unique identifier, and there is no requirement that it can be used for any other purpose. Any legal globally unique URI MAY be used to identify a namespace. (By "globally unique", we mean constructed according to some set of rules so that it is reasonable to expect that nobody else will use the same URI for a different purpose.) A URI used as an identifier MUST be a full absolute-URI, per RFC 2396 [8]. (Relative URIs and URI-references containing fragment identifiers MUST NOT be used for this purpose.)
名前空間はURIによって特定されます。 この用法で、URIは単にグローバルにユニークな識別子として使用されます、そして、いかなる他の目的にもそれを使用できるという要件が全くありません。 どんな法的なグローバルにユニークなURIも、名前空間を特定するのに使用されるかもしれません。 (何らかのセットの規則に従って「グローバルにユニーク」で、私たちが、組み立てられることを意味するので、他の誰もが異なる役割に同じURIを使用しないと予想するのは妥当です。) URIは識別子が完全な絶対URIであるに違いない、RFC単位で2396[8]を使用しました。 (このために相対URIと断片識別子を含むURI参照を使用してはいけません。)
Within a specific message, an 'NS' header is used to declare a namespace prefix and associate it with a URI that identifies a namespace. Following that declaration, within the scope of that message, the combination of namespace prefix and header name indicates a globally unique identifier for the header (consisting of the namespace URI and header name).
特定のメッセージの中では、'NS'ヘッダーは、名前空間を特定するURIに名前空間接頭語を宣言して、それを関連づけるのに使用されます。 そのメッセージの範囲の中でその宣言に続いて、名前空間接頭語とヘッダー名の組み合わせはヘッダーのためにグローバルにユニークな識別子を示します(名前空間URIとヘッダー名から成って)。
For example:
例えば:
NS: MyFeatures <mid:MessageFeatures@id.foo.com>
MyFeatures.WackyMessageOption: Use-silly-font
ナノ秒: MyFeatures<中間:、 MessageFeatures@id.foo.com 、gt;、MyFeatures.WackyMessageOption: 愚かな字体を使用してください。
This defines a namespace prefix 'MyFeatures' associated with the namespace identifier 'mid:MessageFeatures@id.foo.com'. Subsequently, the prefix indicates that the WackyMessageOption header name referenced is associated with the identified namespace.
これはa名前空間接頭語'中間で'名前空間識別子に関連づけられた'MyFeatures: MessageFeatures@id.foo.com 'を定義します。 次に、接頭語は、参照箇所というWackyMessageOptionヘッダー名が特定された名前空間に関連しているのを示します。
A namespace prefix declaration MUST precede any use of that prefix.
名前空間接頭語宣言はその接頭語のどんな使用にも先行しなければなりません。
With the exception of any application-specific predefined namespace prefixes (see section 6), a namespace prefix is strictly local to the message in which it occurs. The actual prefix used has no global significance. This means that the headers:
どんなアプリケーション特有の事前に定義された名前空間接頭語(セクション6を見る)を除いても、名前空間接頭語は厳密にそれが起こるメッセージにローカルです。 使用される実際の接頭語はどんなグローバルな意味も持っていません。 これがそれを意味する、ヘッダー:
xxx.name: value
yyy.name: value
xxx.name: yyy.nameを評価してください: 値
in two different messages may have exactly the same effect if namespace prefixes 'xxx' and 'yyy' are associated with the same namespace URI. Thus the following have exactly the same meaning:
2つの異なったメッセージでは、名前空間接頭語の'xxx'と'yyy'が同じ名前空間URIに関連しているなら、まさに同じ効果を持っているかもしれません。 したがって、以下には、まさに同じ意味があります:
NS: acme <http://id.acme.widgets/wily-headers/>
acme.runner-trap: set
ナノ秒: 頂上の<の陰険なhttp://id.acme.widgets/ヘッダー/>acme.runner-罠: セットします。
and
そして
NS: widget <http://id.acme.widgets/wily-headers/>
widget.runner-trap: set
ナノ秒: ウィジェットの<の陰険なhttp://id.acme.widgets/ヘッダー/>widget.runner-罠: セットします。
Klyne & Atkins Standards Track [Page 12] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[12ページ]: メッセージ・フォーマット2004年8月
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
ナノ秒: >ランナー<の陰険なhttp://id.acme.widgets/ヘッダー/罠: セットします。
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.
このフレームワークで、異なったimplementersはヘッダー名前複製の心配なしで拡張ヘッダーを創造できます。 それぞれがそれら自身の名前空間の中でヘッダーを定義します。
3.5. Mandatory-to-Recognize Features
3.5. 認識するために義務的な特徴
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.
以下に注意してください。 '以下を必要としてください'というヘッダーの広範囲な使用は相互運用性に害を及ぼすかもしれません。 また、必要なヘッダーを定義するどんなimplementerも他の実装が首尾よく共同利用できるようにヘッダー仕様を発表することが提案されます。
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.
メッセージ内容がKanjiレパートリーからのキャラクタを含んでいるのを示すのに使用されるかもしれません。メッセージの適切な理解のためにレパートリーを表さなければなりません。 この場合、ヘッダー名はただ何らかの必要なふるまいを示すトークン(ヘッダー名前構文を使用して、名前空間協会)です。
Klyne & Atkins Standards Track [Page 13] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[13ページ]: メッセージ・フォーマット2004年8月
3.6. Collected Message Header Syntax
3.6. 集まっているメッセージヘッダー構文
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.
メッセージヘッダー構文の以下の記述はRFC2234[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用法はRFC2234[6]と異なっています。
Collected syntax:
集まっている構文:
Header = Header-name ":" *( ";" Parameter ) SP
Header-value
CRLF
「ヘッダー=ヘッダー名」:、」 *(「」、;、パラメタ) SPヘッダー価値のCRLF
Header-name = [ Name-prefix "." ] Name Name-prefix = Name
「ヘッダー名の=、[名前接頭語、」、」、]、名前名前接頭語=名
Parameter = Lang-param / Ext-param Lang-param = "lang=" Language-tag Ext-param = Param-name "=" Param-value Param-name = Name Param-value = Token / Number / String
パラメタ=ラング-param / Ext-paramラング-param=「lang=」言語タグExt-param=Param-名前「=」Param-値Param-名は名前Param-値=トークン/数/ストリングと等しいです。
Header-value = *HEADERCHAR
ヘッダー値は*HEADERCHARと等しいです。
Name = 1*NAMECHAR
Token = 1*TOKENCHAR
Number = 1*DIGIT
String = DQUOTE *( Str-char / Escape ) DQUOTE
Str-char = %x20-21 / %x23-5B / %x5D-7E / UCS-high
Escape = "\" ( "u" 4(HEXDIG) ; UCS codepoint
/ "b" ; Backspace
/ "t" ; Tab
/ "n" ; Linefeed
/ "r" ; Return
/ DQUOTE ; Double quote
/ "'" ; Single quote
/ "\" ) ; Backslash
「u」4(HEXDIG); UCS codepoint/「b」;はバックスペースキーを押して印字位置を一字分戻ります。名前=1*NAMECHAR Token=1*TOKENCHAR Number=1*DIGIT String=DQUOTE*(Str-炭/エスケープ)DQUOTE Str-炭=%のx20-21/%x23-5B/%x5D-7E / UCS高いEscapeが「\」と等しい、(/「t」; /「n」にタブを付けてください; ラインフィード/「r」と、リターン/DQUOTE; ダブルが引用する、/、「'、「;、単一の引用文/「\」)、;、」、' バックスラッシュ
Formal-name = 1*( Token SP ) / String URI = <defined as absolute-URI by RFC 2396> Language-tag = <defined by RFC 3066>
2396年のRFCによる絶対URIの>言語タグがRFC3066>によって定義された<と等しいときに、正式名は<が定義した1つの*(トークンSP)/ストリングURI=と等しいです。
; Any UCS character except CTLs, or escape
HEADERCHAR = UCS-no-CTL / Escape
; CTLs以外のどんなUCSキャラクタ、またはエスケープHEADERCHAR=、もUCSノーCTL、/エスケープ
Klyne & Atkins Standards Track [Page 14] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[14ページ]: メッセージ・フォーマット2004年8月
; Any US-ASCII char except ".", CTLs or SEPARATORS:
NAMECHAR = %x21 / %x23-27 / %x2a-2b / %x2d
/ %x5e-60 / %x7c / %x7e
/ ALPHA / DIGIT
; 「どんな米国-ASCII炭も除く」、」、CTLsか分離符: NAMECHAR=%x21/%x23-27/%x2a-2b/%x2d/%x5e-60/%x7c/%x7e/アルファ/ケタ
; Any UCS char except CTLs or SEPARATORS:
TOKENCHAR = NAMECHAR / "." / UCS-high
; CTLsかSEPARATORSを除いて、どんなUCSも焦げます: 「TOKENCHARはNAMECHAR/と等しい」、」 /UCS-高値
SEPARATORS = "(" / ")" / "<" / ">" / "@" ; 28/29/3c/3e/40
/ "," / ";" / ":" / "\" / DQUOTE ; 2c/3b/3a/5c/22
/ "/" / "[" / "]" / "?" / "=" ; 2f/5b/5d/3f/3d
/ "{" / "}" / SP ; 7b/7d/20
CTL = <Defined by RFC 2234 -- %x0-%x1f, %x7f>
CRLF = <Defined by RFC 2234 -- CR, LF>
SP = <defined by RFC 2234 -- %x20>
DIGIT = <defined by RFC 2234 -- '0'-'9'>
HEXDIG = <defined by RFC 2234 -- '0'-'9', 'A'-'F', 'a'-'f'>
ALPHA = <defined by RFC 2234 -- 'A'-'Z', 'a'-'z'>
DQUOTE = <defined by RFC 2234 -- %x22>
分離符は「(「/」)」/"<"/">"/"@"と等しいです。 」 "28/29/3c/3e/40 /"、/、」、;、」 / ":" /「\」/DQUOTE。 」 "2c/3b/3a/5c/22 /"//「[「/」]」/“?" / "=" ; 2f/5b/5d/3f/3d /、「「/」」 /SP。 7b/7d/20 CTL = <Defined by RFC 2234 -- %x0-%x1f, %x7f> CRLF = <Defined by RFC 2234 -- CR, LF> SP = <defined by RFC 2234 -- %x20> DIGIT = <defined by RFC 2234 -- '0'-'9'> HEXDIG = <defined by RFC 2234 -- '0'-'9', 'A'-'F', 'a'-'f'> ALPHA = <defined by RFC 2234 -- 'A'-'Z', 'a'-'z'> DQUOTE = <defined by RFC 2234 -- %x22>
To interpret the syntax in a general UCS character environment, use the following productions:
一般的なUCSキャラクタ環境における構文を解釈するには、以下の創作を使用してください:
UCS-no-CTL = %x20-7e / UCS-high UCS-high = %x80-7fffffff
UCSノーCTL、=%x20-7e / UCS高いUCS高い=%x80-7fffffff
To interpret the syntax as defining UTF-8 coded octet sequences, use the following productions:
UTF-8を定義すると八重奏系列がコード化されたので構文を解釈するには、以下の創作を使用してください:
UCS-no-CTL = UTF8-no-CTL
UCS-high = UTF8-multi
UTF8-no-CTL = %x20-7e / UTF8-multi
UTF8-multi = %xC0-DF %x80-BF
/ %xE0-EF %x80-BF %x80-BF
/ %xF0-F7 %x80-BF %x80-BF %x80-BF
/ %xF8-FB %x80-BF %x80-BF %x80-BF %x80-BF
/ %xFC-FD %x80-BF %x80-BF %x80-BF %x80-BF %x80-BF
UCSノーCTL、等しさ、UTF8、CTL UCS高値がない、=UTF8-マルチ、UTF8ノーCTL、等しさ、%x20-7e / UTF8、-、マルチUTF8-マルチ、=%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ソフトウェアとの互換性のために含まれています。 このメッセージ・フォーマットがSHOULDであると生成するアプリケーションがRFC3629[13]でさらに制限された仕様に合っているUTF-8を生成します。
Klyne & Atkins Standards Track [Page 15] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[15ページ]: メッセージ・フォーマット2004年8月
4. Header Definitions
4. ヘッダー定義
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).
この仕様はアプリケーションで1人の巻き癖の使用に手があいているヘッダーを定義します: アプリケーション仕様は使用されるかもしれないヘッダー、認識しなければならないもの、およびどんなメッセージにも現れなければならないものを示さなければなりません(セクション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) ここで対応する意味論で指定されたRFC2822[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<つぼ:ietf:paramsに関連しています: cpim-ヘッダー: >。([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用法はRFC2234[6]と異なっています。
4.1. The 'From' Header
4.1. 'From'ヘッダー
Indicates the sender of a message.
メッセージの送付者を示します。
Header name: From
ヘッダー名: from
Namespace URI:
<urn:ietf:params:cpim-headers:>
名前空間URI: <つぼ:ietf:params: cpimヘッダー:>。
Syntax:
(see also section 3.6)
構文: (また、セクション3.6を見ます)
From-header = "From" ": " [ Formal-name ] "<" URI ">"
; "From" is case-sensitive
「ヘッダーからの=“From"」: 「[正式名]"<"URI">"」。 "From"は大文字と小文字を区別しています。
Description:
Indicates the sender or originator of a message.
記述: メッセージの送付者か創始者を示します。
Klyne & Atkins Standards Track [Page 16] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[16ページ]: メッセージ・フォーマット2004年8月
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: くまのプーさんの<、不-、: pooh@100akerwood.com 、gt。
From: <im:tigger@100akerwood.com>
From: <、不-、: tigger@100akerwood.com 、gt。
4.2. The 'To' Header
4.2. 'To'ヘッダー
Specifies an intended recipient of a message.
メッセージの意図している受取人を指定します。
Header name: To
ヘッダー名: to
Namespace URI:
<urn:ietf:params:cpim-headers:>
名前空間URI: <つぼ:ietf:params: cpimヘッダー:>。
Syntax:
(see also section 3.6)
構文: (また、セクション3.6を見ます)
To-header = "To" ": " [ Formal-name ] "<" URI ">"
; "To" is case-sensitive
「ヘッダーへの=“To"」: 「[正式名]"<"URI">"」。 "To"は大文字と小文字を区別しています。
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.
複数の受取人は、複数の'To'ヘッダーを含んでいることによって、示されるかもしれません。
Examples:
例:
To: Winnie the Pooh <im:pooh@100akerwood.com>
To: くまのプーさんの<、不-、: pooh@100akerwood.com 、gt。
To: <im:tigger@100akerwood.com>
To: <、不-、: tigger@100akerwood.com 、gt。
Klyne & Atkins Standards Track [Page 17] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[17ページ]: メッセージ・フォーマット2004年8月
4.3. The 'cc' Header
4.3. 'cc'ヘッダー
Specifies a non-primary recipient ("courtesy copy") for a message.
非プライマリの受取人(「礼儀コピー」)をメッセージに指定します。
Header name: cc
ヘッダー名: cc
Namespace URI:
<urn:ietf:params:cpim-headers:>
名前空間URI: <つぼ:ietf:params: cpimヘッダー:>。
Syntax:
(see also section 3.6)
構文: (また、セクション3.6を見ます)
Cc-header = "cc" ": " [ Formal-name ] "<" URI ">"
; "cc" is case-sensitive
「ccヘッダーは「cc」と等しいです」: 「[正式名]"<"URI">"」。 「cc」は大文字と小文字を区別しています。
Description:
Indicates a courtesy copy recipient of a message.
記述: メッセージの礼儀写し受信者を示します。
If present, the 'Formal-name' identifies the person or "real
world" name for the recipient.
存在しているなら、'正式名'は受取人のために人か「本当の世界」名を特定します。
The URI indicates an address for the recipient.
URIは受取人のためにアドレスを示します。
Multiple courtesy copy recipients may be indicated by including
multiple 'cc' headers.
複数の礼儀写し受信者が、複数の'cc'ヘッダーを含んでいることによって、示されるかもしれません。
Examples:
例:
cc: Winnie the Pooh <im:pooh@100akerwood.com>
cc: くまのプーさんの<、不-、: pooh@100akerwood.com 、gt。
cc: <im:tigger@100akerwood.com>
cc: <、不-、: tigger@100akerwood.com 、gt。
4.4. The 'DateTime' Header
4.4. 'DateTime'ヘッダー
Specifies the date and time a message was sent.
メッセージが送られた日時を指定します。
Header name: DateTime
ヘッダー名: DateTime
Namespace URI:
<urn:ietf:params:cpim-headers:>
名前空間URI: <つぼ:ietf:params: cpimヘッダー:>。
Syntax:
(see also section 3.6)
構文: (また、セクション3.6を見ます)
DateTime-header = "DateTime" ": " date-time
; "DateTime" is case-sensitive
「DateTime-ヘッダーは"DateTime"と等しいです」: 「日付-時間」。 "DateTime"は大文字と小文字を区別しています。
Klyne & Atkins Standards Track [Page 18] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[18ページ]: メッセージ・フォーマット2004年8月
(where the syntax of 'date-time' is a profile of ISO8601 [24]
defined in "Date and Time on the Internet" [11])
('日付-時間'の構文は「インターネットの日時」[11])で定義されたISO8601[24]のプロフィールです。
Description:
The 'DateTime' header supplies the date and time at which the
sender sent the message.
記述: 'DateTime'ヘッダーは送付者がメッセージを送った日時を供給します。
One purpose of the this header is to provide for protection
against a replay attack, by allowing the recipient to know when
the message was intended to be sent. The value of the date header
is the senders's current time when the message was transmitted,
using ISO 8601 [24] date and time format as profiled in "Date and
Time on the Internet: Timestamps" [11].
1つの目的、このヘッダーは反射攻撃に対する保護に備えることになっています、受取人が、いつメッセージが送られることを意図したかを知っているのを許容することによって。 日付のヘッダーの値はメッセージが送られた送付者sの現在の時間です、8601年のISO[24]日付と中で輪郭を描かれる形式が「インターネットで以下の日付を入れて、調節する」時を費やして 「タイムスタンプ。」[11]
Example:
例:
DateTime: 2001-02-01T12:16:49-05:00
DateTime: 2001-02-01T12: 16時49分から5時0分
4.5. The 'Subject' Header
4.5. '受けることがある'ヘッダー
Contains a description of the topic of the message.
メッセージの話題の記述を含んでいます。
Header name: Subject
ヘッダー名: 対象
Namespace URI:
<urn:ietf:params:cpim-headers:>
名前空間URI: <つぼ:ietf:params: cpimヘッダー:>。
Syntax:
(see also section 3.6)
構文: (また、セクション3.6を見ます)
Subject-header = "Subject" ":" [ ";" Lang-param ] SP *HEADERCHAR
; "Subject" is case-sensitive
「受けることがあるヘッダー=「対象」」:、」 [「; 」 ラング-param] SP*HEADERCHAR。 「対象」は大文字と小文字を区別しています。
Description:
The 'Subject' header supplies the sender's description of the
topic or content of the message.
記述: '受けることがある'ヘッダーは送付者の話題の記述かメッセージの内容を提供します。
The sending agent should specify the language parameter if it has
any reasonable knowledge of the language used by the sender to
indicate the message subject.
送付者がメッセージ対象を示すのにそれで言語に関するどんな妥当な知識も使用するなら、送付エージェントは言語パラメタを指定するべきです。
Example:
例:
Subject:;lang=en Eeyore's feeling very depressed today
Subject:; lang=アンEeyoreは今日、非常に不景気であると感じること。
Klyne & Atkins Standards Track [Page 19] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[19ページ]: メッセージ・フォーマット2004年8月
4.6. The 'NS' Header
4.6. 'ナノ秒'ヘッダー
Declare a local namespace prefix.
ローカルの名前空間接頭語を宣言してください。
Header name: NS
ヘッダー名: ナノ秒
Namespace URI:
<urn:ietf:params:cpim-headers:>
名前空間URI: <つぼ:ietf:params: cpimヘッダー:>。
Syntax:
(see also section 3.6)
構文: (また、セクション3.6を見ます)
NS-header = "NS" ": " [ Name-prefix ] "<" URI ">"
; "NS" is case-sensitive
「ナノ秒ヘッダー=「ナノ秒」」: 「[名前接頭語]"<"URI">"」。 「NS」は大文字と小文字を区別しています。
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
ナノ秒: MyAlias<中間:、 MessageFeatures@id.foo.com 、gt;、MyAlias.MyHeader: 個人的な拡大データ
4.7. The 'Require' Header
4.7. '必要'ヘッダー
Specify a header or feature that must be implemented by the receiver for correct message processing.
正しいメッセージ処理のために受信機で実装しなければならないヘッダーか特徴を指定してください。
Header name: Require
ヘッダー名: 必要です。
Namespace URI:
<urn:ietf:params:cpim-headers:>
名前空間URI: <つぼ:ietf:params: cpimヘッダー:>。
Syntax:
(see also section 3.6)
構文: (また、セクション3.6を見ます)
Require-header = "Require" ": " Header-name *( "," Header-name )
; "Require" is case-sensitive
「「必要=」」: 「ヘッダー名の*、(「」 ヘッダー名、)、」、。 「必要」は大文字と小文字を区別しています。
Description:
Indicates a header or feature that must be implemented or
understood by the receiver for correct message processing. See
section 3.5 for more details.
記述: 正しいメッセージ処理のために受信機に実装されなければならないか、または解釈しなければならないヘッダーか特徴を示します。 その他の詳細に関してセクション3.5を見てください。
Klyne & Atkins Standards Track [Page 20] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[20ページ]: メッセージ・フォーマット2004年8月
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
5. Examples
5. 例
The examples in the following sections use the per-line tags below to indicate different parts of the overall message format:
以下のセクションの例は総合的なメッセージ・フォーマットの異なった一部分を示すのに以下の1系列あたりのタグを使用します:
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: 総合的なメッセージsのためのMIMEヘッダー: 空白の区切り線h: メッセージヘッダーe: メッセージ内容xを含むカプセル化されたMIMEオブジェクト: MIMEのセキュリティの複合メッセージラッパー
The following examples also assume <urn:ietf:params:cpim-headers:> is the implied default namespace for the application.
また、以下の例は<つぼ:ietf:params: cpimヘッダーを仮定します:>はアプリケーションのための暗示しているデフォルト名前空間です。
5.1. An Example Message/CPIM Message
5.1. 例のメッセージ/CPIMメッセージ
The following example shows a Message/CPIM message:
以下の例はMessage/CPIMメッセージを示しています:
m: Content-type: Message/CPIM
s:
h: From: MR SANDERS <im:piglet@100akerwood.com>
h: To: Depressed Donkey <im:eeyore@100akerwood.com>
h: DateTime: 2000-12-13T13:40:00-08:00
h: Subject: the weather will be fine today
h: Subject:;lang=fr beau temps prevu pour aujourd'hui
h: NS: MyFeatures <mid:MessageFeatures@id.foo.com>
h: Require: MyFeatures.VitalMessageOption
h: MyFeatures.VitalMessageOption: Confirmation-requested
h: MyFeatures.WackyMessageOption: Use-silly-font
s:
e: Content-type: text/xml; charset=utf-8
e: Content-ID: <1234567890@foo.com>
e:
e: <body>
e: Here is the text of my message.
e: </body>
m: 文書内容: メッセージ/CPIM s: h: From: MR SANDERS<、不-、: piglet@100akerwood.com 、gt;、h: To: 不景気なDonkey<、不-、: eeyore@100akerwood.com 、gt;、h: DateTime: 2000-12-13 T13: 40:00-08:00時間: Subject: 天気は晴れた今日になるでしょうh: Subject:; lang=frしゃれ者タンprevuはaujourd'hui hを注ぎます: ナノ秒: MyFeatures<中間:、 MessageFeatures@id.foo.com 、gt;、h: 必要です: MyFeatures.VitalMessageOption h: MyFeatures.VitalMessageOption: hを確認して要求します: MyFeatures.WackyMessageOption: 使用愚かなフォントs: e: 文書内容: テキスト/xml。 charset=utf-8 e: コンテントID: <1234567890@foo.com>e: e: <ボディー>e: ここ. 私のメッセージのテキストはeです: </ボディー>。
Klyne & Atkins Standards Track [Page 21] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[21ページ]: メッセージ・フォーマット2004年8月
5.2. An Example Esing MIME multipart/signed
5.2. 複合/が署名したExample Esing MIME
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.
アプリケーションか実装が、Message/CPIMを固定するのにRFC1847[14]、およびいくつかの適切なセキュリティプロトコルを使用するかもしれません。(例えば、S/MIME[19]かopenPGP[17])と、暗合方式。
Using S/MIME [19] and pkcs7, the above message would look like this:
S/MIMEの[19]とpkcs7を使用して、上記のメッセージはこれに似ているでしょう:
x: Content-Type: multipart/signed; boundary=next;
micalg=sha1;
protocol=application/pkcs7-signature
x:
x: --next
m: Content-Type: Message/CPIM
s:
h: From: MR SANDERS <im:piglet@100akerwood.com>
h: To: Dopey Donkey <im:eeyore@100akerwood.com>
h: DateTime: 2000-12-13T13:40:00-08:00
h: Subject: the weather will be fine today
h: Subject:;lang=fr beau temps prevu pour aujourd'hui
h: NS: MyFeatures <mid:MessageFeatures@id.foo.com>
h: Require: MyFeatures.VitalMessageOption
h: MyFeatures.VitalMessageOption: Confirmation-requested
h: MyFeatures.WackyMessageOption: Use-silly-font
s:
e: Content-type: text/xml; charset=utf-8
e: Content-ID: <1234567890@foo.com>
e:
e: <body>
e: Here is the text of my message.
e: </body>
x: --next
x: Content-Type: application/pkcs7-signature
x:
x: (signature stuff)
:
x: --next--
x: コンテントタイプ: 複合か署名される。 次の境界=。 micalg=sha1。 =pkcs7アプリケーション/署名xについて議定書の中で述べてください: x: --次のm: コンテントタイプ: メッセージ/CPIM s: h: From: MR SANDERS<、不-、: piglet@100akerwood.com 、gt;、h: To: 麻酔にかかっているDonkey<、不-、: eeyore@100akerwood.com 、gt;、h: DateTime: 2000-12-13 T13: 40:00-08:00時間: Subject: 天気は晴れた今日になるでしょうh: Subject:; lang=frしゃれ者タンprevuはaujourd'hui hを注ぎます: ナノ秒: MyFeatures<中間:、 MessageFeatures@id.foo.com 、gt;、h: 必要です: MyFeatures.VitalMessageOption h: MyFeatures.VitalMessageOption: hを確認して要求します: MyFeatures.WackyMessageOption: 使用愚かなフォントs: e: 文書内容: テキスト/xml。 charset=utf-8 e: コンテントID: <1234567890@foo.com>e: e: <ボディー>e: ここ. 私のメッセージのテキストはeです: </ボディー>x: --次のx: コンテントタイプ: pkcs7アプリケーション/署名x: x: (署名もの) : x: --次--
6. Application Design Considerations
6. アプリケーション設計問題
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'content typeは定義されるようにデフォルト名前空間URIを使用します。'つぼ: ietf: params-cpim-ヘッダー: 'いかなる他の暗黙の名前空間接頭語も定義しません。 異なった要件がメディアの一部と異なったMIMEメディアタイプを定義して、示すべきであり、必要なデフォルト名前空間URIを指定して、どんな暗示している名前空間接頭語も定義するのをさせるアプリケーションが、仕様をタイプします。
Klyne & Atkins Standards Track [Page 22] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[22ページ]: メッセージ・フォーマット2004年8月
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 メッセージで一度より多く見えるかもしれないどんなヘッダー、および彼らが解釈されることになっている(例えば、どのように異なった言語パラメタ値がある複数の'Subject:'ヘッダーを解釈しますか)方法。
o Security mechanisms and crytography schemes to be used with the
application, including any mandatory-to-implement security
provisions.
o どんな実装するために義務的なセキュリティ条項も含むアプリケーションと共に使用されるべきセキュリティー対策とcrytography体系。
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 メッセージ転送エージェントのネットワークの中では、中間ゲートウェイは何らかの方法でMessage/CPIM内容を変えてはいけません。 これはヘッダーを変えることができませんし、再命令できないで、転送コード化を変えることができないで、言語を変えることができないのなどを含意します。
o Because Message/CPIM messages are immutable, any transfer agent
that wants to modify the message should create a new Message/CPIM
message with the modified header and with the original message as
its content. (This approach is similar to real-world bill-of-
lading handling, where each person in the chain attaches a new
sheet to the message. Then anyone can validate the original
message and see what has changed and who changed it by following
the trail of amendments. Another metaphor is including the old
message in a new envelope.)
o Message/CPIMメッセージが不変であるので、メッセージを変更したがっているどんな証券代行も内容として変更されたヘッダーとオリジナルのメッセージで新しいMessage/CPIMメッセージを作成するべきです。 (このアプローチが本当の世界請求書と同様である、-、チェーンの各人が積載取り扱い新しいシートをメッセージに取り付けるところで。 次に、だれでも、修正の道に続くことによって、オリジナルのメッセージを有効にして、何が変化するか、そして、だれがそれを変えたかを見ることができます。 別の比喩は新しい封筒に古いメッセージを含んでいることです。)
In chosing security mechanisms for an applications, the following IAB survey documents may be helpful:
アプリケーションのためにセキュリティー対策をchosingするのにおいて、以下のIAB調査ドキュメントは有用であるかもしれません:
o Security Mechanisms for the Internet [28]
o インターネットへのセキュリティー対策[28]
o A Survey of Authentication Mechanisms [29].
o 認証機構[29]の調査。
7. IANA Considerations
7. IANA問題
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 新しいMIME content type価値、RFC2048[3]あたりのMessage/CPIM。 下のセクション7.1で登録テンプレートを見つけることができます。
Klyne & Atkins Standards Track [Page 23] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[23ページ]: メッセージ・フォーマット2004年8月
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 つぼ:ietf:params: 新しいIANA URNサブ名前空間、cpimヘッダー:、RFC3553[12]単位で。 下のセクション7.2で登録テンプレートを見つけることができます。
7.1. Registration for Message/CPIM Content Type
7.1. メッセージ/CPIM content typeのための登録
To: ietf-types@iana.org
To: ietf-types@iana.org
Subject: Registration of MIME media type Message/CPIM
Subject: MIMEメディアタイプMessage/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ビットか2進です、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.
適切な転送コード化が使用されているなら、このcontent typeは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]).
また、メールメッセージに関してセキュリティ問題を見てください。(RFC2822[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
広められた仕様: RFC3862
Applications which use this media type: Instant messaging
このメディアタイプを使用するアプリケーション: インスタントメッセージング
Klyne & Atkins Standards Track [Page 24] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[24ページ]: メッセージ・フォーマット2004年8月
Additional information:
The default namespace URI associated with this content-type is
'urn:ietf:params:cpim-headers:'. (See RFC 3862 for further
details.)
追加情報: デフォルト名前空間URIは交際しました。このcontent typeと共に、'つぼ:ietf:params: cpimヘッダーがあります:、' (さらに詳しい明細についてはRFC3862を見てください。)
See also the Common Profile for Instant Messaging (CPIM) [26].
また、Instant Messaging(CPIM)[26]のためにCommon Profileを見てください。
Person & email address to contact for further information:
G. Klyne, <GK-IETF@ninebynine.org>
詳細のために連絡する人とEメールアドレス: G。 Klyne、 <GK-IETF@ninebynine.org 、gt。
Intended usage: LIMITED USE
意図している用法: 限られた使用
Author/Change controller: IETF
コントローラを書くか、または変えてください: IETF
7.2. Registration for urn:ietf:params:cpim-headers
7.2. つぼ:ietf:paramsのための登録: cpim-ヘッダー
Registry name: cpim-headers
登録名: cpim-ヘッダー
Specification:
RFC 3862. Additional values may be defined by standards track
RFCs that update or obsolete RFC 3862.
仕様: RFC3862。 加算値はRFC3862をアップデートするか、または時代遅れにする標準化過程RFCsによって定義されるかもしれません。
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メッセージヘッダー名です、上で定義されるように。(それは、制限されたセットの米国-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
'a)がどんな非URNキャラクタも取り替える、(対応する'%hh'エスケープシーケンスがあるRFC2141[5])によって定義される、(RFC2396[8])単位で。 そして
b) prepending the resulting string with 'urn:ietf:params:cpim-
headers:'.
'つぼ:ietf:paramsで結果として起こるストリングをprependingするb): cpimヘッダー:、'
Thus, the URI corresponding to the CPIM message header 'From:'
would be 'urn:ietf:params:cpim-headers:From'. The URI
corresponding to the (putative) CPIM message header 'Top&Tail'
would be 'urn:ietf:params:cpim-headers:Top%26Tail'.
その結果、ヘッダー'From:'が'つぼ:ietf:paramsであるだろうというCPIMメッセージに対応するURI: cpim-ヘッダー:、' ''つぼ:ietf:params: cpim-ヘッダー: 最高%は26Tailだったでしょう'なら(推定)のCPIMメッセージヘッダーの'の先端とTailに対応するURI。
Klyne & Atkins Standards Track [Page 25] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[25ページ]: メッセージ・フォーマット2004年8月
8. Internationalization Considerations
8. 国際化問題
Message headers use UTF-8 character encoding throughout; hence, they can convey the full UCS-4 (Unicode [30], ISO/IEC 10646 [25]) character repertoire.
ヘッダーがUTF-8文字符号化を使用するメッセージ。 したがって、彼らは完全UCS-4を運ぶことができます。(ユニコード[30]、ISO/IEC10646[25])キャラクタレパートリー。
Language tagging is provided for message headers using the "Lang" parameter (section 3.3).
「ラング」パラメタ(セクション3.3)を使用することで言語タグ付けをメッセージヘッダーに提供します。
Message content is any MIME-encapsulated content, and normal MIME content internationalization considerations apply.
メッセージ内容はあらゆるMIMEでカプセル化された内容です、そして、MIMEの正常な内容国際化問題は適用されます。
9. Security Considerations
9. セキュリティ問題
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.
Message/CPIM形式はセキュリティで念頭に設計されています。 特に、それは、署名と暗号化に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.
Message/CPIMメッセージが2進のメッセージ(UTF-8コード化による)であるので、それらが非8に清潔な状態で噛み付いている輸送の向こう側に伝えられるなら、証券代行は全体のメッセージにトンネルを堀らなければなりません。 メッセージzデータの符号化を変えるのは、オプションではありません。 これは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.
結果として起こるメッセージには、メッセージのコード化と非コード化によるデータの損失があってはいけません。 例えば、アプリケーションは、この必要条件を満たすためにMIMEのbase64の満足している転送コード化をMessage/CPIM物に適用するのを選ぶかもしれません。
10. Acknowledgements
10. 承認
The authors thank the following for their helpful comments: Harald Alvestrand, Walter Houser, Leslie Daigle, Mark Day, Brian Raymor.
作者が感謝する、彼らの役に立つコメントのための以下: ブライアンRaymor、ハラルドAlvestrand(ウォルター・ハウザー、レスリーDaigle)は日をマークします。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
解放された[1]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[2]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
Klyne & Atkins Standards Track [Page 26] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[26ページ]: メッセージ・フォーマット2004年8月
[3] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet
Mail Extensions (MIME) Part Four: Registration Procedures", BCP
13, RFC 2048, November 1996.
解放された[3]、N.、Klensin、J.、およびJ.ポステル、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、BCP13、RFC2048、1996年11月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[5] Moats, R., "URN Syntax", RFC 2141, May 1997.
[5]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[6] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[6] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[7] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[7]Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.
[8]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、RFC2396、1998年8月。
[9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[10] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[10]、BCP47、RFC3066、2001年1月。
[11] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[11] Klyne(G.とC.ニューマン)は「インターネットで以下の日付を入れて、調節します」。 「タイムスタンプ」、RFC3339、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] 食事、M.、Masinter、L.、ハーディー、T.、およびG.Klyne、「登録されたプロトコルパラメタのためのサブ名前空間のIETFつぼ」、BCP73、RFC3553(2003年6月)。
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[13]Yergeau、F.、「UTF-8、ISO10646インチ、STD63、RFC3629、11月2003日の変化形式
11.2. Informative References
11.2. 有益な参照
[14] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted",
RFC 1847, October 1995.
[14] ガルビン、J.、マーフィー、S.、クロッカー、S.、および解放されたN.、「MIMEのためのセキュリティMultiparts:」 「サインされて複合の/がコード化した複合/」、RFC1847、1995年10月。
[15] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson,
R., Crispin, M., and P. Svanberg, "The Report of the IAB
Character Set Workshop held 29 February - 1 March, 1996", RFC
2130, April 1997.
[15] ワイダー、C.、プレストン、C.、シモンセン、K.、Alvestrand、H.、アトキンソン、R.、クリスピン、M.、およびP.スバンベルク、「IAB文字コードWorkshopのReportは2月29日に成立しました--1996年3月1日」、RFC2130、1997年4月。
[16] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word
Extensions: Character Sets, Languages, and Continuations", RFC
2231, November 1997.
解放された[16]、N.、およびK.ムーア、「パラメタ値をまねてください、そして、コード化されて、拡大を言い表してください」 「文字コード、言語、および続刊」、RFC2231、11月1997日
Klyne & Atkins Standards Track [Page 27] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[27ページ]: メッセージ・フォーマット2004年8月
[17] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP
Message Format", RFC 2440, November 1998.
[17] カラスとJ.とDonnerhackeとL.とフィニー、H.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC2440、1998年11月。
[18] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[18] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[19] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC
2633, June 1999.
[19]Ramsdell、B.、エド、「S/MIMEバージョン3メッセージ仕様」、RFC2633、6月1999日
[20] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
Messaging / Presence Protocol Requirements", RFC 2779, February
2000.
[20] 日、M.とAggarwalとS.とモーア、G.とJ.ヴィンセント、「インスタントメッセージング/存在プロトコル要件」、RFC2779、2000年2月。
[21] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[21] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[22] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
Recommendation xml, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>.
[22] T.、パオリ、J.、Sperberg-マックィーン、C.、およびE.Maler、「拡張マークアップ言語(XML)1.0(2番目の教育)」をいななかせてください、W3C Recommendation xml、2000年10月、<http://www.w3.org/TR/2000/REC-xml-20001006>。
[23] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C
Recommendation xml-names, January 1999,
<http://www.w3.org/TR/REC-xml-names>.
[23] ロバの鳴き声、T.、オランダ人、D.、およびA.Layman、「XMLの名前空間」が1999年1月に<http://www.w3.org/TR/REC-xml名を>にW3C Recommendation xml挙げます。
[24] International Organization for Standardization, "Data elements
and interchange formats - Information interchange -
Representation of dates and times", ISO Standard 8601, June
1988.
[24] 国際標準化機構、「データ要素と置き換え形式--情報交換--日付と回の表現」、ISO Standard8601(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] 国際標準化機構、「情報Technology--普遍的なMultiple-八重奏コード化された文字コード(UCS)--第1部:、」 「構造と基本多言語水準」(ISO規格10646-1)は1993がそうするかもしれません。
[26] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC
3860, August 2004.
[26] ピーターソン、J.、「インスタントメッセージング(CPIM)のための一般的なプロフィール」、RFC3860、2004年8月。
[27] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
August 2004.
[27] ピーターソン、J.、「存在(CPP)のための一般的なプロフィール」、RFC3859、2004年8月。
[28] Bellovin, S., Kaufman, C., and J. Schiller, "Security Mechanisms
for the Internet", RFC 3631, December 2003.
2003年12月の[28]BellovinとS.とコーフマン、C.とJ.シラー、「インターネットへのセキュリティー対策」RFC3631。
[29] Rescorla, E., "A Survey of Authentication Mechanisms", Work in
Progress, March 2004.
[29] レスコラ、E.、「認証機構の調査」が進歩、2004年3月に働いています。
Klyne & Atkins Standards Track [Page 28] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[28ページ]: メッセージ・フォーマット2004年8月
[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] ユニコード共同体、「ユニコード規格、バージョン4インチ、アディソン-ウエスリー、ボストン、MA。」 ISBN0-321-18578-1 2003年4月の<http://www.unicode.org/ユニコード/標準の/バージョン/enumeratedversions.html#ユニコード_4_0_0>。
12. Authors' Addresses
12. 作者のアドレス
Graham Klyne Nine by Nine
グラハムKlyne9時9分前
EMail: GK-IETF@ninebynine.org URI: http://www.ninebynine.net/
メール: GK-IETF@ninebynine.org ユリ: http://www.ninebynine.net/
Derek Atkins IHTFP Consulting 6 Farragut Ave Somerville, MA 02144 USA
デリックアトキンスIHTFP Consulting6ファラガット・Ave MA02144サマービル(米国)
Phone: +1 617 623 3745 EMail: derek@ihtfp.com, warlord@alum.mit.edu
以下に電話をしてください。 +1 3745年の617 623メール: derek@ihtfp.com 、将軍@alum.mit.edu
Klyne & Atkins Standards Track [Page 29] RFC 3862 CPIM: Message Format August 2004
KlyneとアトキンスStandardsはRFC3862CPIMを追跡します[29ページ]: メッセージ・フォーマット2004年8月
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Klyne & Atkins Standards Track [Page 30]
Klyneとアトキンス標準化過程[30ページ]
一覧
スポンサーリンク
