RFC2532 日本語訳

Network Working Group                                        L. Masinter
Request for Comments: 2532                             Xerox Corporation
Category: Standards Track                                        D. Wing
                                                           Cisco Systems
                                                              March 1999

Masinterがコメントのために要求するワーキンググループL.をネットワークでつないでください: 2532年のゼロックス社のカテゴリ: 1999年の標準化過程D.翼のシスコシステムズの行進

                 Extended Facsimile Using Internet Mail

インターネットメールを使用する拡張ファクシミリ

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 (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 All rights reserved。

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.

これらの付加的な機能は、存在、将来の規格対応することのメールインフラストラクチャ、およびメールユーザエージェントを相互運用性の最高水準に提供するように現在ファックスユーザによって楽しまれているレベルに近似するサービスのレベルを提供している間、設計されています。

   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>の要求された権利のオンラインリストに相談してください。

1.  Introduction

1. 序論

   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

新機能は、メール転送エージェント(MTAs)とメールユーザエージェント(MUAs)の存立基盤で共同利用できて、積極的な配送確認や気質通知などの高度な機能性の既存の規格を利用するように設計されています。 The

Masinter & Wing             Standards Track                     [Page 1]

RFC 2532                 Extended Internet Fax                March 1999

1999年のインターネットファックス行進のときに広げられたMasinterと翼の標準化過程[1ページ]RFC2532

   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]と題をつけられた別のドキュメントで完全に説明されます。

1.1.  Definition of Terms

1.1. 用語の定義

   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の上で受取人を実装することができました、POP3かIMAPを使用することでメールを検索するスタンドアロンデバイス、入力メッセージ(LPRサーバと同様の)を印刷するSMTPサーバー。

   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].

「キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、中の解釈されて、説明されるとして」 「5月」、「推薦され」て、このドキュメントで「任意」があるNOT[RFC2119]はそうするべきです。

1.2.  GSTN Fax Gateways ("onramp"/"offramp")

1.2. GSTNファックスゲートウェイ(「入口ランプ」/「出口ランプ」)

   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ファックスからSMTP(「入口ランプ」)までSMTPからGSTNファックス(「出口ランプ」)までの動きは本書では説明されません。 しかしながら、そのようなゲートウェイSHOULDには、送付者と受取人の振舞いの特性が本書では説明されるようにあります。

2.  Delivery and Processing Confirmation

2. 配送と処理確認

   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

インターネットメールでは、Delivery(メールボックスへの)とDisposition(紙かスクリーンへの)の操作は時間(メッセージの店と推進による)と位置(新聞販売店(MTA)とユーザエージェント(MUA)の分離による)で切り離されるかもしれません。 確認

Masinter & Wing             Standards Track                     [Page 2]

RFC 2532                 Extended Internet Fax                March 1999

1999年のインターネットファックス行進のときに広げられたMasinterと翼の標準化過程[2ページ]RFC2532

   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つの異なった標準化過程メカニズムはこれらの2つの操作を供給します: それぞれ配送Status Notifications(DSN)[RFC1891、RFC1894]とMessage Disposition Notifications(MDN)[RFC2298]

   This section defines requirements for devices or services that are to
   be considered compliant with this document.

このセクションはこのドキュメントで言いなりになると考えられることになっているデバイスかサービスのための要件を定義します。

2.1.  Sender Requirements

2.1. 送付者要件

   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]によって説明された形式の)に発信するかもしれない、封筒、-、アドレスは送付者で指定しました。 したがって、送付者によって供給されたアドレスからの封筒は適切にそのような配信障害メッセージを扱うことができなければなりません。

2.1.1.  Delivery Confirmation

2.1.1. 配送確認

   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-値のSUCCESS([RFC1891]のセクション5.1)とesmtp-キーワードNOTIFYを含んでいることによって、Delivery Status Notificationを要求しなければなりません。

2.1.2.  Processing Confirmation

2.1.2. 処理確認

   If the sender desires processing confirmation, the sender MUST
   request Message Disposition Notification ([RFC2298] section 2) when
   sending the message itself.

メッセージ自体を送るとき、送付者が処理確認を望んでいるなら、送付者はMessage Disposition Notification([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.

* MDNsは配送確認に使用されてはいけませんが、単に気質(「処理」)通知の役に立ちます。

      *  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]).

アドレスが送付者で提供した、Disposition通知、分野ができるに違いない、Message Disposition Notificationsメッセージ[RFC2298]とSHOULDを受け取るために、Message Disposition Notification形式にはないメッセージは受け取ることができてください、(それが生成するレガシーシステムの存在、非RFC2298対応する、応答、Disposition通知、分野) そして、Disposition通知、アドレス、封筒、-、アドレスSHOULDは、MDN要求([RFC2298]のセクション2.1)への自動化された応答を許容するために合っています。

