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)
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).
著作権（C）インターネット協会（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ファクシミリと同等の、インターネットメールのための信頼性と能力交渉を達成するために必要な残りの機能を追加し、インターネット上でファクシミリデータの「フルモード」キャリッジを定義します。現在、ファックス、ユーザーによって楽しまれているものに近いレベルのサービスを提供しながら、これらの追加機能は、標準準拠の電子メールインフラストラクチャとメールユーザエージェントとの相互運用性の最高レベルを提供するように設計されています。
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.
この仕様は、インターネットメール[RFC2532]を使用してインターネットメールを使用してファクシミリの簡易モード[RFC3965]および拡張ファクシミリ内の前の仕事の際構築、インターネットを介してファクシミリデータの「フルモード」キャリッジを規定します。また、この仕様は、古典的な[T30]ファクシミリと同等の、インターネットメールのための信頼性の高い能力交渉を達成するために必要な残りの機能を追加します。密接に現在のファックスユーザーが享受サービスのレベルを近似するサービスのレベルを提供しながら、これらの追加機能は、標準準拠の電子メールインフラストラクチャとメールユーザエージェントとの相互運用性の最高レベルを提供するように設計されています。
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].
キーワードは "MUST" は、 "MUST NOT"、 "REQUIRED" は、 "SHOULD" "ないもの" "ものと" べきではありません」、 "推奨"、 "MAY"、および "" OPTIONALこの文書に記載されているにしています[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.
機能情報を交換するための一つの方法は、受信者によってサポートされることが知られている最良のバージョンを送信するために、発信を可能にし、受信者がそれを要求した場合にも、より適したバージョンを送信するために事後の技術を、使用しています。このメカニズムは、[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つのメカニズムが機能情報の二つの異なるリポジトリを参照すると良いかもしれませんし、これらのリポジトリは、さまざまな情報が含まれる場合があります。おそらく、これは、これらのリポジトリの少なくとも一方が不正確であることを意味します。したがって、大きな問題ではなく、同期より、正当の一つです。
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]豊田、K.、およびD.クロッカー、 "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]バックリー、R.、VENABLE、D.、マッキンタイア、L.、パーソンズ、G.、およびJ.・ラファティ、 "インターネットファックスのためのファイル形式"、RFC 3949、2005年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.ウィング、 "インターネットメールを使用して、拡張ファクシミリ"、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.、ウイング、D.、MUTZ、A.、およびK. Holtman、 "表示、印刷用メディアの機能、およびファックス"、RFC 2534、1999年3月。
[RFC2542] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999.
[RFC2542] Masinter、L.、 "用語およびインターネットファックスの目標"、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.マッキンタイア、RFC 2879 "インターネットファクス（V2）のコンテンツ機能のスキーマ"、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.クロッカー、 "電子メールに基づいて、メッセージングサービスのためのコンテントネゴシエーション"、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]豊田、K.、大野、H.、村井、J.、およびD.翼、 "インターネットメールを使用するファクシミリのシンプルモード"、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]フロイド、S.とL. Daigle氏、 "オープン・プラグイン可能なエッジサービスのための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月 "一般におけるドキュメントファクシミリ伝送のための手順は、交換電話網"。
Appendix A. Direct Mode
付録A.ダイレクトモード
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.
完全にファクシミリをエミュレートする電子メール・プロファイルは、いくつかの異なる問題を解決しなければなりません。一つは、文書表現のセマンティクスが忠実であることを保証するためです。もう一つは、送信者と受信者との間の相互作用は、電話ベースのファクシミリの場合と同様であることです。特に、相互作用の適時性を保証しなければなりません。 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メッセージの内容を調整する機能情報を使用します。
Appendix B. Acknowledgements
付録B.謝辞
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ファックスワーキンググループは、IETFおよびITUと共同で、熱心に電子メールプロファイルを介して、古典的なファクシミリのインターネットベースのエミュレーションを生成するために複数年の努力に参加しています。最初の、最小限のメカニズムを提供して、実装と運用経験など多くのファクシミリの機能を含むように仕様を開発するグループの意欲の恩恵を受けての努力が得られました。
Authors' Addresses
著者のアドレス
Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA
デイブ・クロッカーブランデンブルクインターネットワーキング675スプルースドライブサニーベール、CA 94086 USA
Phone: +1.408.246.8253 EMail: dcrocker@bbiw.net
電話：+1.408.246.8253電子メール：dcrocker@bbiw.net
Graham Klyne Nine by Nine UK
ナイン英国によるグラハムKlyneナイン
Phone: EMail: GK-IETF@ninebynine.org
電話番号：Eメール：GK-IETF@ninebynine.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。