RFC3297 日本語訳
3297 Content Negotiation for Messaging Services based on Email. G.Klyne, R. Iwazaki, D. Crocker. July 2002. (Format: TXT=97094 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Klyne
Request for Comments: 3297 Clearswift Corporation
Category: Standards Track R. Iwazaki
Toshiba TEC
D. Crocker
Brandenburg InternetWorking
July 2002
Klyneがコメントのために要求するワーキンググループG.をネットワークでつないでください: 3297年のClearswift社のカテゴリ: 標準化過程R.Iwazaki東芝TEC D.医者ブランデンブルクインターネットワーキング2002年7月
Content Negotiation for Messaging Services based on Email
メールに基づくメッセージサービスのための内容Negotiation
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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
1. 序論… 3 1.1 このドキュメントの構造… 4 1.2 用語とコンベンションを記録してください… 4 1.2 .1用語… 4 1.2 .2 目標を設計してください… 5 1.2 .3 他のドキュメントコンベンション… 5 2. バックグラウンドと目標… 5 2.1バックグラウンド… 5 2.1 .1 ファックスして、メールします。 5 2.1 インターネットファックスの.2の現在の施設… 6 2.2 輪を閉じます… 6
Klyne, et. al. Standards Track [Page 1] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[1ページ]RFC3297の満足している交渉
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
満足している交渉の2.3の目標… 8 3. 満足している交渉のための枠組み…10 3.1 代替手段のしるしはデータを送ってください…11 3.1 .1 デフォルトデータの形式の選択…12 3.1 .2 MDNは交互のデータがフォーマットする表示を要求します…12 3.1 代替のデータ形式に関する.3情報…13 3.2 受信機オプション…14 3.2 認識されなかった.1の選択肢…14 3.2 望まれていなかった.2代替手段…14 3.2 好まれた.3代替手段…14 3.3 代替のメッセージデータを送ってください…3.4が領収書を確認する16はメッセージデータに憤慨します…17 4. Content-代替手段ヘッダー…18 5. Original Message IDメッセージヘッダー…18 6. 代替のデータのためのMDN拡張子…19 6.1 代替のデータを送る準備を示します…19 6.2 代替のデータのための優先を示します…20 6.3 代替のデータを示すのはもう利用可能ではありません…21 6.4 オリジナルのデータの損失を示します…22 6.5 MDN応答の自動発信…22 7. インターネットファックス問題…22 8. 例…23 8.1 発信はインターネットファックスイメージを高めました…23 8.2 初期のデータが使用可能のインターネットファックス…27 8.3 受信機能力を下ろすのを交渉してください…28 8.4 ホームページの別版を送って、タイプしてください…32 9. IANA問題…36 9.1 新しいメッセージヘッダー…36 9.2 MDN拡張子…36 9.2 .1通知オプション'利用可能な代替手段'…36 9.2 .2通知オプション'利用可能でない代替手段'…36 9.2 修飾語が'代替手段で好んだ'.3気質…37 9.2 .4気質修飾語は'オリジナルで損をしました'…37 10. 国際化問題…37 11. セキュリティ問題…37 12. 承認…38 13. 参照…38 付録A: 実現問題…40 A.1受信機状態…40 メッセージデータのA.2受信機バッファリング…41 A.3送付者状態…42 代替手段の申し出のA.4タイムアウト…42 受信機能力のA.5タイムアウト…42 タイムリーな配送とのA.6関係…43 A.7のはかない能力…43 MDNsが自動発生しているはずがないA.8状況…44 付録B: さらなる増進の候補…44人の作者のアドレス…45
Klyne, et. al. Standards Track [Page 2] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[2ページ]RFC3297の満足している交渉
Full Copyright Statement..........................................46
完全な著作権宣言文…46
1. Introduction
1. 序論
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.
「インターネットメールを使用する拡張Facsimile」[1]は、インターネットメールプロトコルを使用することでイメージデータの転送を指定します。 「SupportedメディアFeatures Using Extensionsを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.
送付者に受信機の能力に関する正確な情報がないとき、ここで説明されたメカニズムは追加メッセージ周遊旅行を被るかもしれません。 このメカニズムの重要な目標は情報が余分な周遊旅行が必要であるかどうか決定するために提供されるのを十分許容することです。
Klyne, et. al. Standards Track [Page 3] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[3ページ]RFC3297の満足している交渉
1.1 Structure of this document
1.1 このドキュメントの構造
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は新しいメール・メッセージヘッダー、オリジナルのメッセージデータとの交渉の間に送られた代替のデータを関連させて、新しい取引の始まりと古いメッセージ取引の継続を区別するのに使用される'元のMessage ID'について説明します。
Section 6 describes extensions to the Message Disposition Notification (MDN) framework [4] that support negotiation between the communicating parties.
セクション6は交信パーティーの間の交渉を支持する拡大をMessage Disposition Notification(MDN)枠組み[4]に説明します。
1.2 Document terminology and conventions
1.2 ドキュメント用語とコンベンション
1.2.1 Terminology
1.2.1 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[22]で説明されるように本書では解釈されることであるべきですか?
Capability exchange
An exchange of information between communicating parties
indicating the kinds of information they can generate or consume.
交信することの間の能力交換An情報交換は、それらが発生するか、または消費できる情報の種類を示しながら、パーティーへ行きます。
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.
それがプレゼンテーションのためにユーザに受け入れることができるメッセージデータの種類を示すa受信エージェントによる情報の能力識別Provision。
Content negotiation
An exchange of information (negotiation metadata) which leads to
selection of the appropriate representation (variant) when
transferring a data resource.
データリソースを移すとき適切な表現(異形)の選択につながる満足している交渉An情報交換(交渉メタデータ)。
Klyne, et. al. Standards Track [Page 4] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[4ページ]RFC3297の満足している交渉
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.
RFC2703[17]は満足している交渉に関連する他のいくつかの用語を紹介します。
1.2.2 Design goals
1.2.2 デザイン目標
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記法はRFC2542(「インターネットファックスの用語と目標」[3])単位で使用されます。 これらの記法に関連している意味は以下の通りです。
{1} there is general agreement that this is a critical
characteristic of any definition of content negotiation for
Internet Fax.
そこの1は一般協定です。インターネットファックスのための内容交渉のどんな定義のきわどい特性。
{2} most believe that this is an important characteristic of
content negotiation for Internet Fax.
2 大部分は、これがインターネットファックスのための満足している交渉の重要な特性であると信じています。
{3} there is general belief that this is a useful feature of
content negotiation for Internet Fax, but that other factors
might override; a definition that does not provide this
element is acceptable.
3 これがインターネットファックスのための満足している交渉の役に立つ特徴であるのにもかかわらずの、他の要素がくつがえされるかもしれないという一般的な信念があります。 この要素を提供しない定義は許容できます。
1.2.3 Other document conventions
1.2.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.
以下に注意してください。 このようなコメントは原理の追加不要不急な情報をこのドキュメントの後ろに供給します。 そのような情報は、conformant実現を組み込むのに必要ではありませんが、より大きい深さでデザインを理解したがっている人を助けるかもしれません。
2. Background and goals
2. バックグラウンドと目標
2.1 Background
2.1 バックグラウンド
2.1.1 Fax and email
2.1.1 ファックスとメール
One of the goals of the work to define a facsimile service using Internet mail has been to deliver benefits of the traditional Group 3 Fax service in an email environment. Traditional Group 3 Fax leans heavily on the idea that an online exchange of information discloses a receiver's capabilities to the sender before any message data is transmitted.
インターネット・メールを使用することでファクシミリサービスを定義する仕事の目標の1つはメール環境における伝統的なGroup3ファックスサービスの恩恵を送ることです。 伝統的なGroup3ファックスはどんなメッセージデータも送られる前に情報のオンライン交換が送付者への受信機の能力を明らかにするという考えにかなり依存します。
Klyne, et. al. Standards Track [Page 5] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[5ページ]RFC3297の満足している交渉
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.
何らかのレベルの相互運用性、Group3ファックス、およびインターネット・メールを保証するには、何らかの基線形式(すなわち、それぞれ基本的な画像形式か明瞭なASCIIテキスト)に対処できるすべての受信機を当てにしてください。 能力交換か満足している交渉の役割が可能にすることである、良さ、-、入手できるところで使われるべき基線能力。
One of the challenges addressed by this specification is how to adapt the email environment to provide a fax-like service. A sender must not make any a priori assumption that the receiver can recognize anything other than a simple email message. There are some important uses of email that are fundamentally incompatible with the fax model of message passing and content negotiation (notably mailing lists). So we need to have a way of recognizing when content negotiation is possible, without breaking the existing email model.
この仕様で記述された挑戦の1つはファックスのようなサービスを提供するためにどうメール環境を適合させるかということです。 送付者は受信機が簡単なメールメッセージ以外の何も認識できるという少しの先験的な仮定もしてはいけません。 メールのいくつかの基本的にメッセージ・パッシングと満足している交渉(著しくメーリングリスト)のファックスモデルと両立しない重要な用途があります。 それで、満足している交渉が既存のメールモデルを壊さないで可能であるときに、私たちは認識の方法を必要とします。
2.1.2 Current facilities in Internet Fax
2.1.2 インターネットファックスの現在の施設
"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].
「インターネットメールを使用する拡張Facsimile」[1]は受信機能力情報の限られた支給にメッセージの送付者に備えます、Message Disposition Notifications[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.
このメカニズムはメッセージを受け取られて、処理してある後に明らかにされるべき受信機能力に備えます。 その後のトランスミッションに同じ受信機にこの情報を使用できます。しかし、多くのコミュニケーションは、一回限りの与えられた送付者から与えられた受信機までのメッセージであり、これの利益を得ることができません。
2.2 Closing the loop
2.2 輪を閉じること。
Classic Internet mail is an "open loop" process: no information is returned back to the point from which the message is sent. This has been unkindly --but accurately-- characterized as "send and pray", since it lacks confirmation.
古典的なインターネット・メールは「転々流通」プロセスです: メッセージが送られる肝心の後部をどんな情報にも返しません。 これは不親切に、しかし、正確にそうです--「発信してください、そして、祈ってください」として、確認を欠いているので、特徴付けられます。
Sending a message and obtaining confirmation that the message has been received is a "closed loop" process: the confirmation sent back to the sender creates a loop around which information is passed.
メッセージを送って、確認を得て、メッセージを受け取ったのは、「クローズドループ」プロセスです: 送付者に送り返された確認は情報が通過される輪を作成します。
Klyne, et. al. Standards Track [Page 6] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[6ページ]RFC3297の満足している交渉
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.
多くのインターネットメールエージェントは、クローズドループプロセスに参加して、その結果、メッセージの領収書に応じる責任を全く持たないように設計されていません。 インターネット標準への後の追加(著しくDelivery Service Notification[18]とMessage Disposition Notification[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.
aは造を通信させます。満足している交渉がクローズドループ機能である、(この提案の目的--見るのが2.3、項目(f))を区分して、それを必要とする、受取人、送付者への何らかの応答。 満足している交渉がインターネット・メールの自発的の、そして、高い潜在の環境の上に閉ループ機能を改装しなければならないので、メールにおける満足している交渉のための挑戦は賛成者側がクローズドループ状況を認めて、したがって、輪を閉じる彼らの責任を認めることができると証明することです。
Three different loops can be identified in a content negotiation:
満足している交渉で3つの異なった輪を特定できます:
Sender Receiver
| |
Initial message ------>------------ v
| |
(1) ------------<--- Request alternative data
| |
Send alternative ------>------------ (2)
| |
(3) ------------<------ Confirm receipt
of usable data
送付者受信機| | 初期のメッセージ------>、-、-、-、-、-、-、-、-、-、-、-- v| | (1) ------------<-- 代替のデータを要求してください。| | 代替手段を送ってください。------>、-、-、-、-、-、-、-、-、-、-、-- (2) | | (3) ------------<、-、-、-、-、-- 使用可能なデータの領収書を確認してください。
(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) 送付者は処理されていた状態で受信データが「プロセス-可能」であるか、またはあった確認を受け取ります。
Klyne, et. al. Standards Track [Page 7] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[7ページ]RFC3297の満足している交渉
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:
内容が発信したなら、送付者から、受信機による「プロセス-可能」が来ていて、確認を送って、次に、全体のプロセスをaに簡単な状態で減少させるというオリジナルのメッセージで、輪を送るか、または確認してください:
Sender Receiver
| |
Initial message ------>------------ v
| |
(3) ------------<------ Confirm receipt
of usable data
送付者受信機| | 初期のメッセージ------>、-、-、-、-、-、-、-、-、-、-、-- v| | (3) ------------<、-、-、-、-、-- 使用可能なデータの領収書を確認してください。
2.3 Goals for content negotiation
2.3 満足している交渉の目標
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サポート導入、特にGroup3ファックスのために採用されるものがそうするべきです。
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.
これは、送付者が、受信機が能力交換プロトコル要素を理解できるのでいくつかの重要なメッセージデータを送ることによっていつも始動しなければならないと仮定してはいけないことを意味します。
Klyne, et. al. Standards Track [Page 8] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[8ページ]RFC3297の満足している交渉
(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.
3が同じデータの複数のバージョンを伝えるならソリューションが採用した(f)。 特にそれは当てにしてはいけません。1 ただ一つのメッセージで同じデータの複数のきまりきって発信しているインスタンスを当てにしてください。
This does not prohibit sending multiple versions of the same
data, but it must not be a requirement to do so. A sender may
choose to send multiple versions together (e.g., plain text and
some other format), but the capability exchange mechanism
selected must not depend on such behaviour.
これは、同じデータの複数のバージョンを送るのを禁止しませんが、それはそうするという要件であるはずがありません。 送付者は、一緒に複数のバージョン(例えば、プレーンテキストとある他の形式)を送るのを選ぶかもしれませんが、交換メカニズムが選択した能力はそのようなふるまいによってはいけません。
(g) The solution adopted should {2} be consistent with and
applicable to other Internet email based applications; e.g.,
regular email, voice messaging, unified messaging, etc.
ソリューションが2がメールが基礎づけた他のインターネットに一致して適切なアプリケーションであるなら採用した(g)。 例えば、通常のメール、声のメッセージング、ユニファイド・メッセージングなど
(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.).
2が清潔にに関連して作動するならメカニズムが定義した(i)。
(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 低いメモリ素子で実装可能することになってください。 すなわち、それは任意の量のメッセージデータをバッファリングできるどんなパーティーにも頼るべきではありません。
Klyne, et. al. Standards Track [Page 9] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[9ページ]RFC3297の満足している交渉
(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.)
(送付システムでこの目標を完全に満たすのは可能でないかもしれません。 しかし、送付者に何らかの与えられたメッセージをバッファリングできるくらいの記憶力がないなら、それは、満足している交渉を提供しないのを選ぶことができます。)
3. Framework for content negotiation
3. 満足している交渉のためのフレームワーク
This section starts with an outline of the negotiation process, and provides greater detail about each stage in following sub-sections.
このセクションは、交渉プロセスのアウトラインから始まって、各ステージに関する、よりすばらしい詳細を小区分に続くのに明らかにします。
1. Sender sends initial message data with an indication of
alternative formats available (section 3.1). Initial data MAY be
a baseline or some other guess of what the recipient can handle.
1. 代替の形式のしるしが利用可能な状態で(セクション3.1)送付者は初期のメッセージデータを送ります。 初期のデータは、受取人が扱うことができることに関する基線かある他の推測であるかもしれません。
2. The receiver has three main options:
2. 受信機には、3つの主なオプションがあります:
(a) Does not recognize the optional alternative formats, and
passively accepts the data as sent (section 3.2.1).
(a) 任意の代替の形式を認識しないで、送るように(セクション3.2.1)データを受け身に受け入れます。
(b) Does recognize the alternatives offered, and actively
accepts the data as sent (section 3.2.2).
(b)は代替手段が提供したと認めて、送るように活発にデータを受け入れます(セクション3.2.2)。
(c) Recognizes the alternatives offered, and determines that it
prefers to receive an alternative format. An MDN response
is sent (i) indicating that the original data was not
processed, and (ii) containing receiver capability
information so that the sender may select a suitable
alternative (section 3.2.3).
(c)は、代替手段が提供したと認めて、代替の書式を受けるのを好むことを決定します。 オリジナルのデータが処理されなかったのを示す(i)、および送付者が適当な代替手段を選択できるように受信機能力情報を含む(ii)(セクション3.2.3)をMDN応答に送ります。
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.
受取人だけが、'以下のこと'で'cc:'と命名したか、またはオリジナルのメッセージの'bcc:'ヘッダーがこのように代替のデータ書式を要求するかもしれないことに注意してください。 オリジナルのメッセージヘッダーで指定されなかった受取人は、満足している交渉を開始するのを試みてはいけません。
NOTE: the prohibition on initiation of negotiation by
recipients other than those explicitly addressed is to avoid
the sender from having to deal with negotiation requests
from unexpected parties.
以下に注意してください。 明らかに扱われたもの以外の受取人による交渉の開始での禁止は予期していなかったパーティーからの交渉要求に対処しなければならないので送付者を避けることです。
3. On receipt of an MDN response indicating preference for an
alternative data format, the sender MUST select and transmit
message data matched to the receiver's declared capabilities, or
send an indication that the receiver's request cannot be honoured.
When sending alternative data, the sender suppresses the
indication that alternative data is available, so the negotiation
process cannot loop.
3. 代替のデータの形式のための好みを示すMDN応答を受け取り次第、送付者は、受信機の宣言している能力に合わせられたメッセージデータを選択して、送らなければならないか、または受信機の要求を尊敬できないという指示を送らなければなりません。 代替のデータを送るとき、送付者が代替のデータが利用可能であるという指示を抑圧するので、交渉プロセスは輪にされることができません。
Klyne, et. al. Standards Track [Page 10] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[10ページ]RFC3297の満足している交渉
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.
以下に注意してください。 受信機は受け取るために特定のデータの形式を選びません。 その選択は送付者に責任があります。 私たちは、このアプローチが受信機に代替手段を選ばせるより簡単であることがわかりました、伝統的なGroup3ファックスとしてメールで既存のメカニズムを当てにして、同じパターンに従うので。 さらに、それは代替手段の範囲が説明するのが難しいかもしれない状況に対処します。
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].
このアプローチはHTTP使用では、「受け入れてください」というサーバの駆動交渉ヘッダー[13]と同様です。 これはTransparent Content Negotiation[14]、どれがメールで「複合か代替」で使用することで組み立てられるかもしれないか、そして、または「外部のメッセージ/ボディー」MIMEの種類[15]の一部としてやる気満々のスタイルの交渉が備えたエージェントHTTPに異なっています。
3.1 Send data with an indication of alternatives
3.1は代替手段のしるしでデータを送ります。
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) Message-IDヘッダーの形におけるメッセージ識別。
(c) appropriate 'Content-features' header(s) [7] describing the
default message data sent,
(c) デフォルトメッセージデータについて説明する適切な'満足している特徴'ヘッダー[7]が発信しました。
(d) a request for Message Disposition Notification [4],
(d) Message Disposition Notification[4]を求める要求
(e) an indication that it is prepared to send different message
data, using an 'Alternative-available' MDN option field [9],
and
そして(e) '利用可能な代替手段'MDNオプション・フィールド[9]を使用して、異なったメッセージデータを送るのが準備されているという指示。
(f) an indication of the alternative data formats available, in the
form of 'Content-alternative' header(s) [8]. Note: more than
one Content-alternative' header MAY be specified; see section
3.1.3 for more information.
(f) '内容代替'のヘッダー[8]の形で利用可能な代替のデータ形式のしるし。 以下に注意してください。 '1つ以上の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
代替のデータ形式の有用性を示したので、送付者がしばらく必要事項を保持すると予想されます、そのようなデータを要求する機会を受信機に許容して。 しかし、そのように示す、([9]) 送付者がこの情報を無期限に保持しないと予想されるのを確実にしてください。 そのような情報が保持されるべきである時の正確な長さはここで指定されません。 このようにして
Klyne, et. al. Standards Track [Page 11] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[11ページ]RFC3297の満足している交渉
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.
代替の情報に関する要求があまりに遅く到着するかもしれない可能性は存在しています、そして、次に、送付者はもうデータを得ることができないという指示を送るでしょう。 メッセージ移転であるなら、予定された時以内に完成されるのは、間隔です。(例えば、次に、[21])を使用して、通常、送付者は少なくともその期間、データを保守するはずです。
3.1.1 Choice of default data format
3.1.1 デフォルトデータの形式の選択
The normal default format is text/plain. This is the format sent unless the sender has prior knowledge or expectation of other content formats supported by the recipient. Some uses of email presume some other default format (e.g. Intenet fax [1] has TIFF profile S [11] as its default format; see section 7 of this document).
正常な省略時書式はテキスト/明瞭です。 これは送付者が受取人に他の満足している形式への先の知識か期待をサポートさせない場合送られた形式です。 メールのいくつかの用途が、ある他のデフォルトが形式であると推定します(例えば、Intenetファックス[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.
「拡張Facsimile Usingインターネットメール」[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プロトコル)の範囲を超えて情報を収集するかもしれません。
3.1.2 MDN request indicating alternate data formats
3.1.2 MDNは代替のデータがフォーマットする表示を要求します。
When a sender is indicating preparedness to send alternative message data, it MUST request a Message Disposition Notification (MDN) [4].
送付者が代替のメッセージデータを送るために気構えを示しているとき、それはMessage Disposition Notification(MDN)[4]を要求しなければなりません。
It indicates its readiness to send alternative message data by including the MDN option 'Alternative-available' [9] with the MDN request. Presence of this MDN request option simply indicates that the sender is prepared to send some different data format if it has more accurate or up-to-date information about the receiver's capabilities. Of itself, this option does not indicate whether the alternatives are likely to be better or worse than the default data sent -- that information is provided by the "Content-alternative" header(s) [8].
それはMDN要求でMDNオプション'利用可能な代替手段'[9]を含んでいることによって代替のメッセージデータを送る準備を示します。 このMDN要求オプションの存在は、それに受信機の能力の正確であるか最新の情報があるなら送付者がいくらかの異なったデータの形式を送る用意ができているのを単に示します。 それ自体では、このオプションは、代替手段がデフォルトデータが発信したよりさらに良いか、または悪い傾向があるかどうかを示しません--情報は「内容代替」のヘッダー[8]によって提供されます。
When using the 'Alternative-available' option in an MDN request, the message MUST also contain a 'Message-ID:' header with a unique message identifier.
また、MDN要求における'利用可能な代替手段'オプションを使用するとき、メッセージはユニークなメッセージ識別子で'Message ID: 'ヘッダーを含まなければなりません。
Klyne, et. al. Standards Track [Page 12] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[12ページ]RFC3297の満足している交渉
3.1.3 Information about alternative data formats
3.1.3 代替のデータ形式に関する情報
A sender can provide information about the alternative message data available by applying one or more 'Content-alternative' headers to message body parts for which alternative data is available, each indicating media features [5,6] of an available alternative.
送付者は1個以上の'内容代替'のヘッダーを代替のデータが利用可能であるメッセージ身体の部分に付けることによって利用可能な代替のメッセージデータの情報を提供できます、それぞれ利用可能な代替手段のメディア機能[5、6]を示して。
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.)
代替の形式はしばしば元々送られたcontent typeの変化になるでしょう。 異なったcontent typeを提供できるとき、対応する内容代替のヘッダーで'タイプ'メディア特徴タグ[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.
さらに、'内容代替'のヘッダーはMIME身体の部分に適用します。そこでは、MDN'利用可能な代替手段'オプションが全体でメッセージに適用されます。
Klyne, et. al. Standards Track [Page 13] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[13ページ]RFC3297の満足している交渉
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ヘッダーが内容の提供されて利用可能な代替手段を説明するのにどう使用されるかもしれないかを示しています。
3.2 Receiver options
3.2 受信機オプション
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) 何らかの代替の形式を好んでください。
3.2.1 Alternatives not recognized
3.2.1 認識されなかった代替手段
This corresponds to the case that the receiver is a simple mode Internet fax recipient [12], or a traditional email user agent.
これは受信機があるケースに対応しています。純真なモードインターネットファックス受取人[12]、または伝統的なメールユーザエージェント。
The receiver does not recognize the alternatives offered, or chooses not to recognize them, and simply accepts the data as sent. A standard MDN response [4] or an extended MDN response [2] MAY be generated at the receiver's option.
受信機は、代替手段が提供したと認めないか、それらを認識しないのを選んで、または送るように単にデータを受け入れます。 標準のMDN応答[4]か拡張MDN応答[2]が受信機の選択で生成されるかもしれません。
3.2.2 Alternative not desired
3.2.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応答SHOULD。
This is the same as the defined behaviour of an Extended Internet Fax receiver [1,2].
これはExtendedインターネットファックス受信機[1、2]の定義されたふるまいと同じです。
3.2.3 Alternative preferred
3.2.3 好まれた代替手段
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
本件は、移されるべき現在のメッセージのための選択方式に関するデータを許容するためにExtendedインターネットファックス[1、2]のふるまいを広げています。 オリジナルのメッセージが'利用可能な代替手段'MDNオプションを含むだけであるならこのオプションが続かれるかもしれない、(代替
Klyne, et. al. Standards Track [Page 14] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[14ページ]RFC3297の満足している交渉
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:').
データが再送する、これがゆだねないどんな使用)であるかもしれない さらに、受取人がメッセージヘッダー('以下のこと'、'cc:'または'bcc:')で明らかに宛てられるだけであるなら、このオプションは続かれるかもしれません。
The receiver recognizes that alternative data is available, and based on the information provided determines that an alternative format would be preferable. An MDN response [4] is sent, which MUST contain the following:
受信機は、代替のデータが利用可能であると認めて、提供された情報に基づいて代替の形式が望ましいことを決定します。 MDN応答[4](以下を含まなければなりません)を送ります:
o an 'Alternative-preferred' disposition modifier [9] indicating
that some data format other than that originally sent is
preferred,
o それを除いたいくらかのデータの形式が元々発信したのを示す'代替手段で都合のよい'気質修飾語[9]は好まれます。
o an 'Original-Message-ID:' field [4] with the message identifier
from the received message, and
o そして'元のMessage ID: '受信されたメッセージからのメッセージ識別子で[4]をさばいてください。
o receiver capabilities, per RFC 2530 [2].
o RFC2530[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応答を送ると、受信機は何らかの選択肢が送られる期待に提供されたメッセージデータを捨てるかもしれません。 しかし、送付者が代替のデータのために限られた生涯を示して、表示する受信機の能力の中に受け取られたオリジナルのデータがあるなら、受信機SHOULD NOTはそれを捨てます。 代替のデータが合理的に受け取られるしばらくオリジナルのデータを保持できるくらいの記憶を欠いていて、受信機SHOULDはオリジナルのデータを受け入れて、表示します。 その時それを表示する受信機の能力の中にオリジナルのデータがなくて、SHOULDはオリジナルのデータを捨てて、代替の書式を要求します。
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) 元々提供されたデータを提示してください、(それがまだ利用可能であるなら)。
Klyne, et. al. Standards Track [Page 15] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[15ページ]RFC3297の満足している交渉
(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.
受信機ふるまいオプションのさらなる議論に関してAppendix Aを見てください。
NOTE: A cache control indicator on recipient capabilities has
been considered, but is not included in this specification.
(Sometimes, a recipient may want to offer certain capabilities
only under certain circumstances, and does not wish them to be
remembered for future use; e.g., not wanting to receive colour
images for routine communications.)
以下に注意してください。 受取人能力に関するキャッシュ制御インディケータは、考えられましたが、この仕様に含まれていません。 (受取人は、時々、ある状況だけの下に、ある能力を提供したいかもしれなくて、それらが今後の使用のために覚えていられて欲しくはありません; 例えば、通常のコミュニケーションのための色のイメージを受け取りたくはありません。)
NOTE: the receiver does not actually get to select any specific
data format offered by the sender. The final choice of data
format is always made by the sender, based on the receiver's
declared capabilities. This approach:
以下に注意してください。 受信機は、実際に送付者によって提供されたどんな特定のデータの形式も選択し始めません。 データの形式の最終的な選択は受信機の宣言している能力に基づいていつも送付者によってされます。 このアプローチ:
(a) more closely matches the style of T.30 content negotiation,
(a) 以上は密接にT.30の満足している交渉のスタイルに合っています。
(b) provides for clean integration with the current extended
mode Internet fax specification,
現在の拡張モードインターネットファックス仕様で(b)は清潔な統合に備えます。
(c) builds upon existing email mechanisms in a consistent
fashion, and
そして(c) 存在するときの体格が一貫したファッションでメカニズムをメールする。
(d) allows for cases (e.g., dynamically generated content) where
it is not feasible for the sender to enumerate the
alternatives available.
(d)は送付者が利用可能な代替手段を列挙するのが、可能でないところでケースを考慮します(例えば、内容であるとダイナミックに生成されます)。
3.3 Send alternative message data
3.3は代替のメッセージデータを送ります。
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要求、送付者SHOULDが代替のメッセージデータを送るのをであっ'て、'代替手段で、都合のよ示す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要求を含むべきですが、SHOULD NOTは'利用可能な代替手段'気質通知修飾語を含んでいます。
Klyne, et. al. Standards Track [Page 16] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[16ページ]RFC3297の満足している交渉
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.
送付者がどんな理由でももうメッセージデータを送ることができないなら、それは失敗した転送を示す受信機にメッセージを送らなければなりません。 それ、また、SHOULDは失敗を示す受信機のためのレポートを作ります、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.
代替のデータに関する要求に対応して受信機に送られたどんなメッセージも'元のMessage ID: '受信された気質通知メッセージからのOriginalメッセージID値を含むヘッダー[23]を含まなければならない、('Message IDはどれです:、'、オリジナルのメッセージ) aを区別してください。また、そして、このヘッダーが、関連するのに勤める、再送、(または、失敗メッセージ) オリジナルのメッセージでオリジナルのメッセージから、再送します。
3.4 Confirm receipt of resent message data
メッセージデータを再送して、3.4は領収書を確認します。
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].
再送するとデータが受信されていて('元のメッセージID: 'ヘッダーフィールドの存在によって示されます)、受信機は、データの最終的な気質が受信されたのを示して、またRFC2530[2]あたりの将来のメッセージに使用されるかもしれない能力を示すMDN応答と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:
再送、もう代替のデータを得ることができないで('利用可能でない代替手段'気質通知修飾語を含んでいるのによる)、受信機が送られたオリジナルのデータを捨てて、それが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".
そして、メッセージ気質応答に「削除されること」の最終的なメッセージ気質を示させてください。
Klyne, et. al. Standards Track [Page 17] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[17ページ]RFC3297の満足している交渉
4. The Content-alternative header
4. Content-代替手段ヘッダー
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:
RFC2234[10]のABNF記法を使用して、'内容代替手段'ヘッダーの構文は以下と定義されます。
Content-alternative-header =
"Content-alternative" ":" Alternative-feature-expression
「満足している代替のヘッダーは「満足している代替手段」と等しい」:、」 代替の特徴式
Alternative-feature-expression =
<As defined for 'Filter' by RFC 2533 [6]>
'フィルタ'のためにRFC2533によって定義された代替の特徴式=<As[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.
1つ以上の'満足している選択肢: 'ヘッダーは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.
Content-代替手段ヘッダー価値を解釈するとき、したがって、受信機は、明らかに言及されなかった特徴が供給されたデータと示された代替手段において異なっていないと仮定するかもしれません。 例えば、Content-代替手段ヘッダーが代替のMIME content typeについて言及しないなら、受信機は、利用可能な代替手段が供給されたデータと同じcontent typeを使用すると仮定するかもしれません。
See also the example in section 8.4.
また、セクション8.4の例を見てください。
5. The Original-Message-ID message header
5. Original Message IDメッセージヘッダー
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).
または、'元のMessage ID'ヘッダーがどんなメッセージ応答も関連させるのに使用される、それが関係する(また、セクション3.2.3、3.3を見ます)オリジナルのメッセージと共に再送します。 Aが再送する、オリジナルのメッセージ(それ自身のユニークなMessage-IDがそれで評価しなければならない(RFC2822あたりセクション3.6.4)そう)と、異なります。
Klyne, et. al. Standards Track [Page 18] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[18ページ]RFC3297の満足している交渉
The syntax for this header is:
このヘッダーのための構文は以下の通りです。
"Original-Message-ID" ":" msg-id
「「元のMessage ID」」:、」 msg-イド
where 'msg-id' is defined by RFC 2822 as:
'msg-イド'がRFC2822によって定義されるところ:
msg-id = "<" id-left "@" id-right ">"
msg-イド="<"イドによる左の"@"イド権利">"
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-イド'値はMessage-IDで供給されたそれと同じであるに違いありません: または、現在のメッセージが応答であるオリジナルのメッセージのヘッダー、再送します。
6. MDN extension for alternative data
6. 代替のデータのためのMDN拡張子
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.
ここで、私たちは、送付者が代替のメッセージデータ形式を送って、受信機が何らかの代替の形式のための優先を示すのを許容する準備を示すのを許容するためにMessage Disposition Notification(MDN)プロトコル[4]と2つの拡大を定義します。
Indication of what alternatives may be available or preferred are not covered here. This functionality is provided by the 'Content- alternative' MIME header [8] and "Indicating Supported Media Features Using Extensions to DSN and MDN" [2].
しるしはどんな代替手段が利用可能であるか、または都合のよいかもしれないかについてここにカバーされていません。 '内容代替手段'MIMEヘッダー[8]と「表示は、メディアが特徴であるとDSNとMDNに拡張子を使用することでサポートした」[2]はこの機能性を提供します。
6.1 Indicating readiness to send alternative data
6.1 代替のデータを送る準備を示すこと。
A sender wishing to indicate its readiness to send alternative message data formats must request an MDN response using the MDN 'Disposition-Notification-To:' header [4].
代替のメッセージデータ形式を送る準備を示したがっている送付者は、MDN'気質通知To:'ヘッダー[4]を使用することでMDN応答を要求しなければなりません。
The MDN request is accompanied by a 'Disposition-Notification- Options:' header containing the parameter 'Alternative-available' with an importance value of 'optional'. (The significance of 'optional' is that receiving agents unaware of this option do not generate inappropriate failure responses.)
'利用可能な気質通知オプション: 'パラメタを含むヘッダー'代替手段'でMDN要求は'任意'の重要性値で伴われます。 ('任意'の意味はこのオプションに気づかない受信エージェントが不適当な失敗応答を生成しないということです。)
This specification defines a value for 'attribute' to be used in an MDN 'Disposition-Notification-Options:' header [4]:
この仕様は''MDNでは、使用される'気質通知オプションを結果と考えてください'というヘッダー[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: <は>気質通知オプションを送付者と同じくらい扱います: 代替手段利用可能な=任意の<生涯>。
Klyne, et. al. Standards Track [Page 19] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[19ページ]RFC3297の満足している交渉
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].
メッセージはMDNを求める要求と共に'代替手段利用可能な'また、オプションは'Message IDを含まなければならなく'ヘッダーフィールド[20]で発信しました。
6.2 Indicating a preference for alternative data
6.2 代替のデータのための優先を示すこと。
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
気質: 削除されたか代替手段で都合のよい<動作モード<発信>/モード>。
Klyne, et. al. Standards Track [Page 20] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[20ページ]RFC3297の満足している交渉
For example, an automatically generated response might contain:
例えば、自動的に生成している応答は以下を含むかもしれません。
Disposition:
automatic-action/MDN-sent-automatically,
deleted/alternative-preferred
気質: 自動..動作..発信..自動的..削除..代替手段..都合のよい
An MDN response containing an 'alternative-preferred' disposition modifier MUST also contain an 'Original-message-ID:' field [4] with the 'Message-ID:' value from the original message.
また、'代替手段で都合のよい'気質修飾語を含むMDN応答は'オリジナルのメッセージIDを含まなければなりません: ''Message IDがある分野[4]:'オリジナルのメッセージからの値。
An MDN response containing an 'alternative-preferred' disposition modifier SHOULD also contain a 'Media-accept-features:' field [2] indicating the capabilities that the sender should use in selecting an alternative form of message data. If this field is not supplied, the sender should assume some baseline feature capabilities. Receiver capabilities supplied with an alternative-preferred disposition notification MUST NOT be cached: they may apply to the current transaction only.
またSHOULDが選択方式に関するメッセージデータを選択しながら'メディアは特徴を受け入れる'という送付者が使用するべきである能力を示す分野[2]を含む'代替手段で都合のよい'気質修飾語を含むMDN応答。 この野原が供給されないなら、送付者は、何らかの基線が特徴能力であると仮定するべきです。 代替手段で都合のよい気質通知が供給された受信機能力をキャッシュしてはいけません: 彼らは経常取引だけに適用するかもしれません。
6.3 Indicating alternative data is no longer available
6.3 もう代替のデータを得ることができないのを示すこと。
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'気質通知To:'ヘッダー[4]を指定しなければなりません。
This specification defines a value for 'attribute' to be used in an MDN 'Disposition-Notification-Options:' header [4]:
この仕様は''MDNでは、使用される'気質通知オプションを結果と考えてください'というヘッダー[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: <は>気質通知オプションを送付者と同じくらい扱います: 代替手段利用可能でない=が必要です。(本当に)
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を含まなければなりません: ''Message IDからの値を含むヘッダー[23]:'オリジナルのメッセージのヘッダー。
Klyne, et. al. Standards Track [Page 21] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[21ページ]RFC3297の満足している交渉
6.4 Indicating loss of original data
6.4 オリジナルのデータの損失を示すこと。
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: ''Message IDがある分野[4]:'値を含まなければならない'オリジナルに無くなっている'気質を含んでいて、再送が通信するか、またはオリジナルから、通信してください、(いいえが再送する、受け取った、)
6.5 Automatic sending of MDN responses
6.5 MDN応答の自動発信
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応答を送る際に、安全上の配慮は、RFC2298に[4] 自動MDN応答に関する(セクション2.1と6.2)を尊敬しなければならないと述べました。 特に、満足している交渉を実行できるシステムは一般に、ユーザが交渉応答を無効にするオプションを持たなければなりません、1メッセージあたり1つの基礎、または両方で。
7. Internet Fax Considerations
7. インターネットファックス問題
Internet fax is an application that uses email to exchange document images (see RFC RFC 2305 [12] and RFC 2532 [1]).
インターネットファックスはドキュメントイメージを交換するのにメールを使用するアプリケーションです。(RFC RFC2305[12]とRFC2532[1])を見てください。
Both sender and receiver parts of this specification involve the use of media feature expressions. In the context of Internet fax, any such expressions SHOULD employ feature tags defined by "Content feature schema for Internet fax" [16]. In a wider email context, any valid media features MAY be used.
送付者とこの仕様の受信機部分の両方がメディア特徴式の使用にかかわります。 インターネットファックスの文脈では、どんなそのような式SHOULDも「インターネットファックスのための満足している特徴図式」[16]によって定義された特徴タグを使います。 より広いメール関係では、どんな有効なメディア機能も使用されるかもしれません。
Klyne, et. al. Standards Track [Page 22] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[22ページ]RFC3297の満足している交渉
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]に関しては、「イメージ/いさかい」はメッセージデータのための想定されたcontent typeです。 TIFFプロフィールS能力を送って、あえてすべてのインターネットファックスデバイスを特に、受けることができます。([11])のセクション3。 インターネットファックスデバイスの間にコミュニケーションがあるとき、この能力は想定されるかもしれません。 しかし、インターネットファックス(例えば、ファックス能力があるジェネリックメールエージェント)のために定義されたこれらの能力を越えるデバイスに対処するとき、ファックスが能力であると仮定しないで、交渉パーティーが彼らのすべての能力に関して明白であることは、より良いでしょう。
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.
インターネットファックスデバイスさえ、彼らが他のそのようなデバイスとコミュニケートしていると仮定しないなら、より良いでしょう。 インターネットメールを使用するとき、この事実を確立するどんな信頼できる方法もありません。 したがって、いかなる他のメールエージェントともメッセージを交換すると合理的に予想されるどんなインターネットファックスデバイスに関しても、インターネットファックス能力(イメージ/いさかい基線形式取り扱いの)が明らかに想定されませんが、述べられているのは、RECOMMENDEDです。
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.
特に'メディアは特徴を受け入れる'というSHOULDが明らかに示す(=「イメージ/いさかい」をタイプします)受信機MDN応答とそれらが理解されているとただ仮定するよりむしろ基線TIFF能力におけるヘッダー。
8. Examples
8. 例
8.1 Sending enhanced Internet Fax image
8.1 発信はインターネットファックスイメージを高めました。
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日の00:18:00(東部夏時間の)-0400From: ジェーン Sender <Jane_Sender@example.com 、gt;、メッセージイド: <199509200019.12345@example.com>Subject: モードのインターネットのファックスの完全な内容交渉To: トム Recipient <Tom_Recipient@example.org 、gt;、気質通知To: Jane_Sender@example.com 気質通知オプション: 利用可能な代替手段は任意の、そして、永久的なMIMEバージョンと等しいです: 1.0コンテントタイプ: 複合か混ぜられる。 境界="RAA14128.773615765/ example.com"
Klyne, et. al. Standards Track [Page 23] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[23ページ]RFC3297の満足している交渉
--RAA14128.773615765/ example.com
Content-type: image/tiff
Content-Transfer-Encoding: base64
Content-features:
(& (color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
Content-alternative:
(& (color=Binary)
(image-file-structure=TIFF-limited)
(dpi=400)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MMR)
(MRC-mode=0)
(ua-media=stationery) )
--RAA14128.773615765/ example.com文書内容: いさかいContent転送イメージ/コード化: base64 Content-特徴: ((=を着色して、2進にします)(イメージファイル構造=いさかい最小量の)(dpi=200)(dpi-xyratio=1)(紙サイズ=A4)(画像符号化はMHと等しいです)(MRC-モード=0)(ua-メディア=文房具)) 満足している代替手段: ((=を着色して、2進にします)(イメージファイル構造=いさかいで限られた)(dpi=400)(dpi-xyratio=1)(紙サイズ=A4)(画像符号化はMMRと等しいです)(MRC-モード=0)(ua-メディア=文房具))
[TIFF-FX Profile-S message goes here]
[TIFF-FX Profile-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"
日付: 水曜日、1995年9月20日の00:19:00(東部夏時間の)-0400From: トム Recipient <Tom_Recipient@example.org 、gt;、メッセージイド: <199509200020.12345@example.org>Subject: Re: モードのインターネットのファックスの完全な内容交渉To: ジェーン Sender <Jane_Sender@example.com 、gt;、MIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは気質通知と等しいです。 境界="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.
メッセージが9月20日に00:18:00(東部夏時間の)-0400でトム Recipient <Tom_Recipient@example.org に1995を転送した、gt;、対象で、「モードのインターネットのファックスの完全な内容交渉」を受け取りました。 メッセージデータの選択方式は要求されています。
Klyne, et. al. Standards Track [Page 24] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[24ページ]RFC3297の満足している交渉
--RAA14128.773615766/example.org
Content-Type: message/disposition-notification
--RAA14128.773615766/example.orgコンテントタイプ: 気質メッセージ/通知
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: トムズ-pc.cs.example.org。 IFAX-FullModeのオリジナルの受取人: rfc822;Tom-Recipient@example.org 最終受理者: rfc822;Tom-Recipient@example.org の元のMessage ID: <199509200019.12345@example.com>気質: MDNは自動的に自動動作/発信していました。 メディアが特徴を受け入れた状態で/を削除する、代替手段で都合のよい状態で: タイプ..イメージ..いさかい..着色..2進..イメージ..ファイル構造..等しい..いさかい..dpi..dpi..dpi..dpi..dpi..dpi..画像符号化..画像符号化..等しい..イメージ..コード化..規制..等しい..しま..サイズ..モード..紙サイズ..メディア..等しい..文房具
--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日の00:21:00(東部夏時間の)-0400From: ジェーン Sender <Jane_Sender@example.com 、gt;、メッセージイド: <の199509200021.12345@example.comの>のオリジナルのメッセージイド: <199509200019.12345@example.com>Subject: インターネットのファックスの完全なモード映像電送To: トム Recipient <Tom_Recipient@example.org 、gt;、気質通知To: Jane_Sender@example.com MIMEバージョン: 1.0コンテントタイプ: 複合か混ぜられる。 境界="RAA14128.773615768/ example.com"
--RAA14128.773615768/ example.com
Content-type: image/tiff
Content-Transfer-Encoding: base64
--RAA14128.773615768/ example.com文書内容: いさかいContent転送イメージ/コード化: base64
[TIFF-FX profile-F message goes here]
[TIFF-FXプロフィールFメッセージはここに行きます]
--RAA14128.773615768/ example.com--
--RAA14128.773615768/ example.com--
Klyne, et. al. Standards Track [Page 25] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[25ページ]RFC3297の満足している交渉
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"
日付: 水曜日、1995年9月20日の00:22:00(東部夏時間の)-0400From: トム Recipient <Tom_Recipient@example.org 、gt;、メッセージイド: <199509200022.12345@example.org>Subject: Re: インターネットのファックスの完全なモード映像電送To: ジェーン Sender <Jane_Sender@example.com 、gt;、MIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは気質通知と等しいです。 境界="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.
メッセージが9月20日に00:21:00(東部夏時間の)-0400でトム Recipient <Tom_Recipient@example.org に1995を転送した、gt;、対象で、インターネットFAX Full Modeで「インターネットのファックスの完全なモード映像電送」を処理してあります。
--RAA14128.773615769/example.org
Content-Type: message/disposition-notification
--RAA14128.773615769/example.orgコンテントタイプ: 気質メッセージ/通知
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: トムズ-pc.cs.example.org。 IFAX-FullModeのオリジナルの受取人: rfc822;Tom-Recipient@example.org 最終受理者: rfc822;Tom-Recipient@example.org の元のMessage ID: <199509200021.12345@example.com>気質: MDNは自動的に自動動作/発信していました。 処理されて、メディアは特徴を受け入れます: タイプ..イメージ..いさかい..着色..2進..イメージ..ファイル構造..等しい..いさかい..dpi..dpi..dpi..dpi..dpi..dpi..画像符号化..画像符号化..等しい..イメージ..コード化..規制..等しい..しま..サイズ..モード..紙サイズ..メディア..等しい..文房具
--RAA14128.773615769/example.org--
--RAA14128.773615769/example.org--
Klyne, et. al. Standards Track [Page 26] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[26ページ]RFC3297の満足している交渉
8.2 Internet fax with initial data usable
8.2 初期のデータが使用可能のインターネットファックス
This example shows how the second and subsequent transfers between the systems in the previous example might be conducted. Using knowledge gained from the previous exchange, the sender includes profile-F data with its first contact.
この例は前の例のシステムの間の2番目の、そして、その後の転送がどう行われるかもしれないかを示しています。 前の交換から獲得された知識を使用して、送付者は最初の接触に伴うプロフィール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日の00:19:00(東部夏時間の)-0400From: ジェーン Sender <Jane_Sender@example.com 、gt;、メッセージイド: <199509200019.12345@example.com>Subject: モードのインターネットのファックスの完全な内容交渉To: トム Recipient <Tom_Recipient@example.org 、gt;、気質通知To: Jane_Sender@example.com 気質通知オプション: 利用可能な代替手段は任意の、そして、永久的なMIMEバージョンと等しいです: 1.0コンテントタイプ: 複合か混ぜられる。 境界="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com
Content-type: image/tiff
Content-Transfer-Encoding: base64
Content-features:
(& (color=Binary)
(image-file-structure=TIFF-limited)
(dpi=400)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MMR)
(MRC-mode=0)
(ua-media=stationery) )
Content-alternative:
(& (color=Binary)
(image-file-structure=TIFF-minimal)
(dpi=200)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MH)
(MRC-mode=0)
(ua-media=stationery) )
--RAA14128.773615765/ example.com文書内容: いさかいContent転送イメージ/コード化: base64 Content-特徴: ((=を着色して、2進にします)(イメージファイル構造=いさかいで限られた)(dpi=400)(dpi-xyratio=1)(紙サイズ=A4)(画像符号化はMMRと等しいです)(MRC-モード=0)(ua-メディア=文房具)) 満足している代替手段: ((=を着色して、2進にします)(イメージファイル構造=いさかい最小量の)(dpi=200)(dpi-xyratio=1)(紙サイズ=A4)(画像符号化はMHと等しいです)(MRC-モード=0)(ua-メディア=文房具))
[TIFF-FX Profile-F message goes here]
[TIFF-FX Profile-Fメッセージはここに行きます]
--RAA14128.773615765/ example.com--
--RAA14128.773615765/ example.com--
Klyne, et. al. Standards Track [Page 27] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[27ページ]RFC3297の満足している交渉
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"
日付: 水曜日、1995年9月20日の00:22:00(東部夏時間の)-0400From: トム Recipient <Tom_Recipient@example.org 、gt;、メッセージイド: <199509200022.12345@example.org>Subject: Re: インターネットのファックスの完全なモード映像電送To: ジェーン Sender <Jane_Sender@example.com 、gt;、MIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは気質通知と等しいです。 境界="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.
メッセージが9月20日に00:19:00(東部夏時間の)-0400でトム Recipient <Tom_Recipient@example.org に1995を転送した、gt;、対象で、インターネットFAX Full Modeで「インターネットのファックスの完全なモード映像電送」を処理してあります。
--RAA14128.773615769/example.org
Content-Type: message/disposition-notification
--RAA14128.773615769/example.orgコンテントタイプ: 気質メッセージ/通知
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: トムズ-pc.cs.example.org。 IFAX-FullModeのオリジナルの受取人: rfc822;Tom-Recipient@example.org 最終受理者: rfc822;Tom-Recipient@example.org の元のMessage ID: <199509200021.12345@example.com>気質: MDNは自動的に自動動作/発信していました。 処理されて、メディアは特徴を受け入れます: タイプ..イメージ..いさかい..着色..2進..イメージ..ファイル構造..等しい..いさかい..dpi..dpi..dpi..dpi..dpi..dpi..画像符号化..画像符号化..等しい..イメージ..コード化..規制..等しい..しま..サイズ..モード..紙サイズ..メディア..等しい..文房具
--RAA14128.773615769/example.org--
--RAA14128.773615769/example.org--
Klyne, et. al. Standards Track [Page 28] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[28ページ]RFC3297の満足している交渉
8.3 Negotiate to lower receiver capability
8.3は、受信機能力を下ろすのを交渉します。
In this example, the sender has incorrectly assumed that the receiver has a higher capability, and must re-send lower capability data in response to the receiver's response showing lesser capability.
この例では、送付者は、受信機が、より高い能力を持って、より少ない能力を示している受信機の応答に対応して低い能力データを再送しなければならないと不当に仮定しました。
An Internet fax sends a profile-F (A4, 400x400dpi, MMR) image. When the receiver cannot handle this, it falls back to baseline profile-S. As this is a baseline format, it is not necessary to declare that capability with the original message. When a receiver is faced with data it cannot process from a negotiating sender, it can do no better than to respond with a description of its actual capabilities and let the sender determine the outcome.
インターネットファックスはプロフィールF(A4、400x400dpi、MMR)イメージを送ります。 受信機がこれを扱うことができないとき、それは基線へSの輪郭を描いて後ろへ下がります。 これが基線形式であるので、オリジナルのメッセージでその能力を宣言するのは必要ではありません。 受信機はそれが交渉している送付者から処理できないデータに直面しているとき、それで、送付者が、実際の能力の記述がある反応するより良いノーをして、結果を決定できます。
Sender's initial message:
送付者の初期のメッセージ:
Date: Wed, 20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Negotiate Down
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
日付: 水曜日、1995年9月20日の00:18:00(東部夏時間の)-0400From: ジェーン Sender <Jane_Sender@example.com 、gt;、メッセージイド: <199509200019.12345@example.com>Subject: インターネットのファックスの完全なモードは以下まで交渉します。 トム Recipient <Tom_Recipient@example.org 、gt;、気質通知To: Jane_Sender@example.com 気質通知オプション: 利用可能な代替手段は任意の、そして、永久的なMIMEバージョンと等しいです: 1.0コンテントタイプ: 複合か混ぜられる。 境界="RAA14128.773615765/ example.com"
--RAA14128.773615765/ example.com
Content-type: image/tiff
Content-Transfer-Encoding: base64
Content-features:
(& (color=Binary)
(image-file-structure=TIFF-limited)
(dpi=400)
(dpi-xyratio=1)
(paper-size=A4)
(image-coding=MMR)
(MRC-mode=0)
(ua-media=stationery) )
--RAA14128.773615765/ example.com文書内容: いさかいContent転送イメージ/コード化: base64 Content-特徴: ((=を着色して、2進にします)(イメージファイル構造=いさかいで限られた)(dpi=400)(dpi-xyratio=1)(紙サイズ=A4)(画像符号化はMMRと等しいです)(MRC-モード=0)(ua-メディア=文房具))
[TIFF-FX Profile-F message goes here]
[TIFF-FX Profile-Fメッセージはここに行きます]
--RAA14128.773615765/ example.com--
--RAA14128.773615765/ example.com--
Klyne, et. al. Standards Track [Page 29] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[29ページ]RFC3297の満足している交渉
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"
日付: 水曜日、1995年9月20日の00:19:00(東部夏時間の)-0400From: トム Recipient <Tom_Recipient@example.org 、gt;、メッセージイド: <199509200020.12345@example.org>Subject: Re: インターネットのファックスの完全なモードは以下まで交渉します。 ジェーン Sender <Jane_Sender@example.com 、gt;、MIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは気質通知と等しいです。 境界="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.
メッセージが9月20日に00:18:00(東部夏時間の)-0400でトム Recipient <Tom_Recipient@example.org に1995を転送した、gt;、対象で、「モードのインターネットのファックスの完全な内容交渉」を受け取りました。 メッセージデータの選択方式は要求されています。
--RAA14128.773615766/example.org
Content-Type: message/disposition-notification
--RAA14128.773615766/example.orgコンテントタイプ: 気質メッセージ/通知
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: トムズ-pc.cs.example.org。 IFAX-FullModeのオリジナルの受取人: rfc822;Tom-Recipient@example.org 最終受理者: rfc822;Tom-Recipient@example.org の元のMessage ID: <199509200019.12345@example.com>気質: MDNは自動的に自動動作/発信していました。 メディアが特徴を受け入れた状態で/を削除する、代替手段で都合のよい状態で: ((タイプ=「イメージ/いさかい」)(=を着色して、2進にします)(イメージファイル構造=いさかい最小量の)(dpi=200)(dpi-xyratio=1)(紙サイズ=A4)(画像符号化はMHと等しいです)(MRC-モード=0)(ua-メディアは文房具と等しいです))
--RAA14128.773615766/example.org--
--RAA14128.773615766/example.org--
Klyne, et. al. Standards Track [Page 30] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[30ページ]RFC3297の満足している交渉
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日の00:21:00(東部夏時間の)-0400From: ジェーン Sender <Jane_Sender@example.com 、gt;、メッセージイド: <の199509200021.12345@example.comの>のオリジナルのメッセージイド: <199509200019.12345@example.com>Subject: インターネットのファックスの完全なモード映像電送To: トム Recipient <Tom_Recipient@example.org 、gt;、気質通知To: Jane_Sender@example.com MIMEバージョン: 1.0コンテントタイプ: 複合か混ぜられる。 境界="RAA14128.773615768/ example.com"
--RAA14128.773615768/ example.com
Content-type: image/tiff
Content-Transfer-Encoding: base64
--RAA14128.773615768/ example.com文書内容: いさかいContent転送イメージ/コード化: 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"
日付: 水曜日、1995年9月20日の00:22:00(東部夏時間の)-0400From: トム Recipient <Tom_Recipient@example.org 、gt;、メッセージイド: <199509200022.12345@example.org>Subject: Re: インターネットのファックスの完全なモード映像電送To: ジェーン Sender <Jane_Sender@example.com 、gt;、MIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは気質通知と等しいです。 境界="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.
メッセージが9月20日に00:21:00(東部夏時間の)-0400でトム Recipient <Tom_Recipient@example.org に1995を転送した、gt;、対象で、インターネットFAX Full Modeで「インターネットのファックスの完全なモード映像電送」を処理してあります。
--RAA14128.773615769/example.org
Content-Type: message/disposition-notification
--RAA14128.773615769/example.orgコンテントタイプ: 気質メッセージ/通知
Klyne, et. al. Standards Track [Page 31] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[31ページ]RFC3297の満足している交渉
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: トムズ-pc.cs.example.org。 IFAX-FullModeのオリジナルの受取人: rfc822;Tom-Recipient@example.org 最終受理者: rfc822;Tom-Recipient@example.org の元のMessage ID: <199509200021.12345@example.com>気質: MDNは自動的に自動動作/発信していました。 処理されて、メディアは特徴を受け入れます: ((=を着色して、2進にします)(イメージファイル構造=いさかい最小量の)(dpi=200)(dpi-xyratio=1)(紙サイズ=A4)(画像符号化はMHと等しいです)(MRC-モード=0)(ua-メディア=文房具))
--RAA14128.773615769/example.org--
--RAA14128.773615769/example.org--
8.4 Sending an alternative content type
8.4 ホームページの別版タイプを送ること。
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)イメージとPDF文書が基線への代替手段としてイメージ/TIFFを提供した限られた色を示しています。
Sender's initial message:
送付者の初期のメッセージ:
(Note that the MIME content type is not specified for the
image/tiff alternative, being the same as that provided, but
is mentioned for the application/pdf alternative.)
(MIME内容タイプがイメージ/いさかい代替手段に指定されないことに注意してください、それが提供しますが、アプリケーション/pdf代替手段のために言及されるのと同じであることで。)
Date: Wed,20 Sep 1995 00:18:00 (EDT)-0400
From: Jane Sender <Jane_Sender@example.com>
Message-Id: <199509200019.12345@example.com>
Subject: Internet FAX Full Mode Content Negotiation
To: Tom Recipient <Tom_Recipient@example.org>
Disposition-Notification-To: Jane_Sender@example.com
Disposition-Notification-Options:
Alternative-available=optional,permanent
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="RAA14128.773615765/ example.com"
日付: 水曜日、1995年9月20日の00:18:00(東部夏時間の)-0400From: ジェーン Sender <Jane_Sender@example.com 、gt;、メッセージイド: <199509200019.12345@example.com>Subject: モードのインターネットのファックスの完全な内容交渉To: トム Recipient <Tom_Recipient@example.org 、gt;、気質通知To: Jane_Sender@example.com 気質通知オプション: 利用可能な代替手段は任意の、そして、永久的なMIMEバージョンと等しいです: 1.0コンテントタイプ: 複合か混ぜられる。 境界="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)
--RAA14128.773615765/ example.com文書内容: いさかいContent転送イメージ/コード化: base64 Content-特徴: ((色=バイナリー)(イメージファイル構造=いさかい最小量)です。
Klyne, et. al. Standards Track [Page 32] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[32ページ]RFC3297の満足している交渉
(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) )
(dpi=200) (dpi-xyratio=1)(紙サイズ=A4)(画像符号化はMHと等しいです)(MRC-モード=0)(ua-メディア=文房具) 満足している代替手段: ((=を着色して、2進にします)(イメージファイル構造=いさかいで限られた)(dpi=400)(dpi-xyratio=1)(紙サイズ=A4)(画像符号化はMMRと等しいです)(MRC-モード=0)(ua-メディア=文房具)) 満足している代替手段: ((タイプ=「アプリケーション/pdf」)(色は株式会社と等しいです)(dpi=400)(紙サイズ=A4)(ua-メディアは文房具と等しいです))
[TIFF-FX Profile-S message goes here]
[TIFF-FX Profile-Sメッセージはここに行きます]
--RAA14128.773615765/ example.com--
--RAA14128.773615765/ example.com--
Receiver sends MDN response to initial message:
受信機はメッセージに頭文字をつけるために応答をMDNに送ります:
(Note that this response indicates an ability to handle the
PDF MIME content-types, but with only binary colour.)
(この応答がPDF MIMEの満足しているタイプを扱う能力を示すことに注意しなさい、ただし、バイナリーだけで、着色してください。)
Date: Wed,20 Sep 1995 00:19:00 (EDT)-0400
From: Tom Recipient <Tom_Recipient@example.org>
Message-Id: <199509200020.12345@example.org>
Subject: Re: Internet FAX Full Mode Content Negotiation
To: Jane Sender <Jane_Sender@example.com>
MIME-Version: 1.0
Content-Type: multipart/report;
report-type=disposition-notification;
boundary="RAA14128.773615766/example.org"
日付: 水曜日、1995年9月20日の00:19:00(東部夏時間の)-0400From: トム Recipient <Tom_Recipient@example.org 、gt;、メッセージイド: <199509200020.12345@example.org>Subject: Re: モードのインターネットのファックスの完全な内容交渉To: ジェーン Sender <Jane_Sender@example.com 、gt;、MIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは気質通知と等しいです。 境界="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.
メッセージが9月20日に00:18:00(東部夏時間の)-0400でトム Recipient <Tom_Recipient@example.org に1995を転送した、gt;、対象で、「モードのインターネットのファックスの完全な内容交渉」を受け取りました。 メッセージデータの選択方式は要求されています。
Klyne, et. al. Standards Track [Page 33] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[33ページ]RFC3297の満足している交渉
--RAA14128.773615766/example.org
Content-Type: message/disposition-notification
--RAA14128.773615766/example.orgコンテントタイプ: 気質メッセージ/通知
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: トムズ-pc.cs.example.org。 IFAX-FullModeのオリジナルの受取人: rfc822;Tom-Recipient@example.org 最終受理者: rfc822;Tom-Recipient@example.org の元のMessage ID: <199509200019.12345@example.com>気質: MDNは自動的に自動動作/発信していました。 メディアが特徴を受け入れた状態で/を削除する、代替手段で都合のよい状態で: タイプ..イメージ..いさかい..着色..2進..イメージ..ファイル構造..いさかい..最小量..dpi..dpi..画像符号化..等しい..モード..紙サイズ..メディア..等しい..文房具..タイプ..アプリケーション..着色..2進..dpi..dpi..等しい..紙サイズ..メディア..等しい..文房具
--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日の00:21:00(東部夏時間の)-0400From: ジェーン Sender <Jane_Sender@example.com 、gt;、メッセージイド: <の199509200021.12345@example.comの>のオリジナルのメッセージイド: <199509200019.12345@example.com>Subject: インターネットのファックスの完全なモード映像電送To: トム Recipient <Tom_Recipient@example.org 、gt;、気質通知To: Jane_Sender@example.com MIMEバージョン: 1.0コンテントタイプ: 複合か混ぜられる。 境界="RAA14128.773615768/ example.com"
--RAA14128.773615768/ example.com
Content-type: application/pdf
Content-Transfer-Encoding: base64
--RAA14128.773615768/ example.com文書内容: pdf Content転送アプリケーション/コード化: base64
[PDF data goes here]
[PDFデータはここに行きます]
--RAA14128.773615768/ example.com--
--RAA14128.773615768/ example.com--
Klyne, et. al. Standards Track [Page 34] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[34ページ]RFC3297の満足している交渉
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"
日付: 水曜日、1995年9月20日の00:22:00(東部夏時間の)-0400From: トム Recipient <Tom_Recipient@example.org 、gt;、メッセージイド: <199509200022.12345@example.org>Subject: Re: インターネットのファックスの完全なモード映像電送To: ジェーン Sender <Jane_Sender@example.com 、gt;、MIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは気質通知と等しいです。 境界="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.
メッセージが9月20日に00:21:00(東部夏時間の)-0400でトム Recipient <Tom_Recipient@example.org に1995を転送した、gt;、対象で、インターネットFAX Full Modeで「インターネットのファックスの完全なモード映像電送」を処理してあります。
--RAA14128.773615769/example.org
Content-Type: message/disposition-notification
--RAA14128.773615769/example.orgコンテントタイプ: 気質メッセージ/通知
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: トムズ-pc.cs.example.org。 IFAX-FullModeのオリジナルの受取人: rfc822;Tom-Recipient@example.org 最終受理者: rfc822;Tom-Recipient@example.org の元のMessage ID: <199509200021.12345@example.com>気質: MDNは自動的に自動動作/発信していました。 処理されて、メディアは特徴を受け入れます: タイプ..イメージ..いさかい..着色..2進..イメージ..ファイル構造..いさかい..最小量..dpi..dpi..画像符号化..等しい..モード..紙サイズ..メディア..等しい..文房具..タイプ..アプリケーション..着色..2進..dpi..dpi..等しい..紙サイズ..メディア..等しい..文房具
--RAA14128.773615769/example.org--
--RAA14128.773615769/example.org--
Klyne, et. al. Standards Track [Page 35] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[35ページ]RFC3297の満足している交渉
9. IANA Considerations
9. IANA問題
9.1 New message headers
9.1 新しいメッセージヘッダー
This specification defines new email/MIME message headers:
この仕様は新しいメール/MIMEメッセージヘッダーを定義します:
Content-alternative
Original-Message-ID
内容代替の元のMessage ID
As such, there being no registry of email headers, it is an update to the specifications of RFC 2822 and RFC 2045.
そういうものとして、メールヘッダーには登録が全くなくて、それはRFC2822とRFC2045の仕様へのアップデートです。
9.2 MDN extensions
9.2 MDN拡張子
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.
この仕様はMessage Disposition Notification(MDN)プロトコルと拡大を定義します。 下のセクションは必要に応じてこれらの拡大のためのRFC2298[4]、セクション10のそばの登録テンプレートです。
9.2.1 Notification option 'Alternative-available'
9.2.1 通知オプション'利用可能な代替手段'
(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)キャラクターコード化: 米国-ASCII文字だけが使用されています。
(d) Semantics:
(see this document, section 6.1)
(d)意味論: (このドキュメント、セクション6.1を見ます)
9.2.2 Notification option 'Alternative-not-available'
9.2.2 通知オプション'利用可能でない代替手段'
(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)キャラクターコード化: 米国-ASCII文字だけが使用されています。
(d) Semantics
(see this document, section 6.3)
(d) 意味論(このドキュメント、セクション6.3を見ます)
Klyne, et. al. Standards Track [Page 36] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[36ページ]RFC3297の満足している交渉
9.2.3 Disposition modifier 'Alternative-preferred'
9.2.3 修飾語が'代替手段で好んだ'気質
(a) Disposition-modifier name:
Alternative-preferred
(a) 気質修飾語は以下を命名します。 代替手段..都合のよい
(b) Semantics:
(see this document, section 6.2)
(b)意味論: (このドキュメント、セクション6.2を見ます)
9.2.4 Disposition modifier 'Original-lost'
9.2.4 気質修飾語は'オリジナルで損をしました'。
(a) Disposition-modifier name:
Original-lost
(a) 気質修飾語は以下を命名します。 オリジナルに無くなります。
(b) Semantics:
(see this document, section 6.4)
(b)意味論: (このドキュメント、セクション6.4を見ます)
10. Internationalization considerations
10. 国際化問題
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.
この処理の主な候補は代替の情報を要求する気質通知応答に伴うテキストです。 通常の使用で、プロトコルデザインは、受取人が自動的にこの応答を処理できるのを確実にします。 例外的に、受信エージェントはユーザにそれを表示するかもしれません。
11. Security Considerations
11. セキュリティ問題
Security considerations of this specification can be divided into two main areas:
この仕様のセキュリティ問題を2つの主な領域に分割できます:
o Privacy concerns with automated MDN response generation: see
section 6.5 of this document, and the security considerations
section of RFC 2298 [4].
o 自動化されたMDN応答世代があるプライバシーの問題: このドキュメントのセクション6.5、およびRFC2298[4]のセキュリティ問題部を見てください。
o Risks of negotiation: see the security considerations section
transaction. If alternative data arrives subsequently, it may be
ignored or possibly also displayed or printed. A successful
completion MDN may be sent to the sender.
o 交渉のリスク: セキュリティ問題セクション取引を見てください。 代替のデータが次に到着するなら、ことによるとそれを無視するか、また、表示するか、または印刷するかもしれません。 無事終了MDNを送付者に送るかもしれません。
Klyne, et. al. Standards Track [Page 37] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[37ページ]RFC3297の満足している交渉
12. Acknowledgements
12. 承認
The basic structure of the negotiation described here was first documented in a draft by Mr. Toru Maeda of Canon.
ここで説明された交渉の基本構造は最初に、草稿でキヤノンのToruマエダさんによって記録されました。
Helpful comments on earlier drafts were provided by Mr Hiroshi Tamura, Ted Hardie and Larry Masinter.
以前の草稿の役に立つコメントはHiroshi田村さん、テッド・ハーディー、およびラリーMasinterによって提供されました。
13. References
13. 参照
[1] Masinter, L. and D. Wing, "Extended Facsimile using Internet
Mail", RFC 2532, March 1999.
[1] Masinter、L.、およびD.は1999年3月に「拡張ファクシミリはインターネットメールを使用すること」でのRFC2532に翼をつけさせます。
[2] Wing, D., "Indicating Supported Media Features Using Extensions
to DSN and MDN", RFC 2530, March 1999.
[2] 翼、D.、「表示はDSNとMDNに拡張子を使用することでメディア機能を支持した」RFC2530、1999年3月。
[3] Masinter, L., "Terminology and Goals for Internet Fax", RFC
2542, March 1999.
[3] より多くのMasinterに、L.と、「インターネットファックスの用語と目標」(RFC2542)は1999を行進させます。
[4] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998.
[4]Fajman、R.、「メッセージ気質通知のための広げることができるメッセージ・フォーマット」、RFC2298、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.ハーディー、「メディアはタグ登録手順を特徴とする」RFC2506、1999年3月。
[6] Klyne, G., "A syntax for describing media feature sets", BCP
31, RFC 2533, March 1999.
[6]Klyne、G.、「特徴が設定するメディアを説明するための構文」、BCP31、RFC2533、1999年3月。
[7] Klyne, G., "Indicating media features for MIME content", RFC
2938, September 2000.
[7]Klyne、G.、「MIME内容のためのメディア機能を示します」、RFC2938、2000年9月。
[8] 'Content-alternative' header (this memo, section 4)
[8] '内容代替'のヘッダー(このメモ、セクション4)
[9] MDN extension for alternative data (this memo, section 6)
[9] 代替のデータのためのMDN拡張子(このメモ、セクション6)
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[10] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[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.、ヴェナブル、D.、Zilles(S.、パーソンズ、G.、およびJ.Rafferty)は「インターネットファックスのために形式をファイルします」、RFC2301、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.は飛んで行きます、「ファクシミリの簡単なモードはインターネットメールを使用し」て、RFC2305、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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
Klyne, et. al. Standards Track [Page 38] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[38ページ]RFC3297の満足している交渉
[14] Holtman, K. and A. Mutz, "Transparent Content Negotiation in
HTTP", RFC 2295, March 1998.
[14]HoltmanとK.とA.Mutz、「HTTPにおけるわかりやすい満足している交渉」、RFC2295、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部:」 「メディアタイプ」、RFC2046、1996年11月。
[16] Klyne, G. and L. McIntyre, "Content feature schema for Internet
fax V2", RFC 2879, August 2000.
[16]KlyneとG.とL.マッキンタイヤ、「インターネットファックスV2"、RFC2879、2000年8月のための満足している特徴図式。」
[17] Klyne, G., "Protocol-independent Content Negotiation
Framework", RFC 2703, September 1999.
[17]Klyne、G.、「プロトコルから独立している満足している交渉枠組み」、RFC2703、1999年9月。
[18] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC 1891, January 1996.
[18] ムーア、K.、「配送状態通知のためのSMTPサービス拡張子」、RFC1891、1996年1月。
[19] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[19]Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[20] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[20] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[23] 'Original-Message-ID' header for mail messages (this memo,
section 5)
[23] メール・メッセージのための'元のMessage ID'ヘッダー(このメモ、セクション5)
[24] Klyne, G., "MIME Content Types in Media Feature Expressions",
RFC 2913, September 2000.
[24]Klyne、G.、「メディアのMIMEの満足しているタイプは表現を特徴とする」RFC2913、2000年9月。
Klyne, et. al. Standards Track [Page 39] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[39ページ]RFC3297の満足している交渉
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.
このセクションはこの仕様の標準の部分ではありません。 むしろ、それはデザインの間に私たちが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.
郵便ユーザエージェントと比べたこの提案のimplementersのためのたぶん最も大きい含意は内容が交渉されている間に受信機である種の州の情報を保守する必要性です。
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 代替の形式要求が送られた時。
Klyne, et. al. Standards Track [Page 40] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[40ページ]RFC3297の満足している交渉
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).
セクション3.2.1を見てください、3.2。ホームページの別版が利用可能のメッセージの受信機に新しい交渉州の情報を保持できるくらいの記憶力がないなら、それで譲渡禁止のふるまいへ後ろへ下がって、データが受信されていると受け入れて、MDNがそのデータの気質を示すかもしれない、(.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.)
このために部分的なメッセージデータをバッファリングするべきではありません: オリジナルのメッセージの一部を表示するのは、受信データのすべてを表示する許容できる代用品ではありません。 (診断目的でいくつかのオリジナルのメッセージデータを保つのにおいて何らかの値があるかもしれません。)
Klyne, et. al. Standards Track [Page 41] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[41ページ]RFC3297の満足している交渉
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).
送付者が、メッセージ内容の代替の形式を提供できるのを示すとき、それは要求されるなら代替手段が利用可能であることを保証しようとすることへの何らかの責任を引き受けます。 したがって、メッセージ内容(オリジナルとどんな選択肢の両方も)は相当期間の間、格納されるべきです、どんな対応するMessage-ID値と共にも。
A request for retransmission must be accompanied by an Original- Message-ID value that the sender can use to correlate with the message data originally sent.
送付者が元々送られたメッセージデータと互いに関連するのに使用できるOriginal Message 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.
交渉の間に宣言された受信機能力が無期限に利用可能であると思うべきではありません。
Klyne, et. al. Standards Track [Page 42] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[42ページ]RFC3297の満足している交渉
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.
この交渉枠組みは、はかない能力で念頭に設計されていませんが、それらに対処するのにおいて慎重に融通がきくかもしれません。
Klyne, et. al. Standards Track [Page 43] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[43ページ]RFC3297の満足している交渉
A.8 Situations where MDNs must not be auto-generated
MDNsが自動発生しているはずがない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.
プライバシーの問題を覚えておいて、implementersはシステムが自動的に最初に明白な許可を得ていなくて受取人の居場所を明らかにするかもしれない方法で交渉交換に入らないのに慎重であるはずです。 例えば、受信するなら、メッセージは何らかの方法でユーザの現実の所在によって、自動交渉を実行するべきではありません。
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.
この付録は考えられましたが、現在の仕様に含まれていなかった満足している交渉のいくつかの可能な特徴をリストアップします。 (b) 多くの場合、除外の理由は(a) 思いがけない追加複雑さを導入するかもしれないということでした、そして、どんな無視できない要件も認識されませんでした。
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 交渉応答は異なった能力で異なった受信機終点を示すかもしれません。
Klyne, et. al. Standards Track [Page 44] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[44ページ]RFC3297の満足している交渉
Authors' Addresses
作者のアドレス
Graham Klyne (editor) Clearswift Corporation, 1310 Waterside, Arlington Business Park Theale Reading, RG7 4SA United Kingdom
グラハムKlyne(エディタ)Clearswift社、1310年の水辺、アーリントンのビジネスパークTheale読書、RG7 4SAイギリス
Phone: +44 11 8903 8903 Fax: +44 11 8903 9000 EMail: GK@ACM.ORG
以下に電話をしてください。 +44 11 8903 8903、Fax: +44 11 8903 9000はメールされます: GK@ACM.ORG
Ryuji Iwazaki TOSHIBA TEC CORPORATION 2-4-1, Shibakoen, Minato-ku, Tokyo, 105-8524 Japan
龍治Iwazaki東芝株式会社テック2-4-1、Shibakoen、港区、日本東京105-8524
Phone: +81 3 3438 6866 Fax: +81 3 5402 6355 EMail: iwa@rdl.toshibatec.co.jp
以下に電話をしてください。 +81 3 3438 6866、Fax: +81 3 5402 6355はメールされます: iwa@rdl.toshibatec.co.jp
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA
デーヴ医者ブランデンブルクインターネットワーキング675はサニーベルカリフォルニア94086博士(米国)を小綺麗にします。
Phone: +1 408 246 8253 Fax: +1 408 249 6205 EMail: dcrocker@brandenburg.com
以下に電話をしてください。 +1 408 246、8253Fax: +1 6205年の408 249メール: dcrocker@brandenburg.com
Klyne, et. al. Standards Track [Page 45] RFC 3297 Content Negotiation for Messaging Services July 2002
et Klyne、アル。 サービス2002年7月に通信するための標準化過程[45ページ]RFC3297の満足している交渉
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or 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機能のための基金は現在、インターネット協会によって提供されます。
Klyne, et. al. Standards Track [Page 46]
et Klyne、アル。 標準化過程[46ページ]
一覧
スポンサーリンク
