Network Working Group V. Cancio
Request for Comments: 3249 Xerox Corporation
Category: Informational M. Moldovan
G3 Nova Technology, Inc.
H. Tamura
Ricoh Company, LTD.
D. Wing
Cisco Systems
September 2002
Implementers Guide for Facsimile Using Internet Mail
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document is intended for the implementers of software that use email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents.
この文書は、これは情報の文書であり、そのガイドラインは、参照文書に取って代わるいないRFC 2305および2532を使用してファクシミリに送信する電子メールを使用するソフトウェアの実装者を対象としています。
Table of Contents
目次
1. Introduction .................................................. 2
1.1 Organization of this document ................................ 2
1.2 Discussion of this document .................................. 2
2. Terminology ................................................... 3
3. Implementation Issues Specific to Simple Mode ................. 3
3.1 Simple Mode Fax Senders ...................................... 3
3.1.1 Multipart-alternative ...................................... 3
3.2 Simple Mode Fax Receivers .................................... 4
3.2.1 Multipart-alternative and Storage Capacity ................. 4
4. Implementation Issues Specific to Extended Mode ............... 4
4.1 Multipart-alternative ........................................ 4
4.2 Correlation of MDN with Original Message ..................... 4
4.3 Correlation of DSN with Original Message ..................... 5
4.4 Extended Mode Receivers ...................................... 5
4.4.1 Confirmation of receipt and processing from User Agents .... 5
4.4.1.1 Discrepancies in MDN [9] Interpretation .................. 5
4.4.1.2 Disposition-Type and body of message in MDN .............. 6
4.4.2 "Subject" of MDN and DSN in Success and Failure Cases ...... 6
4.4.3 Extended Mode Receivers that are MTAs (or ESMTP servers) ... 7
4.4.3.1 Success Case Example ..................................... 7
4.4.3.2 Failure Case Example 1 ................................... 9
4.4.3.3 Failure Case Example 2 ................................... 10
4.4.4 Extended Mode Receivers that are POP3/IMAP4 ................ 11
4.4.4.1 Success Case Example ..................................... 11
4.4.4.2 Failure Case Example ..................................... 12
4.4.5 Receiving Multiple Attachments ............................. 13
5. Implementation Issues Specific to the File Format ............. 13
5.1 IFD Placement & Profile-S Constraints ........................ 13
5.2 Precautions for implementers of RFC 2301 [4] ................. 14
5.2.1 Errors encountered during interoperability testing ......... 14
5.2.2 Color Gamut Considerations ................................. 14
5.2.3 File format Considerations ................................. 15
5.2.3.1 Considerations for greater reader flexibility ............ 15
5.2.3.2 Error considerations ..................................... 16
5.3 Content-Type for the file format ............................. 17
6. Implementation Issues for Internet Fax Addressing ............. 17
7. Security Considerations ....................................... 18
8. Acknowledgements .............................................. 18
9. References .................................................... 18
10. Authors' Addresses ........................................... 20
11. Full Copyright Statement ..................................... 21
This document clarifies published RFCs which standardize facsimile communications using Internet Email. The intent is to prevent implementations that deviate in such a way as to cause interoperability problems.
この文書は、インターネット電子メールを使用してFAX通信を標準化し公表RFCを明確にしています。その意図は、相互運用性の問題を引き起こすような方法で逸脱実装を防ぐためです。
This document contains four sections that clarify, in order, the handling of simple mode fax messages, extended mode fax messages, the file format, and the internet addressing of fax recipients.
この文書では、順番に、シンプルモードのファックスメッセージ、拡張モードのファックスメッセージ、ファイル形式、およびファックス受信者のアドレス指定、インターネットの取り扱いを明確に四つの部分が含まれています。
See Section 2 for terminology.
専門用語については、セクション2を参照してください。
Discussion of this document should take place on the Internet fax mailing list hosted by the Internet Mail Consortium (IMC). Please send comments regarding this document to:
本書の議論は、インターネットメールコンソーシアム（IMC）が主催するインターネットファクスメーリングリストで行われるべき。このドキュメントに関するコメントを送ってください。
ietf-fax@imc.org
いえｔｆーふぁｘ＠いｍｃ。おｒｇ
To subscribe to this list, send a message with the body 'subscribe' to "ietf-fax-request@imc.org".
このリストを購読するには、「ietf-fax-request@imc.org」に「購読の体にメッセージを送信します。
To see what has gone on before you subscribed, please see the mailing list archive at:
あなたが加入する前に行っているかを確認するには、でメーリングリストのアーカイブを参照してください。
http://www.imc.org/ietf-fax/
ｈっｔｐ：／／ｗっｗ。いｍｃ。おｒｇ／いえｔｆーふぁｘ／
The following terms are used throughout this document:
以下の用語は、この文書全体で使用されています。
DSN - RFC 1894, "An Extensible Message Format for Delivery Status Notifications" [7] Extended Mode - RFC 2532, "Extended Facsimile Using Internet Mail" [3] MDN - RFC 2298, "An Extensible Message Format for Message Disposition Notifications" [9] Simple Mode - RFC 2305, "A Simple Mode of Facsimile Using Internet Mail" [2] TIFF - profile S or F of "File Format for Internet Fax" [4] delivered as "image/tiff" TIFF-FX - other profiles sent as "image/tiff-fx"
DSN - RFC 1894、「配送状態通知のための広げることができるメッセージフォーマット」[7]拡張モード - RFC 2532、「インターネットメールを使用して、拡張ファクシミリ」[3] MDN - RFC 2298、「メッセージ処分通知のための広げることができるメッセージフォーマット」[ 9]シンプルモード - RFC 2305「インターネットメールを使用するファクシミリのシンプルモード」[2] TIFF - プロファイルS又は「インターネットファクスのファイル形式」のF [4]「画像/ TIFF」TIFF-FXとして送達 - その他「画像/ TIFF-FX」として送信されたプロファイル
In examples, "C:" is used to indicate lines sent by the client, and "S:" to indicate those sent by the server.
例では、「C：」は、クライアントから送られた行を示すために使用され、そして「S：」は、サーバによって送信されたものを示すために。
Issues specific to Simple Mode [2] are described below:
シンプルモード[2]に固有の問題は以下の通りであります：
Although a requirement of MIME compliance (16, Section 5.1.4), some email client implementations are not capable of correctly processing messages with a MIME Content-Type of "multipart/alternative". If a sender is unsure if the recipient is able to correctly process a message with a Content-Type of "multipart/alternative", the sender should assume the worst and not use this MIME Content-Type.
MIME準拠（16、セクション5.1.4）の要件が、いくつかの電子メールクライアントの実装が正しく「マルチパート/代替」のMIMEのContent-Typeのでメッセージを処理することができません。受信者が正しく「マルチパート/代替」のコンテンツタイプを使用してメッセージを処理することが可能である場合、送信者不明の場合は、送信者は最悪の仮定およびこのMIMEのContent-Typeを使用しないでください。
Devices with little storage capacity are unable to cache previous parts of a multipart/alternative message. In order for such devices to correctly process only one part of a multipart/alternative message, such devices may simply use the first part of a multipart/alternative message it is capable of processing.
少しストレージ容量を持つデバイスはマルチパート/代替メッセージの前の部分をキャッシュすることはできません。そのようなデバイスが正しくマルチパート/代替メッセージの一部のみを処理するために、そのようなデバイスは、単にそれが処理することが可能なマルチパート/代替メッセージの最初の部分を使用することができます。
This behavior means that even if subsequent, higher-fidelity parts could have been processed, they will not be used.
この動作は、その後、高忠実度の部分が処理された可能性があっても、彼らは使用されないことを意味します。
This behavior can cause user dissatisfaction because when two high-fidelity but low-memory devices are used with each other, the lowest-fidelity part of the multipart/alternative will be processed.
2高忠実度が、低メモリデバイスが相互に使用されている場合、マルチパート/代替の最低忠実度の部分が処理されるため、この動作は、ユーザーの不満を引き起こす可能性があります。
The solution to this problem is for the sender to determine the capability of the recipient and send only high fidelity parts. However, a mechanism to determine the recipient capabilities prior to an initial message sent to the recipient doesn't yet exist on the Internet.
送信者が受信者の能力を決定し、唯一の高忠実度の部品を送信するために、この問題への解決策です。しかし、従来の受信者に送信された最初のメッセージに受信者の能力を決定するためのメカニズムは、まだインターネット上に存在しません。
After an initial message is sent, the Extended Mode mechanism, described in RFC 2532 [3], Section 3.3, enables a recipient to include its capabilities in a delivery and/or a disposition notification: in a DSN, if the recipient device is an RFC 2532/ESMTP [3] compliant server or in an MDN if the recipient is a User Agent.
受信装置である場合、DSNに初期メッセージが送信された後、拡張モード機構は、2532 [3]、セクション3.3は、送達および/または配置の通知にその機能を含むように受信者を有効にRFCに記載しますRFC 2532 / ESMTP [3]準拠のサーバーまたはMDNに受信者がユーザーエージェントである場合。
Issues specific to Extended Mode [3] fax are described below. Note that any Extended Mode device also needs to consider issues specific to Simple Mode (Section 3 of this document).
拡張モード[3]のファックスに固有の問題は、以下に記載されています。任意の拡張モードデバイスはまた、シンプルモード（このドキュメントのセクション3）に固有の問題を検討する必要があることに注意してください。
Sections 3.1.1 and 3.2.1 are also applicable to this mode.
セクション3.1.1と3.2.1も、このモードに適用されます。
To re-iterate a paragraph from section 2.1, RFC 2298 [9]:
セクション2.1、RFC 2298から再び反復段落〜[9]。
A message that contains a Disposition-Notification-To header SHOULD also contain a Message-ID header, as specified in RFC 822 [10]. This will permit automatic correlation of MDNs with original messages by user agents.
RFC 822 [10]で指定されるように処分-NOTIFICATION-にヘッダを含むメッセージは、メッセージIDヘッダを含むべきです。これは、ユーザエージェントによるオリジナルメッセージで開封通知の自動相関を可能にします。
Similar to the requirement to correlate an MDN, above, DSNs also need to be correlated. This is best done using the ENVID parameter in the "MAIL" command. See Sections 3 and 5.4 of RFC 1891 [5] for details.
MDNを相関するための要件と同様に、上記の、DSNはまた、相関される必要があります。これは最高の「MAIL」コマンドでENVIDパラメータを使用して行われます。詳細については、[5]のセクション3およびRFC 1891の5.4を参照してください。
Confirmation that the facsimile image (attachment) was delivered and successfully processed is an important aspect of the extended mode of the facsimile using Internet mail. This section describes implementation issues with several types of confirmations.
ファクシミリ画像（アタッチメント）が配信され、正常に処理されたことの確認は、インターネットメールを使用してファクシミリの拡張モードの重要な側面です。このセクションでは、確認のいくつかのタイプと実装の問題について説明します。
When a message is received with the "Disposition-Notification-To" header and the receiver has determined whether the message can be processed, it may generate a:
メッセージは、「処分-NOTIFICATION-TO」ヘッダーと受信機がメッセージを処理できるかどうかを決定したと、それが生成することができる受信した場合。
a) Negative MDN in case of error, or
a）は負のエラーの場合はMDN、または
b) Positive MDN in case of success
B）正MDN成功の場合
The purpose of receiving a requested MDN acknowledgement from an Extended Mode recipient is the indication of success or failure to process the file attachment that was sent. The attachment, not the body, constitutes the facsimile message. Therefore an Extended Mode sender would expect, and it is recommended that the Extended Mode receiver send (with an MDN), an acknowledgement of the success or failure to decode and process the file attachment.
拡張モードの受信者から要求されたMDN応答を受信するためには、成功または送信された添付ファイルを処理するために、障害の指標です。アタッチメントではなく、本体は、ファクシミリメッセージを構成しています。したがって、拡張モードの送信者が期待する、そして拡張モードの受信機は、（MDNで）成功または添付ファイルをデコードし、処理するために、失敗の確認応答を送信することをお勧めします。
Implementers of the Extended Mode [3] should be consistent in the feedback provided to senders in the form of error codes and/or failure/success messages.
拡張モードの実装は、[3]のエラーコード及び/又は故障/成功メッセージの形態で送信者に提供されるフィードバックに一貫しているべきです。
An Extended Mode sender must be aware that RFC 2298 [9] does not distinguish between the success or failure to decode the body-content part of the message and the success or failure to decode a file attachment. Consequently MDNs may be received which do not reflect the success or failure to decode the attached file, but rather to decode the body-content part of the message.
拡張モードの送信者は、RFC 2298 [9]添付ファイルをデコードするために、メッセージのボディコンテンツ部分および成功または失敗を復号するために成功したか失敗したかを区別しないことに注意しなければなりません。したがって開封通知は、成功または添付ファイルをデコードに失敗したことを反映していない、むしろメッセージのボディ・コンテンツ部分を復号化するためにどの受信されてもよいです。
If the receiver of an MDN request is an RFC 2532 compliant device that automatically prints the received Internet mail messages and attachments, or forwards the attachment via GSTN fax, it should, in the case of success:
MDN要求の受信機は自動的に受信したインターネットメールメッセージと添付ファイルを印刷し、またはGSTNファックスを経由して添付ファイルを転送するRFC 2532準拠のデバイスであれば、それは成功した場合に、すべきです：
a) Use a "disposition-type" of "dispatched" (with no "disposition-modifier") in the MDN, and
A）MDNでNO「配置改質剤」）で（「派遣」の「配置型」を使用し、及び
b) Use text similar to the following in the body of the message:
b）は、メッセージの本文に次のようなテキストを使用します。
"This is a Return Receipt for the mail that you sent to [above, or below, or this address, etc]. The message and attached files[s] may have been printed, faxed or saved. This is no guarantee that the message has been read or understood".
「これは[など、上記、または下記、またはこのアドレス]あなたがに送信されたメールの戻り領収書です。メッセージと添付ファイル[S]は、印刷、ファックスまたは保存されている可能性があります。これは、そのメッセージ保証するものではありません「読んだり理解されています。
and in the case of failure:
そして障害が発生した場合：
a) Use a "disposition-type" of "processed" and disposition-modifier of "error", and
A）「処理」と「エラー」の処分-修飾の「気質型」を使用し、
b) Use text similar to the following in the body of the message:
b）は、メッセージの本文に次のようなテキストを使用します。
"This is a Return Receipt for the mail that you sent to [above, or below, or this address, etc]. An error occurred while attempting to decode the attached file[s]".
「これは、[上記、以下、またはこのアドレスなど]に送信されたメールの戻り領収書です。[S]を添付ファイルをデコードしようとしたときにエラーが発生しました」。
This recommendation adheres to the definition in RFC 2298 [9] and helps to distinguish the returned MDNs for proper handling.
この勧告は、[9] RFC 2298で定義に準拠し、適切に処理するため返された開封通知を区別するのに役立ちます。
Implementers may wish to consider sending messages in the language of the sender (by utilizing a header field from the original message) or including multiple languages, by using multipart/alternative for the text portion of the MDN.
実装は、MDNのテキスト部分のためのマルチパート/代替手段を使用することによって、または複数の言語を含む（元のメッセージからヘッダーフィールドを利用して）送信者の言語でメッセージを送信することを検討することを望むかもしれません。
Because legacy e-mail applications do not parse the machine-readable headers, e-mail users depend on the human-readable parts of the MDN to recognize the type of acknowledgement that is received.
従来の電子メールアプリケーションは、機械読み取り可能なヘッダーを解析していないため、電子メールユーザーが受信した確認応答の種類を認識するためにMDNの人間が読める部分に依存しています。
Examples:
例：
MDN: Subject: Your message was processed successfully. (MDN) Subject: Your message has been rejected. (MDN)
MDN：件名：あなたのメッセージが正常に処理されました。 （MDN）件名：あなたのメッセージが拒否されました。 （MDN）
DSN: Subject: Your message was delivered successfully. (DSN) Subject: Your message could not be delivered. (DSN) Subject: Your message is delayed. (DSN)
DSN：件名：あなたのメッセージが正常に配信されました。 （DSN）件名：あなたのメッセージを配信することができませんでした。 （DSN）件名：あなたのメッセージが遅延しています。 （DSN）
SMTP server-based implementations are strongly encouraged to implement the "SMTP Service Extension for Returning Enhanced Error Codes" [8]. This standard is easy to implement and it allows detailed standardized success and error indications to be returned to the sender by the submitting MTA.
SMTPサーバーベースの実装が強く、「強化されたエラーコードを返すためのSMTPサービス拡張」を実装することが奨励されている[8]。この規格は、実装が容易であり、詳細な標準化された成功とエラー表示が提出MTAによって差出人に返送することができます。
The following examples, are provided as illustration only. They should not be interpreted as limiting the protocol or the DSN form. If the examples conflict with the definitions in the standards (RFC 1891[5]/1893[6]/1894[7]/2034[8]), the standards take precedence.
以下の実施例は、単に例示として提供されます。これらは、プロトコルまたはDSNの形態を限定するものとして解釈されるべきではありません。例は、標準の定義と競合する（RFC 1891 [5] / 1893 [6] / 1894 [7] / 2034 [8]）、規格が優先場合。
In the following example the sender <jean@example.com> sends a message to the receiver <ifax@example.net> which is an ESMTP server and the receiver successfully decodes the message.
次の例では、送信者は、<jean@example.com> ESMTPサーバーであり、受信側がメッセージを正常に復号する受信機<ifax@example.net>にメッセージを送信します。
example.com
+-------+
| Mail |
| User |
| Agent |
+-------+
|
V
+----------+ +--------+ +---------+
| Mail + | Mail | | Mail |
|Submission|----->|Transfer|---->|Transfer |
| Agent | | Agent | | Agent |
+----------+ +--------+ +---------+
example.org example.net
えぁｍｐぇ。おｒｇ えぁｍｐぇ。ねｔ
SMTP Sequence:
SMTPシーケンス：
S: 220 example.net SMTP service ready C: EHLO example.org S: 250-example.net S: 250-DSN S: 250 ENHANCEDSTATUSCODES C: MAIL FROM:<jean@example.com> RET=HDRS ENVID=MM123456 S: 250 2.1.0 Originator <jean@example.com> ok C: RCPT TO:<ifax@example.net> NOTIFY=SUCCESS,FAILURE \ ORCPT=rfc822;ifax@example.net S: 250 2.1.5 Recipient <ifax@example.net> ok C: DATA S: 354 Send message, ending in <CRLF>.<CRLF> C: C: [Message goes here.] C: C: . S: 250 2.0.0 Message accepted C: QUIT S: 221 2.0.0 Goodbye
S：220 example.net SMTPサービス準備C：EHLO example.org S：250-example.net S：250-DSN S：250 ENHANCEDSTATUSCODES C <jean@example.com> RET = HDRS ENVID = MM123456 S：FROM MAIL ：250 2.1.0発信<jean@example.com> OK C：RCPT TO：<ifax@example.net> = SUCCESSをNOTIFY、FAILURE \ ORCPT = RFC822; ifax@example.net S：250 2.1.5受信者<IFAX @ example.net> OK C：DATA S：<CRLF>で終わる354送信メッセージ、<CRLF> C：C：[メッセージがここに入ります。] C：C：。 S：250 2.0.0メッセージ受け入れC：QUIT S：221 2.0.0さようなら
DSN (to jean@example.com):
DSN（そのjean@example.com）：
Date: Mon, 12 Dec 1999 19:01:57 +0900 From: postmaster@example.net Message-ID: <19991212190157.01234@example.net> To: jean@example.com Subject: Your message was delivered successfully. (DSN) MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary=JUK199912121854870001
日付：月、1999年12月12日19時01分57秒0900投稿者：postmaster@example.netメッセージ-ID：<19991212190157.01234@example.net>へ：jean@example.com件名：あなたのメッセージが正常に配信されました。 （DSN）MIME-バージョン：1.0のContent-Type：マルチパート/レポート。レポートタイプ=配送状況。境界= JUK199912121854870001
--JUK199912121854870001 Content-type: text/plain
--JUK199912121854870001コンテンツタイプ：テキスト/平野
Your message (id MM123456) was successfully delivered to ifax@example.net.
あなたのメッセージ（ID MM123456）が正常にifax@example.netに配信されました。
--JUK199912121854870001 Content-type: message/delivery-status
--JUK199912121854870001コンテンツタイプ：/配信ステータスメッセージ
Reporting-MTA: dns; example.net Original-Envelope-ID: MM123456 Final-Recipient: rfc822;ifax@example.net Action: delivered Status: 2.1.5 (Destination address valid) Diagnostic-Code: smtp; 250 2.1.5 Recipient <ifax@example.net> ok
報告-MTA：DNSを。 example.netオリジナル・封筒-ID：MM123456最終受信者：RFC822; ifax@example.netアクション：配信ステータス：2.1.5（有効な宛先アドレス）診断-コード：SMTP; 250 2.1.5受信者<ifax@example.net> OK
--JUK199912121854870001 Content-type: message/rfc822
--JUK199912121854870001コンテンツタイプ：メッセージ/ RFC822
[headers of returned message go here.]
[返されたメッセージのヘッダーには、ここに行きます。]
--JUK199912121854870001--
--JUK199912121854870001--
In this example, the receiver determines it is unable to decode the attached file AFTER it has received the SMTP message. The receiver then sends a 'failure' DSN.
この例では、受信機は、SMTPメッセージを受信した後に添付ファイルをデコードすることができないかを判断します。次に、受信機は「失敗」DSNを送信します。
example.com
+-------+
| Mail |
| User |
| Agent |
+-------+
|
V
+----------+ +--------+ +---------+
| Mail + | Mail | | Mail |
|Submission|----->|Transfer|---->|Transfer |
| Agent | | Agent | | Agent |
+----------+ +--------+ +---------+
example.org example.net
SMTP Sequence:
SMTPシーケンス：
This is the same as the case a). After the sequence, a decode error occurs at the receiver, so instead of a 'success' DSN, a 'failure' DSN is sent.
これは）ケースAと同じです。シーケンスの後、デコードエラーが非常に代わり「成功」DSNの、受信機で生じる、「失敗」DSNが送信されます。
DSN (to jean@example.com):
DSN（そのjean@example.com）：
Date: Mon, 12 Dec 1999 19:31:20 +0900 From: postmaster@example.net Message-ID: <19991212193120.87652@example.net> To: jean@example.com Subject: Your message could not be delivered. (DSN) MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary=JUK199912121934240002
日付：月、1999年12月12日午後7時31分20秒0900投稿者：postmaster@example.netメッセージ-ID：<19991212193120.87652@example.net>へ：jean@example.com件名：あなたのメッセージを配信することができませんでした。 （DSN）MIME-バージョン：1.0のContent-Type：マルチパート/レポート。レポートタイプ=配送状況。境界= JUK199912121934240002
--JUK199912121934240002 Content-type: text/plain
--JUK199912121934240002コンテンツタイプ：テキスト/平野
Your message (id MM123456) to ifax@example.net resulted in an error while attempting to decode the attached file.
添付ファイルをデコードしようとしたときにあなたのメッセージ（ID MM123456）がエラーになりましたifax@example.netします。
--JUK199912121934240002 Content-type: message/delivery-status
--JUK199912121934240002コンテンツタイプ：/配信ステータスメッセージ
Reporting-MTA: dns; example.net Original-Envelope-ID: MM123456 Final-Recipient: rfc822;ifax@example.net Action: Failed Status: 5.6.1 (Media not supported) Diagnostic-Code: smtp; 554 5.6.1 Decode error
報告-MTA：DNSを。 example.netオリジナル・封筒-ID：MM123456最終受信者：RFC822; ifax@example.net処置：失敗しましたステータス：5.6.1（メディアがサポートされていない）の診断-コード：SMTP; 554 5.6.1デコードエラー
--JUK199912121934240002 Content-type: message/rfc822
--JUK199912121934240002コンテンツタイプ：メッセージ/ RFC822
[headers of returned message go here.]
[返されたメッセージのヘッダーには、ここに行きます。]
--JUK199912121934240002--
--JUK199912121934240002--
In this example, the receiver determines it is unable to decode the attached file BEFORE it accepts the SMTP transmission.
この例では、受信機は、SMTP送信を受け付ける前に、添付ファイルをデコードすることができないかを判断します。
SMTP sequence:
SMTPシーケンス：
S: 220 example.net SMTP service ready C: EHLO example.org S: 250-example.net S: 250-DSN S: 250 ENHANCEDSTATUSCODES C: MAIL FROM:<jean@example.com> RET=HDRS ENVID=MM123456 S: 250 2.1.0 Originator <jean@example.com> ok C: RCPT TO:<ifax@example.net> NOTIFY=SUCCESS,FAILURE \ ORCPT=rfc822;ifax@example.net S: 250 2.1.5 Recipient <ifax@example.net> ok C: DATA S: 354 Send message, ending in <CRLF>.<CRLF> C: C: [Message goes here.] C: C: . S: 554 5.6.1 Media not supported C: QUIT S: 221 2.0.0 Goodbye
S：220 example.net SMTPサービス準備C：EHLO example.org S：250-example.net S：250-DSN S：250 ENHANCEDSTATUSCODES C <jean@example.com> RET = HDRS ENVID = MM123456 S：FROM MAIL ：250 2.1.0発信<jean@example.com> OK C：RCPT TO：<ifax@example.net> = SUCCESSをNOTIFY、FAILURE \ ORCPT = RFC822; ifax@example.net S：250 2.1.5受信者<IFAX @ example.net> OK C：DATA S：<CRLF>で終わる354送信メッセージ、<CRLF> C：C：[メッセージがここに入ります。] C：C：。 S：554枚の5.6.1メディアがサポートされていませんC：SをQUIT：221 2.0.0さようなら
DSN:
DSN：
Note: In this case, the previous MTA generates the DSN that is forwarded to the original sender. The receiving MTA has not accepted delivery and therefore can not generate a DSN.
注：この場合には、前回のMTAは、元の送信者に転送されるDSNを生成します。受信MTAは、DSNを生成することができない、したがって送達を受け入れていません。
NOTE: This document does not define new disposition-types or
disposition-modifiers. Those used below are defined in RFC
2298[9]. This section provides examples on how POP3/IMAP4 devices
may use the already defined values.
These examples are provided as illustration only. They should not be interpreted as limiting the protocol or the MDN form. If the examples conflict with the MDN [9] standard, the standard takes precedence.
これらの実施例は単に例示として提供されます。これらは、プロトコルまたはMDN形態を限定するものとして解釈されるべきではありません。 MDN [9]規格例競合した場合、標準が優先されます。
If the original sender receives an MDN which has "displayed", "dispatched" or "processed" disposition-type without disposition-modifier, the receiver may have received or decoded the attached file that it sent. The MDN does not guarantee that the receiver displays, prints or saves the attached file. See Section 4.4.1.1, Discrepancies in MDN Interpretation.
元の送信者が配置-修飾語なしで、「派遣」または「処理」気質型「表示」したMDNを受信した場合、受信機は、受信されたか、送信された添付ファイルを復号化していることができます。 MDNは、受信者が表示し、プリントや添付ファイルを保存していることを保証するものではありません。セクション4.4.1.1、MDNの解釈で不一致を参照してください。
NOTE: This example does not include the third component of the MDN.
注：この例では、MDNの第三成分が含まれていません。
Date: 14 Dec 1999 17:48:44 +0900 From: ken_recipient@example.com Message-ID: <19991214174844.98765@example.com> Subject: Your message was processed successfully. (MDN) To: mary@example.net Mime-Version: 1.0 Content-Type: multipart/report; report-type=disposition-notification; boundary="61FD1001_IFAX"
日付：1999年12月14日午後05時48分44秒0900投稿者：ken_recipient@example.comメッセージ-ID：<19991214174844.98765@example.com>件名：あなたのメッセージが正常に処理されました。 （MDN）へ：mary@example.netマイム・バージョン：1.0のContent-Type：マルチパート/レポート。 =処分通知型を報告。境界= "61FD1001_IFAX"
--61FD1001_IFAX Content-Type: text/plain
--61FD1001_IFAXのContent-Type：text / plainの
This is a Return Receipt for the mail that you sent to "ken_recipient@example.com". The message and attached files may have been printed, faxed or saved. This is no guarantee that the message has been read or understood.
これは、あなたが「ken_recipient@example.com」に送信されたメールの戻り領収書です。メッセージと添付ファイルは、印刷されたファックスまたは保存されている可能性があります。これは、メッセージが読まか理解されていることを保証するものではありません。
--61FD1001_IFAX Content-Type: message/disposition-notification
--61FD1001_IFAXのContent-Type：気質メッセージ/通知
Reporting-UA: ken-ifax.example.com; barmail 1999.10 Original-Recipient: rfc822;ken_recipient@example.com Final-Recipient: rfc822;ken_recipient@example.com Original-Message-ID: <19991214174010O.mary@example.net> Disposition: automatic-action/MDN-sent-automatically; dispatched
報告-UA：ken-ifax.example.com。 1999.10 barmailオリジナル・受信者：RFC822; ken_recipient@example.com最終受信者：RFC822; ken_recipient@example.comオリジナル・メッセージ-ID：<19991214174010O.mary@example.net>処分：自動アクション/ MDN-送られ、自動的に;派遣
--61FD1001_IFAX--
--61FD1001_IFAX--
If the original sender receives an MDN with an "error" or "warning" disposition-modifier, it is possible that the receiver could not receive or decode the attached file. Currently there is no mechanism to associate the disposition-type with the handling of the main content body of the message or the attached file.
元の送信者が「エラー」または「警告」処分改質剤でMDNを受信した場合には、受信機が受信または添付ファイルをデコードできなかった可能性があります。現在、メッセージや添付ファイルの主なコンテンツ本体の取り扱いと処分型を関連付けるメカニズムはありません。
Date: 14 Dec 1999 19:48:44 +0900 From: ken_recipient@example.com Message-ID: <19991214194844.67325@example.com> Subject: Your message has been rejected. (MDN) To: mary@example.net Mime-Version: 1.0 Content-Type: multipart/report; report-type=disposition-notification; boundary="84FD1011_IFAX"
日付：1999年12月14日午前19時48分44秒0900投稿者：ken_recipient@example.comメッセージ-ID：<19991214194844.67325@example.com>件名：あなたのメッセージが拒否されました。 （MDN）へ：mary@example.netマイム・バージョン：1.0のContent-Type：マルチパート/レポート。 =処分通知型を報告。境界= "84FD1011_IFAX"
--84FD1011_IFAX Content-Type: text/plain
--84FD1011_IFAXのContent-Type：text / plainの
This is a Return Receipt for the mail that you sent to "ken_recipient@example.com". An error occurred while attempting to decode the attached file[s]".
これは、あなたが「ken_recipient@example.com」に送信されたメールの戻り領収書です。 [S]」の添付ファイルをデコードしようとしたときにエラーが発生しました。
--84FD1011_IFAX Content-Type: message/disposition-notification
--84FD1011_IFAXのContent-Type：気質メッセージ/通知
Reporting-UA: ken-ifax.example.com; barmail 1999.10 Original-Recipient: rfc822;ken_recipient@example.com Final-Recipient: rfc822;ken_recipient@example.com Original-Message-ID: <199912141823123.mary@example.net> Disposition: automatic-action/MDN-sent-automatically; processed/error
報告-UA：ken-ifax.example.com。 1999.10 barmailオリジナル・受信者：RFC822; ken_recipient@example.com最終受信者：RFC822; ken_recipient@example.comオリジナル・メッセージ-ID：<199912141823123.mary@example.net>処分：自動アクション/ MDN-送られ、自動的に;処理された/エラー
--84FD1011_IFAX Content-Type: message/rfc822
--84FD1011_IFAXのContent-Type：メッセージ/ RFC822
[original message goes here]
[元のメッセージがここに入り]
--84FD1011_IFAX--
--84FD1011_IFAX--
A received email message could contain multiple attachments and each distinct attachment could use TIFF or TIFF-FX with different encodings or resolutions, and these could be mixed with other file types.
受信した電子メールメッセージは、複数の添付ファイルを含めることができ、それぞれ異なるアタッチメントは異なるエンコーディングまたは解像度のTIFFまたはTIFF-FXを使用することができ、これらは、他のファイルタイプと混合することができます。
There is currently no mechanism to identify, in a returned MDN, the attachments that were successfully decoded from those that could not be decoded.
、返されるMDNで、正常に復号化することができなかったものからデコードされた添付ファイルを識別するためのメカニズムは現在ありません。
If the Extended Mode recipient is unable to decode any of the attached files, it is recommended that the Extended Mode recipient return a decoding error for the entire message.
拡張モードの受信者が添付ファイルのいずれかをデコードすることができない場合は、拡張モードの受信者がメッセージ全体の復号エラーを返すことをお勧めします。
a) An IFD is required, by TIFF 6.0, to begin on a word boundary, however, there is ambiguity with regard to the defined size of a word. A word should be interpreted as a 2-byte quantity. This recommendation is based on examination of Figure 1 and the definition of IFD Entry, Bytes 8-11, found in Section 2 of TIFF 6.0.
A）IFDはワード境界で開始するために、TIFF 6.0により、必要とされる、しかし、言葉の定義されたサイズに関してあいまいさがあります。ワードは、2バイトの量として解釈されるべきです。この勧告は、図1の検査やTIFF 6.0の第2節で見IFDエントリ、バイト8-11の定義に基づいています。
b) Low memory devices, which support resolutions greater than the required Profile-S, may be memory-constrained, such that those devices cannot properly handle arbitrary placement of TIFF IFDs within a TIFF file.
B）必要なプロファイル-Sよりも大きい解像度をサポート低メモリデバイスは、メモリ制約、それらのデバイスが正しくTIFFファイル内のTIFFのIFDの任意の配置を扱うことができないようにしてもよいです。
To interoperate with a receiver that is constrained, it is strongly recommended that senders always place the IFD at the beginning of the image file when using any of the Profiles defined in [4].
制約されている受信機と相互運用するために、強く、[4]で定義されたプロファイルのいずれかを使用する場合、送信者は、常に、画像ファイルの先頭にIFDを置くことをお勧めします。
The TIFF/RFC 2301 [4] errors listed below were encountered during interoperability testing and are provided so that implementers of TIFF readers and writers can take precautionary measures.
TIFF / RFC 2301 [4]下記に記載されたエラーは、相互運用性のテスト中に遭遇したとTIFFのリーダーやライターの実装は、予防措置をとることができるように提供されています。
a) Although Profile S of TIFF [4] specifies that files should be in little-endian order, during testing it was found that some common TIFF writers create big-endian files. If possible, the TIFF reader should be coded to handle big-endian files. TIFF writers should always create little-endian files to be compliant with the standard and to allow interoperation with memory-constrained devices.
A）TIFFのプロファイルSは、[4]のファイルは、それがいくつかの一般的なTIFFライターはビッグエンディアンのファイルを作成することが判明したテスト中、リトルエンディアンの順序でなければならないことを指定しますが。可能であれば、TIFFリーダは、ビッグエンディアンのファイルを処理するためにコード化されなければなりません。 TIFFの作家は常に標準に準拠すると、メモリに制約のあるデバイスとの相互運用を可能にするために、リトルエンディアンのファイルを作成する必要があります。
b) Bytes 0-1 of the Image File Header are supposed to be set to "II" (4949h) or "MM" (4d4dh) to indicate the byte order. During testing, other values were encountered. Readers should handle cases where the byte order field contains values other than "II" or "MM", and writers should ensure the correct value is used.
b）のイメージファイルヘッダの0-1バイトは、バイト順序を示すために、「II」（4949h）または「MM」（4d4dh）に設定されることになっています。試験中に、他の値が検出されました。読者は、バイトオーダーフィールドは「II」または「MM」以外の値、および作家は正しい値が使用されていることを確認する必要があります含まれているケースを処理する必要があります。
The ITULAB encoding (PhotometricInterpretation = 10) allows choosing a gamut range for L*a*b* (see the TIFF field Decode), which in turn provides a way to place finer granularity on the integer values represented in this colorspace. But consequently, an inadequate gamut choice may cause a loss in the preservation of colors that don't fall within the space of colors bounded by the gamut. As such, it is worth commenting on this.
ITULABエンコード（PhotometricInterpretation = 10）は、今度は、この色空間で表された整数値に細かい粒度を配置する方法を提供するL * a * b *表（TIFFフィールドのデコードを参照）用の色域範囲を選択することができます。しかし、その結果、不十分な色域の選択は、色域に囲まれた色のスペースに入らない色の保全の損失が発生することがあります。このように、それはこの上でコメントする価値があります。
The ITULAB default gamut, L [0,100] a [-85,85] b [-75,125], was chosen to accommodate most scan devices, which are typically acquired from a hardcopy source. It wasn't chosen to deal with the range of color from camera input or sRGB monitor data. In fact, when dealing with images from the web and other display oriented sources, the color range for a scanned hardcopy may likely be inadequate. It is important to use a gamut that matches the source of the image data.
ITULABデフォルト域、L [0100] [-85,85] B [-75125]、一般的にハードコピーのソースから取得される最もスキャン装置を収容するために選択しました。これは、カメラ入力またはsRGBの監視データから色の範囲に対応するように選択されませんでした。ウェブおよび他のディスプレイ指向のソースからの画像を扱う場合、実際には、スキャンしたハードコピーのための色範囲はおそらく不十分であってもよいです。なお、画像データのソースと一致した色域を使用することが重要です。
The following guidelines are recommended:
次のガイドラインを推奨します。
1. When acquiring input from a printed hardcopy source, without modification, the ITU-T Recommendation T.42 default ITULAB gamut should be appropriate.
1.印刷ハードコピーのソースからの入力を取得すると、変更することなく、ITU-T勧告T.42のデフォルトITULAB域が適切でなければなりません。
2. For an sRGB source, the ITU-T Recommendation T.42 default ITULAB gamut is not appropriate. A more appropriate gamut to consider is: L [0,100], a [-88,99] and b [-108.8,95.2]. These may be realized by using the following Decode values for 8-bit data: (0/1, 100/1, -22440/255, 25245/255, -27744/255, 24276/255).
sRGBのソースの場合、ITU-T勧告T.42のデフォルトITULAB域が適切でない2。考慮すべきより適切な色域は：L [0100]、[-88,99]とB [-108.8,95.2]。 （0/1、100/1、-22440/255、255分の25245、-27744/255、255分の24276）：これは8ビットのデータについては、次のデコード値を用いて実現されてもよいです。
3. If the range of L*a*b* value can be precomputed efficiently before converting to ITULAB, then you may get the best result by picking a gamut that is custom to this range.
Lの範囲* a * b *値がITULABに変換する前に、効率的に事前に計算することができた場合は3、あなたはこの範囲にカスタムで色域を選ぶことにより、最良の結果を得ることができます。
Implementers should make sure of the contents in the following two sections.
実装者は、次の2つのセクションの内容を確認してください。
a) Readers are able to handle cases where IFD offsets point beyond the end of the file, while writers ensure that the IFD offset does not point beyond the end of the file.
作家は、IFDがファイルの終わりを超えて指していないことを確実にオフセットしながら、a）の読者は、IFDオフセットは、ファイルの終わりを超えて指すケースを処理することができます。
b) Readers are able to handle the first IFD offset being on a non-word boundary, while writers ensure that the first IFD offset is on a word boundary.
b）は、読者は最初のIFDを処理することができるライターオフセット最初のIFDは、ワード境界上にあることを確認しながら、非ワード境界上にあるオフセット。
c) Readers are flexible and able to accommodate: IFDs that are not presented in ascending page order; IFDs that are not placed at a location that precedes the image which the IFD describes; next IFD offsets that precede the current IFD, the current IFDs' field data, or the current IFDs' image data. Writers on the other hand should generate files with IFDs presented in ascending page order; IFDs placed at a location that precedes the image which the IFD describes; the next IFD should always follow the current IFD and all of its data.
C）読者は、柔軟で適応することができる：昇順ページ順に提示されていないのIFD。 IFDが記述する画像に先行する位置に配置されていないのIFD。現在のIFD、現在のIFDフィールドデータ、または現在のIFD画像データの前に次のIFDオフセット。一方、作家は昇順ページ順に提示のIFDを持つファイルを生成する必要があります。 IFDが記述する画像に先行する位置に配置さのIFD。次のIFDは常に現在のIFDとそのデータのすべてに従ってください。
d) Writers generate tags with the appropriate type of data (for example RATIONAL instead of SRATIONAL). Readers are flexible with those types of misrepresentations that may be readily accommodated (for example SHORT instead of LONG) and lead to enhanced robustness.
D）作家は（）の代わりにSRATIONALの合理的な、例えば、データの適切なタイプのタグを生成します。読者は、（代わりにLONGの例略して）容易に収容することができる不実表示のこれらのタイプを有する柔軟であり、拡張堅牢性をもたらします。
e) The appropriate count is associated with the tags (it is not 0 and matches the tag requirement), while readers are flexible with these types of misrepresentations, which may be readily accommodated and lead to enhanced robustness.
読者は容易に収容向上堅牢に導くことができる不実表示、これらのタイプのフレキシブルでありながらE）適切なカウントは、（それが0でなく、タグの要件に一致する）タグに関連付けられています。
f) Tags appear in the correct order in the IFD and readers are flexible with these types of misrepresentations.
F）タグIFDに正しい順序で表示され、読者は虚偽のこれらのタイプの可撓性です。
a) Readers only accept files with bytes 2-3 of the Image File Header equal to 42 (2Ah), the "magic number", as being valid TIFF or TIFF-FX files, while writers only generate files with the appropriate magic number.
作家が唯一の適切なマジックナンバーを持つファイルを生成しながら、a）の読者は唯一、有効なTIFFまたはTIFF-FXファイルとして42に等しいイメージファイルヘッダ（2AH）、「マジックナンバー」、のバイト2-3でファイルを受け入れます。
b) Files are not generated with missing field entries, and readers reject any such files.
B）ファイルが欠落しているフィールドエントリを生成し、そして読者はどのようなファイルを拒否されていません。
c) The PageNumber value is based on the order within the Primary IFD chain. The ImageLayer values are based on the layer order and the image order within the layer respectively. Readers may reject the pages where the PageNumber or ImageLayer values are not consistent with the number of Primary IFDs, number of layers or number of images within the layers.
C）ページ番号の値は、プライマリIFDチェーン内の順序に基づいています。 ImageLayer値は層の順序及びそれぞれの層内の画像の順序に基づいています。読者は、ページ番号または値にImageLayerプライマリのIFDの数、層または層内の画像の数の数と一致していないページを拒否することができます。
d) Tags are unique within an IFD and readers may reject pages where this is not the case.
D）タグはIFD内で一意であり、読者はこれがそうでないページを拒否することができます。
e) Strip data does not overlap other file data and the reader may error appropriately.
E）ストリップデータが他のファイルのデータを重複しないと読者は、適宜エラーできます。
f) The strip offset does not point outside the file, under these conditions readers may reject the page where this is the case.
F）オフセットストリップは、これらの条件下で、読者は、このような場合は、ページを拒否することができる、ファイルの外側に指しません。
g) The strip offset + StripByteCounts does not point outside the file, under these conditions the reader may error appropriately.
G）+ StripByteCountsオフセットストリップは、これらの条件下で、リーダは、適宜エラーできる、ファイルの外側に指しません。
h) Only one endian order is used within the file otherwise the rendered file will be corrupted.
H）つのみエンディアン順序は、そうでなければレンダリングファイルが破損されるファイル内で使用されています。
i) Tag values are consistent with the data contained within the image strip. For example, a bi-level black mark on a white background image strip with a PhotometricInterpretation tag value of "1" (bit value of "0" means black) will result in the rendering of the image as white marks on a black background (reverse video).
ⅰ）タグの値は、画像ストリップに含まれるデータと一致しています。例えば、「1」のPhotometricInterpretationで値が白背景画像ストリップ上のバイレベルブラックマーク（黒い背景に白いマーク等の画像のレンダリングをもたらすであろう（「0」のビット値が黒を意味します）反転表示）。
j) For the special color spaces (ITULAB, YCBCR, CMYK), the parameters used for transformations are correct and compliant with the specification.
j）は、特別な色空間（ITULAB、YCBCR、CMYK）の場合、変換に使用されるパラメータが正しいと仕様に準拠しています。
k) The XPosition and YPosition values are consistent with the horizontal and vertical offsets of the top-left of the IFD from the top-left of the Primary IFD, in units of the resolution. To do otherwise results in misplacement of the rendered image.
K）XPositionとYPosition値は、解像度の単位で、左上プライマリIFDのからIFDの左上の水平および垂直オフセットと一致しています。レンダリングされた画像の配置ミスでそれ以外の結果をすることができません。
l) All combinations of tag values are correct, with special attention being given to the sets: XResolution, YResolution and ImageWidth; PhotometricInterpretation, SamplesPerPixel, and BitsPerSample. Any appropriate combinations will likely result in image distortion or an inability to render the image.
L）タグ値の全ての組み合わせは、特別な注意がセットに与えられると、正しい：XResolution、YResolutionおよびImageWidth。 PhotometricInterpretation、SamplesPerPixel、とは、bitsPerSample。任意の適切な組み合わせは、おそらく画像の歪みや画像をレンダリングすることができないことになります。
m) The appropriate Compression types are used for the image layers within a Profile M file, such as a bi-level coder for the mask layers (i.e. odd numbered layers) and multi-level (color) coders for the background and foreground layers. Readers should reject files where this is not true.
M）適切な圧縮タイプは、背景と前景層のマスク層のためのバイレベルコーダ（すなわち、奇数層）とマルチレベル（色）コーダなどのプロファイルMファイル内の画像層に使用されます。読者は、これは真実ではないファイルを拒絶する必要があります。
The content-type "image/tiff" should only be used for Profiles S and F. Some existing implementations based on [4] may use "image/tiff" for other Profiles. However, this usage is now deprecated. Instead, the content-type "image/tiff-fx", whose registration is being defined in [17] should be used.
コンテンツタイプ「画像/ TIFF」は、プロファイルSおよびF [4]他のプロファイルは、「画像/ TIFF」を使用することができるに基づいて、いくつかの既存の実装のためにのみ使用されるべきです。しかし、この使用法は廃止されます。代わりに、その登録[17]で定義されているコンテンツ・タイプ「画像/ TIFF-FX」は、使用されるべきです。
To maximize interworking with devices that are only capable of rendering Profile S or F, "image/tiff" SHOULD be used when transporting Profile S or F.
プロファイルSまたはFを輸送する際のプロファイルSまたはFをレンダリングすることしかできないデバイスとのインターワーキングを最大化するために、「画像/ TIFF」に使用されるべきである（SHOULD）
The "+" and "=" characters are valid within message headers, but must be encoded within some ESMTP commands, most notably ORCPT [5]. Implementations must take special care that ORCPT (and other ESMTP values) are properly encoded.
「+」と「=」の文字が[5]メッセージヘッダ内で有効ですが、いくつかのESMTPコマンド内で符号化されなければならない、最も顕著なのORCPT。実装はORCPT（および他のESMTP値）が適切にエンコードされている特別な注意を払う必要があります。
For example, the following header is valid as-is:
たとえば、次のヘッダーはそのまま有効です。
To: Home Fax <FAX=+390408565@example.com>
To：ホームファックス<FAX=+390408565@example.com>
but when used with ORCPT, the "=" and "+" must be encoded like this:
ORCPTで使用するときには、「=」と「+」次のようにエンコードする必要があります。
RCPT TO:<FAX=+390408565@example.com> \ ORCPT=FAX+3D+2B390408565@example.com
RCPT TO：<FAX=+390408565@example.com> \ ORCPT=FAX+3D+2B390408565@example.com
Note the "=" and "+" are valid inside the forward-path, but must be encoded when used within the esmtp value.
「=」との注意「+」は、フォワードパス内の有効であるが、ESMTP値内で使用される場合、符号化されなければなりません。
See [5] for details on this encoding.
このエンコーディングの詳細については、[5]を参照してください。
With regards to this document, Sections 5 in RFC 2305 [2] and Section 4 in RFC 2532 [3] apply.
この文書に関して、RFC 2305におけるセクション5 [2]及びRFC 2532でセクション4 [3]適用します。
The authors gratefully acknowledge the following persons who contributed or made comments on earlier versions of this memo: Claudio Allocchio, Richard Coles, Ryuji Iwazaki, Graham Klyne, James Rafferty, Kensuke Yamada, Jutta Degener and Lloyd McIntyre.
クラウディオAllocchio、リチャード・コールズ、竜二Iwazaki、グラハムKlyne、ジェームズ・ラファティ、健介山田、ユッタ・デッジナーとロイド・マッキンタイア：作者は感謝してこのメモの以前のバージョンにコメントを貢献したか、作られた、次の者を認めます。
[1] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999.
[1] Masinter、L.、 "用語およびインターネットファックスの目標"、RFC 2542、1999年3月を。
[2] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 3205, March 1998.
[2]豊田、K.、大野、H.、村井、J.およびD.翼、 "インターネットメールを使用するファクシミリのシンプルモード"、RFC 3205、1998年3月。
[3] Masinter, L. and D. Wing, "Extended Facsimile Using Internet Mail", RFC 2532, March 1999.
[3] Masinter、L.とD.ウィング、 "インターネットメールを使用して、拡張ファクシミリ"、RFC 2532、1999年3月。
[4] McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G. and J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998.
[4]マッキンタイア、L.、Zilles、S.、バックリー、R.、VENABLE、D.、パーソンズ、G.とJ.・ラファティ、 "インターネットファックスのためのファイル形式"、RFC 2301、1998年3月。
[5] Moore, K., "SMTP Service Extension for Delivery Status Notification", RFC 1891, January 1996.
[5]ムーア、K.、 "配信状態通知のためのSMTPサービス拡張子"、RFC 1891、1996年1月。
[6] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[6]ヴォードルイユ、G.、 "強化されたメールシステムステータスコード"、RFC 1893、1996年1月。
[7] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.
[7]ムーア、K.とG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、RFC 1894、1996年1月。
[8] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[8]、N.、RFC 2034、1996年10月 "SMTPサービス拡張は、強化されたエラーコードを返すために、" 解放されました。
[9] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[9] Fajman、R.、RFC 2298、1998年3月の "メッセージ処分通知のための広げることができるメッセージフォーマット"。
[10] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[10]クロッカー、D.、 "ARPAインターネットテキストメッセージの形式の規格"、STD 11、RFC 822、1982年8月。
[11] Postel, J., "A Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[11]ポステル、J.、 "簡易メール転送プロトコル"、STD 10、RFC 821、1982年8月。
[12] Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001.
[12] Allocchio、C.、 "インターネットメールにおける最小GSTNアドレス形式"、RFC 3191、2001年10月。
[13] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.
[13] Allocchio、C.、 "インターネットメールにおける最小のFAXアドレス形式"、RFC 3192、2001年10月。
[14] Allocchio, C., "GSTN Address Element Extensions in E-mail Services", RFC 2846, June 2000
[14] Allocchio、C.、 "GSTNアドレスEメールサービスの要素拡張機能"、RFC 2846、2000年6月
[15] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, D., "SMTP Service Extensions", RFC 2846, November 1995
[15] Klensin、J.、フリード、N.、ローズ、M.、Stefferud、E.およびD.クロッカー、D.、 "SMTPサービス拡張"、RFC 2846、1995年11月
[16] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996
[16]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月
[17] McIntyre, L., Parsons, G. and J. Rafferty, "Tag Image File Format Fax eXtended (TIFF-FX) - image/tiff-fx MIME Sub-type Registration", RFC 3250, September 2002.
[17]マッキンタイア、L.、パーソンズ、G.とJ.ラファティーは、 "タグイメージファイル形式のFAX番号は（TIFF-FX）拡張 - 画像/ TIFF-FX MIMEサブタイプ登録"、RFC 3250、2002年9月。
[18] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[18] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[19] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[19]レズニック、P.、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
Vivian Cancio 103 Cuesta Drive Los Altos, CA 94022
ビビアンCancio 103クエスタドライブロスアルトス、CA 94022
Phone: +1-650-948-3135 EMail: vcancio@pacbell.net
電話：+ 1-650-948-3135 Eメール：vcancio@pacbell.net
Mike Moldovan G3 Nova Technology Inc. 5743 Corsa Avenue, Suite 122 Westlake Village, CA 91362
マイクモルドバG3ノバ・テクノロジー株式会社5743コルサアベニュー、スイート122ウェストレイク・ビレッジ、CA 91362
Phone: (818) 865-6600 Ext.113 EMail: mmoldovan@g3nova.com
電話：（818）865-6600 Ext.113 Eメール：mmoldovan@g3nova.com
Hiroshi Tamura Ricoh Company, LTD. 1-3-6 Nakamagome, Ohta-ku Tokyo 143-8555 Japan
ひろし たむら りこｈ こｍぱｎｙ、 ＬＴＤ。 １ー３ー６ なかまごめ、 おｈたーく ときょ １４３ー８５５５ じゃぱん
Phone: +81-3-3777-8124 Fax: +81-3-5742-8859 EMail: tamura@toda.ricoh.co.jp
電話：+ 81-3-3777-8124ファックス：+ 81-3-5742-8859 Eメール：tamura@toda.ricoh.co.jp
Dan Wing Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134-1706 USA
ダン・ウィングシスコシステムズ社170 W.タスマン・ドライブサンノゼ、CA 95134-1706 USA
Phone: +1-408-525-5314 Fax: +1-408-527-8083 EMail: dwing@cisco.com
電話：+ 1-408-525-5314ファックス：+ 1-408-527-8083 Eメール：dwing@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。