[要約] RFC 3297は、電子メールを基にしたメッセージングサービスのためのコンテンツネゴシエーションに関する規格です。このRFCの目的は、メッセージングサービス間でのコンテンツの適切な交換を可能にするための標準化とガイドラインの提供です。
Network Working Group G. Klyne
Request for Comments: 3297 Clearswift Corporation
Category: Standards Track R. Iwazaki
Toshiba TEC
D. Crocker
Brandenburg InternetWorking
July 2002
Content Negotiation for Messaging Services based on Email
電子メールに基づくメッセージングサービスのコンテンツネゴシエーション
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet email.
このメモは、インターネット電子メールを使用するファクシミリ、音声、その他のメッセージングサービスのコンテンツネゴシエーションメカニズムについて説明しています。
Services such as facsimile and voice messaging need to cope with new message content formats, yet need to ensure that the content of any given message is renderable by the receiving agent. The mechanism described here aims to meet these needs in a fashion that is fully compatible with the current behaviour and expectations of Internet email.
ファクシミリや音声メッセージなどのサービスは、新しいメッセージコンテンツ形式に対処する必要がありますが、特定のメッセージのコンテンツが受信エージェントによってレンダリング可能であることを確認する必要があります。ここで説明するメカニズムは、インターネットメールの現在の動作と期待と完全に互換性のある方法でこれらのニーズを満たすことを目的としています。
Table of Contents
目次
1. Introduction................................................... 3
1.1 Structure of this document ................................. 4
1.2 Document terminology and conventions ....................... 4
1.2.1 Terminology............................................ 4
1.2.2 Design goals........................................... 5
1.2.3 Other document conventions............................. 5
2. Background and goals........................................... 5
2.1 Background ................................................. 5
2.1.1 Fax and email.......................................... 5
2.1.2 Current facilities in Internet Fax..................... 6
2.2 Closing the loop ........................................... 6
2.3 Goals for content negotiation .............................. 8
3. Framework for content negotiation..............................10
3.1 Send data with an indication of alternatives ...............11
3.1.1 Choice of default data format..........................12
3.1.2 MDN request indicating alternate data formats..........12
3.1.3 Information about alternative data formats.............13
3.2 Receiver options ...........................................14
3.2.1 Alternatives not recognized............................14
3.2.2 Alternative not desired................................14
3.2.3 Alternative preferred..................................14
3.3 Send alternative message data ..............................16
3.4 Confirm receipt of resent message data .....................17
4. The Content-alternative header.................................18
5. The Original-Message-ID message header.........................18
6. MDN extension for alternative data.............................19
6.1 Indicating readiness to send alternative data ..............19
6.2 Indicating a preference for alternative data ...............20
6.3 Indicating alternative data is no longer available .........21
6.4 Indicating loss of original data ...........................22
6.5 Automatic sending of MDN responses .........................22
7. Internet Fax Considerations....................................22
8. Examples.......................................................23
8.1 Sending enhanced Internet Fax image ........................23
8.2 Internet fax with initial data usable ......................27
8.3 Negotiate to lower receiver capability .....................28
8.4 Sending an alternative content type ........................32
9. IANA Considerations............................................36
9.1 New message headers ........................................36
9.2 MDN extensions .............................................36
9.2.1 Notification option 'Alternative-available'............36
9.2.2 Notification option 'Alternative-not-available'........36
9.2.3 Disposition modifier 'Alternative-preferred'...........37
9.2.4 Disposition modifier 'Original-lost'...................37
10. Internationalization considerations...........................37
11. Security Considerations.......................................37
12. Acknowledgements..............................................38
13. References....................................................38
Appendix A: Implementation issues.................................40
A.1 Receiver state .............................................40
A.2 Receiver buffering of message data .........................41
A.3 Sender state ...............................................42
A.4 Timeout of offer of alternatives ...........................42
A.5 Timeout of receiver capabilities ...........................42
A.6 Relationship to timely delivery ............................43
A.7 Ephemeral capabilities .....................................43
A.8 Situations where MDNs must not be auto-generated ...........44
Appendix B: Candidates for further enhancements...................44
Authors' Addresses................................................45
Full Copyright Statement..........................................46
This memo describes a mechanism for email based content negotiation which provides an Internet fax facility comparable to that of traditional facsimile, which may be used by other messaging services that need similar facilities.
このメモは、電子メールベースのコンテンツネゴシエーションのメカニズムについて説明します。これは、従来のファクシミリに匹敵するインターネットファックス機能に匹敵するインターネットファックス機能を提供します。
"Extended Facsimile using Internet Mail" [1] specifies the transfer of image data using Internet email protocols. "Indicating Supported Media Features Using Extensions to DSN and MDN" [2] describes a mechanism for providing the sender with the details of a receiver's capabilities. The capability information thus provided, if stored by the sender, can be used in subsequent transfers between the same sender and receiver.
「インターネットメールを使用した拡張ファクシミリ」[1]は、インターネットメールプロトコルを使用して画像データの転送を指定します。「DSNとMDNへの拡張機能を使用してサポートされているメディア機能を示す」[2]は、受信者の機能の詳細を送信者に提供するメカニズムを説明しています。このように提供された機能情報は、送信者によって保存されている場合、同じ送信者と受信機の間の後続の転送で使用できます。
Many communications are one-off or infrequent transfers between a given sender and receiver, and cannot benefit from this "do better next time" approach.
多くの通信は、特定の送信者と受信機の間の1回限りまたはまれな転送であり、この「次の時間をやる」アプローチから利益を得ることができません。
An alternative facility available in email (though not widely implemented) is for the sender to use 'multipart/alternative' [15] to send a message in several different formats, and allow the receiver to choose. Apart from the obvious drawback of network bandwidth use, this approach does not of itself allow the sender to truly tailor its message to a given receiver, or to obtain confirmation that any of the alternatives sent was usable by the receiver.
電子メールで利用可能な代替機能（広く実装されていませんが）は、送信者が「MultiPart/Alternative」[15]を使用して、いくつかの異なる形式でメッセージを送信し、受信機を選択できるようにすることです。ネットワーク帯域幅の使用の明らかな欠点とは別に、このアプローチ自体は、送信者が特定のレシーバーにメッセージを真に調整したり、送信された代替案のいずれかが受信機によって使用可能であることの確認を取得することを許可することはできません。
This memo describes a mechanism that allows better-than-baseline data formats to be sent in the first communication between a sender and receiver. The same mechanism can also achieve a usable message transfer when the sender has based the initial transmission on incorrect information about the receiver's capabilities. It allows the sender of a message to indicate availability of alternative formats, and the receiver to indicate that an alternative format should be provided to replace the message data originally transmitted.
このメモは、送信者と受信機の間の最初の通信でベースラインよりも優れたデータ形式を送信できるメカニズムを説明しています。同じメカニズムは、送信者が最初の送信を受信機の機能に関する誤った情報に基づいている場合に使用可能なメッセージ転送を実現することもできます。これにより、メッセージの送信者が代替形式の可用性を示すことができ、受信者は、最初に送信されたメッセージデータを置き換えるために代替形式を提供する必要があることを示します。
When the sender does not have the correct information about a receiver's capabilities, the mechanism described here may incur an additional message round trip. An important goal of this mechanism is to allow enough information to be provided to determine whether or not the extra round trip is required.
送信者が受信者の機能に関する正しい情報を持っていない場合、ここで説明するメカニズムには追加のメッセージが発生する可能性があります。このメカニズムの重要な目標は、余分な往復が必要かどうかを判断するのに十分な情報を提供できるようにすることです。
The main part of this memo addresses the following areas:
このメモの主要な部分は、次の領域に対応しています。
Section 2 describes some of the background, and sets out some specific goals that are addressed in this specification.
セクション2では、背景の一部について説明し、この仕様で対処されている特定の目標を設定します。
Section 3 describes the proposed content negotiation framework, indicating the flow of information between a sender and receiver.
セクション3では、提案されたコンテンツネゴシエーションフレームワークについて説明し、送信者と受信機の間の情報の流れを示します。
Section 4 contains a detailed description of the 'Content-alternative' header that is used to convey information about alternative available formats. This description is intended to stand independently of the rest of this specification, with a view to being usable in conjunction with other content negotiation protocols.
セクション4には、代替利用可能な形式に関する情報を伝えるために使用される「コンテンツ代替」ヘッダーの詳細な説明が含まれています。この説明は、他のコンテンツネゴシエーションプロトコルと組み合わせて使用可能であることを考慮して、この仕様の残りの部分とは独立して立つことを目的としています。
Section 5 describes a new mail message header, 'Original-Message-ID', which is used to correlate alternative data sent during negotiation with the original message data, and to distinguish the continuation of an old message transaction from the start of a new transaction.
セクション5では、交渉中に送信された代替データを元のメッセージデータと相関させ、新しいトランザクションの開始からの古いメッセージトランザクションの継続を区別するために使用される新しいメールメッセージヘッダー「Original-Message-ID」について説明します。。
Section 6 describes extensions to the Message Disposition Notification (MDN) framework [4] that support negotiation between the communicating parties.
セクション6では、通信当事者間の交渉をサポートするメッセージ処分通知（MDN）フレームワーク[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 RFC 2119 [22].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [22]に記載されているように解釈される。
Capability exchange An exchange of information between communicating parties indicating the kinds of information they can generate or consume.
能力交換通信当事者間の情報交換は、生成または消費できる情報の種類を示すものです。
Capability identification Provision of information by the a receiving agent that indicates the kinds of message data that it can accept for presentation to a user.
ユーザーへのプレゼンテーションに受け入れることができるメッセージデータの種類を示す、受信エージェントによる情報の能力識別の提供。
Content negotiation An exchange of information (negotiation metadata) which leads to selection of the appropriate representation (variant) when transferring a data resource.
コンテンツ交渉データリソースの転送時に適切な表現（バリアント）の選択につながる情報交換（交渉メタデータ）。
Message transaction
メッセージトランザクション
A sequence of exchanges between a message sender and receiver that accomplish the transfer of message data.
メッセージデータの転送を達成するメッセージ送信者と受信機の間の交換のシーケンス。
RFC 2703 [17] introduces several other terms related to content negotiation.
RFC 2703 [17]は、コンテンツの交渉に関連するいくつかの他の用語を導入します。
In discussing the goals for content negotiation, {1}, {2}, {3} notation is used, per RFC 2542, "Terminology and Goals for Internet Fax" [3]. The meanings associated with these notations are:
コンテンツネゴシエーションの目標について議論する際に、{1}、{2}、{3}表記が使用され、RFC 2542、「インターネットFAXの用語と目標」[3]。これらの表記に関連する意味は次のとおりです。
{1} there is general agreement that this is a critical characteristic of any definition of content negotiation for Internet Fax.
{1}これは、インターネットファックスのコンテンツネゴシエーションの定義の重要な特性であるという一般的な合意があります。
{2} most believe that this is an important characteristic of content negotiation for Internet Fax.
{2}これは、インターネットファックスのコンテンツ交渉の重要な特徴であるとほとんど信じています。
{3} there is general belief that this is a useful feature of content negotiation for Internet Fax, but that other factors might override; a definition that does not provide this element is acceptable.
{3}これはインターネットファックスのコンテンツネゴシエーションの有用な機能であるが、他の要因が無効になる可能性があるという一般的な信念があります。この要素を提供しない定義は受け入れられます。
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.
注：このようなコメントは、このドキュメントの背後にある根拠に関する追加の非必須情報を提供します。このような情報は、適切な実装を構築するために必要ではありませんが、設計をより深く理解したい人を助けるかもしれません。
One of the goals of the work to define a facsimile service using Internet mail has been to deliver benefits of the traditional Group 3 Fax service in an email environment. Traditional Group 3 Fax leans heavily on the idea that an online exchange of information discloses a receiver's capabilities to the sender before any message data is transmitted.
インターネットメールを使用してファクシミリサービスを定義する作業の目標の1つは、電子メール環境で従来のグループ3ファックスサービスの利点を提供することです。従来のグループ3 FAXは、メッセージデータが送信される前に、オンライン情報交換が受信者の機能を送信者に開示するという考えに大きく傾いています。
By contrast, Internet mail has been developed to operate in a different fashion, without any expectation that the sender and receiver will exchange information prior to message transfer. One consequence of this is that all mail messages must contain some kind of meaningful message data: messages that are sent simply to elicit information from a receiving message handling agent are not generally acceptable in the Internet mail environment.
対照的に、送信者と受信者がメッセージ転送の前に情報を交換することを期待することなく、インターネットメールが別の方法で動作するように開発されました。これの結果の1つは、すべてのメールメッセージに何らかの意味のあるメッセージデータが含まれている必要があることです。受信メッセージ処理エージェントから情報を引き出すために単に送信されるメッセージは、インターネットメール環境では一般的に受け入れられません。
To guarantee some level of interoperability, Group 3 Fax and Internet mail rely on all receivers being able to deal with some baseline format (i.e., a basic image format or plain ASCII text, respectively). The role of capability exchange or content negotiation is to permit better-than baseline capabilities to be employed where available.
あるレベルの相互運用性を保証するために、グループ3ファックスとインターネットメールは、ベースライン形式（つまり、基本的な画像形式またはプレーンASCIIテキスト）に対処できるすべてのレシーバーに依存しています。能力交換またはコンテンツ交渉の役割は、利用可能な場合はベースラインよりも優れた能力を採用できるようにすることです。
One of the challenges addressed by this specification is how to adapt the email environment to provide a fax-like service. A sender must not make any a priori assumption that the receiver can recognize anything other than a simple email message. There are some important uses of email that are fundamentally incompatible with the fax model of message passing and content negotiation (notably mailing lists). So we need to have a way of recognizing when content negotiation is possible, without breaking the existing email model.
この仕様で扱われる課題の1つは、FAXのようなサービスを提供するために電子メール環境を適応させる方法です。送信者は、レシーバーが簡単な電子メールメッセージ以外のものを認識できるという先験的な仮定を立ててはなりません。メッセージの合格とコンテンツネゴシエーション（特にメーリングリスト）のFAXモデルと根本的に互換性がないメールのいくつかの重要な用途があります。したがって、既存の電子メールモデルを壊すことなく、コンテンツの交渉が可能な場合を認識する方法が必要です。
"Extended Facsimile using Internet Mail" [1] provides for a limited provision of receiver capability information to the sender of a message, using an extension to Message Disposition Notifications [2,4], employing media feature tags [5] and media feature expressions [6].
「インターネットメールを使用した拡張ファクシミリ」[1]は、メッセージの送信者にレシーバー機能情報を限定的な提供を提供し、拡張機能を使用してメッセージ処分通知[2,4]を使用し、メディア機能タグ[5]とメディア機能表現を使用します。[6]。
This mechanism provides for receiver capabilities to be disclosed after a message has been received and processed. This information can be used for subsequent transmissions to the same receiver. But many communications are one-off messages from a given sender to a given receiver, and cannot benefit from this.
このメカニズムは、メッセージを受信して処理した後に開示するレシーバー機能を提供します。この情報は、同じ受信機への後続の送信に使用できます。しかし、多くの通信は、特定の送信者から特定のレシーバーへの1回限りのメッセージであり、これに恩恵を受けることはできません。
Classic Internet mail is an "open loop" process: no information is returned back to the point from which the message is sent. This has been unkindly --but accurately-- characterized as "send and pray", since it lacks confirmation.
古典的なインターネットメールは「オープンループ」プロセスです。メッセージが送信されるポイントに返される情報はありません。これは、確認がないため、「送信と祈り」として特徴付けられているので、不親切に - 正確には祈ります。
Sending a message and obtaining confirmation that the message has been received is a "closed loop" process: the confirmation sent back to the sender creates a loop around which information is passed.
メッセージを送信して、メッセージが受信されたことの確認を取得することは「クローズドループ」プロセスです。送信者に送信された確認は、情報が渡されるループを作成します。
Many Internet email agents are not designed to participate in a closed loop process, and thus have no responsibility to respond to receipt of a message. Later additions to Internet standards, notably Delivery Service Notification [18] and Message Disposition Notification [4], specify means for certain confirmation responses to be sent back to the sender, thereby closing the loop. However conformance to these enhancements is optional and full deployment is in the future.
多くのインターネットメールエージェントは、クローズドループプロセスに参加するように設計されていないため、メッセージの受信に応答する責任はありません。インターネット標準への後の追加、特に配信サービス通知[18]およびメッセージ処分通知[4]は、特定の確認応答が送信者に送信される平均を指定し、それによってループを閉じます。ただし、これらの機能強化への適合性はオプションであり、完全な展開は将来的に行われます。
DSN must be fully implemented by the entire infrastructure; further when support is lacking, the message is still sent on in open-loop fashion. Sometimes, transmission and delivery should instead be aborted and the fact be reported to the sender.
DSNは、インフラストラクチャ全体で完全に実装する必要があります。さらに、サポートが不足している場合、メッセージはまだオープンループで送信されます。代わりに、送信と配送を中止し、事実を送信者に報告することがあります。
Due to privacy considerations for end-users, MDN usage is entirely voluntary.
エンドユーザーのプライバシーに関する考慮事項により、MDNの使用は完全に任意です。
Content negotiation is a closed loop function (for the purposes of this proposal -- see section 2.3, item (f)), and requires that the recipient of a message make some response to the sender. Since content negotiation must retro-fit a closed-loop function over Internet mail's voluntary and high-latency environment, a challenge for content negotiation in email is to establish that consenting parties can recognize a closed loop situation, and hence recognize their responsibilities to close the loop.
コンテンツネゴシエーションはクローズドループ関数です（この提案の目的で - セクション2.3、アイテム（f）を参照）。メッセージの受信者が送信者に何らかの応答をすることを要求します。コンテンツネゴシエーションは、インターネットメールの自発的かつ高遅延環境に閉ループ機能をレトロフィットする必要があるため、電子メールのコンテンツ交渉の課題は、同意者がクローズドループの状況を認識し、したがって、彼らの責任を認識していることを確立することです。ループ。
Three different loops can be identified in a content negotiation:
コンテンツネゴシエーションで3つの異なるループを識別できます。
Sender Receiver
| |
Initial message ------>------------ v
| |
(1) ------------<--- Request alternative data
| |
Send alternative ------>------------ (2)
| |
(3) ------------<------ Confirm receipt
of usable data
(1) Sender receives acknowledgement that negotiable content has been received
(1) 送信者は、交渉可能なコンテンツが受信されたという謝辞を受け取ります
(2) Receiver receives confirmation that its request for data has been received.
(2) 受信者は、データのリクエストが受信されたことを確認します。
(3) Sender receives confirmation that received data is processable, or has been processed.
(3) 送信者は、受信したデータが処理可能であるか、処理されているという確認を受け取ります。
Although the content negotiation process is initiated by the sender, it is not established until loop (1) is closed with an indication that the receiver desires alternative content.
コンテンツネゴシエーションプロセスは送信者によって開始されますが、レシーバーが代替コンテンツを希望することを示すループ（1）が閉じられるまで確立されません。
If content sent with the original message from the sender is processable by the receiver, and a confirmation is sent, then the entire process is reduced to a simple send/confirm loop:
送信者からの元のメッセージで送信されたコンテンツが受信機によって処理可能であり、確認が送信された場合、プロセス全体が単純な送信/確認ループに削減されます。
Sender Receiver
| |
Initial message ------>------------ v
| |
(3) ------------<------ Confirm receipt
of usable data
The primary goal {1} is to provide a mechanism that allows arbitrary enhanced content features to be used with Internet fax systems. The mechanism should {2} support introduction of new features over time, particularly those that are adopted for Group 3 fax.
主な目標{1}は、インターネットFAXシステムで任意の強化されたコンテンツ機能を使用できるようにするメカニズムを提供することです。メカニズムは、{2}時間の経過に伴う新機能の導入、特にグループ3ファックスに採用されているものをサポートする必要があります。
Further goals are:
さらなる目標は次のとおりです。
(a) Must {1} interwork with existing simple mode Internet fax systems.
(a) 既存のシンプルモードインターネットファックスシステムとのインターワーク{1}マストが必要です。
(b) Must {1} interwork with existing email clients.
(b) {1}既存の電子メールクライアントとのインターワークが必要です。
The term "interwork" used above means that the mechanism must be introduced in a way that may be ignored by existing systems, and systems enhanced to use the negotiation mechanisms will behave in a fashion that is expected by existing systems. (I.e., existing clients are not expected in any way to participate in or be aware of content negotiation.)
上記で使用される「インターワーク」という用語は、既存のシステムで無視される可能性のある方法でメカニズムを導入しなければならないことを意味し、交渉メカニズムを使用するように強化されたシステムは、既存のシステムで予想される方法で動作します。（つまり、既存のクライアントは、コンテンツの交渉に参加したり、認識したりすることは期待されていません。）
(c) Must {1} avoid transmission of "administrative non messages". (I.e., only messages that contain meaningful content for the end user may be sent unless it is known that the receiving system will interpret them, and not attempt to display them.) This requirement has been stated very strongly by the email community.
(c) {1}「管理非メッセージ」の送信を避けなければなりません。（つまり、受信システムがそれらを解釈し、それらを表示しようとしないことがわかっていない限り、エンドユーザーの意味のあるコンテンツを含むメッセージのみが送信される場合があります。）この要件は、電子メールコミュニティによって非常に強く述べられています。
This means that a sender must not assume that a receiver can understand the capability exchange protocol elements, so must always start by sending some meaningful message data.
これは、送信者が受信者が機能交換プロトコル要素を理解できると想定してはならないため、意味のあるメッセージデータを送信することから常に開始する必要があることを意味します。
(d) Avoid {1} multiple renderings of a message. In situations where multiple versions of a message are transferred, the receiver must be able to reliably decide on a single version to be displayed.
(d) {1}メッセージの複数のレンダリングを避けてください。メッセージの複数のバージョンが転送される状況では、受信者は表示される単一のバージョンを確実に決定できる必要があります。
(e) Minimize {2} round trips needed to complete a transmission. Ideally {3} every enhanced transmission will result in simply sending data that the recipient can process, and receiving a confirmation response.
(e) トランスミッションを完了するために必要な{2}丸い旅行を最小化します。理想的には{3}すべての拡張された送信により、受信者が処理できるデータを単に送信し、確認応答を受信します。
(f) The solution adopted should not {3} transmit multiple versions of the same data. In particular, it must not {1} rely on routinely sending multiple instances of the same data in a single message.
(f) 採用されたソリューションは、同じデータの複数のバージョンを送信しないでください。特に、{1}は、同じデータの複数のインスタンスを単一のメッセージに日常的に送信することに依存してはなりません。
This does not prohibit sending multiple versions of the same data, but it must not be a requirement to do so. A sender may choose to send multiple versions together (e.g., plain text and some other format), but the capability exchange mechanism selected must not depend on such behaviour.
これは、同じデータの複数のバージョンの送信を禁止するものではありませんが、そうするための要件であってはなりません。送信者は、複数のバージョンを一緒に送信することを選択できます（たとえば、プレーンテキストやその他の形式など）が、選択された機能交換メカニズムはそのような動作に依存してはなりません。
(g) The solution adopted should {2} be consistent with and applicable to other Internet email based applications; e.g., regular email, voice messaging, unified messaging, etc.
(g) 採用されたソリューションは、{2}と他のインターネットメールベースのアプリケーションと一致し、適用できる必要があります。たとえば、通常の電子メール、音声メッセージ、統一メッセージなど。
(h) Allow for a graceful recovery from stale cache information. A sender might use historic information to send non-baseline data with an initial message. If this turns out to be unusable by the recipient, it should still be possible {3} for the baseline data, or some other acceptable format, to be selected and transferred.
(h) 古いキャッシュ情報からの優雅な回復を可能にします。送信者は、歴史的な情報を使用して、初期メッセージで非基本データを送信する場合があります。これが受信者によって使用できないことが判明した場合、ベースラインデータまたはその他の許容される形式については、選択および転送される可能性があります。
(i) The mechanism defined should {2} operate cleanly in conjunction with the mechanisms already defined for extended mode Internet fax (extended DSN and MDN [2], etc.).
(i) 定義されたメカニズムは、{2}は、拡張モードのインターネットファックス（拡張DSNおよびMDN [2]など）で既に定義されているメカニズムと組み合わせてきれいに動作する必要があります。
(j) As much as possible, existing email mechanisms should {3} be used rather than inventing new ones. (It is clear that some new mechanisms will be needed, but they should be defined cautiously.)
(j) 可能な限り、既存の電子メールメカニズムは、新しい電子メールメカニズムを発明するのではなく、{3}を使用する必要があります。（いくつかの新しいメカニズムが必要であることは明らかですが、それらは慎重に定義する必要があります。）
(k) The mechanism should {2} be implementable in low memory devices. That is, it should not depend on any party being able to buffer arbitrary amounts of message data.
(k) メカニズムは、低メモリデバイスで{2}を実装可能にする必要があります。つまり、任意の量のメッセージデータをバッファリングできる当事者に依存するべきではありません。
(It may not be possible to completely satisfy this goal in a sending system. But if the sender does not have enough memory to buffer some given message, it can choose to not offer content negotiation.)
（送信システムでこの目標を完全に満たすことはできないかもしれません。しかし、送信者が指定されたメッセージをバッファするのに十分なメモリを持っていない場合、コンテンツの交渉を提供しないことを選択できます。）
This section starts with an outline of the negotiation process, and provides greater detail about each stage in following sub-sections.
このセクションは、ネゴシエーションプロセスの概要から始まり、次のサブセクションの各段階についてさらに詳細に説明します。
1. Sender sends initial message data with an indication of alternative formats available (section 3.1). Initial data MAY be a baseline or some other guess of what the recipient can handle.
1. 送信者は、使用可能な代替形式の兆候を持つ初期メッセージデータを送信します（セクション3.1）。初期データは、受信者が処理できるもののベースラインまたはその他の推測である場合があります。
2. The receiver has three main options:
2. 受信機には3つの主なオプションがあります。
(a) Does not recognize the optional alternative formats, and passively accepts the data as sent (section 3.2.1).
(a) オプションの代替形式を認識せず、送信されたデータを受動的に受け入れます（セクション3.2.1）。
(b) Does recognize the alternatives offered, and actively accepts the data as sent (section 3.2.2).
(b) 提供された代替案を認識し、送信されたデータを積極的に受け入れます（セクション3.2.2）。
(c) Recognizes the alternatives offered, and determines that it prefers to receive an alternative format. An MDN response is sent (i) indicating that the original data was not processed, and (ii) containing receiver capability information so that the sender may select a suitable alternative (section 3.2.3).
(c) 提供された代替案を認識し、代替形式を受信することを好むと判断します。MDN応答が送信されます（i）元のデータが処理されていないことを示し、（ii）送信者が適切な代替案を選択できるように受信機能力情報を含む（セクション3.2.3）。
Note that only recipients named in 'to:', 'cc:' or 'bcc:' headers in the original message may request alternative data formats in this way. Recipients not named in the original message headers MUST NOT attempt to initiate content negotiation.
'to：'、 'cc：'または 'bcc：' headersに名前が付けられた受信者のみが、元のメッセージのヘッダーがこの方法で代替データ形式を要求する場合があることに注意してください。元のメッセージヘッダーに命名されていない受信者は、コンテンツの交渉を開始しようとしてはなりません。
NOTE: the prohibition on initiation of negotiation by recipients other than those explicitly addressed is to avoid the sender from having to deal with negotiation requests from unexpected parties.
注：明示的に対処されたもの以外の受信者による交渉の開始に関する禁止は、予期しない関係者からの交渉要求に対処する必要がないことを明示的に扱っているもの以外のものです。
3. On receipt of an MDN response indicating preference for an alternative data format, the sender MUST select and transmit message data matched to the receiver's declared capabilities, or send an indication that the receiver's request cannot be honoured. When sending alternative data, the sender suppresses the indication that alternative data is available, so the negotiation process cannot loop.
3. 代替データ形式の優先権を示すMDN応答を受け取ったとき、送信者は受信者の宣言された機能に一致するメッセージデータを選択して送信するか、受信者の要求を尊重できないことを示す必要があります。代替データを送信する場合、送信者は、代替データが利用可能であるという兆候を抑制し、交渉プロセスがループできません。
4. On receipt of final data from the sender, the receiver sends an MDN response indicating acceptance (or otherwise) of the data received.
4. 送信者からの最終データを受信すると、受信者は受信したデータの受け入れ（またはその他）を示すMDN応答を送信します。
NOTE: the receiver does not choose the particular data format to be received; that choice rests with the sender. We find that this approach is simpler than having the receiver choose an alternative, because it builds upon existing mechanisms in email, and follows the same pattern as a traditional Group 3 fax. Further, it deals with situations where the range of alternatives may be difficult to describe.
注：受信者は、受信する特定のデータ形式を選択しません。その選択は送信者にあります。このアプローチは、電子メールの既存のメカニズムに基づいており、従来のグループ3ファックスと同じパターンに従うため、受信者に代替品を選択するよりも簡単であることがわかります。さらに、代替品の範囲を説明するのが難しい状況を扱っています。
This approach is similar to server driven negotiation in HTTP using "Accept" headers [13]. This is distinct to the agent-driven style of negotiation provided for HTTP as part of Transparent Content Negotiation [14], or which might be constructed in email using "multipart/alternative" and "message/external-body" MIME types [15].
このアプローチは、「受け入れる」ヘッダー[13]を使用して、HTTPのサーバー駆動型交渉に似ています。これは、透明なコンテンツネゴシエーションの一部としてHTTPに提供されるエージェント主導のネゴシエーションスタイル[14]、または「MultiPart/Alternative」および「Message/外部ボディ」MIMEタイプ[15]を使用して電子メールで構築される可能性があることとは異なります。。
A sender that is prepared to provide alternative message data formats MUST send the following message elements:
代替メッセージデータ形式を提供するために準備された送信者は、次のメッセージ要素を送信する必要があります。
(a) a default message data format,
(a) デフォルトのメッセージデータ形式、
(b) message identification, in the form of a Message-ID header.
(b) メッセージIDヘッダーの形でのメッセージ識別。
(c) appropriate 'Content-features' header(s) [7] describing the default message data sent,
(c) 適切な「コンテンツフィーチャー」ヘッダー[7]が送信されたデフォルトのメッセージデータを説明する、
(d) a request for Message Disposition Notification [4],
(d) メッセージ処分通知のリクエスト[4]、
(e) an indication that it is prepared to send different message data, using an 'Alternative-available' MDN option field [9], and
(e) 「代替利用可能な」MDNオプションフィールド[9]を使用して、異なるメッセージデータを送信する準備ができていることを示しています。
(f) an indication of the alternative data formats available, in the form of 'Content-alternative' header(s) [8]. Note: more than one Content-alternative' header MAY be specified; see section 3.1.3 for more information.
(f) 「コンテンツ代替」ヘッダー[8]の形で利用可能な代替データ形式の兆候。注：複数のコンテンツ代替ヘッダーが指定される場合があります。詳細については、セクション3.1.3を参照してください。
Having indicated the availability of alternative data formats, the sender is expected to hold the necessary information for some time, allowing the receiver an opportunity to request such data. But, unless it so indicates (see [9]), the sender is not expected to hold this information indefinitely; the exact length of time such information should be held is not specified here. Thus, the possibility exists that a request for alternative information may arrive too late, and the sender will then send an indication that the data is no longer available. If message transference is being completed within a predetermined time interval (e.g., using [21]), then the sender should normally maintain the data for at least that period.
代替データ形式の可用性を示しているため、送信者はしばらくの間必要な情報を保持し、受信者がそのようなデータを要求する機会を提供することが期待されます。しかし、そうでない限り（[9]を参照）、送信者はこの情報を無期限に保持することは期待されていません。そのような情報を保持すべき正確な時間は、ここでは指定されていません。したがって、代替情報のリクエストが遅すぎる可能性がある可能性が存在し、送信者はデータが利用できなくなったことを示します。メッセージ転送が所定の時間間隔内で完了している場合（例：[21]を使用するなど）、送信者は通常、少なくともその期間にデータを維持する必要があります。
The normal default format is text/plain. This is the format sent unless the sender has prior knowledge or expectation of other content formats supported by the recipient. Some uses of email presume some other default format (e.g. Intenet fax [1] has TIFF profile S [11] as its default format; see section 7 of this document).
通常のデフォルト形式はテキスト/プレーンです。これは、送信者が受信者がサポートする他のコンテンツ形式の事前知識または期待を持っている場合を除き、送信される形式です。電子メールの一部は、他のデフォルト形式（例：Intenet Fax [1]がデフォルト形式としてTIFFプロファイルS [11]を持っていると仮定しています。このドキュメントのセクション7を参照）。
"Extended Facsimile Using Internet Mail" [1] and "Indicating Supported Media Features Using Extensions to DSN and MDN" [2] indicate a possible mechanism for a sender to have prior knowledge of receiver capabilities. This specification builds upon the mechanism described there.
「インターネットメールを使用した拡張ファクシミリ」[1]および「DSNおよびMDNへの拡張機能を使用したサポートされているメディア機能を示す」[2]は、送信者が受信機機能の事前知識を持つ可能性のあるメカニズムを示しています。この仕様は、そこに記載されているメカニズムに基づいています。
As always, the sender may gather information about the receiver in other ways beyond the scope of this document (e.g., a directory service or the suggested RESCAP protocol).
いつものように、送信者は、このドキュメントの範囲を超えて他の方法で受信機に関する情報を収集することができます（例：ディレクトリサービスまたは推奨されるRescapプロトコル）。
When a sender is indicating preparedness to send alternative message data, it MUST request a Message Disposition Notification (MDN) [4].
送信者が代替メッセージデータを送信する準備を示している場合、メッセージ処分通知（MDN）[4]を要求する必要があります。
It indicates its readiness to send alternative message data by including the MDN option 'Alternative-available' [9] with the MDN request. Presence of this MDN request option simply indicates that the sender is prepared to send some different data format if it has more accurate or up-to-date information about the receiver's capabilities. Of itself, this option does not indicate whether the alternatives are likely to be better or worse than the default data sent -- that information is provided by the "Content-alternative" header(s) [8].
これは、MDNリクエストにMDNオプション「代替利用可能」[9]を含めることにより、代替メッセージデータを送信する準備ができていることを示しています。このMDNリクエストオプションの存在は、受信者の機能に関するより正確または最新情報がある場合、送信者が異なるデータ形式を送信する準備ができていることを単に示します。それ自体、このオプションは、代替が送信されたデフォルトのデータよりも優れているか悪いかを示していません。その情報は「コンテンツ代替」ヘッダー[8]によって提供されます。
When using the 'Alternative-available' option in an MDN request, the message MUST also contain a 'Message-ID:' header with a unique message identifier.
MDNリクエストで「代替利用可能な」オプションを使用する場合、メッセージには「メッセージID：」ヘッダーを含むヘッダーも含める必要があります。
A sender can provide information about the alternative message data available by applying one or more 'Content-alternative' headers to message body parts for which alternative data is available, each indicating media features [5,6] of an available alternative.
送信者は、1つまたは複数の「コンテンツ代替」ヘッダーを、使用可能な代替メディア機能[5,6]を示す代替データが利用可能なボディ部分に1つ以上の「コンテンツ代替」ヘッダーを適用することにより、利用可能な代替メッセージデータに関する情報を提供できます。
The purpose of this information is to allow a receiver to decide whether any of the available alternatives are preferable, or likely to be preferable, to the default message data provided.
この情報の目的は、提供されたデフォルトのメッセージデータに対して、利用可能な代替品のいずれかが望ましいか、好ましい可能性が高いかを受信者が決定できるようにすることです。
Not every available alternative is required to be described in this way, but the sender should include enough information to allow a receiver to determine whether or not it can expect more useful message data if it chooses to indicate a preference for some alternative that matches its capabilities.
この方法で説明する必要があるわけではありませんが、送信者には、受信機がその機能に一致する代替案の好みを示すことを選択した場合、より有用なメッセージデータを期待できるかどうかを判断できるようにするのに十分な情報を含める必要があります。。
Alternative formats will often be variations of the content-type originally sent. When different content-types can be provided, they should be indicated in a corresponding content-alternative header using the 'type' media feature tag [24]. (See example 8.4.)
代替形式は、多くの場合、元々送信されたコンテンツタイプのバリエーションです。異なるコンテンツタイプを提供できる場合、「タイプ」メディア機能タグ[24]を使用して、対応するコンテンツ代替ヘッダーで示される必要があります。（例8.4を参照してください。）
NOTE: the sender is not necessarily expected to describe every single alternative format that is available -- indeed, in cases where content is generated on-the-fly rather than simply selected from an enumeration of possibilities, this may be infeasible. The sender is expected to use one or more 'Content-alternative' headers to reasonably indicate the range of alternative formats available.
注：送信者は、利用可能なすべての代替形式を記述することが必ずしも期待されるわけではありません。実際、可能性の列挙から単に選択されるのではなく、コンテンツがフライで生成される場合、これは実行不可能です。送信者は、1つ以上の「コンテンツ代替」ヘッダーを使用して、利用可能な代替形式の範囲を合理的に示すことが期待されています。
The final format actually sent will always be selected by the sender, based on the receiver's capabilities. The 'Content-alternative' headers are provided here simply to allow the receiver to make a reasonable decision about whether to request an alternative format that better matches its capabilities.
実際に送信された最終形式は、受信者の機能に基づいて、常に送信者によって選択されます。「コンテンツ代替」ヘッダーは、レシーバーがその機能をより良く一致させる代替形式を要求するかどうかについて合理的な決定を下すためだけに提供されます。
ALSO NOTE: this header is intended to be usable independently of the MDN extension that indicates the sender is prepared to send alternative formats. It could be used with a different protocol having nothing to do with email or MDN. Thus, the 'Content-alternative' header provides information about alternative data formats without actually indicating if or how they might be obtained.
また、注：このヘッダーは、送信者が代替形式を送信する準備ができていることを示すMDN拡張機能とは無関係に使用できることを目的としています。電子メールやMDNとは何の関係もない別のプロトコルで使用できます。したがって、「コンテンツ代替」ヘッダーは、実際に取得するかどうか、またはどのように取得するかを実際に示さずに、代替データ形式に関する情報を提供します。
Further, the 'Content-alternative' header applies to a MIME body part, where the MDN 'Alternative-available' option applies to the message as a whole.
さらに、「コンテンツ代替」ヘッダーは、MDNの「代替利用可能な」オプションがメッセージ全体に適用されるMIMEボディパーツに適用されます。
The example sections of this memo show how the 'Content-features:' and 'Content-alternative:' MIME headers may be used to describe the content provided and available alternatives.
このメモのセクションの例は、「コンテンツフィーチュア」と「コンテンツ代替：」MIMEヘッダーを使用して、提供されたコンテンツと利用可能な代替案を説明する方法を示しています。
A negotiation-aware system receiving message data without an indication of alternative data formats MUST process that message in the same way as a standard Internet fax system or email user agent.
代替データ形式を示すことなくメッセージデータを受信するネゴシエーション認識システムは、標準のインターネットFAXシステムまたは電子メールユーザーエージェントと同じ方法でそのメッセージを処理する必要があります。
Given an indication of alternative data format options, the receiver has three primary options:
代替データ形式オプションの兆候があると、受信者には3つの主要なオプションがあります。
(a) do not recognize the alternatives: passively accept what is provided,
(a) 代替案を認識しないでください：提供されているものを受動的に受け入れ、
(b) do not prefer the alternatives: actively accept what is provided, or
(b) 代替手段を好まないでください：提供されるものを積極的に受け入れる、または
(c) prefer some alternative format.
(c) いくつかの代替形式をお勧めします。
This corresponds to the case that the receiver is a simple mode Internet fax recipient [12], or a traditional email user agent.
これは、レシーバーが単純なモードインターネットファックス受信者[12]、または従来の電子メールユーザーエージェントであるという場合に対応します。
The receiver does not recognize the alternatives offered, or chooses not to recognize them, and simply accepts the data as sent. A standard MDN response [4] or an extended MDN response [2] MAY be generated at the receiver's option.
受信者は、提供された代替案を認識せず、それらを認識しないことを選択し、送信されたデータを単に受け入れるだけです。標準のMDN応答[4]または拡張されたMDN応答[2]は、受信機のオプションで生成される場合があります。
The receiver does recognize the alternatives offered, but specifically chooses to accept the data originally offered. An MDN response SHOULD be sent indicating acceptance of the data and also containing the receiver's capabilities.
受信者は、提供された代替案を認識していますが、特に当初提供されていたデータを受け入れることを選択します。データの受け入れを示すMDN応答を送信し、受信者の機能も含める必要があります。
This is the same as the defined behaviour of an Extended Internet Fax receiver [1,2].
これは、拡張インターネットファックス受信機の定義された動作と同じです[1,2]。
This case extends the behaviour of Extended Internet Fax [1,2] to allow an alternative form of data for the current message to be transferred. This option may be followed ONLY if the original message contains an 'Alternative-available' MDN option (alternative data re-sends may not use this option). Further, this option may be followed ONLY if the recipient is explicitly addressed in the message headers ('to:', 'cc:' or 'bcc:').
このケースは、拡張されたインターネットファックス[1,2]の動作を拡張して、現在のメッセージの代替形式のデータを転送できるようにします。このオプションは、元のメッセージに「代替利用可能な」MDNオプションが含まれている場合にのみ従うことができます（代替データの再センドはこのオプションを使用しない場合があります）。さらに、このオプションは、受信者がメッセージヘッダー（ 'to：'、 'cc：'または 'bcc：'）で明示的にアドレス指定されている場合にのみ従うことができます。
The receiver recognizes that alternative data is available, and based on the information provided determines that an alternative format would be preferable. An MDN response [4] is sent, which MUST contain the following:
受信者は、代替データが利用可能であることを認識し、提供された情報に基づいて、代替形式が望ましいと判断します。MDN応答[4]が送信されます。これには以下が含まれている必要があります。
o an 'Alternative-preferred' disposition modifier [9] indicating that some data format other than that originally sent is preferred,
o 最初に送信されたもの以外の一部のデータ形式が推奨されることを示す「代替プロファリー」処分修飾因子[9]、
o an 'Original-Message-ID:' field [4] with the message identifier from the received message, and
o an 'origional-message-id：'受信したメッセージからのメッセージ識別子を備えたフィールド[4]、および
o receiver capabilities, per RFC 2530 [2].
o RFC 2530ごとの受信機能能力[2]。
On sending such an MDN response, the receiver MAY discard the message data provided, in the expectation that some alternative will be sent. But if the sender has indicated a limited lifetime for the alternative data, and the original data received is within the receiver's capability to display, the receiver SHOULD NOT discard it. Lacking sufficient memory to hold the original data for a period of time within which alternative data would reasonably be received, the receiver SHOULD accept and display the original data. In the case that the original data is not within the receiver's capability to display then it SHOULD discard the original data and request an alternative format.
このようなMDN応答を送信すると、レシーバーは、一部の代替案が送信されると予想されて、提供されたメッセージデータを破棄することができます。しかし、送信者が代替データに対して寿命が限られていることを示しており、受信した元のデータが受信者の表示機能内にある場合、受信者はそれを破棄すべきではありません。代替データが合理的に受信される期間、元のデータを保持するのに十分なメモリがないため、受信者は元のデータを受け入れて表示する必要があります。元のデータが受信者の表示機能内にない場合、元のデータを破棄して代替形式を要求する必要があります。
NOTE: the above rules are meant to ensure that the content negotiation framework does not result in the loss of data that would otherwise be received and displayed.
注：上記のルールは、コンテンツネゴシエーションフレームワークが、そうでなければ受信および表示されるデータの損失をもたらさないことを保証するためのものです。
Having requested alternative data and not displayed the original data, the receiver MUST remember this fact and be prepared to take corrective action if alternative data is not received within a reasonable time (e.g., if the MDN response or transmission of alternative data is lost in transit).
代替データを要求し、元のデータを表示しなかったため、受信者はこの事実を覚えていて、合理的な時間内に代替データが受信されない場合は是正措置を講じる必要があります（たとえば、輸送中にMDN応答または代替データの送信が失われた場合）。
Corrective action might be any of the following:
是正措置は次のいずれかです。
(a) re-send the MDN response, and continue waiting for an alternative,
(a) MDN応答を再送信し、代替案を待ち続けます。
(b) present the data originally supplied (if it is still available), or
(b) 元々提供されたデータを提示します（まだ利用可能な場合）、または
(c) generate an error response indicating loss of data.
(c) データの損失を示すエラー応答を生成します。
On concluding that alternative data is not forthcoming, the preferred option is (b), but this may not be possible for receivers with limited memory.
代替データが近づいていないと結論付けても、優先オプションは（b）ですが、これはメモリが限られているレシーバーでは不可能かもしれません。
See Appendix A for further discussion of receiver behaviour options.
受信者の動作オプションの詳細については、付録Aを参照してください。
NOTE: A cache control indicator on recipient capabilities has been considered, but is not included in this specification. (Sometimes, a recipient may want to offer certain capabilities only under certain circumstances, and does not wish them to be remembered for future use; e.g., not wanting to receive colour images for routine communications.)
注：受信者機能に関するキャッシュ制御インジケーターが考慮されていますが、この仕様には含まれていません。（受信者は、特定の状況下でのみ特定の機能を提供したい場合があり、将来の使用のために覚えておくことを望まない場合があります。
NOTE: the receiver does not actually get to select any specific data format offered by the sender. The final choice of data format is always made by the sender, based on the receiver's declared capabilities. This approach:
注：レシーバーは、実際に送信者が提供する特定のデータ形式を選択することはできません。データ形式の最終的な選択は、受信者の宣言された機能に基づいて、常に送信者によって行われます。このアプローチ：
(a) more closely matches the style of T.30 content negotiation,
(a) T.30コンテンツネゴシエーションのスタイルに密接に一致し、
(b) provides for clean integration with the current extended mode Internet fax specification,
(b) 現在の拡張モードのインターネットファックス仕様とのクリーンな統合を提供します。
(c) builds upon existing email mechanisms in a consistent fashion, and
(c) 既存の電子メールメカニズムを一貫した方法で構築し、
(d) allows for cases (e.g., dynamically generated content) where it is not feasible for the sender to enumerate the alternatives available.
(d) 送信者が利用可能な代替案を列挙することが実行不可能なケース（たとえば、動的に生成されたコンテンツなど）を許可します。
Having offered to provide alternative data by including an 'Alternative-available' option with the original MDN request, and on receipt of an MDN response indicating 'Alternative-preferred', the sender SHOULD transmit alternative message data that best matches the receiver's declared capabilities. (In the exceptional case that the response requesting an alternative data format does not contain receiver capabilities, a baseline format should be selected.)
元のMDNリクエストに「代替利用可能な」オプションを含めることにより、代替データを提供することを提案し、「代替プロファーレッド」を示すMDN応答を受け取ったときに、送信者は受信者の宣言された機能に最もよく一致する代替メッセージデータを送信する必要があります。（代替データ形式を要求する応答にレシーバー機能が含まれていないという例外的な場合、ベースライン形式を選択する必要があります。）
If any part of the best available message data matching the receiver capabilities is the same as that originally sent, it MUST still be re-transmitted because the receiver may have discarded the original data. Any data sent as a result of receiving an 'Alternative-preferred' response should include an MDN request but SHOULD NOT include an 'Alternative-available' disposition notification modifier.
受信機の機能を一致させる最良の利用可能なメッセージデータの一部が元々送信されたものと同じである場合、受信者が元のデータを破棄した可能性があるため、再送信する必要があります。「代替予防」応答を受信した結果として送信されたデータには、MDNリクエストを含める必要がありますが、「代替利用可能な」処分通知修飾子を含めるべきではありません。
If the sender is no longer able to send message data for any reason, it MUST send a message to the receiver indicating a failed transfer. It SHOULD also generate a report for the receiver indicating the failure, containing an MDN request and including an 'Alternative-not-available' disposition notification modifier.
送信者が何らかの理由でメッセージデータを送信できなくなった場合、転送の失敗を示すメッセージを受信者に送信する必要があります。また、MDNリクエストを含み、「代替で利用できない」処分通知修飾子を含む、障害を示すレシーバーのレポートを生成する必要があります。
Any message sent to a receiver in response to a request for alternative data MUST include an 'Original-Message-ID:' header [23] containing the Original-message-ID value from the received disposition notification message (which is the 'Message-ID:' from the original message). This header serves to correlate the re-send (or failure message) with the original message, and also to distinguish a re-send from an original message.
代替データのリクエストに応じて受信機に送信されたメッセージには、 'Original-message-id：' header [23]が含まれている必要があります。ID： '元のメッセージから）。このヘッダーは、再センド（または故障メッセージ）を元のメッセージと相関させ、元のメッセージと再センドを区別するのに役立ちます。
When resent data is received (indicated by presence of an 'original-message-ID:' header field), the receiver processes that data and generates an MDN response indicating the final disposition of the data received, and also indicating capabilities that may be used for future messages, per RFC 2530 [2] and RFC 2532 [1].
resしたデータが受信されると（ 'original-message-id：'ヘッダーフィールドの存在によって示されます）、受信機はそのデータを処理し、受信したデータの最終的な配置を示すMDN応答を生成し、使用する可能性のある機能を示す将来のメッセージの場合、RFC 2530 [2]およびRFC 2532 [1]ごとに。
If the re-send indicates that alternative data is no longer available (by including an 'Alternative-not-available' disposition notification modifier), and the receiver still holds the original data sent, it should display or process the original data and send an MDN response indicating the final disposition of that data. Thus, the response to an 'Alternative-not-available' indication may be a successful disposition notification.
再送信が、代替データが使用できなくなったことを示している場合（「代替の利用できない」処分通知修飾子を含めることで）、受信者はまだ送信された元のデータを保持している場合、元のデータを表示または処理して送信する必要があります。そのデータの最終処分を示すMDN応答。したがって、「代替で利用できない」兆候に対する応答は、成功した処分通知である可能性があります。
If the re-send indicates that alternative data is no longer available (by including an 'Alternative-not-available' disposition notification modifier), and the receiver has discarded the original data sent, it SHOULD:
再センドが、代替データが使用できなくなったことを示している場合（「代替で利用できない」処分通知修飾子を含めることで）、受信者が送信された元のデータを破棄した場合、次のようにする必要があります。
(a) display or process the failure message received, OR
(a) 受信した障害メッセージを表示または処理します
(b) construct and display a message indicating that message data has been lost, preferably indicating the sender, time, subject, message identifier and other information that may help the recipient user to identify the missing message.
(b) メッセージデータが失われたことを示すメッセージを構築して表示し、受信者ユーザーが欠落しているメッセージを識別するのに役立つ送信者、時間、件名、メッセージ識別子およびその他の情報を示すことが望ましい。
and send a message disposition response indicating a final message disposition of "deleted".
「削除された」の最終的なメッセージ処分を示すメッセージ処分応答を送信します。
The 'Content-alternative:' header is a MIME header that can be attached to a MIME body part to indicate availability of some alternative form of the data it contains. This header does not, of itself, indicate how the alternative form of data may be accessed.
'Content-Alternative：' HeaderはMimeヘッダーであり、Mime Body Partに接続して、含まれるデータの代替形式の可用性を示すことができます。このヘッダーは、それ自体、データの代替形式にアクセスする方法を示していません。
Using the ABNF notation of RFC 2234 [10], the syntax of a 'Content-alternative' header is defined as:
RFC 2234 [10]のABNF表記を使用すると、「コンテンツ代替」ヘッダーの構文は次のとおりです。
Content-alternative-header =
"Content-alternative" ":" Alternative-feature-expression
Alternative-feature-expression = <As defined for 'Filter' by RFC 2533 [6]>
rfc 2533 [6]>による「フィルター」で定義されているように、代替feature-expression = <
More than one 'Content-alternative:' header may be applied to a MIME body part, in which case each one is taken to describe a separate alternative data format that is available.
複数の「コンテンツ代替：」ヘッダーは、MIMEボディの部分に適用される場合があります。その場合、それぞれが利用可能な別の代替データ形式を説明するために使用されます。
A content-alternative header is used with some MIME-encapsulated data, and is interpreted in that context. The intent is to indicate possible variations of that data, and it is not necessarily expected to be a complete free-standing description of a specific available data. Enough information should be provided for a receiver to be able to decide whether or not the alternative thus described (a) is likely to be an improvement over the actual data provided, and (b) is likely to be processable by the receiver.
コンテンツ代替ヘッダーは、いくつかのMIMEカプセル化データで使用され、そのコンテキストで解釈されます。意図は、そのデータの可能なバリエーションを示すことであり、特定の利用可能なデータの完全な自立型説明であると必ずしも期待されるわけではありません。このように説明した代替案が（a）提供された実際のデータよりも改善される可能性が高いかどうかを決定できるように、レシーバーに十分な情報を提供する必要があり、（b）レシーバーが処理可能である可能性があります。
Thus, when interpreting a Content-alternative header value, a receiver may assume that features not explicitly mentioned are not different in the indicated alternative from the supplied data. For example, if a Content-alternative header does not mention an alternative MIME content-type, the receiver may assume that the available alternative uses the same content-type as the supplied data.
したがって、コンテンツの代替ヘッダー値を解釈する場合、レシーバーは、明示的に言及されていない機能が、提供されたデータと指定された代替案で異なっていないと想定する場合があります。たとえば、コンテンツ代替ヘッダーが代替MIMEコンテンツタイプに言及していない場合、受信者は、利用可能な代替が提供されたデータと同じコンテンツタイプを使用すると想定する場合があります。
See also the example in section 8.4.
セクション8.4の例も参照してください。
The 'Original-Message-ID' header is used to correlate any message response or re-send with the original message to which it relates (see also sections 3.2.3, 3.3). A re-send is distinct from the original message, so it MUST have its own unique Message-ID value (per RFC 2822, section 3.6.4).
「Original-Message-ID」ヘッダーは、メッセージ応答を相関させるために使用されるか、関連する元のメッセージを再送信するために使用されます（セクション3.2.3、3.3も参照）。再センドは元のメッセージとは異なるため、独自のメッセージ-ID値（RFC 2822、セクション3.6.4）が必要です。
The syntax for this header is:
このヘッダーの構文は次のとおりです。
"Original-Message-ID" ":" msg-id
where 'msg-id' is defined by RFC 2822 as:
ここで、「MSG-ID」はRFC 2822によって定義されています。
msg-id = "<" id-left "@" id-right ">"
The 'msg-id' value given must be identical to that supplied in the Message-ID: header of the original message for which the current message is a response or re-send.
指定された「MSG-ID」値は、メッセージIDで提供されるものと同一でなければなりません。現在のメッセージが応答または再センドである元のメッセージのヘッダーです。
Here, we define two extensions to the Message Disposition Notification (MDN) protocol [4] to allow a sender to indicate readiness to send alternative message data formats, and to allow a receiver to indicate a preference for some alternative format.
ここでは、メッセージ処分通知（MDN）プロトコル[4]に2つの拡張機能を定義して、送信者が代替メッセージデータ形式を送信する準備ができるようにし、レシーバーが代替形式の優先権を示すことを可能にします。
Indication of what alternatives may be available or preferred are not covered here. This functionality is provided by the 'Content-alternative' MIME header [8] and "Indicating Supported Media Features Using Extensions to DSN and MDN" [2].
ここでは、どのような代替手段が利用可能か、好まれるかを示しています。この機能は、「コンテンツ代替」MIMEヘッダー[8]および「DSNおよびMDNへの拡張機能を使用してサポートされているメディア機能を示す」[2]によって提供されます。
A sender wishing to indicate its readiness to send alternative message data formats must request an MDN response using the MDN 'Disposition-Notification-To:' header [4].
代替メッセージデータ形式を送信する準備ができていることを示す送信者は、MDN 'Rise-notification-' 'Header [4]を使用してMDN応答を要求する必要があります。
The MDN request is accompanied by a 'Disposition-Notification-Options:' header containing the parameter 'Alternative-available' with an importance value of 'optional'. (The significance of 'optional' is that receiving agents unaware of this option do not generate inappropriate failure responses.)
MDNリクエストには、「オプション」の重要な値を持つパラメーター「代替利用可能」を含む「気質 - 解釈オプション：「ヘッダー」」が添付されます。（「オプション」の重要性は、このオプションに気付いていない受信エージェントが不適切な障害応答を生成しないことです。）
This specification defines a value for 'attribute' to be used in an MDN 'Disposition-Notification-Options:' header [4]:
この仕様では、MDN '処分 - notification-optionsで使用される「属性」の値を定義します：' header [4]：
attribute =/ "Alternative-available"
Thus, a sender includes the following headers to indicate that alternative message data is available:
したがって、送信者には、代替メッセージデータが利用可能であることを示すために、次のヘッダーが含まれています。
Disposition-Notification-To:
<sender-address>
Disposition-Notification-Options:
Alternative-available=optional,<lifetime>
where <lifetime> is "transient" or "permanent", indicating whether the alternative data will be made available for just a short while, or for an indefinite period. A value of "permanent" indicates that the data is held on long term storage and can be expected to be available for at least several days, and probably weeks or months. A value of "transient" indicates that the alternative data may be discarded at any time, though it would normally be held for the expected duration of a message transaction.
ここで、<Lifetime>は「一時的」または「永続的」であり、ほんの少しの間、または無期限に代替データが利用可能になるかどうかを示します。「永続的」の値は、データが長期保管に保持されていることを示し、少なくとも数日間、おそらく数週間または数か月で利用可能になると予想されることを示しています。「一時的」の値は、通常、メッセージトランザクションの予想される期間は保持されるが、代替データがいつでも破棄される可能性があることを示します。
NOTE: the <lifetime> parameter is provided to help low-memory receivers (which are unable to store received data) avoid loss of information through requesting an alternative data format that may become unavailable.
注：<Lifetime>パラメーターは、低メモリレシーバー（受信データを保存できない）を支援するために提供されます。
A message sent with a request for an MDN with an 'Alternative-available' option MUST also contain a 'Message-ID:' header field [20].
「代替利用可能な」オプションを備えたMDNのリクエストで送信されたメッセージには、「メッセージID：」ヘッダーフィールド[20]も含まれている必要があります。
The MDN specification [4] defines a number of message disposition options that may be reported by the receiver of a message:
MDN仕様[4]は、メッセージの受信者が報告できる多くのメッセージ処分オプションを定義します。
disposition-type = "displayed"
/ "dispatched"
/ "processed"
/ "deleted"
/ "denied"
/ "failed"
disposition-modifier = ( "error" / "warning" )
/ ( "superseded" / "expired" /
"mailbox-terminated" )
/ disposition-modifier-extension
This specification defines an additional value for 'disposition-modifier-extension':
この仕様は、「処分モジーエクステンション」の付加価値を定義します。
disposition-modifier-extension =/ "Alternative-preferred"
気質 - モジーエクステンション=/「代替プロファーレッド」
When a receiver requests that an alternative format be sent, it sends a message disposition notification message containing the following disposition field:
受信者が代替形式を送信するように要求すると、次の処分フィールドを含むメッセージ処分通知メッセージを送信します。
Disposition:
<action-mode>/<sending-mode>,
deleted/alternative-preferred
For example, an automatically generated response might contain:
たとえば、自動的に生成された応答には以下が含まれる場合があります。
Disposition: automatic-action/MDN-sent-automatically, deleted/alternative-preferred
処分：自動アクション/MDN-Sent-Automatical、削除/代替プロファリー
An MDN response containing an 'alternative-preferred' disposition modifier MUST also contain an 'Original-message-ID:' field [4] with the 'Message-ID:' value from the original message.
「代替プロファー」の処分修飾子を含むMDN応答には、 'Message-id：'値を使用した 'origional-message-id：' field [4]も含まれている必要があります。
An MDN response containing an 'alternative-preferred' disposition modifier SHOULD also contain a 'Media-accept-features:' field [2] indicating the capabilities that the sender should use in selecting an alternative form of message data. If this field is not supplied, the sender should assume some baseline feature capabilities. Receiver capabilities supplied with an alternative-preferred disposition notification MUST NOT be cached: they may apply to the current transaction only.
「代替プロファー」の処分修飾子を含むMDN応答には、「メディアアセプトフェイティア：」フィールド[2]も含まれている必要があります。このフィールドに供給されていない場合、送信者はいくつかのベースライン機能機能を想定する必要があります。代替予防処分通知を提供する受信機機能は、キャッシュされてはなりません。現在のトランザクションのみに適用する場合があります。
A sender that receives a request for alternative data that is no longer available, or is unable to provide alternative data matching the receiver's capabilities, MUST respond with an indication of this fact, sending a message containing data describing the failure.
利用できなくなった代替データのリクエストを受信したり、受信機の機能に一致する代替データを提供できない送信者は、この事実を示して応答し、障害を説明するデータを含むメッセージを送信する必要があります。
Such a message MUST specify the MDN 'Disposition-Notification-To:' header [4], accompanied by a 'Disposition-Notification-Options:' header containing the parameter 'Alternative-not-available' with an importance value of 'required'.
このようなメッセージは、MDN '気質 - notification to：'ヘッダー[4]を指定する必要があります。。
This specification defines a value for 'attribute' to be used in an MDN 'Disposition-Notification-Options:' header [4]:
この仕様では、MDN '処分 - notification-optionsで使用される「属性」の値を定義します：' header [4]：
attribute =/ "Alternative-not-available"
Thus, a sender includes the following headers to indicate that the alternative message data previously offered is no longer available:
したがって、送信者には、以前に提供された代替メッセージデータが利用できなくなったことを示すために、次のヘッダーが含まれています。
Disposition-Notification-To:
<sender-address>
Disposition-Notification-Options:
Alternative-not-available=required,(TRUE)
A message sent with a request for an MDN with an 'Alternative-not-available' option MUST also contain an 'Original-message-ID:' header [23] containing the value from the 'Message-ID:' header of the original message.
「Alternative-Not-Abailable」オプションを備えたMDNのリクエストで送信されたメッセージには、 'Message-id：'ヘッダーからの値を含む 'origional-message-id：' header [23]も含まれている必要があります。メッセージ。
This specification defines an additional value for 'disposition-modifier-extension':
この仕様は、「処分モジーエクステンション」の付加価値を定義します。
disposition-modifier-extension =/ "original-lost"
dision-modifier-extension =/ "original-lost"
When a receiver loses message data because it lacks memory to store the original while waiting for an alternative to be sent, it sends a message disposition notification containing the following field:
レシーバーが送信の代替案を待っている間にオリジナルを保存するメモリがないためにメッセージデータを失うと、次のフィールドを含むメッセージ処分通知を送信します。
Disposition:
<action-mode>/<sending-mode>,
deleted/original-lost
For example, an automatically generated response might contain:
たとえば、自動的に生成された応答には以下が含まれる場合があります。
Disposition: automatic-action/MDN-sent-automatically, deleted/original-lost
処分：自動アクション/MDN-Sent-automalical、削除/元のロスト
An MDN response containing an 'original-lost' disposition modifier MUST also contain an 'Original-message-ID:' field [4] with the 'Message-ID:' value from the resent message, or from the original message (if no re-send has been received).
「元のロスト」処分修飾子を含むMDN応答には、 'message-id：' value from rece-id： 'field [4]を含む必要があります。再センドが受信されました）。
In sending an MDN response that requests alternative data, the security concerns stated in RFC 2298 [4] (sections 2.1 and 6.2) regarding automatic MDN responses must be respected. In particular, a system capable of performing content negotiation MUST have an option for its user to disable negotiation responses, either generally, on a per-message basis, or both.
代替データを要求するMDN応答を送信する際に、自動MDN応答に関するRFC 2298 [4]（セクション2.1および6.2）に記載されているセキュリティの懸念を尊重する必要があります。特に、コンテンツネゴシエーションを実行できるシステムには、ユーザーが一般的に、ユーサージごとに、またはその両方で交渉の回答を無効にするオプションが必要です。
Internet fax is an application that uses email to exchange document images (see RFC RFC 2305 [12] and RFC 2532 [1]).
インターネットFAXは、電子メールを使用してドキュメント画像を交換するアプリケーションです（RFC RFC 2305 [12]およびRFC 2532 [1]を参照）。
Both sender and receiver parts of this specification involve the use of media feature expressions. In the context of Internet fax, any such expressions SHOULD employ feature tags defined by "Content feature schema for Internet fax" [16]. In a wider email context, any valid media features MAY be used.
この仕様の送信者部品とレシーバーの両方の部分には、メディア機能の表現の使用が含まれます。インターネットFAXのコンテキストでは、このような表現は、「インターネットファックスのコンテンツフィーチャスキーマ」で定義された機能タグを使用する必要があります[16]。より広い電子メールのコンテキストでは、有効なメディア機能を使用できます。
For Internet fax [12], "image/tiff" is the assumed content-type for message data. In particular, all Internet fax devices are presumed to be capable of sending and receiving the TIFF profile S capabilities (Section 3 of [11]). When communication is between Internet fax devices, this capability may be assumed. But when dealing with devices that go beyond these capabilities defined for Internet fax (e.g. generic email agents with fax capabilities) it would be better not to assume fax capabilities, and for the negotiating parties to be explicit with respect to all their capabilities.
インターネットFAX [12]の場合、「Image/Tiff」はメッセージデータの想定コンテンツタイプです。特に、すべてのインターネットFAXデバイスは、TIFFプロファイルの機能を送信および受信できると推定されます（[11]のセクション3）。インターネットFAXデバイス間の通信がある場合、この機能が想定される場合があります。しかし、インターネットファックス（たとえば、ファックス機能を備えたジェネリックメールエージェントなど）に定義されたこれらの機能を超えたデバイスを扱う場合、ファックス機能を想定せず、交渉者がすべての機能に関して明示的になることをお勧めします。
It would be better if even Internet fax devices do not assume that they are communicating with other such devices. When using Internet email, there is no reliable way to establish this fact. Therefore, for any Internet fax device that may reasonably be expected to exchange messages with any other email agent, it is RECOMMENDED that Internet fax capabilities (such as image/tiff baseline format handling) are not assumed but stated explicitly.
インターネットFAXデバイスでさえ、他のそのようなデバイスと通信していると想定していない場合は、より良いでしょう。インターネットメールを使用する場合、この事実を確立する信頼できる方法はありません。したがって、他の電子メールエージェントとメッセージを交換することが合理的に予想されるインターネットFAXデバイスの場合、インターネットファックス機能（画像/TIFFベースライン形式の処理など）は想定されていないが、明示的に述べることをお勧めします。
In particular, the 'Media-Accept-Features:' header in receiver MDN responses SHOULD explicitly indicate (type="image/tiff") and baseline TIFF capabilities, rather than just assuming that they are understood.
特に、「メディアaccept-features：」レシーバーMDN応答のヘッダーは、理解されていると仮定するのではなく、単に想定するのではなく、明示的に（Type = "Image/Tiff"）およびベースラインTIFF機能を示す必要があります。
An Internet fax sender has a profile-F (A4, 400x400dpi, MMR) image to send to a receiver. The baseline for Internet fax is 200x200dpi and MH image compression.
インターネットFAX送信者には、受信者に送信するプロファイルF（A4、400x400DPI、MMR）画像があります。インターネットファックスのベースラインは200x200DPIおよびMH画像圧縮です。
Sender's initial message:
送信者の最初のメッセージ：
Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com Content-type: image/tiff Content-Transfer-Encoding: base64 Content-features: (& (color=Binary) (image-file-structure=TIFF-minimal) (dpi=200) (dpi-xyratio=1) (paper-size=A4) (image-coding=MH) (MRC-mode=0) (ua-media=stationery) ) Content-alternative: (& (color=Binary) (image-file-structure=TIFF-limited) (dpi=400) (dpi-xyratio=1) (paper-size=A4) (image-coding=MMR) (MRC-mode=0) (ua-media=stationery) )
-RAA14128.773615765/ example.com Content-Type：Image/ Tiff Content-Transfer-Encoding：Base64 Content-Features：（＆（color = binary）（image-file-structure = tiff-minimal）（dpi = 200）（dpi-xiratio = 1）（Paper-size = a4）（image-coding = mh）（mrc-mode = 0）（ua-media = stationer））content-alternative：（＆（color = binary）（yigas-file-structure = tiff-rimited）（dpi = 400）（dpi-xyratio = 1）（paper-size = a4）（image-coding = mmr）（mrc-mode = 0）（ua-media = stationer）））
[TIFF-FX Profile-S message goes here]
[tiff-fxプロファイル-Sメッセージはここにあります]
--RAA14128.773615765/ example.com--
-raa14128.773615765/ example.com----
Receiver sends MDN response to initial message:
受信者は、最初のメッセージにMDN応答を送信します。
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Content Negotiation
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
--RAA14128.773615766/example.org
-RAA14128.773615766/example.org
The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to Tom Recipient <Tom_Recipient@example.org> with subject "Internet FAX Full Mode Content Negotiation" has been received. An alternative form of the message data is requested.
1995年9月20日に00:18:00（EDT）-0400にTomの受信者に送信されたメッセージ<tom_recipient@example.org>「インターネットファックスフルモードコンテンツネゴシエーション」が受信されました。メッセージデータの代替形式が要求されます。
--RAA14128.773615766/example.org Content-Type: message/disposition-notification
-RAA14128.773615766/example.org Content-Type：Message/Dais-Notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200019.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically;
deleted/alternative-preferred
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF)
(| (& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(MRC-mode=0)
(paper-size=[A4,B4])
(ua-media=stationery) )
--RAA14128.773615766/example.org--
-raa14128.773615766/example.org---
Sender's message with enhanced content:
コンテンツを強化した送信者のメッセージ：
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200021.12345@example.com>
Original-Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615768/ example.com"
--RAA14128.773615768/ example.com Content-type: image/tiff Content-Transfer-Encoding: base64
-raa14128.773615768/ example.com Content-Type：Image/ Tiff Content-Transfer-Encoding：base64
[TIFF-FX profile-F message goes here]
[tiff-fxプロフィール-fメッセージはこちらに行く]
--RAA14128.773615768/ example.com--
-raa14128.773615768/ example.com----
Receiver sends MDN confirmation of enhanced message content:
受信者は、拡張されたメッセージコンテンツのMDN確認を送信します。
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
-raa14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom Recipient <Tom_Recipient@example.org> with subject " Internet FAX Full Mode Image Transmission" has been processed in Internet FAX Full Mode.
1995年9月20日に00:21:00（EDT）-0400にTOM受信者に送信されたメッセージ<tom_recipient@example.org>「インターネットファックスフルモード画像伝送」は、インターネットファックスフルモードで処理されています。
--RAA14128.773615769/example.org Content-Type: message/disposition-notification
-RAA14128.773615769/example.org Content-Type：Message/Dais-Notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF)
(| (& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(MRC-mode=0)
(paper-size=[A4,B4])
(ua-media=stationery) )
--RAA14128.773615769/example.org--
-raa14128.773615769/example.org----
This example shows how the second and subsequent transfers between the systems in the previous example might be conducted. Using knowledge gained from the previous exchange, the sender includes profile-F data with its first contact.
この例は、前の例のシステム間の2番目とその後の転送がどのように実行されるかを示しています。以前の交換から得た知識を使用して、送信者には最初の連絡先のプロファイルデータが含まれています。
Sender's initial message:
送信者の最初のメッセージ：
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com Content-type: image/tiff Content-Transfer-Encoding: base64 Content-features: (& (color=Binary) (image-file-structure=TIFF-limited) (dpi=400) (dpi-xyratio=1) (paper-size=A4) (image-coding=MMR) (MRC-mode=0) (ua-media=stationery) ) Content-alternative: (& (color=Binary) (image-file-structure=TIFF-minimal) (dpi=200) (dpi-xyratio=1) (paper-size=A4) (image-coding=MH) (MRC-mode=0) (ua-media=stationery) )
-RAA14128.773615765/ example.com Content-Type：Image/ Tiff Content-Transfer-Encoding：Base64 Content-Features：（＆（color = binary）（image-file-structure = tiff-rimited）（dpi = 400）（dpi-xyratio = 1）（Paper-size = a4）（image-coding = mmr）（mrc-mode = 0）（ua-media = stationer））content-alternative：（＆（color = binary）（image-file-structure = tiff-minimal）（dpi = 200）（dpi-xyratio = 1）（paper-size = a4）（image-coding = mh）（mrc-mode = 0）（ua-media = stationery）））
[TIFF-FX Profile-F message goes here]
[tiff-fxプロフィール-fメッセージはこちらに行く]
--RAA14128.773615765/ example.com--
-raa14128.773615765/ example.com----
Receiver sends MDN confirmation of received message content:
受信者は、受信したメッセージコンテンツのMDN確認を送信します。
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
-raa14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:19:00 (EDT) -0400 to Tom Recipient <Tom_Recipient@example.org> with subject "Internet FAX Full Mode Image Transmission" has been processed in Internet FAX Full Mode.
1995年9月20日に00:19:00（EDT）-0400にTOM受信者に送信されたメッセージ<tom_recipient@example.org>「インターネットファックスフルモード画像伝送」は、インターネットファックスフルモードで処理されています。
--RAA14128.773615769/example.org Content-Type: message/disposition-notification
-RAA14128.773615769/example.org Content-Type：Message/Dais-Notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF)
(| (& (dpi=200) (dpi-xyratio=200/100) )
(& (dpi=200) (dpi-xyratio=1) )
(& (dpi=400) (dpi-xyratio=1) ) )
(| (image-coding=[MH,MR,MMR])
(& (image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(MRC-mode=0)
(paper-size=[A4,B4])
(ua-media=stationery) )
--RAA14128.773615769/example.org--
-raa14128.773615769/example.org----
In this example, the sender has incorrectly assumed that the receiver has a higher capability, and must re-send lower capability data in response to the receiver's response showing lesser capability.
この例では、送信者は、受信者がより高い機能を持っていると誤って想定しており、より少ない機能を示すレシーバーの応答に応じて、より低い機能データを再送信する必要があります。
An Internet fax sends a profile-F (A4, 400x400dpi, MMR) image. When the receiver cannot handle this, it falls back to baseline profile-S. As this is a baseline format, it is not necessary to declare that capability with the original message. When a receiver is faced with data it cannot process from a negotiating sender, it can do no better than to respond with a description of its actual capabilities and let the sender determine the outcome.
インターネットファックスは、プロファイル-F（A4、400x400DPI、MMR）画像を送信します。受信者がこれを処理できない場合、ベースラインプロファイルSに戻ります。これはベースライン形式であるため、元のメッセージでその機能を宣言する必要はありません。レシーバーがデータに直面している場合、交渉の送信者から処理できない場合、実際の機能の説明で応答し、送信者に結果を決定させることよりも良いことはありません。
Sender's initial message:
送信者の最初のメッセージ：
Date: Wed, 20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Negotiate Down
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com Content-type: image/tiff Content-Transfer-Encoding: base64 Content-features: (& (color=Binary) (image-file-structure=TIFF-limited) (dpi=400) (dpi-xyratio=1) (paper-size=A4) (image-coding=MMR) (MRC-mode=0) (ua-media=stationery) )
-RAA14128.773615765/ example.com Content-Type：Image/ Tiff Content-Transfer-Encoding：Base64 Content-Features：（＆（color = binary）（image-file-structure = tiff-rimited）（dpi = 400）（DPI-XYRATIO = 1）（Paper-Size = A4）（Image-Coding = MMR）（MRC-Mode = 0）（UA-Media =文房具））
[TIFF-FX Profile-F message goes here]
[tiff-fxプロフィール-fメッセージはこちらに行く]
--RAA14128.773615765/ example.com--
-raa14128.773615765/ example.com----
Receiver sends MDN response to initial message:
受信者は、最初のメッセージにMDN応答を送信します。
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Negotiate Down
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
--RAA14128.773615766/example.org
-RAA14128.773615766/example.org
The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to Tom Recipient <Tom_Recipient@example.org> with subject "Internet FAX Full Mode Content Negotiation" has been received. An alternative form of the message data is requested.
1995年9月20日に00:18:00（EDT）-0400にTomの受信者に送信されたメッセージ<tom_recipient@example.org>「インターネットファックスフルモードコンテンツネゴシエーション」が受信されました。メッセージデータの代替形式が要求されます。
--RAA14128.773615766/example.org Content-Type: message/disposition-notification
-RAA14128.773615766/example.org Content-Type：Message/Dais-Notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200019.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically;
deleted/alternative-preferred
Media-Accept-Features:
(& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
--RAA14128.773615766/example.org--
-raa14128.773615766/example.org---
Sender's message with baseline content:
ベースラインコンテンツを含む送信者のメッセージ：
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200021.12345@example.com>
Original-Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615768/ example.com"
--RAA14128.773615768/ example.com Content-type: image/tiff Content-Transfer-Encoding: base64
-raa14128.773615768/ example.com Content-Type：Image/ Tiff Content-Transfer-Encoding：base64
[TIFF-FX profile-S message goes here]
[tiff-fxプロファイル-Sメッセージはここにあります]
--RAA14128.773615768/ example.com--
-raa14128.773615768/ example.com----
Receiver sends MDN confirmation of impoverished message content:
受信者は、貧しいメッセージコンテンツのMDN確認を送信します。
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
-raa14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom Recipient <Tom_Recipient@example.org> with subject " Internet FAX Full Mode Image Transmission" has been processed in Internet FAX Full Mode.
1995年9月20日に00:21:00（EDT）-0400にTOM受信者に送信されたメッセージ<tom_recipient@example.org>「インターネットファックスフルモード画像伝送」は、インターネットファックスフルモードで処理されています。
--RAA14128.773615769/example.org
Content-Type: message/disposition-notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(& (color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
--RAA14128.773615769/example.org--
-raa14128.773615769/example.org----
As noted in section 4, the sender can offer the data using a different MIME content-type. This example shows a profile-F (A4, 400x400dpi, MMR) image and a limited-colour PDF document offered as alternatives to a baseline image/TIFF.
セクション4で述べたように、送信者は異なるMIMEコンテンツタイプを使用してデータを提供できます。この例は、プロファイル-F（A4、400x400DPI、MMR）画像と、ベースライン画像/TIFFの代替として提供される限られた色PDFドキュメントを示しています。
Sender's initial message:
送信者の最初のメッセージ：
(Note that the MIME content type is not specified for the image/tiff alternative, being the same as that provided, but is mentioned for the application/pdf alternative.)
（MIMEコンテンツタイプは、画像/TIFFの代替品には指定されておらず、提供されたものと同じであるが、アプリケーション/PDFの代替案で言及されていることに注意してください。）
Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com Content-type: image/tiff Content-Transfer-Encoding: base64 Content-features: (& (color=Binary) (image-file-structure=TIFF-minimal) (dpi=200) (dpi-xyratio=1) (paper-size=A4) (image-coding=MH) (MRC-mode=0) (ua-media=stationery) ) Content-alternative: (& (color=Binary) (image-file-structure=TIFF-limited) (dpi=400) (dpi-xyratio=1) (paper-size=A4) (image-coding=MMR) (MRC-mode=0) (ua-media=stationery) ) Content-alternative: (& (type="application/pdf") (color=Limited) (dpi=400) (paper-size=A4) (ua-media=stationery) )
-RAA14128.773615765/ example.com Content-Type：Image/ Tiff Content-Transfer-Encoding：Base64 Content-Features：（＆（color = binary）（image-file-structure = tiff-minimal）（dpi = 200）（dpi-xiratio = 1）（Paper-size = a4）（image-coding = mh）（mrc-mode = 0）（ua-media = stationer））content-alternative：（＆（color = binary）（yigas-file-structure = tiff-rimited）（dpi = 400）（dpi-xyratio = 1）（paper-size = a4）（image-coding = mmr）（mrc-mode = 0）（ua-media = stationer））-alternative：（＆（type = "application/pdf"）（color = limited）（dpi = 400）（paper-size = a4）（ua-media =文房具））
[TIFF-FX Profile-S message goes here]
[tiff-fxプロファイル-Sメッセージはここにあります]
--RAA14128.773615765/ example.com--
-raa14128.773615765/ example.com----
Receiver sends MDN response to initial message:
受信者は、最初のメッセージにMDN応答を送信します。
(Note that this response indicates an ability to handle the PDF MIME content-types, but with only binary colour.)
（この応答は、PDF MIMEコンテンツタイプを処理する能力を示していることに注意してください。
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Content Negotiation
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
--RAA14128.773615766/example.org
-RAA14128.773615766/example.org
The message sent on 1995 Sep 20 at 00:18:00 (EDT) -0400 to Tom Recipient <Tom_Recipient@example.org> with subject "Internet FAX Full Mode Content Negotiation" has been received. An alternative form of the message data is requested.
1995年9月20日に00:18:00（EDT）-0400にTomの受信者に送信されたメッセージ<tom_recipient@example.org>「インターネットファックスフルモードコンテンツネゴシエーション」が受信されました。メッセージデータの代替形式が要求されます。
--RAA14128.773615766/example.org Content-Type: message/disposition-notification
-RAA14128.773615766/example.org Content-Type：Message/Dais-Notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200019.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically;
deleted/alternative-preferred
Media-Accept-Features:
(| (& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(image-coding=MH)
(MRC-mode=0)
(paper-size=A4)
(ua-media=stationery) )
(& (type="application/pdf")
(color=Binary)
(dpi-xyratio=1)
(dpi=[200,400])
(paper-size=[A4,B4])
(ua-media=stationery) ) )
--RAA14128.773615766/example.org--
-raa14128.773615766/example.org---
Resend with alternative content-type:
代替コンテンツタイプの再送信：
Date: Wed,20 Sep 1995 00:21:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200021.12345@example.com>
Original-Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Image Transmission
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615768/ example.com"
--RAA14128.773615768/ example.com Content-type: application/pdf Content-Transfer-Encoding: base64
-RAA14128.773615768/ example.com Content-Type：Application/ PDF Content-Transfer-Encoding：base64
[PDF data goes here]
[PDFデータはここに行きます]
--RAA14128.773615768/ example.com--
-raa14128.773615768/ example.com----
Receiver sends MDN confirmation of enhanced message content:
受信者は、拡張されたメッセージコンテンツのMDN確認を送信します。
(Also indicating the PDF capability for future messages.)
（将来のメッセージのPDF機能も示しています。）
Date: Wed,20 Sep 1995 00:22:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200022.12345@example.org>
Subject: Re: Internet FAX Full Mode Image Transmission
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615769/example.org"
--RAA14128.773615769/example.org
-raa14128.773615769/example.org
The message sent on 1995 Sep 20 at 00:21:00 (EDT) -0400 to Tom Recipient <Tom_Recipient@example.org> with subject " Internet FAX Full Mode Image Transmission" has been processed in Internet FAX Full Mode.
1995年9月20日に00:21:00（EDT）-0400にTOM受信者に送信されたメッセージ<tom_recipient@example.org>「インターネットファックスフルモード画像伝送」は、インターネットファックスフルモードで処理されています。
--RAA14128.773615769/example.org Content-Type: message/disposition-notification
-RAA14128.773615769/example.org Content-Type：Message/Dais-Notification
Reporting-UA: Toms-pc.cs.example.org; IFAX-FullMode
Original-Recipient: rfc822;Tom-Recipient@example.org
Final-Recipient: rfc822;Tom-Recipient@example.org
Original-Message-ID: <199509200021.12345@example.com>
Disposition: automatic-action/MDN-sent-automatically; processed
Media-Accept-Features:
(| (& (type="image/tiff")
(color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(image-coding=MH)
(MRC-mode=0)
(paper-size=A4)
(ua-media=stationery) )
(& (type="application/pdf")
(color=Binary)
(dpi-xyratio=1)
(dpi=[200,400])
(paper-size=[A4,B4])
(ua-media=stationery) ) )
--RAA14128.773615769/example.org--
-raa14128.773615769/example.org----
This specification defines new email/MIME message headers:
この仕様では、新しい電子メール/MIMEメッセージヘッダーを定義します。
Content-alternative Original-Message-ID
Content-Alternative Original-Message-ID
As such, there being no registry of email headers, it is an update to the specifications of RFC 2822 and RFC 2045.
そのため、電子メールヘッダーのレジストリはありません。これは、RFC 2822およびRFC 2045の仕様の更新です。
This specification defines extensions to the Message Disposition Notification (MDN) protocol. The sections below are the registration templates for these extensions, as required by RFC 2298 [4], section 10.
この仕様では、メッセージ処分通知（MDN）プロトコルへの拡張機能を定義します。以下のセクションは、RFC 2298 [4]、セクション10で要求されるように、これらの拡張機能の登録テンプレートです。
(a) Disposition-notification-option name: Alternative-available
(a) 気質 - 解釈 - オプション名：代替利用可能
(b) Syntax: (see this document, section 6.1)
(b) 構文：（このドキュメント、セクション6.1を参照）
(c) Character-encoding: US-ASCII characters only are used
(c) キャラクターエンコード：US-ASCII文字は使用されます
(d) Semantics: (see this document, section 6.1)
(d) セマンティクス：（このドキュメント、セクション6.1を参照）
(a) Disposition-notification-option name: Alternative-not-available
(a) 気質 - 解釈 - オプション名：代替手段で利用できません
(b) Syntax: (see this document, section 6.1)
(b) 構文：（このドキュメント、セクション6.1を参照）
(c) Character-encoding: US-ASCII characters only are used
(c) キャラクターエンコード：US-ASCII文字は使用されます
(d) Semantics (see this document, section 6.3)
(d) セマンティクス（このドキュメント、セクション6.3を参照）
(a) Disposition-modifier name: Alternative-preferred
(a) 処分モジー名：代替プロファリー
(b) Semantics: (see this document, section 6.2)
(b) セマンティクス：（このドキュメント、セクション6.2を参照）
(a) Disposition-modifier name: Original-lost
(a) 処分モジーの名前：元のロスト
(b) Semantics: (see this document, section 6.4)
(b) セマンティクス：（このドキュメント、セクション6.4を参照）
This specification deals with protocol exchanges between mail user agents, and as such does not deal primarily with human readable text. But not all user agents may automatically handle the protocol elements defined here, and may attempt to display text from the protocol elements to the user.
この仕様は、メールユーザーエージェント間のプロトコル交換を扱うため、主に人間の読み取り可能なテキストを扱っていません。ただし、すべてのユーザーエージェントがここで定義されているプロトコル要素を自動的に処理するわけではなく、プロトコル要素からユーザーにテキストを表示しようとする場合があります。
The main candidate for this treatment is the text accompanying a disposition notification response that requests alternative information. In normal use, the protocol design ensures that the recipient can process this response automatically; exceptionally, a receiving agent may display it to a user.
この治療の主な候補は、代替情報を要求する気質通知応答に伴うテキストです。通常の使用では、プロトコル設計により、受信者がこの応答を自動的に処理できるようになります。例外的には、受信エージェントがユーザーに表示する場合があります。
Security considerations of this specification can be divided into two main areas:
この仕様のセキュリティ上の考慮事項は、2つの主要な領域に分類できます。
o Privacy concerns with automated MDN response generation: see section 6.5 of this document, and the security considerations section of RFC 2298 [4].
o 自動化されたMDN応答生成に関するプライバシーの懸念：このドキュメントのセクション6.5およびRFC 2298のセキュリティに関する考慮事項セクション[4]を参照してください。
o Risks of negotiation: see the security considerations section transaction. If alternative data arrives subsequently, it may be ignored or possibly also displayed or printed. A successful completion MDN may be sent to the sender.
o 交渉のリスク：セキュリティ上の考慮事項セクショントランザクションを参照してください。その後、代替データが到着した場合、無視されるか、表示または印刷される場合があります。正常な完了MDNを送信者に送信することができます。
The basic structure of the negotiation described here was first documented in a draft by Mr. Toru Maeda of Canon.
ここで説明する交渉の基本構造は、最初にキヤノンのトルメダ氏によってドラフトに記録されました。
Helpful comments on earlier drafts were provided by Mr Hiroshi Tamura, Ted Hardie and Larry Masinter.
初期のドラフトに関する有益なコメントは、田村ヒロシ氏、テッド・ハーディ、ラリー・マシン氏によって提供されました。
[1] Masinter, L. and D. Wing, "Extended Facsimile using Internet Mail", RFC 2532, March 1999.
[1] Masinter、L。およびD. Wing、「インターネットメールを使用した拡張ファクシミリ」、RFC 2532、1999年3月。
[2] Wing, D., "Indicating Supported Media Features Using Extensions to DSN and MDN", RFC 2530, March 1999.
[2] Wing、D。、「DSNおよびMDNへの拡張機能を使用したサポートされているメディア機能を示す」、RFC 2530、1999年3月。
[3] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999.
[3] Masinter、L。、「インターネットファックスの用語と目標」、RFC 2542、1999年3月。
[4] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[4] Fajman、R。、「メッセージ処分通知のための拡張可能なメッセージ形式」、RFC 2298、1998年3月。
[5] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag Registration Procedure", RFC 2506, March 1999.
[5] Holtman、K.、Mutz、A。、およびT. Hardie、「メディア機能タグ登録手順」、RFC 2506、1999年3月。
[6] Klyne, G., "A syntax for describing media feature sets", BCP 31, RFC 2533, March 1999.
[6] Klyne、G。、「メディア機能セットを説明するための構文」、BCP 31、RFC 2533、1999年3月。
[7] Klyne, G., "Indicating media features for MIME content", RFC 2938, September 2000.
[7] Klyne、G。、「MIMEコンテンツのメディア機能を示す」、RFC 2938、2000年9月。
[8] 'Content-alternative' header (this memo, section 4)
[8] 「コンテンツ代替」ヘッダー（このメモ、セクション4）
[9] MDN extension for alternative data (this memo, section 6)
[9] 代替データのMDN拡張機能（このメモ、セクション6）
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[10] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[11] McIntyre, L., Buckley, R., Venable, D., Zilles, S., Parsons, G. and J. Rafferty, "File format for Internet fax", RFC 2301, March 1998.
[11] McIntyre、L.、Buckley、R.、Venable、D.、Zilles、S.、Parsons、G。and J. Rafferty、「Internet Faxのファイル形式」、RFC 2301、1998年3月。
[12] Toyoda K., Ohno H., Murai, J. and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998.
[12] Toyoda K.、Ohno H.、Murai、J。、およびD. Wing、「インターネットメールを使用したファクシミリの単純なモード」、RFC 2305、1998年3月。
[13] 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.
[13] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[14] Holtman, K. and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998.
[14] Holtman、K。およびA. Mutz、「HTTPの透明なコンテンツ交渉」、RFC 2295、1998年3月。
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part 2: Media types", RFC 2046, November 1996.
[15] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[16] Klyne, G. and L. McIntyre, "Content feature schema for Internet fax V2", RFC 2879, August 2000.
[16] Klyne、G。およびL. McIntyre、「インターネットFAX V2のコンテンツ機能スキーマ」、RFC 2879、2000年8月。
[17] Klyne, G., "Protocol-independent Content Negotiation Framework", RFC 2703, September 1999.
[17] Klyne、G。、「プロトコルに依存しないコンテンツネゴシエーションフレームワーク」、RFC 2703、1999年9月。
[18] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
[18] ムーア、K。、「配信ステータス通知のSMTPサービス拡張」、RFC 1891、1996年1月。
[19] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[19] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[20] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[20] Resnick、P。、「インターネットメッセージフォーマット」、RFC 2822、2001年4月。
[21] Klyne, G. and D. Crocker, "Timely Delivery for Facsimile Using Internet Mail", Work in Progress.
[21] Klyne、G。およびD. Crocker、「インターネットメールを使用したファクシミリのタイムリーな配信」、進行中の作業。
[22] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[22] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[23] 'Original-Message-ID' header for mail messages (this memo, section 5)
[23] メールメッセージの「Original-Message-ID」ヘッダー（このメモ、セクション5）
[24] Klyne, G., "MIME Content Types in Media Feature Expressions", RFC 2913, September 2000.
[24] Klyne、G。、「メディア機能表現のMIMEコンテンツタイプ」、RFC 2913、2000年9月。
Appendix A: Implementation issues
付録A：実装の問題
This section is not a normative part of this specification. Rather, it discusses some of the issues that were considered during its design in a way that we hope will be useful to implementers.
このセクションは、この仕様の規範的な部分ではありません。むしろ、設計中に考慮された問題のいくつかについて、実装者にとって有用であることを期待しています。
Probably the biggest implication for implementers of this proposal compared with standard mail user agents is the need to maintain some kind of state information at the receiver while content is being negotiated.
おそらく、標準のメールユーザーエージェントと比較したこの提案の実装者にとって最大の意味は、コンテンツが交渉中にある種の状態情報を受信者に維持する必要性です。
By "receiver state", we mean that a receiver needs to remember that it has received an initial message AND that it has requested an alternative form of data. Without this, when a receiver responds with a request for an alternative data format there is a possibility (if the response does not reach the sender) that the message will be silently lost, despite its having been delivered to the receiving MTA.
「受信者状態」とは、受信者が最初のメッセージを受信したことを覚えておく必要があり、代替形式のデータを要求したことを意味します。これがないと、受信者が代替データ形式のリクエストで応答すると、受信MTAに配信されたにもかかわらず、メッセージが静かに失われる可能性があります（送信者に届かない場合）。
The matter of maintaining receiver state is particularly germane because of the requirement to allow low-memory systems to participate in the content negotiation. Unlike traditional T.30 facsimile, where the negotiation takes place within the duration of a single connection, an extended time may be taken to complete a negotiation in email. State information must be maintained for all negotiations outstanding at any time, and there is no theoretical upper bound on how many there may be.
レシーバー状態を維持する問題は、低メモリシステムがコンテンツの交渉に参加できるようにするための要件のために特に密接に関係しています。単一の接続の期間内に交渉が行われる従来のT.30ファクシミリとは異なり、電子メールの交渉を完了するために長時間となる場合があります。国家情報は、いつでも未払いのすべての交渉について維持する必要があり、何があるかについての理論上の上限はありません。
Keeping receiver state is probably not a problem for systems with high capacity storage devices to hold message data and state information. The remainder of this section discusses strategies that small-system designers might employ to place an upper bound on memory that must be reserved for this information. When a receiver is really memory constrained then message loss remains a possibility, but the mechanisms described here should ensure that it never happens silently.
受信者状態を維持することは、おそらく、大容量ストレージデバイスを備えたシステムがメッセージデータと状態情報を保持する問題ではないでしょう。このセクションの残りの部分では、小型システム設計者がこの情報のために予約する必要があるメモリに上限を配置するために採用する戦略について説明します。レシーバーが実際にメモリが制約されている場合、メッセージの損失は可能性がありますが、ここで説明するメカニズムは、それが静かに起こらないことを保証する必要があります。
So what is this "receiver state"? It must contain, as a minimum:
では、この「受信者状態」とは何ですか？最小限に抑える必要があります。
o the fact that message data was received, and alternative data has been requested,
o メッセージデータが受信され、代替データが要求されたという事実、
o a unique message identifier, and
o 一意のメッセージ識別子、および
o the time at which an alternative format request was sent.
o 代替形式のリクエストが送信された時間。
This allows the receiver to re-issue a request, or to report an error, if requested alternative data does not arrive in a reasonable time.
これにより、レシーバーがリクエストを再発行したり、要求された代替データが合理的な時間に到着しない場合、エラーを報告することができます。
Receiver state may also include:
受信者状態には以下も含まれます。
o a copy of the data originally received. This allows the receiver to display the original data if an alternative is not received.
o 当初受け取ったデータのコピー。これにより、代替案が受信されない場合は、受信機が元のデータを表示できます。
o details of the data format supplied, and alternatives offered. This permits improved diagnostics if alternative data is not received.
o 提供されたデータ形式の詳細、および提供される代替案。これにより、代替データが受信されない場合、診断が改善されます。
If a receiver of a message with alternative content available does not have enough memory to hold new negotiation state information, it may fall back to non-negotiation behaviour, accept the data received and send an MDN indicating disposition of that data (see sections 3.2.1, 3.2.2).
利用可能な代替コンテンツを含むメッセージの受信者が新しいネゴシエーション状態情報を保持するのに十分なメモリを持っていない場合、非交渉動作に戻り、受信したデータを受け入れ、そのデータの処分を示すMDNを送信する可能性があります（セクション3.2を参照してください。1、3.2.2）。
If a receiving system runs low on memory after entering into a negotiation, a number of options may be possible:
受信システムが交渉に入った後にメモリが低い場合、多くのオプションが可能になる場合があります。
o display or print buffered data, if available, and complete the transaction. If alternative data arrives subsequently, it may be ignored or possibly also displayed or printed. A successful completion MDN may be sent to the sender.
o 利用可能な場合はバッファーデータを表示または印刷し、トランザクションを完了します。その後、代替データが到着した場合、無視されるか、表示または印刷される場合があります。正常な完了MDNを送信者に送信することができます。
o discard any buffered data, and continue waiting for alternative data. If alternative data does not subsequently arrive, a message transfer failure should be declared.
o バッファーデータを破棄し、代替データを待ち続けます。代替データがその後到着しない場合、メッセージ転送の障害を宣言する必要があります。
o abort the transfer and declare a message transfer failure: a diagnostic message must be displayed to the local user, and a failure notification sent to the sender.
o 転送を中止し、メッセージ転送の失敗を宣言します。診断メッセージをローカルユーザーに表示し、送信者に送信された失敗通知を表示する必要があります。
If a receiver is capable of buffering received message data while waiting for an alternative, this is to be preferred because it retains the option to display that data if an alternative is not received (see above).
受信者が代替案を待っている間に受信したメッセージデータをバッファリングできる場合、代替手段が受信されない場合にそのデータを表示するオプションを保持するため、これは推奨されます（上記を参照）。
Partial message data should not be buffered for this purpose: displaying part of the original message is not an allowable substitute for displaying all of the received data. (There may be some value in keeping some of the original message data for diagnostic purposes.) If a receiver starts to buffer message data pending negotiation, then finds that the entire message is too large to buffer, it may choose to fall back to "extended mode" and display the incoming data as it is received.
この目的のために部分的なメッセージデータをバッファリングしてはなりません。元のメッセージの一部を表示することは、受信したすべてのデータを表示するための許容可能な代替ではありません。（診断目的で元のメッセージデータの一部を維持することにはある程度の価値があるかもしれません。）レシーバーがメッセージデータを保留中のメッセージデータのバッファーを開始すると、メッセージ全体がバッファーできないほど大きすぎることがわかります。拡張モード」と、受信中に着信データを表示します。
When a sender indicates availability of alternative data, it also indicates whether it is permanently or transiently available. The intent of this is that if alternative data is transient, a receiver should not discard original data received. If necessary, it should simply display the original data without requesting an alternative.
送信者が代替データの可用性を示す場合、それが永続的にまたは一時的に利用可能かを示します。これの目的は、代替データが一時的な場合、受信者は受信した元のデータを破棄しないでください。必要に応じて、代替案を要求せずに元のデータを単に表示する必要があります。
When a sender indicates that it can offer an alternative format of message content, it accepts some responsibility for trying to ensure that alternative is available if requested. Thus, the message content (both original and any alternative) should be stored for a reasonable period, together with any corresponding Message-ID value(s).
送信者がメッセージコンテンツの代替形式を提供できることを示す場合、要求された場合に代替が利用可能であることを確認するための責任を受け入れます。したがって、メッセージコンテンツ（オリジナルと代替の両方）は、対応するメッセージ-ID値とともに、合理的な期間にわたって保存する必要があります。
A request for retransmission must be accompanied by an Original-Message-ID value that the sender can use to correlate with the message data originally sent.
再送信のリクエストには、送信者が最初に送信したメッセージデータと相関するために使用できる元のメッセージ-ID値を添付する必要があります。
If the sender is operating with a high capacity message storage device (e.g., a disk drive), and normally holds the data for extended periods (several days or weeks) then it should indicate that the alternative data is permanently available (see 6.1): a recipient seeing this may discard the original data, assuming that the sender will most likely be able to re-transmit.
送信者が大容量のメッセージストレージデバイス（ディスクドライブなど）で動作し、通常はデータを長期間（数日または数週間）保持している場合、代替データが永続的に利用可能であることを示す必要があります（6.1を参照）。これを見ている受信者は、送信者がおそらく再送信できる可能性が高いと仮定して、元のデータを破棄する可能性があります。
If the sender has limited memory capacity, and is likely to be able to hold the data for no more than a few minutes or hours, it should indicate that the alternative data is transiently available (see 6.1). If there is doubt about a sender's ability to keep the message content, it should indicate that availability of any alternative is transient.
送信者のメモリ容量が限られており、数分または時間以内にデータを保持できる可能性が高い場合、代替データが一時的に利用可能であることを示す必要があります（6.1を参照）。メッセージコンテンツを保持する送信者の能力に疑問がある場合、代替案の可用性が一時的であることを示す必要があります。
It should not be assumed that receiver capabilities declared during negotiation are available indefinitely.
交渉中に宣言されたレシーバー機能が無期限に利用可能であると想定すべきではありません。
In particular, any receiver capabilities declared on a final message confirmation should be regarded as definitive, even if they differ from the capabilities associated with the message just accepted. These may be stored for future use.
特に、最終的なメッセージ確認で宣言されたレシーバー機能は、受け入れられたメッセージに関連付けられた機能と異なる場合でも、決定的なものと見なされるべきです。これらは、将来の使用のために保存される場合があります。
Any receiver capabilities declared when requesting an alternative format should not be stored for future use, as the receiver might be selective about the purposes for which those capabilities may be used.
レシーバーは、それらの機能が使用される可能性のある目的について選択的である可能性があるため、代替形式を要求する際に宣言されたレシーバー機能は将来の使用のために保存されるべきではありません。
Some of the issues of sender state maintenance may be simplified if content negotiation is used in conjunction with a facility for timely delivery (e.g., [21]). If there is a known time window within which a response should be received, the sender may be less conservative about keeping information about outstanding offers of alternative data for extended periods. A sender that exploits timely delivery in this way should indicate that the alternative is transiently available.
コンテンツネゴシエーションがタイムリーな配信のために施設と併用して使用される場合、送信者状態のメンテナンスの問題のいくつかは単純化される場合があります（例：[21]）。応答を受信する必要がある既知の時間ウィンドウがある場合、送信者は、長期にわたって代替データの未払いのオファーに関する情報を保持することについて保守的ではない場合があります。この方法でタイムリーな配信を悪用する送信者は、代替が一時的に利用可能であることを示す必要があります。
Ephemeral capabilities may present some special problems. Consider the case of selection of a particular content variant that may depend on an ephemeral setting.
一時的な能力は、いくつかの特別な問題を提示する可能性があります。一時的な設定に依存する可能性のある特定のコンテンツバリアントの選択の場合を考えてください。
Imagine someone sending a basic fax to a color fax machine, indicating that a color alternative is available. The color fax discards the content and sends an MDN which says "deleted/alternative-preferred" to the originator. It then runs out of colored ink. The originating fax then sends a new message which the colored fax cannot print.
カラーファックスマシンに基本的なファックスを送信する人を想像してください。カラーファックスはコンテンツを破棄し、オリジネーターに「削除/代替プロファリーされた」というMDNを送信します。その後、色付きのインクがなくなります。その後、発信元のFAXは、色付きのファックスが印刷できない新しいメッセージを送信します。
Or consider an the email client in a phone with sound on/off as a related problem. When sound is ON, the phone may be able to accept voice messages by email.
または、関連する問題としてサウンドのオン/オフを備えた電話の電子メールクライアントを考慮してください。音がオンになっている場合、電話は電子メールで音声メッセージを受け入れることができる場合があります。
This negotiation framework has not been designed with ephemeral capabilities in mind, but, with care, may be adaptable to deal with them.
このネゴシエーションフレームワークは、一時的な能力を念頭に置いて設計されていませんが、注意を払って、それらに対処するために適応できる場合があります。
Bearing in mind privacy concerns, implementers should be careful that systems do not automatically enter into a negotiation exchange in a way that may disclose the recipient's whereabouts without first having obtained explicit permission. For example, if receiving a message depends in any way on the user's physical presence, automatic negotiation should not be performed.
プライバシーの懸念を念頭に置いて、実装者は、システムが最初に明示的な許可を取得せずに受信者の居場所を開示する可能性のある方法で自動的に交渉交換に入らないことに注意する必要があります。たとえば、メッセージを受信すると、ユーザーの物理的存在に依存する場合、自動交渉は実行されないでください。
While it may be OK for an unattended fax machine to perform automated negotiation, it is not OK for a PC software package to do so without the users explicit permission as the PC may be switched on only when the user is present. This suggests that default settings in this regard should take account of the type of system.
無人のファックスマシンが自動化されたネゴシエーションを実行することは問題ない場合がありますが、PCが存在する場合にのみPCがオンになる可能性があるため、ユーザーが明示的に許可せずにPCソフトウェアパッケージを行うことは問題ありません。これは、この点でデフォルト設定がシステムのタイプを考慮する必要があることを示唆しています。
Appendix B: Candidates for further enhancements
付録B：さらなる機能強化の候補者
This appendix lists some possible features of content negotiation that were considered, but not included in the current specification. In most cases the reasons for exclusion were (a) that they could introduce unanticipated additional complexities, and (b) no compelling requirement was recognized.
この付録には、考慮されたが現在の仕様には含まれていないコンテンツネゴシエーションのいくつかの可能な機能がリストされています。ほとんどの場合、除外の理由は（a）予期せぬ追加の複雑さを導入できることであり、（b）説得力のある要件が認識されなかったということでした。
o Cache control indicator for recipient capabilities. This would instruct the sender, or other message system component, that capability information in the current message is for the current transaction only, and should NOT be remembered for future transactions. E.g., a recipient may not wish colour capability to be used for routine communications. (See also section A.5 above.)
o 受信者機能のキャッシュ制御インジケーター。これにより、送信者または他のメッセージシステムコンポーネントに、現在のメッセージの機能情報は現在のトランザクション専用であり、将来のトランザクションで記憶されるべきではありません。たとえば、受信者は、日常的な通信に色の能力を使用することを望んでいない場合があります。（上記のセクションA.5も参照してください。）
o Use of q-values [6] in media feature expressions for indicating preference among alternatives available and/or receiver preferences.
o メディアでのQ値[6]の使用は、利用可能な代替案および/または受信機の好みの中で優先性を示すための表現を特徴としています。
o Partial re-sends. There are proposals being developed for "partial MDN" responses that can indicate disposition status on a per-message-part basis. This opens the possibility of partial re-sends when alternative formats are requested for only some of the message body parts. The current specification assumes that either none or all of message is re-sent when content negotiation is used.
o 部分的な再センド。「部分的なMDN」応答のための提案が開発されており、それは1人あたりのパートベースで気質の状態を示すことができます。これにより、メッセージボディの一部のみに対して代替形式が要求される場合、部分的な再除去の可能性が開きます。現在の仕様では、コンテンツネゴシエーションが使用されると、メッセージのいずれかまたはすべてが再セントされることを前提としています。
o Allow negotiation with parties other than originally addressed recipients of a message.
o 最初に扱われた受信者以外の関係者との関係者との交渉を許可します。
o Negotiation response might indicate different receiver endpoint with different capabilities.
o 交渉の応答は、異なる機能を備えた異なる受信機エンドポイントを示している可能性があります。
Authors' Addresses
著者のアドレス
Graham Klyne (editor) Clearswift Corporation, 1310 Waterside, Arlington Business Park Theale Reading, RG7 4SA United Kingdom
Graham Klyne（編集者）Clearswift Corporation、1310 Waterside、Arlington Business Park Theale Reading、RG7 4SA英国
Phone: +44 11 8903 8903
Fax: +44 11 8903 9000
EMail: GK@ACM.ORG
Ryuji Iwazaki TOSHIBA TEC CORPORATION 2-4-1, Shibakoen, Minato-ku, Tokyo, 105-8524 Japan
リュウジ岩崎東shiba Tec Corporation 2-4-1、七koen、鉱物、東京、105-8524日本
Phone: +81 3 3438 6866
Fax: +81 3 5402 6355
EMail: iwa@rdl.toshibatec.co.jp
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale、CA 94086 USA
Phone: +1 408 246 8253
Fax: +1 408 249 6205
EMail: dcrocker@brandenburg.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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 assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
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エディター機能の資金は現在、インターネット協会によって提供されています。