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.
著作権（C）インターネット協会（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.
多くの通信は、指定された送信者と受信者の間の一回限りまたは不定期転送され、そしてこの「より良い次回を行う」アプローチの恩恵を受けることができません。
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.
電子メールで利用可能な代替施設（広く実装されていないが）送信者がいくつかの異なる形式でメッセージを送信し、受信機が選択できるようにする「マルチパート/代替」[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節では、元のメッセージデータとの交渉の際に送られた代替データを相関させるために、新しいトランザクションを開始してから古いメッセージトランザクションの継続を区別するために使用され、「オリジナル・メッセージID」、新しいメールメッセージのヘッダを記述します。
Section 6 describes extensions to the Message Disposition Notification (MDN) framework [4] that support negotiation between the communicating parties.
セクション6 [4]通信当事者間の交渉をサポートするメッセージ気質通知（MDN）フレームワークへの拡張を記述しています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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}の表記は、[3] "インターネットファックスのための用語と目標"、RFC 2542ごとに、使用されています。これらの表記に関連付けられた意味は、以下のとおりです。
{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.
インターネットメールを使用してファクシミリサービスを定義する作業の目標の一つは、電子メール環境での伝統的なグループ3 FAXサービスのメリットを提供することでした。従来のグループ3ファックスは、任意のメッセージデータが送信される前に、情報のオンライン交換が送信者に受信者の能力が開示されているという考えに大きく傾いています。
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 FAXとインターネットメールを保証するために、いくつかのベースライン形式（すなわち、基本的な画像フォーマットや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.
この仕様によって対処課題の一つは、ファックスなどのサービスを提供するために、電子メール環境を適合させる方法です。送信者は、受信機は、単純な電子メールメッセージ以外のものを認識することができます任意の先験的な仮定をしてはなりません。基本的にメッセージパッシングとコンテンツネゴシエーション（特にメーリングリスト）のファックス・モデルと互換性のない電子メールのいくつかの重要な用途があります。だから我々は、既存の電子メールモデルを壊すことなく、コンテンツの交渉が可能な場合に認識の方法を持っている必要があります。
"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.
この機構は、メッセージが受信され、処理された後に開示されるべき受信機機能を提供します。この情報は、同一の受信機への後続の送信のために使用することができます。しかし、多くの通信は、所与の受信機に与えられた送信者からの一回限りのメッセージであり、この恩恵を受けることはできません。
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.
クラシックインターネットメールは、「オープンループ」プロセスである：何の情報は、メッセージが送信された時点に戻されません。これはunkindly - しかしaccurately--それは確認を欠いているので、「送っと祈る」として特徴づけられています。
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:
三つの異なるループは、コンテンツネゴシエーションで識別することができます。
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}は、任意の強化コンテンツ特徴は、インターネットファックスシステムで使用されることを可能にするメカニズムを提供することです。機構は、{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）を採用した溶液を、{3}、同じデータの複数のバージョンを送信してはなりません。特に、それは{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）古いキャッシュ情報から優雅な回復のために許可します。送信者は、最初のメッセージを非ベースライン・データを送信するために、歴史的な情報を使用することがあります。これは、受信者によって使用不能であることが判明した場合、まだベースラインデータ、またはいくつかの他の許容される形式のために、選択および転送する{3}可能であるべきです。
(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）の指示と初期メッセージデータを送信します。初期データは、ベースラインまたは受信者が扱うことができるものの他のいくつかの推測しているかもしれません。
(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）が提供される代替案を認識し、それが別の形式を受け取ることを好むと判定する。送信者が適切な代替（セクション3.2.3）を選択できるようにMDN応答は、元のデータが処理されなかったことを示す（I）、及び（ii）を含む受信機機能情報を送信します。
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.
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.
代替的なデータ形式の好みを示すMDN応答を受信3.、送信者は、選択して受信機の宣言された機能に合わせたメッセージデータを送信、または受信機の要求が受け入れられないことを表示を送信しなければなりません。代替データを送信する際、送信者は、代替データが利用可能であることの表示を抑制し、その交渉プロセスがループすることはできません。
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.
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サーバで駆動ネゴシエーションと同様です。これは、[14]透明コンテンツネゴシエーションの一部として、HTTPのために提供交渉エージェント駆動スタイルに区別され、又は「マルチパート/代替」と「message / external-body」という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）適切な「コンテンツ・機能」ヘッダ（S）[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
「代替利用可能な」MDNオプションフィールドを使用して、（E）は、それが異なるメッセージデータを送信するために用意されていることを示す、[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]。注意：複数のContent-代替」ヘッダを指定することができます。詳細については、セクション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).
通常のデフォルトの形式はtext / plainです。これは、送信者が事前知識または受信者でサポートされている他のコンテンツ形式の期待を持っていない限り、送信されたフォーマットです。電子メールのいくつかの使用は、いくつかの他の既定の形式を推定（例えば、インターネットを完備ファックス[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要求と[9]「代替的に入手可能な」MDNオプションを含めることによって、別のメッセージデータを送信するための準備を示しています。このMDN要求オプションの存在は、単に送信者が、それは、受信機の機能について、より正確または最新の情報を持っている場合、いくつかの異なるデータ形式を送信する用意があることを示しています。その情報は、「コンテンツの代替」ヘッダ（S）によって提供される[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.
送信者は、別のデータが使用可能なメッセージボディ部、利用可能な代替のそれぞれを示すメディア機能[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.
別のデータ・フォーマットの指示なしにメッセージデータを受信するネゴシエーション認識システムは、標準のインターネットファックスシステムまたは電子メールユーザエージェントと同様に、そのメッセージを処理しなければなりません。
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.
これは、受信機は、シンプルモードインターネットFAXの受信者[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のオプションが含まれている場合にのみ従うことができる（代替データの再送信は、このオプションを使用することはできません）。 （：、「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:
受信機は、別のデータが利用可能であり、提供された情報に基づいて、別の形式は好ましいであろうことを決定することを認識する。以下を含まなければならない[4]が送信されるMDN応答：
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「原稿メッセージID：」フィールド[4]受信したメッセージからメッセージ識別子を持つと
o receiver capabilities, per RFC 2530 [2].
RFC 2530あたりO受信機能、[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）は、一貫した方法で既存のe-メール機構に基づいて構築、および
(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.
代替データに対する要求に応答して受信機に送信されたメッセージを含まなければならない」オリジナル・メッセージIDを：「Message-で受信配置通知メッセージ（からオリジナルメッセージ-ID値を含むヘッダ[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].
、データの最終的な配置を示すMDN応答を受信し、また使用することができる能力を示す生成データおよび受信プロセスを：再送データ（ヘッダ・フィールド「オリジナルメッセージ-ID」の存在によって示される）受信された場合将来のメッセージに対して、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）は、メッセージを受信し、ディスプレイ又はプロセス失敗を、OR
(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.
「コンテンツの代替：」ヘッダは、それが含まれているデータのいくつかの代替形態の利用可能性を示すために、MIME本体部分に取り付けることができるMIMEヘッダです。このヘッダは、それ自身の、データの別の形態は、アクセスすることができる方法を示していません。
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
コンテンツの代替ヘッダ=の "Content-代替" "：" オルタナティブ・機能・表現
Alternative-feature-expression = <As defined for 'Filter' by RFC 2533 [6]>
代替的な特徴表現= <RFC 2533によって「フィルタ」について定義した通り[6]>
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).
「オリジナル・メッセージ-ID」ヘッダは、任意のメッセージ応答を相関または（また、セクション3.2.3、3.3を参照）、それが関連する元のメッセージに再送信するために使用されます。それは（RFC 2822、セクション3.6.4あたりの）独自のMessage-ID値を持たなければならないので、再送信は、元のメッセージから区別されます。
The syntax for this header is:
このヘッダの構文は次のとおりです。
"Original-Message-ID" ":" msg-id
"オリジナル・メッセージ-ID" "：" MSG-ID
where 'msg-id' is defined by RFC 2822 as:
ここで、「MSG-IDは」としてRFC 2822によって定義されます。
msg-id = "<" id-left "@" id-right ">"
MSG-ID = "<" ID-右 "@" ID-左 ">"
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」の値は、Message-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.
ここでは、送信者が別のメッセージ・データ・フォーマットを送信する、および受信機はいくつかの代替形式の好みを示すことができるように準備を指示することを可能にする[4]メッセージ気質通知（MDN）プロトコルの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]と[2]「対応メディアは、DSNとMDNに拡張機能を使用した機能を示す」されます。
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].
[4]ヘッダー：代替メッセージのデータフォーマットを送信するための準備を指示することを望む送信者がMDN「処分-NOTIFICATION-に」を使用して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要求がを伴う「処分-NOTIFICATION-オプション：」ヘッダ「オプション」の重要度の値を持つパラメータ「代替利用可能」を含みます。 （「オプション」の意義は、このオプションを知らない受信エージェントが不適切な失敗応答を生成しないということです。）
This specification defines a value for 'attribute' to be used in an MDN 'Disposition-Notification-Options:' header [4]:
この仕様は、MDNで使用される「属性」の値を定義する「処分-NOTIFICATION-オプション：」ヘッダ[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>
処分-通知-TO：<送信者アドレス>処分 - 通知 - オプション：オルタナティブ-利用可能=オプションで、<寿命>
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.
ここで、<寿命>は「一過性」または「永続的」、別のデータがちょうどしばらくの間、または無期限のために利用可能となるかどうかを示します。 「永久」の値は、データが長期記憶に開催され、少なくとも数日間のために利用可能であることを期待することができ、おそらく数週間または数ヶ月ことを示しています。 「一過性」の値は、それが通常のメッセージトランザクションの予想される期間保持されるであろうけれども、代替データは、いつでも廃棄することができることを示しています。
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.
注：<寿命>パラメータは、（受信したデータを格納することができない）低メモリ受信機が使用できなくなる可能性が別のデータ・フォーマットを要求による情報の損失を防ぐために設けられています。
A message sent with a request for an MDN with an 'Alternative-available' option MUST also contain a 'Message-ID:' header field [20].
ヘッダフィールド[20]：「代替利用可能な」オプションでMDN要求で送信されたメッセージはまた、「メッセージID」を含まなければなりません。
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-送信-自動的に、別の優先/削除
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.
元のメッセージからの値：持つフィールド[4]「メッセージID」：「代替好ましい」配置改質剤を含むMDN応答はまた、「オリジナルメッセージ-ID」を含まなければなりません。
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-た：」を指定しなければならないヘッダ[4]を伴う「処分-NOTIFICATION-オプション：」ヘッダが「必要」の重要度の値を有する「代替-利用できない」パラメータを含みます。
This specification defines a value for 'attribute' to be used in an MDN 'Disposition-Notification-Options:' header [4]:
この仕様は、MDNで使用される「属性」の値を定義する「処分-NOTIFICATION-オプション：」ヘッダ[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)
処分-通知-TO：<送信者アドレス>処分 - 通知 - オプション：必要=オルタナティブ・-利用できない、（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.
元のヘッダーの代替-利用できない」オプションを使用してMDNを求める要求で送信されたメッセージも含まなければなりません」オリジナル・メッセージIDを：「メッセージID」の値を含むヘッダ[23]メッセージ。
This specification defines an additional value for 'disposition-modifier-extension':
この仕様は、「処分-修飾子拡張」の付加価値を定義します。
disposition-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-送ら-自動的に、元-失われた/削除
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応答はまた、「オリジナルメッセージ-ID：」を含まなければならないフィールド[4]と「メッセージID：」再送メッセージから、または元のメッセージからの値を（ない場合再送信）受信されています。
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応答を送信では、RFC 2298に記載されているセキュリティ上の懸念は、[4]自動MDN応答に関する（セクション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は、交換文書画像に電子メールを使用するアプリケーション（[1] RFCのRFC 2305 [12]およびRFC 2532を参照）です。
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.
この仕様の両方の送信者と受信者の部分はメディア特徴表現の使用を含みます。インターネットファックスの文脈では、そのような表現は、「インターネットファックスのためのコンテンツ機能スキーマ」[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.
インターネットファックス[12]のために、「画像/ TIFF」は、メッセージデータの想定コンテンツ・タイプです。具体的には、すべてのインターネットファクシミリ装置は、TIFFプロフィールS機能（[11]のセクション3）を送受信することができると推定されます。通信はインターネットファックスデバイスとの間にある場合には、この能力を想定することができます。しかし、FAX機能を前提としない方が良いでしょうインターネットファクス（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.
でもインターネットファックスデバイスは、彼らがそのような他のデバイスと通信していることを前提としていない場合、それは良いだろう。インターネット電子メールを使用する場合は、この事実を確立するための信頼できる方法はありません。したがって、合理的に任意の他のメールエージェントとメッセージを交換することが期待され得る任意のインターネットファクシミリ装置のためには、（例えば、画像/ 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-特徴：」受信MDN応答のヘッダは、明示的にちょうど彼らが理解されていると仮定するのではなく、（タイプ=「画像/ 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.
インターネットファクス送信者が受信機に送信するためのプロファイル-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"
日付：水曜日、1995年9月20日午前0時18分00秒（EDT）-0400から：ジェーン・送信者<Jane_Sender@example.com>メッセージ-ID：<199509200019.12345@example.com>件名：インターネットFAXフルモードのコンテンツネゴシエーション：トム受信者<Tom_Recipient@example.org>処分-通知-TO：Jane_Sender@example.com処分 - 通知 - オプション：オルタナティブ-利用可能=オプションで、恒久的なMIME-バージョン：1.0のContent-Type：multipart / mixedの。境界= "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コンテンツタイプ：image / TIFFコンテンツ転送エンコード：BASE64のコンテンツ特徴：（＆（色=バイナリ）（画像ファイル構造= TIFF-最小）（DPI = 200） （DPI-xyratio = 1）（用紙サイズ= A4）（画像符号化= MH）（MRC-MODE = 0）（UA-メディア=文房具））コンテンツの代替：（＆（色=バイナリ）（イメージ - ファイル構造= TIFF制限）（DPI = 400）（DPI-xyratio = 1）（用紙サイズ= A4）（画像符号化= MMR）（MRC-MODE = 0）（UA-メディア=文房具））
[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.
午後12時18分00秒（EDT）で1995年9月20日に送信されたメッセージ件名「インターネットFAXフルモードのコンテンツネゴシエーション」とトム受信者<Tom_Recipient@example.org>へ-0400が受信されています。メッセージデータの代替フォームが要求されています。
--RAA14128.773615766/example.org Content-Type: message/disposition-notification
--RAA14128.773615766 / example.orgのContent-Type：気質メッセージ/通知
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) )
報告-UA：Toms-pc.cs.example.orgを。 IFAX-FullModeオリジナル・受信者：RFC822; Tom-Recipient@example.org最終受信者：RFC822; Tom-Recipient@example.orgオリジナル・メッセージ-ID：<199509200019.12345@example.com>処分：自動アクション/ MDN- - 自動的に送信。 /代替優先メディア-のAccept-機能削除：（＆（タイプ= "画像/ TIFF"）（色=バイナリ）（画像ファイル構造= TIFF）（|（＆（DPI = 200）（DPI-xyratio = 200/100））（＆（DPI = 200）（DPI-xyratio = 1））（＆（DPI = 400）（DPI-xyratio = 1）））（|（画像符号化= [MH、MR、MMR] （）＆（画像符号化= JBIG）（画像符号化制約= JBIG-T85）（JBIGストライプサイズ= 128）））（MRC-MODE = 0）（用紙サイズ= A4、B4]） （UA-メディア=文房具））
--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"
日付：水曜日、1995年9月20日夜12時21分00秒（EDT）-0400から：ジェーンの送信者<Jane_Sender@example.com>メッセージ-ID：<199509200021.12345@example.com>オリジナル・メッセージ-ID：<199509200019.12345@example。 COM>件名：インターネットFAXフルモードの画像送信に：トム受信者<Tom_Recipient@example.org>処分-通知-TO：Jane_Sender@example.com MIME-バージョン：1.0のContent-Type：multipart / mixedの。境界= "RAA14128.773615768 / example.com"
--RAA14128.773615768/ example.com Content-type: image/tiff Content-Transfer-Encoding: base64
--RAA14128.773615768 / example.comコンテンツタイプ：画像/ tiffのコンテンツ転送 - エンコード：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.
対象とトム受信者<Tom_Recipient@example.org>に0時21分00秒で1995年9月20日に送信されたメッセージ（EDT）-0400「インターネットFAXフルモード画像伝送は、」インターネットFAXフルモードで処理されています。
--RAA14128.773615769/example.org Content-Type: message/disposition-notification
--RAA14128.773615769 / example.orgのContent-Type：気質メッセージ/通知
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) )
報告-UA：Toms-pc.cs.example.orgを。 IFAX-FullModeオリジナル・受信者：RFC822; Tom-Recipient@example.org最終受信者：RFC822; Tom-Recipient@example.orgオリジナル・メッセージ-ID：<199509200021.12345@example.com>処分：自動アクション/ MDN- - 自動的に送信。メディア-のAccept-機能を処理します。（＆（タイプ= "画像/ TIFF"）（色=バイナリ）（画像ファイル構造= TIFF）（|（＆（DPI = 200）（DPI-xyratio = 200/100） （）＆（DPI = 200）（DPI-xyratio = 1））（＆（DPI = 400）（DPI-xyratio = 1）））（|（画像符号化= [MH、MR、MMR]）（＆（画像符号化= JBIG）（画像符号化制約= JBIG-T85）（JBIGストライプサイズ= 128）））（MRC-MODE = 0）（用紙サイズ= A4、B4]）（UAメディア=文具））
--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.
この例では、前の例におけるシステム間目以降の転送が行われる方法を示しています。前回交換から得られた知識を使用して、送信者は、その最初の接点でプロファイル-Fのデータを含んでいます。
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"
日付：水曜日、1995年9月20日夜12時19分00秒（EDT）-0400から：ジェーン・送信者<Jane_Sender@example.com>メッセージ-ID：<199509200019.12345@example.com>件名：インターネットFAXフルモードのコンテンツネゴシエーション：トム受信者<Tom_Recipient@example.org>処分-通知-TO：Jane_Sender@example.com処分 - 通知 - オプション：オルタナティブ-利用可能=オプションで、恒久的なMIME-バージョン：1.0のContent-Type：multipart / mixedの。境界= "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コンテンツタイプ：image / TIFFコンテンツ転送エンコード：BASE64のコンテンツ特徴：（＆（色=バイナリ）（画像ファイル構造= TIFF制限）（DPI = 400） （DPI-xyratio = 1）（用紙サイズ= A4）（画像符号化= MMR）（MRC-MODE = 0）（UA-メディア=文房具））コンテンツの代替：（＆（色=バイナリ）（イメージ - ファイル構造= TIFF-最小）（DPI = 200）（DPI-xyratio = 1）（用紙サイズ= A4）（画像符号化= MH）（MRC-MODE = 0）（UA-メディア=文房具））
[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.
午後12時19分00秒（EDT）で1995年9月20日に送信されたメッセージ件名「インターネットFAXフルモード画像伝送」とトム受信者<Tom_Recipient@example.org>へ-0400は、インターネットFAXフルモードで処理されています。
--RAA14128.773615769/example.org Content-Type: message/disposition-notification
--RAA14128.773615769 / example.orgのContent-Type：気質メッセージ/通知
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) )
報告-UA：Toms-pc.cs.example.orgを。 IFAX-FullModeオリジナル・受信者：RFC822; Tom-Recipient@example.org最終受信者：RFC822; Tom-Recipient@example.orgオリジナル・メッセージ-ID：<199509200021.12345@example.com>処分：自動アクション/ MDN- - 自動的に送信。メディア-のAccept-機能を処理します。（＆（タイプ= "画像/ TIFF"）（色=バイナリ）（画像ファイル構造= TIFF）（|（＆（DPI = 200）（DPI-xyratio = 200/100） （）＆（DPI = 200）（DPI-xyratio = 1））（＆（DPI = 400）（DPI-xyratio = 1）））（|（画像符号化= [MH、MR、MMR]）（＆（画像符号化= JBIG）（画像符号化制約= JBIG-T85）（JBIGストライプサイズ= 128）））（MRC-MODE = 0）（用紙サイズ= A4、B4]）（UAメディア=文具））
--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.
インターネットFAXは、プロファイル-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"
日付：水曜日、1995年9月20日午前0時18分00秒（EDT）-0400から：ジェーンの送信者<Jane_Sender@example.com>メッセージ-ID：<199509200019.12345@example.com>件名：トム：インターネットFAXフルモードがダウンしネゴシエート受信者<Tom_Recipient@example.org>処分-通知-TO：Jane_Sender@example.com処分 - 通知 - オプション：オルタナティブ-利用可能=オプションで、恒久的なMIME-バージョン：1.0のContent-Type：multipart / mixedの。境界= "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コンテンツタイプ：image / TIFFコンテンツ転送エンコード：BASE64のコンテンツ特徴：（＆（色=バイナリ）（画像ファイル構造= TIFF制限）（DPI = 400） （DPI-xyratio = 1）（用紙サイズ= A4）（画像符号化= MMR）（MRC-MODE = 0）（UA-メディア=文房具））
[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.
午後12時18分00秒（EDT）で1995年9月20日に送信されたメッセージ件名「インターネットFAXフルモードのコンテンツネゴシエーション」とトム受信者<Tom_Recipient@example.org>へ-0400が受信されています。メッセージデータの代替フォームが要求されています。
--RAA14128.773615766/example.org Content-Type: message/disposition-notification
--RAA14128.773615766 / example.orgのContent-Type：気質メッセージ/通知
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) )
報告-UA：Toms-pc.cs.example.orgを。 IFAX-FullModeオリジナル・受信者：RFC822; Tom-Recipient@example.org最終受信者：RFC822; Tom-Recipient@example.orgオリジナル・メッセージ-ID：<199509200019.12345@example.com>処分：自動アクション/ MDN- - 自動的に送信。メディアのAccept-特徴代替好ましい/削除：（＆（タイプ= "画像/ TIFF"）（色=バイナリ）（画像ファイル構造= TIFF-最小）（DPI = 200）（DPI-xyratio = 1） （用紙サイズ= A4）（画像符号化= MH）（MRC-MODE = 0）（UA-メディア=文房具））
--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"
日付：水曜日、1995年9月20日夜12時21分00秒（EDT）-0400から：ジェーンの送信者<Jane_Sender@example.com>メッセージ-ID：<199509200021.12345@example.com>オリジナル・メッセージ-ID：<199509200019.12345@example。 COM>件名：インターネットFAXフルモードの画像送信に：トム受信者<Tom_Recipient@example.org>処分-通知-TO：Jane_Sender@example.com MIME-バージョン：1.0のContent-Type：multipart / mixedの。境界= "RAA14128.773615768 / example.com"
--RAA14128.773615768/ example.com Content-type: image/tiff Content-Transfer-Encoding: base64
--RAA14128.773615768 / example.comコンテンツタイプ：画像/ tiffのコンテンツ転送 - エンコード：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.
対象とトム受信者<Tom_Recipient@example.org>に0時21分00秒で1995年9月20日に送信されたメッセージ（EDT）-0400「インターネットFAXフルモード画像伝送は、」インターネットFAXフルモードで処理されています。
--RAA14128.773615769/example.org Content-Type: message/disposition-notification
--RAA14128.773615769 / example.orgのContent-Type：気質メッセージ/通知
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) )
報告-UA：Toms-pc.cs.example.orgを。 IFAX-FullModeオリジナル・受信者：RFC822; Tom-Recipient@example.org最終受信者：RFC822; Tom-Recipient@example.orgオリジナル・メッセージ-ID：<199509200021.12345@example.com>処分：自動アクション/ MDN- - 自動的に送信。メディアのAccept-機能処理：（＆（色=バイナリ）（画像ファイル構造= TIFF-最小）（DPI = 200）（DPI-xyratio = 1）（用紙サイズ= A4）（画像符号化= MH ）（MRC-MODE = 0）（UA-メディア=文房具））
--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.)
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"
日付：水曜日、1995年9月20日午前0時18分00秒（EDT）-0400から：ジェーン・送信者<Jane_Sender@example.com>メッセージ-ID：<199509200019.12345@example.com>件名：インターネットFAXフルモードのコンテンツネゴシエーション：トム受信者<Tom_Recipient@example.org>処分-通知-TO：Jane_Sender@example.com処分 - 通知 - オプション：オルタナティブ-利用可能=オプションで、恒久的なMIME-バージョン：1.0のContent-Type：multipart / mixedの。境界= "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コンテンツタイプ：image / TIFFコンテンツ転送エンコード：BASE64のコンテンツ特徴：（＆（色=バイナリ）（画像ファイル構造= TIFF-最小）（DPI = 200） （DPI-xyratio = 1）（用紙サイズ= A4）（画像符号化= MH）（MRC-MODE = 0）（UA-メディア=文房具））コンテンツの代替：（＆（色=バイナリ）（イメージ - ファイル構造= TIFF制限）（DPI = 400）（DPI-xyratio = 1）（用紙サイズ= A4）（画像符号化= MMR）（MRC-MODE = 0）（UA-メディア=文房具））コンテンツ-alternative：（＆（タイプ= "アプリケーション/ PDF"）（色=リミテッド）（DPI = 400）（用紙サイズ= A4）（UA-メディア=文房具））
[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.)
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.
午後12時18分00秒（EDT）で1995年9月20日に送信されたメッセージ件名「インターネットFAXフルモードのコンテンツネゴシエーション」とトム受信者<Tom_Recipient@example.org>へ-0400が受信されています。メッセージデータの代替フォームが要求されています。
--RAA14128.773615766/example.org Content-Type: message/disposition-notification
--RAA14128.773615766 / example.orgのContent-Type：気質メッセージ/通知
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) ) )
報告-UA：Toms-pc.cs.example.orgを。 IFAX-FullModeオリジナル・受信者：RFC822; Tom-Recipient@example.org最終受信者：RFC822; Tom-Recipient@example.orgオリジナル・メッセージ-ID：<199509200019.12345@example.com>処分：自動アクション/ MDN- - 自動的に送信。削除/代替優先メディア-のAccept-特徴：（|（＆（タイプ= "画像/ TIFF"）（色=バイナリ）（画像ファイル構造= TIFF-最小限）（DPI = 200）（DPI-xyratio = 1）（画像符号化= MH）（MRC-MODE = 0）（用紙サイズ= A4）（UA-メディア=ステーショナリー））（＆（タイプ= "アプリケーション/ PDF"）（色=バイナリ）（dpi- xyratio = 1）（DPI = [200,400]）（用紙サイズ= A4、B4]）（UAメディア=文房具）））
--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"
日付：水曜日、1995年9月20日夜12時21分00秒（EDT）-0400から：ジェーンの送信者<Jane_Sender@example.com>メッセージ-ID：<199509200021.12345@example.com>オリジナル・メッセージ-ID：<199509200019.12345@example。 COM>件名：インターネットFAXフルモードの画像送信に：トム受信者<Tom_Recipient@example.org>処分-通知-TO：Jane_Sender@example.com MIME-バージョン：1.0のContent-Type：multipart / mixedの。境界= "RAA14128.773615768 / example.com"
--RAA14128.773615768/ example.com Content-type: application/pdf Content-Transfer-Encoding: base64
--RAA14128.773615768 / example.comコンテンツタイプ：アプリケーション/ PDFコンテンツ転送 - エンコード：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.
対象とトム受信者<Tom_Recipient@example.org>に0時21分00秒で1995年9月20日に送信されたメッセージ（EDT）-0400「インターネットFAXフルモード画像伝送は、」インターネットFAXフルモードで処理されています。
--RAA14128.773615769/example.org Content-Type: message/disposition-notification
--RAA14128.773615769 / example.orgのContent-Type：気質メッセージ/通知
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) ) )
報告-UA：Toms-pc.cs.example.orgを。 IFAX-FullModeオリジナル・受信者：RFC822; Tom-Recipient@example.org最終受信者：RFC822; Tom-Recipient@example.orgオリジナル・メッセージ-ID：<199509200021.12345@example.com>処分：自動アクション/ MDN- - 自動的に送信。処理されたメディアのAccept-特長：（|（＆（タイプ= "画像/ TIFF"）（色=バイナリ）（画像ファイル構造= TIFF-最小限）（DPI = 200）（DPI-xyratio = 1）（画像-coding = MH）（MRC-MODE = 0）（用紙サイズ= A4）（UA-メディア=ステーショナリー））（＆（タイプ= "アプリケーション/ PDF"）（色=バイナリ）（DPI-xyratio = 1） （DPI = [200,400]）（用紙サイズ= A4、B4]）（UAメディア=文房具）））
--RAA14128.773615769/example.org--
--RAA14128.773615769 / example.org--
This specification defines new email/MIME message headers:
この仕様は、新しい電子メール/ MIMEメッセージヘッダを定義しています。
Content-alternative Original-Message-ID
コンテンツの代替オリジナル・メッセージ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].
自動化されたMDN応答生成とプライバシーの懸念O：[4]このドキュメントのセクション6.5、およびRFC 2298のセキュリティの考慮事項のセクションを参照してください。
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.
ここで説明する交渉の基本的な構造は、第1、キヤノンの徹氏前田案に記載されていました。
Helpful comments on earlier drafts were provided by Mr Hiroshi Tamura, Ted Hardie and Larry Masinter.
以前のドラフトでの有益なコメントは氏宏田村、テッドハーディーとラリーMasinterによって提供されました。
[1] Masinter, L. and D. Wing, "Extended Facsimile using Internet Mail", RFC 2532, March 1999.
[1] Masinter、L.とD.ウィング、 "インターネットメールを使用して拡張ファクシミリ"、RFC 2532、1999年3月。
[2] Wing, D., "Indicating Supported Media Features Using Extensions to DSN and MDN", RFC 2530, March 1999.
[2]ウイング、D.、RFC 2530、1999年3月 "サポートされているメディアを示すには、DSNとMDNに拡張機能を使用しています"。
[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.ハーディ、 "メディア特徴タグの登録手順"、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.、RFC 2938、2000年9月 "MIMEコンテンツのメディア機能を示します"。
[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]クロッカー、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]マッキンタイア、L.、バックリー、R.、VENABLE、D.、Zilles、S.、パーソンズ、G.およびJ.ラファティー、 "インターネットファックスのファイル形式"、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]豊田K.、大野H.、村井、J.およびD.翼、 "インターネットメールを使用するファクシミリのシンプルモード"、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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]解放され、N.と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.マッキンタイア、 "インターネットファクス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.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[20] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[20]レズニック、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.クロッカー、「インターネットメールを使用するファクシミリのためのタイムリーな配信」、進行中の作業。
[22] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[22]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[23] 'Original-Message-ID' header for mail messages (this memo, section 5)
[23]「オリジナル・メッセージ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.
このセクションでは、この仕様の標準的な部分ではありません。むしろ、それは我々が実装に役立つことを願っています方法で、その設計時に考慮された問題のいくつかを説明します。
A.1 Receiver state
A.1レシーバー状態
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転送を中止し、メッセージ転送の失敗を宣言する：診断メッセージは、ローカルユーザに表示し、送信者に送信された障害通知されなければなりません。
A.2 Receiver buffering of message data
メッセージデータのA.2レシーバのバッファリング
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.
送信者が代替データの可用性を示している場合、それはまた、恒久的または一過利用可能であるかどうかを示します。これの目的は、代替データが一時的である場合、受信機は、受信した元のデータを破棄してはならないということです。必要であれば、それは単に選択肢を要求せずに、元のデータが表示されます。
A.3 Sender state
A.3送信者の状態
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値（S）と、合理的な期間のために保存されるべきです。
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値を添付しなければなりません。
A.4 Timeout of offer of alternatives
代替のオファーのA.4タイムアウト
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を参照）一過性に利用可能であることを示す必要があります。メッセージの内容を維持する程度の送信者の能力は疑問がある場合、それは任意の代替の可用性が一時的であることを示す必要があります。
A.5 Timeout of receiver capabilities
受信機機能のA.5タイムアウト
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.
受信機は、これらの機能が使用されるための目的について選択的であるかもしれないとして、別のフォーマットを要求するときに宣言された任意の受信機機能は、将来の使用のために格納されるべきではありません。
A.6 Relationship to timely delivery
タイムリーな配信にA.6関係
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]）。応答を受信すべきで知られている時間窓がある場合、送信者は長期間代替データの未処理のオファーに関する情報を維持約あまり保守的であってもよいです。このように、タイムリーな配送を利用し、送信者は、代替が一時的に利用可能であることを示す必要があります。
A.7 Ephemeral capabilities
A.7エフェメラル機能
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を送信します。その後、カラーインクがなくなりました。発信ファックスは、カラーファックスを印刷することはできません新しいメッセージを送信します。
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.
または関連する問題として、オン/オフ音との電話で電子メールクライアントを考えます。音をONにすると、電話は電子メールで音声メッセージを受け入れることができるかもしれません。
This negotiation framework has not been designed with ephemeral capabilities in mind, but, with care, may be adaptable to deal with them.
この交渉の枠組みは注意して、それらに対処するために適応することができ、心の中で一時的な機能で設計されていないが。
A.8 Situations where MDNs must not be auto-generated
開封通知が自動生成してはならないA.8事態
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.
無人のファクス機が自動ネゴシエーションを実行することはOKかもしれないがPCユーザーが存在する場合にのみオンにすることができるように、ユーザーが明示的な許可なしにそうするPCソフトウェアパッケージのためにOKではありません。これは、この点でのデフォルト設定は、システムのタイプを考慮すべきであることを示唆しています。
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」応答のために開発された提案があります。これは、代替フォーマットのみいくつかのメッセージボディ部分のために要求されたときに再送信部分の可能性を開きます。現在の仕様では、コンテンツネゴシエーションを使用する場合いずれか、メッセージのすべてのいずれかが再送信されないことを前提としています。
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
グラハムKlyne（エディタ）クリアスウィフト社、1310水辺、アーリントンビジネスパークTheale読書、RG7 4SAイギリス
Phone: +44 11 8903 8903 Fax: +44 11 8903 9000 EMail: GK@ACM.ORG
電話：+44 11 8903 8903ファックス：+44 11 8903 9000 Eメール：GK@ACM.ORG
Ryuji Iwazaki TOSHIBA TEC CORPORATION 2-4-1, Shibakoen, Minato-ku, Tokyo, 105-8524 Japan
りゅじ いわざき としば てＣ こＲぽらちおん ２ー４ー１、 しばこえん、 みなとーく、 ときょ、 １０５ー８５２４ じゃぱん
Phone: +81 3 3438 6866 Fax: +81 3 5402 6355 EMail: iwa@rdl.toshibatec.co.jp
電話：+81 3 3438 6866ファックス：+81 3 5402 6355 Eメール：iwa@rdl.toshibatec.co.jp
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA
デイブ・クロッカーブランデンブルクインターネットワーキング675スプルース博士はカリフォルニア州サニーベール94086 USA
Phone: +1 408 246 8253 Fax: +1 408 249 6205 EMail: dcrocker@brandenburg.com
電話：+1 408 246 8253ファックス：+1 408 249 6205 Eメール：dcrocker@brandenburg.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。