[要約] RFC 2532は、インターネットメールを使用した拡張ファクシミリに関する規格です。その目的は、電子メールを介してファクシミリを送受信するための標準化と手順の提供です。
Network Working Group L. Masinter
Request for Comments: 2532 Xerox Corporation
Category: Standards Track D. Wing
Cisco Systems
March 1999
Extended Facsimile Using Internet Mail
インターネットメールを使用してファクシミリを拡張します
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。全著作権所有。
Abstract
概要
This document describes extensions to "Simple Mode of Facsimile Using Internet Mail" [RFC2305] and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing.
このドキュメントでは、「インターネットメールを使用したファクシミリの単純なモード」[RFC2305]への拡張機能について説明し、強化されたドキュメント特性（高解像度、色）の送信や配信と処理の確認など、追加機能について説明します。
These additional features are designed to provide the highest level of interoperability with the existing and future standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates the level currently enjoyed by fax users.
これらの追加機能は、既存および将来の標準に準拠した電子メールインフラストラクチャとメールユーザーエージェントと最高レベルの相互運用性を提供するように設計されており、FAXユーザーが現在享受しているレベルに近似するレベルのサービスを提供します。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights in <http://www.ietf.org/ipr.html>.
IETFは、このドキュメントに含まれる仕様の一部またはすべてに関して請求された知的財産権について通知されています。詳細については、<http://www.ietf.org/ipr.html>の請求権のオンラインリストをご覧ください。
This document notes a number of enhancements to the "Simple Mode of Facsimile Using Internet Mail" [RFC2305] that may be combined to create an extended mode of facsimile using Internet mail.
このドキュメントは、「インターネットメールを使用したファクシミリの単純なモード」[RFC2305]を組み合わせて、インターネットメールを使用してファクシミリの拡張モードを作成することができる多くの強化を指摘しています。
The new features are designed to be interoperable with the existing base of mail transfer agents (MTAs) and mail user agents (MUAs), and take advantage of existing standards for advanced functionality such as positive delivery confirmation and disposition notification. The
新機能は、既存のメール転送エージェント（MTA）およびメールユーザーエージェント（MUA）と相互運用可能になり、肯定的な配信確認や処分通知などの高度な機能の既存の標準を活用するように設計されています。
enhancements described in this document utilize the messaging infrastructure, where possible, instead of creating fax-specific features which are unlikely to be implemented in non-fax messaging software.
このドキュメントで説明されている拡張機能は、可能であれば、非ファックスメッセージングソフトウェアで実装される可能性が低いファックス固有の機能を作成する代わりに、メッセージングインフラストラクチャを利用します。
This document standardizes the following two features.
このドキュメントは、次の2つの機能を標準化しています。
* Delivery confirmation (Section 2) (required) * Additional document features (Section 3) (optional)
* 配達確認（セクション2）（必須） *追加のドキュメント機能（セクション3）（オプション）
These features are fully described in another document titled "Terminology and Goals for Internet Fax" [RFC2542].
これらの機能は、「インターネットファックスの用語と目標」[RFC2542]というタイトルの別のドキュメントで完全に説明されています。
The term "processing" indicates the action of rendering or transmitting the contents of the message to a printer, display device, or fax machine.
「処理」という用語は、メッセージの内容をプリンター、ディスプレイデバイス、またはファックスマシンにレンダリングまたは送信するアクションを示します。
The term "processing confirmation" is an indication by the recipient of a message that it is able to process the contents of that message.
「処理確認」という用語は、そのメッセージの内容を処理できるというメッセージの受信者による兆候です。
The term "recipient" indicates the device which performs the processing function. For example, a recipient could be implemented as a traditional Mail User Agent on a PC, a standalone device which retrieves mail using POP3 or IMAP, an SMTP server which prints incoming messages (similar to an LPR server).
「受信者」という用語は、処理機能を実行するデバイスを示します。たとえば、受信者は、PC上の従来のメールユーザーエージェントとして実装できます。PC3またはIMAPを使用してメールを取得するスタンドアロンデバイス（入ってくるメッセージを印刷するSMTPサーバー（LPRサーバーと同様）があります。
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 [RFC2119].
キーワード「必須」、「必要」、「必須」、「「必要」」、「そうしない」、「そうではない」、「そうすべきではない」、「推奨」、「5月」、および「オプション」は、[RFC2119]で説明されているように解釈されます。
The behavior of gateways from GSTN fax to SMTP ("onramps") and from SMTP to GSTN fax ("offramps") are not described in this document. However, such gateways SHOULD have the behavior characteristics of senders and recipients as described in this document.
GSTN FAXからSMTP（ "Onramps"）およびSMTPからGSTN Fax（ "Offramps"）へのゲートウェイの動作は、このドキュメントでは説明されていません。ただし、このようなゲートウェイには、このドキュメントで説明されているように、送信者と受信者の動作特性が必要です。
In traditional GSTN-based realtime facsimile, the receiving terminal acknowledges successful receipt and processing of every page [T.30].
従来のGSTNベースのリアルタイムファクシミリでは、受信端末はすべてのページの領収書と処理の成功を認めています[T.30]。
In Internet Mail, the operations of Delivery (to the mailbox) and Disposition (to paper or a screen) may be separated in time (due to store and forwarding of messages) and location (due to separation of delivery agent (MTA) and user agent (MUA)). The confirmation of
インターネットメールでは、配達の操作（メールボックスへの）および処分（紙または画面へ）は、時間内に（メッセージのストアと転送のため）（配信エージェント（MTA）とユーザーの分離により）分離される場合があります。エージェント（MUA））。の確認
these two operations are supplied by two different standards-track mechanisms: Delivery Status Notifications (DSN) [RFC1891, RFC1894] and Message Disposition Notifications (MDN) [RFC2298], respectively.
これらの2つの操作は、配信ステータス通知（DSN）[RFC1891、RFC1894]とメッセージ処分通知（MDN）[RFC2298]の2つの異なる標準トラックメカニズムによって提供されます。
This section defines requirements for devices or services that are to be considered compliant with this document.
このセクションでは、このドキュメントに準拠していると見なされるデバイスまたはサービスの要件を定義します。
Because delivery failure may occur (over disk quota, user no longer exists, malconfigured mailer), a delivery failure message (in the format described by [RFC1894] or otherwise) may be sent to the envelope-from address specified by the sender. Thus, the envelope-from address supplied by the sender MUST be able to properly handle such delivery failure messages.
配信の障害が発生する可能性があるため（ディスククォータを超えて、ユーザーは存在しなくなり、マルコンフィギングされたメーラー）、配信障害メッセージ（[RFC1894]で説明されている形式など）は、送信者が指定したエンベロープフロムアドレスに送信できます。したがって、送信者が提供するエンベロープからのアドレスから、そのような配信障害メッセージを適切に処理できる必要があります。
If the sender desires delivery confirmation, the sender MUST request Delivery Status Notification by including the the esmtp-keyword NOTIFY with the esmtp-value SUCCESS (section 5.1 of [RFC1891]).
送信者が配信の確認を希望する場合、送信者はESMTP値の成功（[RFC1891]のセクション5.1）にESMTP-KeyWord通知を含めることにより、配信ステータス通知を要求する必要があります。
If the sender desires processing confirmation, the sender MUST request Message Disposition Notification ([RFC2298] section 2) when sending the message itself.
送信者が確認の確認を希望する場合、送信者はメッセージ自体を送信する際にメッセージ処分通知（[RFC2298]セクション2）を要求する必要があります。
Because a recipient may silently ignore a request for an MDN (section 2.1 of [RFC2298]) at any time:
受信者は、いつでもMDN（[RFC2298]のセクション2.1）のリクエストを静かに無視する可能性があるため：
* MDNs MUST NOT be used for delivery confirmation, but are only useful for disposition ("processing") notification.
* MDNは配信確認に使用する必要はありませんが、処分（「処理」）通知にのみ役立ちます。
* the sender MUST NOT assume the recipient will respond to an MDN request in a subsequent message, even if the recipient has done so in the past.
* 送信者は、受信者が過去に行った場合でも、受信者が後続のメッセージでMDN要求に応答すると想定してはなりません。
The address provided by the sender on the Disposition-Notification-To field MUST be able to receive Message Disposition Notifications messages [RFC2298] and SHOULD be able to receive messages that are not in the Message Disposition Notification format (due to the existence of legacy systems that generate non-RFC2298-compliant responses to the Disposition-Notification-To field). The Disposition-Notification-To address and the envelope-from address SHOULD match to allow automated responses to MDN requests (section 2.1 of [RFC2298]).
気質 - notification-toフィールドで送信者が提供するアドレスは、メッセージ処分通知メッセージ[RFC2298]を受信できる必要があり、メッセージ処分通知形式にないメッセージを受信できる必要があります（レガシーシステムの存在のためにそれは、性質解除からフィールドへの非RFC2298に準拠した応答を生成します）。処分 - 解釈とアドレスとエンベロープからのアドレスは、MDN要求に対する自動化された応答を可能にするために一致する必要があります（[RFC2298]のセクション2.1）。
Recipients SHOULD implement Message Disposition Notifications [RFC2298] and SHOULD indicate supported media features in DSN and MDN messages per [RFC2530].
受信者はメッセージ処分通知[RFC2298]を実装し、[RFC2530]ごとにDSNおよびMDNメッセージのサポートされているメディア機能を示す必要があります。
If the recipient is an SMTP server, it behaves as part of the receiver infrastructure and is therefore subject to the "Receiver Infrastructure" requirements of this document.
受信者がSMTPサーバーである場合、受信者インフラストラクチャの一部として動作するため、このドキュメントの「受信インフラストラクチャ」要件の対象となります。
See also "Recipient Recommendations" in section 5.
セクション5の「受信者の推奨」も参照してください。
Recipients MUST be configurable to silently ignore a request for an MDN (section 2.1 of [RFC2298]).
受信者は、MDNのリクエストを静かに無視するために構成可能でなければなりません（[RFC2298]のセクション2.1）。
If the recipient is an automated message processing system which is not associated with a person, the device MAY be configurable to always respond to MDN requests, but in all cases MUST be configurable to never generate MDNs.
受信者が個人に関連付けられていない自動化されたメッセージ処理システムである場合、デバイスは常にMDN要求に応答するように構成可能である可能性がありますが、すべての場合、MDNを生成しないように設定可能でなければなりません。
A recipient MUST NOT generate an unsolicited MDN to indicate successful processing. A recipient MAY generate an unsolicited MDN (sent to the envelope-from (Return-Path:) address) to indicate processing failure, but subject to the [RFC2298] requirement that it MUST always be possible for an operator to disable unsolicited MDN generation.
受信者は、成功した処理を示すために未承諾MDNを生成してはなりません。受信者は、処理の障害を示すために未承諾MDN（エンベロープから送信される（return-path :)アドレス）を生成することができますが、[RFC2298]要件に従い、オペレーターが未承諾のMDN世代を無効にする必要がある必要があります。
A recipient using POP3 [RFC1939] or IMAP4 [RFC2060] to retrieve its mail MUST NOT generate a Delivery Status Notification message [RFC1894] because such a notification, if it was requested, would have already been issued by the MTA on delivery to the POP3 or IMAP4 message store.
POP3 [RFC1939]またはIMAP4 [RFC2060]を使用して、そのような通知が要求されていれば、POP3への配信に関するMTAによってすでに発行されていたため、配信ステータス通知メッセージ[RFC1894]を生成してはなりません。またはIMAP4メッセージストア。
The recipient MUST NOT use the RFC822 "To:" fields, "Cc:" fields, "Bcc:" fields, or any other fields containing header recipient information to determine the ultimate destination mailbox or addressee, and SHOULD NOT use other RFC822 or MIME fields for making such determinations.
受信者は、rfc822 "に：" fields、 "cc：" fields、 "bcc：" fields、またはヘッダー受信者情報を含むその他のフィールドを使用して、究極の宛先メールボックスまたはアドレスを決定しないでください。そのような決定を行うためのフィールド。
This section explains the requirements of the SMTP messaging infrastructure used by the sender and receiver. This infrastructure is commonly provided by the ISP or a company's internal mailers but can actually be provided by another organization with appropriate service contracts.
このセクションでは、送信者と受信機が使用するSMTPメッセージングインフラストラクチャの要件について説明します。このインフラストラクチャは、一般にISPまたは会社の内部メーラーによって提供されますが、実際には別の組織から適切なサービス契約を提供できます。
Support for DSN [RFC1891] MUST be provided by the mail submission server [RFC2476] used by the sender and MUST be provided up to the mailer responsible for communicating with external (Internet) mailers.
DSN [RFC1891]のサポートは、送信者が使用するMail Submission Server [RFC2476]によって提供され、外部（インターネット）メーラーとの通信を担当するメーラーに提供する必要があります。
Also see section 5.1 of this document.
このドキュメントのセクション5.1も参照してください。
Support for DSN [RFC1891] MUST be provided by the external (Internet-accessible) mailer, and MUST be provided by each mailer between the external mailer and the recipient. If the recipient is implemented as an SMTP server it MUST also support DSN [RFC1891].
DSN [RFC1891]のサポートは、外部（インターネットアクセス可能な）メーラーによって提供され、外部メーラーと受信者の間の各メーラーが提供する必要があります。受信者がSMTPサーバーとして実装されている場合、DSN [RFC1891]もサポートする必要があります。
Section 4 of "A Simple Mode of Facsimile Using Internet Mail" [RFC2305] allows sending only the minimum subset of TIFF for Facsimile "unless the sender has prior knowledge of other TIFF fields or values supported by the recipient."
「インターネットメールを使用したファクシミリの単純なモード」[RFC2305]のセクション4では、「送信者が受信者がサポートする他のTIFFフィールドまたは値の事前知識がない限り」FACSIMILEのTIFFの最小サブセットのみを送信できます。
A recipient MAY support any or all (or any combination) of the TIFF profiles defined in RFC 2301, in addition to profile S. A recipient which supports additional profiles SHOULD indicate this support as per section 3.2 or 3.3 of this document. As a consequence, a sender MAY use those additional TIFF profiles when sending to a recipient with the corresponding capabilities.
受信者は、RFC 2301で定義されたTIFFプロファイルのいずれかまたはすべて（または任意の組み合わせ）をサポートできます。プロファイルSに加えて、追加のプロファイルをサポートする受信者は、このドキュメントのセクション3.2または3.3に従ってこのサポートを示す必要があります。結果として、送信者は、対応する機能を備えた受信者に送信する際に、これらの追加のTIFFプロファイルを使用する場合があります。
A sender SHOULD be able to recognize and process the feature tags as defined in [RFC2531] when reviewing the capabilities presented by a potential recipient. The capability matching rules indicated there (by reference to [RFC2533]) allow for the introduction of new features that may be unrecognized by older implementations.
送信者は、潜在的な受信者が提示する機能を確認する際に、[RFC2531]で定義されている機能タグを認識して処理できる必要があります。（[RFC2533]を参照）そこに示された機能の一致する機能により、古い実装によって認識されない新しい機能の導入が可能になります。
A sender MAY send a message containing both the minimum subset of TIFF for Facsimile (as specified in [RFC2305]) and a higher quality TIFF using multipart/alternative.
送信者は、ファクシミリ用のTIFFの最小サブセット（[RFC2305]で指定）と、MultiPart/Alternativeを使用した高品質のTIFFの両方を含むメッセージを送信できます。
Three methods for the sender to acquire such knowledge are described:
送信者がそのような知識を獲得するための3つの方法について説明します。
1. Sender manual configuration 2. Capabilities in Directory 3. Capabilities returned in MDN or DSN
1. 送信者マニュアル構成2.ディレクトリの機能3. MDNまたはDSNで返される機能
Method (3) SHOULD be used.
方法（3）を使用する必要があります。
An implementation may cache capabilities locally and lose synchronization with the recipient's actual capabilities. A mechanism SHOULD be provided to allow the sender to override the locally-stored cache of capabilities. Also note section 4.1 of this document.
実装は、局所的に機能をキャッシュし、受信者の実際の機能と同期を失う可能性があります。送信者がローカルに保存された機能のキャッシュをオーバーライドできるようにするためのメカニズムを提供する必要があります。また、このドキュメントのセクション4.1に注意してください。
One way a sender can send a document which exceeds the minimum subset allowed by [RFC2305] is for the user controlling the sender to manually override the default settings, usually on a per-recipient basis. For example, during transmission a user could indicate the recipient is capable of receiving high resolution images or color images.
送信者が[RFC2305]で許可されている最小サブセットを超えるドキュメントを送信できる1つの方法は、ユーザーが送信者を制御して、通常はレシピエントごとにデフォルト設定を手動でオーバーライドすることです。たとえば、送信中、ユーザーは受信者が高解像度の画像またはカラー画像を受信できることを示すことができます。
While awkward and not automatic, this mechanism reflects the current state of deployment of configuration for extended capabilities to ordinary Internet email users.
厄介で自動ではありませんが、このメカニズムは、通常のインターネットメールユーザーへの拡張機能の構成の現在の展開の状態を反映しています。
A future direction for enhanced document features is to create a directory structure of recipient capabilities, deployed, for example, through LDAP or DNS. The directory would provide a mechanism by which a sender could determine a recipient's capabilities before message construction or transmission, using a directory lookup. Such mechanisms are not defined in this document.
ドキュメント機能の強化の将来の方向性は、たとえばLDAPやDNSを介して展開された受信者機能のディレクトリ構造を作成することです。ディレクトリは、ディレクトリルックアップを使用して、メッセージの構築または送信の前に、送信者が受信者の機能を決定できるメカニズムを提供します。このようなメカニズムは、このドキュメントでは定義されていません。
There is active investigation within the IETF to develop a solution to this problem, which would resolve a wide range of issues with store-and-forward messaging.
IETF内では、この問題の解決策を開発するための積極的な調査があります。これにより、ストアアンドフォワードメッセージングに関する幅広い問題が解決されます。
As outlined in section 2 of this document, a sender may request a positive DSN or an MDN.
このドキュメントのセクション2で概説されているように、送信者は肯定的なDSNまたはMDNを要求することができます。
If the recipient implements [RFC2530], the DSN or MDN that is returned can contain information describing the recipient's capabilities. The sender can use this information for subsequent communications with that recipient.
受信者が[RFC2530]を実装する場合、返されるDSNまたはMDNには、受信者の機能を説明する情報を含めることができます。送信者は、この情報を使用して、その受信者との後続の通信に使用できます。
The advantage of this approach is that additional infrastructure is not required (unlike section 3.2), and the information is acquired automatically (unlike section 3.1).
このアプローチの利点は、追加のインフラストラクチャが必要ないことです（セクション3.2とは異なり）、情報は自動的に取得されます（セクション3.1とは異なり）。
A sender MUST NOT send a message with no processable content to attempt to elicit an MDN/DSN capability response. Doing so with a message with no processable content (such as a message containing only a request for capabilities or a blank message) will confuse a recipient not already designed to understand the semantics of such a message.
送信者は、MDN/DSN機能応答を引き出すことを試みるために、加工可能なコンテンツのないメッセージを送信してはなりません。加工可能なコンテンツのないメッセージ（機能のリクエストのみを含むメッセージや空白のメッセージなど）でこれを行うと、そのようなメッセージのセマンティクスを理解するようにまだ設計されていない受信者を混乱させます。
A recipient SHOULD indicate the profiles and features supported, even if the recipient supports only Tiff Profile S (the minimum set for fax as defined by [RFC2305]) [RFC2531]. This allows a sender to determine that the recipient is compliant with this Extended Facsimile Using Internet Mail specification.
受信者は、受信者がTIFFプロファイルのみをサポートしている場合でも、サポートされているプロファイルと機能を示している必要があります（[RFC2305]で定義されているFAXの最小セット）[RFC2531]。これにより、送信者は、インターネットメールの仕様を使用して、受信者がこの拡張ファクシミリに準拠していることを判断できます。
As this document is an extension of [RFC2305], the Security Considerations section of [RFC2305] applies to this document.
このドキュメントは[RFC2305]の拡張であるため、[RFC2305]のセキュリティに関する考慮事項セクションがこのドキュメントに適用されます。
The following additional security considerations are introduced by the new features described in this document.
次の追加のセキュリティ上の考慮事項は、このドキュメントで説明されている新機能によって紹介されます。
Inaccurate capability information (section 3) could cause a denial of service. The capability information could be inaccurate due to many reasons, including compromised or improperly configured directory server, improper manual configuration of sender, compromised DNS, or spoofed MDN. If a sender is using cached capability information, there SHOULD be a mechanism to allow the cached information to be ignored or overridden if necessary.
不正確な機能情報（セクション3）は、サービスの拒否を引き起こす可能性があります。侵害または不適切に構成されたディレクトリサーバー、送信者の不適切な手動構成、DNSの侵害、またはスプーフィングされたMDNなど、多くの理由により、機能情報が不正確になる可能性があります。送信者がキャッシュされた機能情報を使用している場合、必要に応じてキャッシュされた情報を無視またはオーバーライドするメカニズムがあるはずです。
Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298] can provide incorrect information to a sender.
[RFC1892、RFC1894、RFC2298]で説明されているように、偽造DSNSまたはMDNSは、送信者に誤った情報を提供できます。
This section contains notes to implementors.
このセクションには、実装者へのメモが含まれています。
In some installations the generally available submit server may not support DSNs. In such circumstances, it may be useful for the sender to implement [RFC974] mail routing as well as additional submission server functions [RFC2476] so that the installation is not constrained by limitations of the incumbent submission server.
一部のインストールでは、一般に利用可能な送信サーバーはDSNSをサポートしていない場合があります。このような状況では、送信者が[RFC974]メールルーティングと追加の提出サーバー関数[RFC2476]を実装することが役立つ場合があり、インストールが現職の提出サーバーの制限によって制約されないようにします。
To provide a high degree of reliability, it is desirable for the sender to know that a recipient could not process a message. The inability to successfully process a message may be detectable by the recipient's MTA or MUA.
高度な信頼性を提供するには、送信者が受信者がメッセージを処理できないことを知ることが望ましいです。メッセージを正常に処理できないことは、受信者のMTAまたはMUAによって検出可能です。
If the recipient's MTA determines the message cannot be processed, the recipient's MTA is strongly encouraged to reject the message with a [RFC1893] status code of 5.6.1. This status code may be returned in response to the end-of-mail-data indicator if the MTA supports reporting of enhanced error codes [RFC2034], or after message reception by generating a delivery failure DSN ("bounce").
受信者のMTAがメッセージを処理できないと判断した場合、受信者のMTAは、[RFC1893]ステータスコード5.6.1でメッセージを拒否することを強くお勧めします。このステータスコードは、MTAが拡張エラーコード[RFC2034]のレポートをサポートしている場合、または配信障害DSN（「バウンス」）を生成してメッセージ受信後に、MTAが拡張エラーコードのレポートをサポートしている場合に応答して返される場合があります。
Note: Providing this functionality in the MTA, via either of the two mechanisms described above, is superior to providing the function using MDNs because MDNs must generally be requested by the sender (and the request may, at any time, be ignored by the receiver). Message rejection performed by the MTA can always occur without the sender requesting such behavior and without the receiver circumventing the behavior.
注：上記の2つのメカニズムのいずれかを介してMTAでこの機能を提供することは、MDNが一般に送信者が要求する必要があるため、MDNを使用して機能を提供するよりも優れています（およびリクエストはいつでも受信者によって無視される場合があります）。MTAによって実行されるメッセージの拒否は、送信者がそのような動作を要求することなく、および受信機が動作を回避することなく常に発生する可能性があります。
If the message contains an MDN request and the recipient's MUA determines the message cannot be processed, the recipient's MUA is strongly encouraged to repond to an MDN request and indicate that processing failed with the disposition-type "processed" or "displayed" and disposition-modifier "error" or "warning" [RFC2298].
メッセージにMDN要求が含まれており、受信者のMUAがメッセージを処理できないと判断した場合、受信者のMUAはMDNリクエストに再送信することを強くお勧めし、処理が「処理された」または「表示」および処分で処理が失敗したことを示します。修飾子「エラー」または「警告」[RFC2298]。
The authors would like to acknowledge the members of the IETF Internet Fax working group, and especially the following contributors who provided assistance and input during the development of this document:
著者は、IETF Internet Faxワーキンググループのメンバー、特にこのドキュメントの開発中に支援と意見を提供した次の貢献者に感謝します。
Vivian Cancio, Richard Coles, David Crocker, Ned Freed, Graham Klyne, MAEDA Toru, Geoff Marshall, Lloyd McIntyre, Keith Moore, George Pajari, James Rafferty, Mike Ruhl, Richard Shockey, Brian Stafford, and Greg Vaudreuil.
ヴィヴィアン・カンシオ、リチャード・コールズ、デビッド・クロッカー、ネッド・フリード、グラハム・クライネ、メーダ・トル、ジェフ・マーシャル、ロイド・マッキンタイア、キース・ムーア、ジョージ・パジャリ、ジェームズ・ラファティ、マイク・ルール、リチャード・ショッキー、ブライアン・スタッフォード、グレッグ・ヴォードルイル。
[RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[RFC2533] Klyne、G。、「メディア機能セットを説明するための構文」、RFC 2533、1999年3月。
[RFC2531] McIntyre, L. and G. Klyne, "Content Feature Schema for Internet Fax", RFC 2531, March 1999.
[RFC2531] McIntyre、L。およびG. Klyne、「インターネットファックスのコンテンツ機能スキーマ」、RFC 2531、1999年3月。
[RFC2530] Wing, D., "Indicating Supported Media Features Using Extensions to DSN and MDN", RFC 2530, March 1999.
[RFC2530] Wing、D。、「DSNおよびMDNへの拡張機能を使用したサポートされているメディア機能を示す」、RFC 2530、1999年3月。
[RFC1891] Moore, K. "SMTP Service Extensions for Delivery Status Notifications", RFC 1891, January 1996.
[RFC1891]ムーア、K。「配信ステータス通知のSMTPサービス拡張」、RFC 1891、1996年1月。
[RFC1893] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[RFC1893] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 1893、1996年1月。
[RFC1894] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.
[RFC1894] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 1894、1996年1月。
[RFC2034] Freed, N, "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[RFC2034] Freed、N、「強化されたエラーコードを返すためのSMTPサービス拡張」、RFC 2034、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2298] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[RFC2298] Fajman、R。、「メッセージ処分通知のための拡張可能なメッセージ形式」、RFC 2298、1998年3月。
[RFC2301] McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G. and J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998.
[RFC2301] McIntyre、L.、Zilles、S.、Buckley、R.、Venable、D.、Parsons、G。and J. Rafferty、「Internet Faxのファイル形式」、RFC 2301、1998年3月。
[RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998.
[RFC2305] Toyoda、K.、Ohno、H.、Murai、J。、およびD. Wing、「インターネットメールを使用したファクシミリの単純なモード」、RFC 2305、1998年3月。
[RFC974] Partridge. C., "Mail routing and the domain system", STD 14, RFC 974, January 1986.
[RFC974]ヤマウズラ。C.、「メールルーティングとドメインシステム」、STD 14、RFC 974、1986年1月。
[RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[RFC2476] Gellens、R。およびJ. Klensin、「Message Submission」、RFC 2476、1998年12月。
[RFC2542] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999.
[RFC2542] Masinter、L。、「インターネットFAXの用語と目標」、RFC 2542、1999年3月。
[T.30] "Procedures for Document Facsimile Transmission in the General Switched Telephone Network", ITU-T (CCITT), Recommendation T.30, July, 1996.
[T.30]「一般的な切り替え電話ネットワークにおけるドキュメントファクシミリ送信の手順」、ITU-T（CCITT）、推奨T.30、1996年7月。
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC1939] Myers、J。およびM. Rose、「郵便局プロトコル - バージョン3」、STD 53、RFC 1939、1996年5月。
[RFC2060] Crispin, M., "Internet Message Access Protocol - Version 4Rev1", RFC 2060, December 1996.
[RFC2060] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン4REV1」、RFC 2060、1996年12月。
Larry Masinter Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304 USA
ラリー・マシンゼロックスパロアルト研究センター3333コヨーテヒルロードパロアルト、カリフォルニア州94304 USA
Fax: +1 650 812 4333
EMail: masinter@parc.xerox.com
Dan Wing Cisco Systems, Inc. 101 Cooper Street Santa Cruz, CA 95060 USA
Dan Wing Cisco Systems、Inc。101 Cooper Street Santa Cruz、CA 95060 USA
Phone: +1 831 457 5200
Fax: +1 831 457 5208
EMail: dwing@cisco.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明するか、その実装を支援する派生作品は、いかなる種類の制限なしに、準備、コピー、公開、配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準のプロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。