Masinter & Wing             Standards Track                     [Page 3]

RFC 2532                 Extended Internet Fax                March 1999

1999年のインターネットファックス行進のときに広げられたMasinterと翼の標準化過程[3ページ]RFC2532

2.2.   Recipient Requirements

2.2. 受取人要件

   Recipients SHOULD implement Message Disposition Notifications
   [RFC2298] and SHOULD indicate supported media features in DSN and MDN
   messages per [RFC2530].

SHOULD道具Message Disposition Notifications[RFC2298]とSHOULDが示す受取人は、メディアがDSNの特徴と[RFC2530]あたり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の「受取人推薦」を見てください。

2.2.1.  MDN Recipient Requirements

2.2.1. MDN受取人要件

   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要求に応じるのにおいて構成可能であるかもしれませんが、すべての場合では決してMDNsを生成するのにおいて構成可能でないに違いありません。

   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を生成するかもしれない、(発信する、封筒、-、(リターン経路:、)、アドレス) 失敗を処理しながら示しますが、オペレータが求められていないMDN世代を無効にするようにそれがいつも可能であるに違いないという[RFC2298]要件にかけるために。

2.2.2.  Recipients Using Mailbox Access Protocols

2.2.2. メールボックスアクセス・プロトコルを使用している受取人

   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.

それが要求されたなら、そのような通知は配送のときにMTAによって既にPOP3かIMAP4メッセージ店に発行されたでしょう、したがって、メールを検索するのに、POP3[RFC1939]かIMAP4[RFC2060]を使用している受取人がDelivery Status Notificationがメッセージ[RFC1894]であると生成してはいけません。

   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「To:」を使用してはいけません。 分野、「Cc:」 分野、「Bcc:」 分野、または最終仕向地メールボックスか受け取り人を決定するヘッダー受取人情報、および他のRFC822かMIMEがそのような決断をするようにさばくSHOULD NOT使用を含むいかなる他の分野。

Masinter & Wing             Standards Track                     [Page 4]

RFC 2532                 Extended Internet Fax                March 1999

1999年のインターネットファックス行進のときに広げられたMasinterと翼の標準化過程[4ページ]RFC2532

2.3.  Messaging Infrastructure Requirements

2.3. メッセージングインフラストラクチャ要件

   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か会社の内部の郵送者によって一般的に提供されますが、別の組織は実際に適切な役務契約に提供できます。

2.3.1.  Sender Infrastructure

2.3.1. 送付者インフラストラクチャ

   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]のサポートを送付者によって使用されたメール服従サーバ[RFC2476]で提供しなければならなくて、外部の(インターネット)郵送者とコミュニケートするのに責任がある郵送者まで提供しなければなりません。

   Also see section 5.1 of this document.

また、このドキュメントのセクション5.1を見てください。

2.3.2.  Receiver Infrastructure

2.3.2. 受信機インフラストラクチャ

   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]をサポートしなければなりません。

3.  Additional Document Capabilities

3. 追加ドキュメント能力

   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."

「送付者は受取人に他のTIFF分野か値に関する先の知識をサポートさせない」場合、「インターネットメールを使用するファクシミリの簡単なモード」[RFC2305]のセクション4は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.

受取人がいずれもサポートするかもしれませんか、またはTIFFプロフィールのすべて(または、どんな組み合わせ)が、RFC2301プロフィールS.A受取人に加えてどれがこのドキュメントのセクション3.2か3.3に従ってSHOULDが示す追加プロフィールにこのサポートをサポートするかを定義しました。 対応する能力がある受取人に発信するとき、結果として、送付者はそれらの追加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.

潜在的受取人によって提示された能力を見直すとき、SHOULDが認識できて、特徴タグを処理する送付者は中で[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.

送付者は複合である、または代替であることでFacsimile([RFC2305]で指定されるように)のためのTIFFの最小の部分集合と、より高い上質のTIFF使用の両方を含むメッセージを送るかもしれません。

Masinter & Wing             Standards Track                     [Page 5]

RFC 2532                 Extended Internet Fax                March 1999

1999年のインターネットファックス行進のときに広げられたMasinterと翼の標準化過程[5ページ]RFC2532

   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)SHOULD、使用されてください。

   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.

実装は、受取人の実際の能力に局所的に能力をキャッシュして、同期を失うかもしれません。 メカニズムSHOULD、提供して、送付者が能力の局所的に保存されたキャッシュをくつがえすのを許容してください。 また、このドキュメントのセクション4.1に注意してください。

3.1.  Sender Manual Configuration

3.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つの方法が手動で既定の設定をくつがえすために送付者を監督しているユーザのためのものです、通常1受取人あたり1個のベースで。 例えば、トランスミッションの間、ユーザは、受取人が解像度の高い像かカラーイメージを受け取ることができるのを示すことができました。

   While awkward and not automatic, this mechanism reflects the current
   state of deployment of configuration for extended capabilities to
   ordinary Internet email users.

