[要約] RFC 3249は、インターネットメールを使用したファクシミリの実装ガイドです。その目的は、ファクシミリの送受信をインターネットメールプロトコルに統合するための指針を提供することです。
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.
Copyright（c）The Internet Society（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.
このドキュメントでは、インターネットメールを使用してファクシミリ通信を標準化する公開されたRFCSを明確にします。意図は、相互運用性の問題を引き起こすような方法で逸脱する実装を防ぐことです。
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.
このドキュメントには、単純なモードFAXメッセージの処理、拡張モードFAXメッセージ、ファイル形式、FAX受信者のインターネットアドレス指定を順番に明確にする4つのセクションが含まれています。
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
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/
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"
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コンテンツタイプの「MultiPart/Alternative」を使用してメッセージを正しく処理できません。受信者がコンテンツタイプの「マルチパート/代替」でメッセージを正しく処理できるかどうかが送信者が不明な場合、送信者は最悪の事態を想定し、このMIMEコンテンツタイプを使用しないでください。
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.
最初のメッセージが送信された後、RFC 2532 [3]のセクション3.3で説明されている拡張モードメカニズムにより、受信者は配信および/または処分通知にその機能を含めることができます。RFC 2532/ESMTP [3]受信者がユーザーエージェントである場合、MDNに準拠したサーバーまたは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] FAXを以下に説明します。拡張モードデバイスは、単純なモードに固有の問題を考慮する必要があることに注意してください（このドキュメントのセクション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-toヘッダーを含むメッセージには、メッセージIDヘッダーも含める必要があります。これにより、ユーザーエージェントによる元のメッセージとMDNの自動相関が可能になります。
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も相関する必要があります。これは、「メール」コマンドのenvidパラメーターを使用して行うのが最適です。詳細については、RFC 1891 [5]のセクション3および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:
「気質 - 解釈」ヘッダーでメッセージが受信され、レシーバーがメッセージを処理できるかどうかを判断すると、次のことが生成される可能性があります。
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]が、メッセージの身体コンテンツ部分を解読しないことと、ファイルの添付ファイルのデコードの成功または失敗を区別しないことに注意する必要があります。その結果、添付ファイルのデコードの成功または失敗を反映するのではなく、メッセージの身体含有部分をデコードすることを反映したMDNを受信する場合があります。
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リクエストの受信者が、受信したインターネットメールメッセージと添付ファイルを自動的に印刷するRFC 2532準拠デバイスである場合、またはGSTN Faxを介して添付ファイルを転送する場合、成功の場合は次のようにする必要があります。
a) Use a "disposition-type" of "dispatched" (with no "disposition-modifier") in the MDN, and
a) MDNで「派遣された」（「処分モジー」なし」の「処分型」を使用し、
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".
「これは、[上または下の、またはこのアドレスなど]に送信したメールの返品領収書です。メッセージと添付ファイルが印刷、ファックス、または保存されている可能性があります。これはメッセージがメッセージを保証するものではありません。読まれたり理解されたりしました」。
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.
この推奨事項は、RFC 2298 [9]の定義に準拠しており、適切な取り扱いのために返されたMDNを区別するのに役立ちます。
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のテキスト部分にMultiPart/Alternativeを使用して、送信者の言語でメッセージを送信するか（元のメッセージからヘッダーフィールドを使用することにより）、複数の言語を含めることを検討することをお勧めします。
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サーバーであり、レシーバーがメッセージを正常に解読することにメッセージを受信者に送信します。
example.com
+-------+
| Mail |
| User |
| Agent |
+-------+
|
V
+----------+ +--------+ +---------+
| Mail + | Mail | | Mail |
|Submission|----->|Transfer|---->|Transfer |
| Agent | | Agent | | Agent |
+----------+ +--------+ +---------+
example.org example.net
example.org emple.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
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
--JUK199912121854870001 Content-type: text/plain
-juk199912121854870001 Content-Type：Text/Plain
Your message (id MM123456) was successfully delivered to ifax@example.net.
メッセージ（ID MM123456）は、ifax@example.netに正常に配信されました。
--JUK199912121854870001
Content-type: message/delivery-status
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
--JUK199912121854870001 Content-type: message/rfc822
-juk199912121854870001 content-type：message/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
--JUK199912121934240002 Content-type: text/plain
-juk199912121934240002 Content-Type：Text/Plain
Your message (id MM123456) to ifax@example.net resulted in an error while attempting to decode the attached file.
メッセージ（IDMM123456）へのメッセージ@example.netへの添付ファイルのデコードを試みながら、エラーが発生しました。
--JUK199912121934240002 Content-type: message/delivery-status
-juk199912121934240002 Content-Type：メッセージ/配信ステータス
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
--JUK199912121934240002 Content-type: message/rfc822
-juk199912121934240002 Content-Type：Message/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
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.
注：このドキュメントでは、新しい気質型または処分モジー因子を定義しません。以下で使用されるものは、RFC 2298 [9]で定義されています。このセクションでは、POP3/IMAP4デバイスが既に定義されている値をどのように使用するかについての例を示します。
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の3番目のコンポーネントは含まれていません。
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"
--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
--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"
--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
--84FD1011_IFAX Content-Type: message/rfc822
-84FD1011_IFAXコンテンツタイプ：メッセージ/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) ただし、TIFF 6.0によってIFDが必要です。ただし、単語の境界で開始するには、定義された単語のサイズに関しては曖昧さがあります。単語は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 [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エンコーディング（Photometricterpretation = 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 [0,100] a [-85,85] b [-75,125]は、通常、ハードコピーソースから取得されるほとんどのスキャンデバイスに対応するために選択されました。カメラ入力またはSRGBモニターデータからの色の範囲を扱うために選択されていませんでした。実際、Webやその他のディスプレイ指向のソースからの画像を扱う場合、スキャンされたハードコピーの色の範囲は不十分な場合があります。画像データのソースに一致する範囲を使用することが重要です。
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 gumutが適切なはずです。
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).
2. SRGBソースの場合、ITU-Tの推奨T.42デフォルトのitulab gumutは適切ではありません。考慮すべきより適切な範囲は、L [0,100]、A [-88,99]、およびB [-108.8,95.2]です。これらは、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.
3. itulabに変換する前にl*a*b*値の範囲を効率的に事前に計算できる場合、この範囲に合わせてカスタムである範囲を選択することで最良の結果を得ることができます。
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.
a) 読者は、IFDオフセットがファイルの終わりを超えて指されるケースを処理することができますが、ライターは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、現在のIFDSのフィールドデータ、または現在のIFDSの画像データに先行するオフセットです。一方、ライターは、昇順のページ順序でIFDSが提示されたファイルを生成する必要があります。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) ライターは、適切なタイプのデータを使用してタグを生成します（たとえば、合理的ではなく合理的）。読者は、これらのタイプの不実表示に柔軟に対応し、容易に収容される可能性があり（たとえば長いではなく短い）、堅牢性の向上につながります。
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) PageNumber値は、プライマリIFDチェーン内の順序に基づいています。イメージライヤーの値は、それぞれレイヤー内のレイヤー順序と画像順序に基づいています。読者は、PageNumberまたは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) ストリップオフセットストリップバイトカウントは、ファイルの外側を指していません。これらの条件下では、読者が適切にエラーを発揮する可能性があります。
h) Only one endian order is used within the file otherwise the rendered file will be corrupted.
h) ファイル内で使用されるEndian注文は1つだけです。そうしないと、レンダリングされたファイルが破損します。
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).
i) タグ値は、画像ストリップ内に含まれるデータと一致しています。 たとえば、「1」の測光解釈タグ値を持つ白い背景画像ストリップ（「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。測光代替、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」は、プロファイルとFにのみ使用する必要があります。ただし、この使用法は廃止されました。代わりに、[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」を使用する必要があります。
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.
「 "および" = "文字はメッセージヘッダー内で有効ですが、一部のESMTPコマンド、特にORCPT [5]内でエンコードする必要があります。実装は、ORCPT（およびその他のESMTP値）が適切にエンコードされていることに特に注意する必要があります。
For example, the following header is valid as-is:
たとえば、次のヘッダーは有効です。
To: Home Fax <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
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 [2]のセクション5およびRFC 2532 [3]のセクション4が適用されます。
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.
著者は、このメモの以前のバージョンについて貢献またはコメントした以下の人に感謝します：クラウディオアロッキオ、リチャードコールズ、リュジ岩崎、グラハムクライネ、ジェームズラファティ、ヤマダ、ジャッタデジェナー、ロイドマッキンティル。
[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] Toyoda、K.、Ohno、H.、Murai、J。、およびD. Wing、「インターネットメールを使用したファクシミリの単純なモード」、RFC 3205、1998年3月。
[3] Masinter, L. and D. Wing, "Extended Facsimile Using Internet Mail", RFC 2532, March 1999.
[3] Masinter、L。およびD. Wing、「インターネットメールを使用した拡張ファクシミリ」、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] McIntyre、L.、Zilles、S.、Buckley、R.、Venable、D.、Parsons、G。and J. Rafferty、「Internet Faxのファイル形式」、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] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 1893、1996年1月。
[7] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.
[7] Moore、K。およびG. Vaudreuil、「配信ステータス通知のための拡張可能なメッセージ形式」、RFC 1894、1996年1月。
[8] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[8] Freed、N。、「強化されたエラーコードを返すためのSMTPサービス拡張」、RFC 2034、1996年10月。
[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] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[11] Postel, J., "A Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[11] Postel、J。、「A Simple Mail Transfer Protocol」、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。、「インターネットメールの最小ファックスアドレス形式」、RFC 3192、2001年10月。
[14] Allocchio, C., "GSTN Address Element Extensions in E-mail Services", RFC 2846, June 2000
[14] Allocchio、C。、「GSTN Address Element Extensions in E-Mail Services」、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.、Freed、N.、Rose、M.、Stefferud、E。およびD. Crocker、D。、「SMTP Service Extensions」、RFC 2846、1995年11月
[16] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996
[16] Freed、N。and 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] McIntyre、L.、Parsons、G。およびJ. Rafferty、「タグイメージファイル形式Fax拡張（TIFF-FX） - Image/Tiff-FX MIMEサブタイプの登録」、RFC 3250、2002年9月。
[18] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[18] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[19] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[19] Resnick、P。、「インターネットメッセージフォーマット」、RFC 2822、2001年4月。
Vivian Cancio 103 Cuesta Drive Los Altos, CA 94022
Vivian Cancio 103 Cuesta Drive Los Altos、CA 94022
Phone: +1-650-948-3135
EMail: vcancio@pacbell.net
Mike Moldovan G3 Nova Technology Inc. 5743 Corsa Avenue, Suite 122 Westlake Village, CA 91362
Mike Moldovan G3 Nova Technology Inc. 5743 Corsa Avenue、Suite 122 Westlake Village、CA 91362
Phone: (818) 865-6600 Ext.113 EMail: mmoldovan@g3nova.com
電話：（818）865-6600 ext.113メール：mmoldovan@g3nova.com
Hiroshi Tamura Ricoh Company, LTD. 1-3-6 Nakamagome, Ohta-ku Tokyo 143-8555 Japan
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
Dan Wing Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134-1706 USA
Dan Wing Cisco Systems、Inc。170 W. Tasman Drive San Jose、CA 95134-1706 USA
Phone: +1-408-525-5314
Fax: +1-408-527-8083
EMail: dwing@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。