[要約] RFC 4142は、インターネットメールのためのフルモードファックスプロファイル（FFPIM）に関する規格です。このRFCの目的は、インターネットメールを使用してフルモードのファックス通信を実現するためのプロトコルと手順を提供することです。
Network Working Group D. Crocker
Request for Comments: 4142 Brandenburg
Category: Standards Track G. Klyne
Nine by Nine
November 2005
Full-mode Fax Profile for Internet Mail (FFPIM)
インターネットメールのフルモードFAXプロファイル（FFPIM）
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 (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
Classic facsimile document exchange represents both a set of technical specifications and a class of service. Previous work has replicated some of that service class as a profile within Internet mail. The current specification defines "full mode" carriage of facsimile data over the Internet, building upon that previous work and adding the remaining functionality necessary for achieving reliability and capability negotiation for Internet mail, on a par with classic T.30 facsimile. These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates what is currently enjoyed by fax users.
古典的なファクシミリドキュメント交換は、一連の技術仕様とサービスのクラスの両方を表します。以前の作業では、そのサービスクラスの一部がインターネットメール内のプロファイルとして再現されていました。現在の仕様では、インターネット上のファクシミリデータの「フルモード」キャリッジを定義し、以前の作業に基づいて、インターネットメールの信頼性と能力交渉を達成するために必要な残りの機能を追加して、古典的なT.30ファクシミリと同等です。これらの追加機能は、FAXユーザーが現在享受しているものを近似するレベルのサービスを提供しながら、標準に準拠した電子メールインフラストラクチャとメールユーザーエージェントで最高レベルの相互運用性を提供するように設計されています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Content Negotiation . . . . . . . . . . . . . . . . . . . . . . 3
2.1. UA-based Content Negotiation. . . . . . . . . . . . . . . . 3
2.2. ESMTP-based Content Negotiation . . . . . . . . . . . . . . 3
2.3. Interactions between UA and ESMTP Negotiation Mechanisms. . 4
3. Content Format . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References. . . . . . . . . . . . . . . . . . . . 5
5.2. Informative References. . . . . . . . . . . . . . . . . . . 6
A. Direct Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . 7
B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
This specification defines "full mode" carriage of facsimile data over the Internet, building upon previous work in A Simple Mode of Facsimile Using Internet Mail [RFC3965] and Extended Facsimile Using Internet Mail [RFC2532]. This specification also adds the remaining functionality necessary to achieve reliable and capable negotiation for Internet mail, on par with classic [T30] facsimile. These additional features are designed to provide the highest level of interoperability with the standards-compliant email infrastructure and mail user agents, while providing a level of service that closely approximates the level of service currently enjoyed by fax users.
この仕様では、インターネット上のファクシミリデータの「フルモード」キャリッジを定義し、インターネットメール[RFC3965]を使用したファクシミリの単純なモードで以前の作業に基づいて構築され、インターネットメール[RFC2532]を使用してファクシミリを拡張します。この仕様は、クラシック[T30]ファクシミリと同等のインターネットメールの信頼できる有能な交渉を達成するために必要な残りの機能を追加します。これらの追加機能は、標準に準拠した電子メールインフラストラクチャとメールユーザーエージェントと最高レベルの相互運用性を提供するように設計されており、FAXユーザーが現在享受しているサービスのレベルに密接に近似するレベルのサービスを提供します。
Basic terminology is discussed in [RFC2542]. Implementations that conform to this specification MUST also conform to [RFC3965] and [RFC2532].
基本的な用語は[RFC2542]で説明されています。この仕様に準拠する実装は、[RFC3965]および[RFC2532]にも準拠する必要があります。
The new features are designed to be interoperable with the existing base of mail transfer agents (MTAs) and mail user agents (MUAs), and to take advantage of existing standards for optional functionality (e.g., positive delivery confirmation and disposition notification). Enhancements described in this document utilize the existing Internet email messaging infrastructure, where possible, instead of creating fax-specific features that are unlikely to be implemented in non-fax messaging software.
新機能は、既存のメール転送エージェント（MTA）およびメールユーザーエージェント（MUA）と相互運用可能になり、オプションの機能の既存の標準（肯定的な配信確認と処分通知など）を活用するように設計されています。このドキュメントに記載されている拡張機能は、可能であれば、既存のインターネット電子メールメッセージングインフラストラクチャを利用しています。
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]で説明されているように解釈されます。
Classic facsimile service is interactive, such that a sending station can discover the capabilities of the receiving station, prior to sending a facsimile of a document. This permits the sender to transmit the best quality of facsimile supported by both the sending station and the receiving station. Internet mail is store-and-forward, with potentially long latency, such that before-the-fact negotiation is problematic.
クラシックファクシミリサービスはインタラクティブであるため、送信ステーションは、ドキュメントのファクシミリを送信する前に、受信ステーションの機能を発見できます。これにより、送信者は、送信ステーションと受信ステーションの両方でサポートされているファクシミリの最高品質を送信できます。インターネットメールは、潜在的に長い待ち時間があるため、店頭にあり、事前の交渉に問題があります。
Use of a negotiation mechanism permits senders to transfer a richer document form than is permitted when using the safer-but-universal default form. Without this mechanism, the sender of a document cannot be certain that the receiving station will be able to support the form.
交渉メカニズムを使用すると、送信者は、より安全ではあるがユニバーサルのデフォルトフォームを使用する場合に許可されるよりも、より豊富なドキュメントフォームを転送できます。このメカニズムがなければ、ドキュメントの送信者は、受信ステーションがフォームをサポートできることを確信できません。
The capabilities that can be negotiated by an FFPIM participant are specified in [RFC2534] and [RFC2879]. Implementations that are conformant to FFPIM MUST support content negotiation as described there.
FFPIM参加者によって交渉できる機能は、[RFC2534]および[RFC2879]で指定されています。FFPIMに適合している実装は、そこに記載されているように、コンテンツの交渉をサポートする必要があります。
One method for exchanging the capabilities information uses a post-hoc technique, which permits an originator to send the best version known to be supported by the recipient, and to also send a better suited version if the recipient requests it. This mechanism is specified in [RFC3297]. FFPIM implementations MUST support this mechanism.
機能情報を交換するための1つの方法は、事後のテクニックを使用します。これにより、オリジネーターは受信者によってサポートされていることが知られている最良のバージョンを送信し、受信者が要求した場合に適したバージョンを送信できます。このメカニズムは[RFC3297]で指定されています。FFPIMの実装は、このメカニズムをサポートする必要があります。
Another method uses an ESMTP option specified in [RFC4141]. It requires support for content negotiation along the entire path the email travels. Using this mechanism, receiving ESMTP servers are able to report capabilities of the addresses (mailboxes) they support, and sending email clients are able to signal both permission and constraints on conversions.
別の方法では、[RFC4141]で指定されたESMTPオプションを使用します。電子メールが移動するパス全体に沿ったコンテンツネゴシエーションのサポートが必要です。このメカニズムを使用して、ESMTPサーバーの受信は、サポートするアドレス（メールボックス）の機能を報告できます。電子メールクライアントに送信すると、コンバージョンの許可と制約の両方を信号することができます。
FFPIM participants MAY support this mechanism.
FFPIM参加者はこのメカニズムをサポートする場合があります。
NOTE: This specification provides for content conversion by unspecified intermediaries. Use of this mechanism carries significant risk. Although intermediaries always have the ability to perform damaging transformations, use of this specification could result in more exploitation of that potential and, therefore, more misbehavior. Use of intermediaries is discussed in [RFC3238].
注：この仕様は、不特定の仲介者によるコンテンツ変換を提供します。このメカニズムの使用には大きなリスクがあります。仲介者は常に損傷の変換を実行する能力を持っていますが、この仕様を使用すると、その可能性がより多くの搾取を行う可能性があり、したがって、より誤動作が生じる可能性があります。仲介者の使用は[RFC3238]で説明されています。
FFPIM participants must ensure that their use of the UA and ESMTP methods for content negotiation is compatible. For example, two mechanisms might consult two different repositories of capabilities information, and those repositories might contain different information. Presumably, this means that at least one of these repositories is inaccurate. Therefore, the larger problem is one of correctness, rather than synchronization.
FFPIM参加者は、コンテンツネゴシエーションのためにUAおよびESMTPメソッドの使用が互換性があることを確認する必要があります。たとえば、2つのメカニズムが機能情報の2つの異なるリポジトリを参照する場合があり、それらのリポジトリには異なる情報が含まれている場合があります。おそらく、これは、これらのリポジトリの少なくとも1つが不正確であることを意味します。したがって、より大きな問題は、同期ではなく正確性の1つです。
This specification does not require a particular method of using the mechanisms together.
この仕様では、メカニズムを一緒に使用する特定の方法は必要ありません。
FFPIM allows the transfer of enhanced TIFF data relative to [RFC3965] and [RFC2532]. The details for these enhancements are contained in [RFC3949]. Implementations that are conformant to FFPIM SHOULD support TIFF enhancements.
FFPIMにより、[RFC3965]および[RFC2532]に対する強化されたTIFFデータの転送が可能になります。これらの強化の詳細は[RFC3949]に含まれています。FFPIMに適合している実装は、TIFFの強化をサポートする必要があります。
It should also be noted that the content negotiation mechanism permits a sender to know the full range of content types that are supported by the recipient. Therefore, requirements for support of TIFF represent a functional minimum for FFPIM.
また、コンテンツネゴシエーションメカニズムにより、送信者が受信者がサポートするコンテンツタイプの全範囲を知ることができることにも注意する必要があります。したがって、TIFFのサポートの要件は、FFPIMの機能的最小を表します。
As this document is an extension of [RFC3965] and [RFC2532], the Security Considerations sections of [RFC3965] and [RFC2532] apply to this document, including discussion of PGP and S/MIME use for authentication and privacy.
このドキュメントは[RFC3965]および[RFC2532]の拡張であるため、[RFC3965]と[RFC2532]のセキュリティに関する考慮事項セクションは、認証とプライバシーのためのPGPおよびS/MIMEの使用の議論を含むこのドキュメントに適用されます。
It appears that the mechanisms added by this specification do not introduce new security considerations. However, the concerns raised in [RFC2532] are particularly salient for these new mechanisms.
この仕様によって追加されたメカニズムは、新しいセキュリティ上の考慮事項を導入していないようです。ただし、[RFC2532]で提起された懸念は、これらの新しいメカニズムにとって特に顕著です。
Use of this specification should occur with particular attention to the following security concerns:
この仕様の使用は、次のセキュリティの懸念に特に注意を払って発生する必要があります。
* Negotiation can be used as a denial of service attack.
* 交渉は、サービス攻撃の拒否として使用できます。
* Negotiation may lead to the use of an unsafe data format.
* 交渉は、安全でないデータ形式の使用につながる可能性があります。
* Negotiation discloses information and therefore raises privacy concerns.
* 交渉は情報を開示しているため、プライバシーの懸念を引き起こします。
Use of the ESMTP CONNEG option permits content transformation by an intermediary, along the mail transfer path. When the contents are encrypted, the intermediary cannot perform the conversion, because it is not expected to have access to the relevant secret keying material. When the contents are signed, but not encrypted, conversion will invalidate the signature. Therefore, permission to convert SHOULD NOT normally be used with signed or sealed messages.
ESMTP Connegオプションの使用により、メール転送パスに沿って、仲介者によるコンテンツ変換が可能になります。コンテンツが暗号化されている場合、関連する秘密のキーイング資料にアクセスできると予想されていないため、仲介者は変換を実行できません。コンテンツが署名されているが暗号化されていない場合、変換は署名を無効にします。したがって、コンバージョンの許可は、通常、署名されたメッセージまたはシールされたメッセージで使用しないでください。
[RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for Content Conversion", RFC 4141, November 2005.
[RFC4141] Toyoda、K。およびD. Crocker、「コンテンツ変換のためのSMTPおよびMIME拡張」、RFC 4141、2005年11月。
[RFC3949] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J. Rafferty, "File Format for Internet Fax", RFC 3949, February 2005.
[RFC3949] Buckley、R.、Venable、D.、McIntyre、L.、Parsons、G。、およびJ. Rafferty、「インターネットFAXのファイル形式」、RFC 3949、2005年2月。
[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月。
[RFC2532] Masinter, L. and D. Wing, " Extended Facsimile Using Internet Mail", RFC 2532, March 1999.
[RFC2532] Masinter、L。およびD. Wing、「インターネットメールを使用した拡張ファクシミリ」、RFC 2532、1999年3月。
[RFC2534] Masinter, L., Wing, D., Mutz, A., and K. Holtman, "Media Features for Display, Print, and Fax", RFC 2534, March 1999.
[RFC2534] Masinter、L.、Wing、D.、Mutz、A。、およびK. Holtman、「ディスプレイ、印刷、FAXのメディア機能」、RFC 2534、1999年3月。
[RFC2542] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999.
[RFC2542] Masinter、L。、「インターネットFAXの用語と目標」、RFC 2542、1999年3月。
[RFC2879] Klyne, G. and L. McIntyre, "Content Feature Schema for Internet Fax (V2)", RFC 2879, August 2000.
[RFC2879] Klyne、G。およびL. McIntyre、「インターネットファックスのコンテンツ機能スキーマ（V2）」、RFC 2879、2000年8月。
[RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, July 2002.
[RFC3297] Klyne、G.、Iwazaki、R。、およびD. Crocker、「電子メールに基づくメッセージサービスのコンテンツ交渉」、RFC 3297、2002年7月。
[RFC3965] Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 3965, December 2004.
[RFC3965] Toyoda、K.、Ohno、H.、Murai、J。、およびD. Wing、「インターネットメールを使用したファクシミリの単純なモード」、RFC 3965、2004年12月。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[RFC3238] Floyd、S。およびL. Daigle、「Open Pluggable Edge ServicesのIAB建築および政策上の考慮事項」、RFC 3238、2002年1月。
[T30] ITU-T (CCITT), "Procedures for Document Facsimile Transmission in the General Switched Telephone Network", Recommendation T.30, July 1996.
[T30] ITU-T（CCITT）、「一般的な切り替えの電話ネットワークでの文書ファクシミリ送信の手順」、推奨T.30、1996年7月。
Email is a store-and-forward service, typically with highly variable delay between the time a message leaves the sender's realm and the time it arrives in the receiver's realm. The number of relays between sender and receiver is also unknown and variable. By contrast, facsimile is generally considered to be direct and immediate.
電子メールはストアアンドフォワードサービスであり、通常、メッセージが送信者の領域を離れるまでの間までに非常に変動する遅延があり、レシーバーの領域に到着するまでです。送信者と受信機の間のリレーの数も不明で可変です。対照的に、ファクシミリは一般に直接的かつ即時であると考えられています。
An email profile that fully emulates facsimile must solve several different problems. One is to ensure that the document representation semantics are faithful. Another is that the interaction between sender and receiver is similar to that of telephony-based facsimile. In particular, it must ensure the timeliness of the interaction. The specifications for FFPIM and its predecessors enable email to emulate the former, the information (semantics) activities of facsimile.
ファクシミリを完全にエミュレートする電子メールプロファイルは、いくつかの異なる問題を解決する必要があります。1つは、文書表現のセマンティクスが忠実であることを確認することです。もう1つは、送信者とレシーバーの間の相互作用が、テレフォニーベースのファクシミリの相互作用と類似していることです。特に、相互作用の適時性を確保する必要があります。FFPIMとその前任者の仕様により、メールは前者、ファクシミリの情報（セマンティクス）活動をエミュレートできるようにします。
The ESMTP CONNEG option sets the stage for achieving the latter, with email-based facsimile transfer that has interactive negotiations, on a par with telephony-based facsimile. The key, additional requirement is to achieve timeliness. Ultimately, timeliness requires configuring sender and receiver email servers to interact directly. The sender's MTA must directly contact the receiver's MTA. With typical email service configurations, the content and interaction semantics of facsimile can be emulated quite well, but timeliness cannot be assured.
ESMTP Connegオプションは、テレフォニーベースのファクシミリと同等に、インタラクティブな交渉を行う電子メールベースのファクシミリ転送を備えた後者を達成するための段階を設定します。重要な要件は、適時性を達成することです。最終的に、適時性には、直接対話するように送信者と受信機の電子メールサーバーを構成する必要があります。送信者のMTAは、受信機のMTAに直接連絡する必要があります。典型的な電子メールサービスの構成により、ファクシミリのコンテンツとインタラクションセマンティクスは非常によくエミュレートできますが、適時性は保証できません。
To achieve direct sending, the originating MTA must not use sending-side intermediaries such as outbound enterprise MTAs. Instead, it must be configured to do transmissions directly to hosts specified in email addresses, based on queries to the public DNS. To achieve direct receiving, the target MTAs must have DNS A records, without MX records. That is, they also must be configured not to use intermediaries.
直接送信を達成するために、発信元のMTAは、アウトバウンドエンタープライズMTAなどの送信側の仲介者を使用してはなりません。代わりに、パブリックDNSへのクエリに基づいて、電子メールアドレスで指定されたホストに直接送信を行うように構成する必要があります。直接受信を達成するには、ターゲットMTAには、MXレコードなしでDNS Aレコードが必要です。つまり、仲介者を使用しないように構成する必要があります。
The sender may then use ESMTP Conneg to determine the capabilities of the receiver. Afterwards the sender will use the capabilities information to tailor the TIFF message content it sends.
送信者は、ESMTP Connegを使用してレシーバーの機能を決定できます。その後、送信者は機能情報を使用して、送信するTIFFメッセージコンテンツを調整します。
The IETF Fax working group, in collaboration with the IETF and the ITU, has diligently participated in a multi-year effort to produce Internet-based emulation of classic facsimile via email profiles. The effort benefited from the group's willingness to provide an initial, minimal mechanism, and then develop the specification to include more facsimile features as implementation and operation experience was gained.
IETF FAXワーキンググループは、IETFおよびITUと協力して、電子メールプロファイルを介してクラシックファクシミリのインターネットベースのエミュレーションを作成するための複数年の努力に熱心に参加しました。この努力は、最初の最小限のメカニズムを提供し、実装と運用の経験が得られるにつれてより多くのファクシミリ機能を含めるために仕様を開発するというグループの意欲から恩恵を受けました。
Authors' Addresses
著者のアドレス
Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA
Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale、CA 94086 USA
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
Graham Klyne Nine by Nine UK
Graham Klyne Nine by Nine UK
Phone: EMail: GK-IETF@ninebynine.org
電話：メール：gk-ietf@ninebynine.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。