無器用であって、自動ではありませんが、このメカニズムは普通のインターネットメールユーザへの拡張能力のために構成の展開の現状を反映します。

3.2.  Capabilities in Directory

3.2. ディレクトリにおける能力

   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の中に活発な調査があります。(問題は店とフォワードメッセージングのさまざまな問題を解決するでしょう)。

3.3.  Capabilities Returned in MDN or DSN

3.3. MDNかDSNで返された能力

   As outlined in section 2 of this document, a sender may request a
   positive DSN or an MDN.

このドキュメントのセクション2で概説されているように、送付者は積極的なDSNかMDNを要求するかもしれません。

Masinter & Wing             Standards Track                     [Page 6]

RFC 2532                 Extended Internet Fax                March 1999

1999年のインターネットファックス行進のときに広げられたMasinterと翼の標準化過程[6ページ]RFC2532

   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と異なって)に情報を取得するということです。

3.3.1.  Restrictions and Recommendations

3.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.

SHOULDが、プロフィールと特徴がサポートしたのを示す受取人受取人が、唯一のTiff ProfileがS([RFC2305]によって定義されるファックスのための最小のセット)[RFC2531]であるとサポートしても。 これで、送付者は、受取人がこのExtended Facsimile Usingインターネットメール仕様で言いなりになると決心できます。

4. Security Considerations

4. セキュリティ問題

   As this document is an extension of [RFC2305], the Security
   Considerations section of [RFC2305] applies to this document.

このドキュメントが[RFC2305]の拡大であるので、[RFC2305]のSecurity Considerations部はこのドキュメントに適用されます。

   The following additional security considerations are introduced by
   the new features described in this document.

以下の追加担保問題は本書では説明された新機能によって紹介されます。

4.1.  Inaccurate Capabilities Information

4.1. 不正確な能力情報

   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を偽造しました。 送付者であるなら、許容するメカニズムが必要なら、無視されるべきであるか、またはくつがえされるべきキャッシュされた情報であったなら、そこでキャッシュされた能力情報を使用するのは、SHOULDですか?

4.2.  Forged MDNs or DSNs

4.2. 偽造MDNsかDSNs

   Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298] can
   provide incorrect information to a sender.

偽造DSNsかMDNs、説明されるように、送付者への不正確な情報は中[RFC1892、RFC1894、RFC2298]で提供されることができます。

Masinter & Wing             Standards Track                     [Page 7]

RFC 2532                 Extended Internet Fax                March 1999

1999年のインターネットファックス行進のときに広げられたMasinterと翼の標準化過程[7ページ]RFC2532

5.  Implementation Notes

5. 実装注意

   This section contains notes to implementors.

このセクションは作成者に注意を含みます。

5.1.  Submit Mailer Does Not Support DSN

5.1. 提出、メイラーはDSNをサポートしません。

   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]であると実装するのが、役に立つかもしれないので、インストールは現職の服従サーバの制限で抑制されません。

5.2.  Recipient Recommendations

5.2. 受取人推薦

   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が5.6の[RFC1893]ステータスコードで.1にメッセージを拒絶するよう強く奨励されます。 MTAが高められたエラーコード[RFC2034]の報告をサポートするか、または配信障害がDSN(「弾み」)であると生成するのによるメッセージレセプションの後に返すなら、メールデータのエンドインディケータに対応してこのステータスコードを返すかもしれません。

   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のこの機能性を提供するのは送付者が一般にMDNsを要求しなければならないので(要求はいつでも、受信機によって無視されるかもしれません)MDNsを使用することで機能を提供するより優れています。 送付者がそのような振舞いを要求して、受信機なしで振舞いを回避しないで、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]を示すことができないことを決定するなら。

6.  Acknowledgements

6. 承認

   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インターネットファックスワーキンググループのメンバー、および特にこのドキュメントの開発の間に支援と入力を提供した以下の貢献者を承認したがっています:

Masinter & Wing             Standards Track                     [Page 8]

RFC 2532                 Extended Internet Fax                March 1999

1999年のインターネットファックス行進のときに広げられたMasinterと翼の標準化過程[8ページ]RFC2532

   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.

ビビアンCancio、リチャード・コールス、デヴィッド・クロッカー、解放されたネッド、グラハムKlyne、マエダToru、ジェフ・マーシャル、ロイド・マッキンタイヤ、キース・ムーア、ジョージPajari、ジェームスRafferty、マイク・リュール、リチャード・ショッキー、ブライアン・スタッフォード、およびグレッグ・ボードルイ。

7.  References

7. 参照

   [RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets",
             RFC 2533, March 1999.

[RFC2533] 1999年3月のKlyne、G.、「特徴が設定するメディアを説明するための構文」RFC2533。

   [RFC2531] McIntyre, L. and G. Klyne, "Content Feature Schema for
             Internet Fax", RFC 2531, March 1999.

[RFC2531] マッキンタイヤとL.とG.Klyne、「インターネットファックスのための満足している特徴図式」、RFC2531、1999年3月。

   [RFC2530] Wing, D., "Indicating Supported Media Features Using
             Extensions to DSN and MDN", RFC 2530, March 1999.

[RFC2530] 翼、D.、「表示は、メディアが特徴であるとDSNとMDNに拡張子を使用することでサポートした」RFC2530、1999年3月。

   [RFC1891] Moore, K. "SMTP Service Extensions for Delivery Status
             Notifications", RFC 1891, January 1996.

[RFC1891]ムーア、K. 「配送状態通知のためのSMTPサービス拡張子」、RFC1891、1996年1月。

   [RFC1893] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
             1893, January 1996.

[RFC1893] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC1893、1996年1月。

   [RFC1894] Moore, K. and G. Vaudreuil, "An Extensible Message Format
             for Delivery Status Notifications", RFC 1894, January 1996.

[RFC1894] ムーアとK.とG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC1894、1996年1月。

   [RFC2034] Freed, N, "SMTP Service Extension for Returning Enhanced
             Error Codes", RFC 2034, October 1996.

解放された[RFC2034]、N、「戻るためのSMTPサービス拡張子はエラーコードを高めた」RFC2034、1996年10月。

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2298] Fajman, R., "An Extensible Message Format for Message
             Disposition Notifications", RFC 2298, March 1998.

[RFC2298] Fajman、R.、「メッセージ気質通知のための広げることができるメッセージ・フォーマット」、RFC2298、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]マッキンタイヤ、L.、Zilles(S.、バックリー、R.、ヴェナブル、D.、パーソンズ、G.、およびJ.Rafferty)は「インターネットファックスのために形式をファイルします」、RFC2301、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] 豊田、K.、大野、H.、村井、J.、およびD.は飛んで行きます、「ファクシミリの簡単なモードはインターネットメールを使用し」て、RFC2305、1998年3月。

   [RFC974]  Partridge. C.,  "Mail routing and the domain system", STD
             14, RFC 974, January 1986.

[RFC974]ヤマウズラ。 C.と、「メールルーティングとドメインシステム」、STD14、RFC974、1月1986日

   [RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
             December 1998.

[RFC2476]GellensとR.とJ.Klensin、「メッセージ提案」、RFC2476、1998年12月。

Masinter & Wing             Standards Track                     [Page 9]

RFC 2532                 Extended Internet Fax                March 1999

1999年のインターネットファックス行進のときに広げられたMasinterと翼の標準化過程[9ページ]RFC2532

   [RFC2542] Masinter, L., "Terminology and Goals for Internet Fax", RFC
             2542, March 1999.

[RFC2542]Masinter、L.と、「インターネットファックスの用語と目標」(RFC2542)は1999を行進させます。

   [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] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」

   [RFC2060] Crispin, M., "Internet Message Access Protocol - Version
             4Rev1", RFC 2060, December 1996.

[RFC2060] クリスピン、M.、「バージョン4Rev1"、RFC2060、1996年インターネットメッセージアクセス・プロトコル--12月。」

Masinter & Wing             Standards Track                    [Page 10]

RFC 2532                 Extended Internet Fax                March 1999

1999年のインターネットファックス行進のときに広げられたMasinterと翼の標準化過程[10ページ]RFC2532

8. Authors' Addresses

8. 作者のアドレス

   Larry Masinter
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304  USA

ラリーMasinterゼロックスパロアルト研究センター3333コヨーテヒル・Roadカリフォルニア94304パロアルト(米国)

   Fax:    +1 650 812 4333
   EMail:  masinter@parc.xerox.com

Fax: +1 4333年の650 812メール: masinter@parc.xerox.com

   Dan Wing
   Cisco Systems, Inc.
   101 Cooper Street
   Santa Cruz, CA 95060  USA

ダン翼のシスコシステムズInc.101クーパー・通りカリフォルニア95060サンタクルス(米国)

   Phone:  +1 831 457 5200
   Fax:    +1 831 457 5208
   EMail:  dwing@cisco.com

以下に電話をしてください。 +1 831 457、5200Fax: +1 5208年の831 457メール: dwing@cisco.com

Masinter & Wing             Standards Track                    [Page 11]

RFC 2532                 Extended Internet Fax                March 1999

1999年のインターネットファックス行進のときに広げられたMasinterと翼の標準化過程[11ページ]RFC2532

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Copyright(C)インターネット協会(1999)。 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Masinter & Wing             Standards Track                    [Page 12]

Masinterと翼の標準化過程[12ページ]