RFC3249 日本語訳
3249 Implementers Guide for Facsimile Using Internet Mail. V. Cancio,M. Moldovan, H. Tamura, D. Wing. September 2002. (Format: TXT=40413 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Cancioがコメントのために要求するワーキンググループV.をネットワークでつないでください: 3249年のゼロックス社のカテゴリ: 情報のM.の会社Ltd.D.翼のシスコシステムズMoldovan G3新星技術Inc.H.田村リコー2002年9月
Implementers Guide for Facsimile Using Internet Mail
インターネットメールを使用するファクシミリのためのImplementersガイド
Status of this Memo
この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)インターネット協会(2002)。 All rights reserved。
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.
このドキュメントはRFC2305と2532を使用することでファクシミリに発信するのにメールを使用するソフトウェアのimplementersのために意図します。 これは情報のドキュメントです、そして、ガイドラインは参照をつけられたドキュメントに取って代わりません。
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
1. 序論… 2 1.1 このドキュメントの組織… 2 1.2 このドキュメントの議論… 2 2. 用語… 3 3. 簡単なモードに特定の導入問題… 3 3.1 純真なモードFax Senders… 3 3.1 .1 複合代替手段… 3 3.2 簡単なモードファックス受信機… 4 3.2 .1の複合代替手段と記憶容量… 4 4. 拡張モードに特定の導入問題… 4 4.1 複合代替手段… 4 4.2 オリジナルのメッセージがあるMDNの相関関係… 4 4.3 オリジナルのメッセージがあるDSNの相関関係… 5 4.4 モード受信機を広げています… 5 4.4 .1 Userエージェントからの領収書と処理の確認… 5 4.4 .1 MDN[9]解釈における.1の食い違い… 5
Cancio, et. al. Informational [Page 1] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[1ページ]のRFC3249Implementersガイド
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
4.4.1.2 MDNのメッセージの気質タイプとボディー… 6 4.4 成功と失敗事件におけるMDNとDSNの.2「対象」… 6 4.4 .3 MTAs(または、ESMTPサーバ)であるMode Receiversを広げています… 7 4.4 .3 .1 成功事例… 7 4.4 .3 .2 失敗事例1… 9 4.4 .3 .3 失敗事例2… 10 4.4 .4 POP3/IMAP4であるMode Receiversを広げています… 11 4.4 .4 .1 成功事例… 11 4.4 .4 .2 失敗事例… 12 4.4 .5 複数の付属を受けます… 13 5. ファイル形式に特定の導入問題… 13 5.1 IFDプレースメントとプロフィールS規制… 13 RFC2301[4]のimplementersのための5.2の注意… 14 5.2 相互運用性テストの間に遭遇する.1の誤り… 14 5.2 .2 全域を問題に着色してください… 14 5.2 .3 形式Considerationsをファイルしてください… 15 5.2 .3 より大きい読者の柔軟性のための.1の問題… 15 5.2 .3 .2 誤り問題… 16 ファイル形式のための5.3コンテントタイプ… 17 6. インターネットへの導入問題はファックスでアドレシングを送ります… 17 7. セキュリティ問題… 18 8. 承認… 18 9. 参照… 18 10. 作者のアドレス… 20 11. 完全な著作権宣言文… 21
1. Introduction
1. 序論
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をはっきりさせます。 意図は原因相互運用性問題に関してそのような方法で逸脱する実現を防ぐことです。
1.1 Organization of this document
1.1 このドキュメントの組織
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.
このドキュメントはオーダーでファックス受取人の簡単なモードファックス通信の取り扱い、拡張モードファックス通信、ファイル形式、およびインターネットアドレシングをはっきりさせる4つのセクションを含みます。
See Section 2 for terminology.
用語に関してセクション2を見てください。
1.2 Discussion of this document
1.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:
このドキュメントの議論はインターネットメールConsortium(IMC)によってホスティングされたインターネットファックスメーリングリストで行われるべきです。 以下のことのためにこのドキュメントに関してコメントを送ってください。
ietf-fax@imc.org
ietf-fax@imc.org
Cancio, et. al. Informational [Page 2] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[2ページ]のRFC3249Implementersガイド
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/
2. Terminology
2. 用語
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--RFC1894、「配送状態通知のための広げることができるメッセージ・フォーマット」[7]はRFC Mode--2532を広げました、「インターネットメールを使用する拡張ファクシミリ」[3]MDN--RFC2298、RFC「メッセージ気質通知のための広げることができるメッセージ・フォーマット」[9]の簡単なMode--2305、「インターネットメールを使用するファクシミリの簡単なモード」[2]TIFF--「イメージ/いさかい」TIFF-FXとして渡された「インターネットファックスのためのファイル形式」[4]のプロフィールSかF--他のプロフィールは「いさかいイメージ/fx」として発信しました。
In examples, "C:" is used to indicate lines sent by the client, and "S:" to indicate those sent by the server.
例で「C:」 そして、クライアントによって送られた線を示すのに使用される、「S:」 サーバによって送られたものを示すために。
3. Implementation Issues Specific to Simple Mode
3. 簡単なモードに特定の導入問題
Issues specific to Simple Mode [2] are described below:
Simple Mode[2]に特定の問題は以下で説明されます:
3.1 Simple Mode Fax Senders
3.1 純真なモードFax Senders
3.1.1 Multipart/alternative
3.1.1 複合である、または代替です。
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コンテントタイプで正しくメッセージを処理できません。 送付者が受取人が「複合か代替」のコンテントタイプで正しくメッセージを処理できるかどうか不確かであるなら、送付者は、最悪を仮定して、このMIMEコンテントタイプを使用するべきではありません。
Cancio, et. al. Informational [Page 3] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[3ページ]のRFC3249Implementersガイド
3.2 Simple Mode Fax Receivers
3.2 簡単なモードファックス受信機
3.2.1 Multipart/alternative and Storage Capacity
3.2.1 複合/代替手段と記憶容量
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.
初期のメッセージを送った後に、RFC2532[3]で説明されたExtended Modeメカニズム(セクション3.3)は、受取人が配送、そして/または、気質通知で能力を入れるのを可能にします: 受取人装置が受取人がUserエージェントであるならDSN RFCの2532/ESMTPの[3]対応することのサーバかMDNにあるなら。
4. Implementation Issues Specific to Extended Mode
4. 拡張モードに特定の導入問題
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).
Extended Mode[3]ファックスに特定の問題は以下で説明されます。 また、どんなExtended Mode装置も、問題がSimple Mode(このドキュメントのセクション3)に特定であると考える必要に注意してください。
4.1 Multipart/Alternative
4.1複合/代替手段
Sections 3.1.1 and 3.2.1 are also applicable to this mode.
セクション3.1.1とまた.1も適切である3.2、このモード。
4.2. Correlation of MDN with Original Message
4.2. オリジナルのメッセージがあるMDNの相関関係
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.
aを含むメッセージ、Disposition通知、また、ヘッダーSHOULDはRFC822[10]で指定されるようにMessage-IDヘッダーを含んでいます。 これはユーザエージェントによるオリジナルのメッセージでMDNsの自動修正を可能にするでしょう。
Cancio, et. al. Informational [Page 4] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[4ページ]のRFC3249Implementersガイド
4.3 Correlation of DSN with Original Message
4.3 オリジナルのメッセージがあるDSNの相関関係
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を関連させるという要件と同様であることで、また、上では、DSNsが、関連する必要があります。 これは最も上手に「メール」コマンドにENVIDパラメタを使用し終わっています。 詳細のためのRFC1891[5]のセクション3と5.4を見てください。
4.4 Extended Mode Receivers
4.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.
ファクシミリが像を描く確認(付属)は渡されて、首尾よく処理されているのが、インターネット・メールを使用するファクシミリの拡張モードの重要な一面であるということでした。 このセクションはいくつかのタイプの確認で導入問題について説明します。
4.4.1 Confirmation of receipt and processing from User Agents
4.4.1 Userエージェントからの領収書と処理の確認
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を発生させるかもしれないと決心していました:
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.
Extended Mode受取人から要求されたMDN承認を受ける目的は成功か送られたファイル付属を処理しないことのしるしです。 ボディーではなく、付属がファクシミリメッセージを構成します。 したがって、Extended Mode送付者は予想するでしょう、そして、Extended Mode受信機が発信するのは(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.
Extended Mode[3]のImplementersはエラーコード、そして/または、失敗/成功メッセージの形で送付者に提供されたフィードバックで一貫しているべきです。
4.4.1.1 Discrepancies in MDN [9] Interpretation
4.4.1.1 MDN[9]解釈における食い違い
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.
Extended Mode送付者はRFC2298[9]が成功、メッセージと成功のボディー内容部分を解読しないことまたはファイル付属を解読しないことを見分けないのを意識しているに違いありません。 その結果添付ファイルを解読するために成否を反映するのではなく、むしろメッセージのボディー内容部分を解読するために反映するMDNsを受け取るかもしれません。
Cancio, et. al. Informational [Page 5] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[5ページ]のRFC3249Implementersガイド
4.4.1.2 Disposition-Type and body of message in MDN
4.4.1.2 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要求の受信機が自動的に受信されたインターネットメール・メッセージと付属を印刷するか、またはGSTNファックスで付属を進めるRFC2532対応することの装置であるなら、成功の場合では、装置です:
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".
「これはあなたが[上、下、またはこのアドレスなど]に送ったメールのためのReturn Receiptです。」 メッセージと添付ファイル[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]".
「これはあなたが[上、下、またはこのアドレスなど]に送ったメールのためのReturn Receiptです。」 「添付ファイル[s]を解読するのを試みている間、誤りは発生しました。」
This recommendation adheres to the definition in RFC 2298 [9] and helps to distinguish the returned MDNs for proper handling.
この推薦は、RFC2298[9]との定義を固く守って、適切な取り扱いのために返されたMDNsを区別するのを助けます。
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.
送付者(オリジナルのメッセージからヘッダーフィールドを利用するのによる)か複数の言語を含んでいることの言葉を借りて言えばImplementersは、メッセージを送ると考えたがっているかもしれません、MDNのテキスト一部において複合である、または代替で使用することによって。
4.4.2 "Subject" of MDN and DSN in Success and Failure Cases
4.4.2 成功と失敗事件におけるMDNとDSNの「対象」
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.
遺産メールアプリケーションが機械可読なヘッダーを分析しないので、Eメールの利用者は受け取られていている承認のタイプを見分けるためにMDNの人間読み込み可能な部分を当てにします。
Examples:
例:
MDN:
Subject: Your message was processed successfully. (MDN)
Subject: Your message has been rejected. (MDN)
MDN: Subject: あなたのメッセージは首尾よく処理されました。 (MDN) Subject: あなたのメッセージは拒絶されました。 (MDN)
Cancio, et. al. Informational [Page 6] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[6ページ]のRFC3249Implementersガイド
DSN:
Subject: Your message was delivered successfully. (DSN)
Subject: Your message could not be delivered. (DSN)
Subject: Your message is delayed. (DSN)
DSN: Subject: 首尾よくあなたのメッセージを送りました。 (DSN) Subject: あなたのメッセージを送ることができませんでした。 (DSN) Subject: あなたのメッセージは遅れます。 (DSN)
4.4.3 Extended Mode Receivers that are MTAs (or ESMTP servers)
4.4.3 MTAsである拡張Mode Receivers(または、ESMTPサーバ)
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])、規格は優先します。
4.4.3.1 Success Case Example
4.4.3.1 成功事例
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.
以下の例の sender <jean@example.com 、gt;、メッセージを receiver <ifax@example.net に送る、gt;、どれがESMTPサーバと受信機であるかは首尾よくメッセージを解読します。
example.com
+-------+
| Mail |
| User |
| Agent |
+-------+
|
V
+----------+ +--------+ +---------+
| Mail + | Mail | | Mail |
|Submission|----->|Transfer|---->|Transfer |
| Agent | | Agent | | Agent |
+----------+ +--------+ +---------+
example.com+-------+ | メール| | ユーザ| | エージェント| +-------+ | +に対して----------+ +--------+ +---------+ | メール+| メール| | メール| |服従|、-、-、-、--、>|転送|、-、-、--、>|転送| | エージェント| | エージェント| | エージェント| +----------+ +--------+ +---------+
example.org example.net
example.org example.net
Cancio, et. al. Informational [Page 7] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[7ページ]のRFC3249Implementersガイド
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: 250ENHANCEDSTATUSCODES C: FROM:<jean@example.com に郵送してください、gt;、=HDRS ENVID=MM123456 Sを浸水させてください: 250 2.1.0 Originator <jean@example.com 、gt;、OK C: RCPT TO:<ifax@example.net 、gt;、=成功に通知してください、そして、失敗\ORCPTは rfc822;ifax@example.net Sと等しいです: 250 2.1.5 Recipient <ifax@example.net 、gt;、OK C: データS: 354 <CRLF><CRLF>Cに終わって、メッセージを送ってください: C: [メッセージはここに行きます。] C: C: . S: 250 2.0.0 メッセージはCを受け入れました: 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+0900From: postmaster@example.net Message ID: <19991212190157.01234@example.net>To: jean@example.com Subject: 首尾よくあなたのメッセージを送りました。 (DSN) MIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは配送状態と等しいです。 境界=JUK199912121854870001
--JUK199912121854870001
Content-type: text/plain
--JUK199912121854870001文書内容: テキスト/平野
Your message (id MM123456) was successfully delivered
to ifax@example.net.
首尾よく、あなたのメッセージ(イドMM123456)を ifax@example.net に渡しました。
--JUK199912121854870001
Content-type: message/delivery-status
--JUK199912121854870001文書内容: 配送メッセージ/状態
Cancio, et. al. Informational [Page 8] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[8ページ]のRFC3249Implementersガイド
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 Original Envelope ID: MM123456最終受理者: rfc822;ifax@example.net 動作: 渡されたStatus: 2.1.5 (送付先アドレス有効)の診断コード: smtp。 250 2.1.5 Recipient <ifax@example.net 、gt;、間違いありませんさ
--JUK199912121854870001
Content-type: message/rfc822
--JUK199912121854870001文書内容: メッセージ/rfc822
[headers of returned message go here.]
[返されたメッセージのヘッダーはここに行きます。]
--JUK199912121854870001--
--JUK199912121854870001--
4.4.3.2 Failure Case Example 1
4.4.3.2 失敗事例1
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.
この例では、受信機は、添付ファイルのAFTERを解読できないことを決定します。それはSMTPメッセージを受け取りました。 そして、受信機は'失敗'DSNを送ります。
example.com
+-------+
| Mail |
| User |
| Agent |
+-------+
|
V
+----------+ +--------+ +---------+
| Mail + | Mail | | Mail |
|Submission|----->|Transfer|---->|Transfer |
| Agent | | Agent | | Agent |
+----------+ +--------+ +---------+
example.org example.net
example.com+-------+ | メール| | ユーザ| | エージェント| +-------+ | +に対して----------+ +--------+ +---------+ | メール+| メール| | メール| |服従|、-、-、-、--、>|転送|、-、-、--、>|転送| | エージェント| | エージェント| | エージェント| +----------+ +--------+ +---------+ 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)と同じです。 系列、aが解読した後に、誤りが受信機に発生するので、'成功'DSNの代わりに、'失敗'DSNを送ります。
Cancio, et. al. Informational [Page 9] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[9ページ]のRFC3249Implementersガイド
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日の19:31:20+0900From: postmaster@example.net Message ID: <19991212193120.87652@example.net>To: jean@example.com Subject: あなたのメッセージを送ることができませんでした。 (DSN) MIMEバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは配送状態と等しいです。 境界=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.
添付ファイルを解読するのを試みている間、 ifax@example.net へのあなたのメッセージ(イドMM123456)は誤りをもたらしました。
--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 Original Envelope 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--
4.4.3.3 Failure Case Example 2
4.4.3.3 失敗事例2
In this example, the receiver determines it is unable to decode the attached file BEFORE it accepts the SMTP transmission.
この例では、受信機は、添付ファイルのBEFOREを解読できないことを決定します。それはSMTPトランスミッションを受け入れます。
Cancio, et. al. Informational [Page 10] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[10ページ]のRFC3249Implementersガイド
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: 250ENHANCEDSTATUSCODES C: FROM:<jean@example.com に郵送してください、gt;、=HDRS ENVID=MM123456 Sを浸水させてください: 250 2.1.0 Originator <jean@example.com 、gt;、OK C: RCPT TO:<ifax@example.net 、gt;、=成功に通知してください、そして、失敗\ORCPTは rfc822;ifax@example.net Sと等しいです: 250 2.1.5 Recipient <ifax@example.net 、gt;、OK C: データS: 354 <CRLF><CRLF>Cに終わって、メッセージを送ってください: C: [メッセージはここに行きます。] C: C: . S: 554 5.6.1 メディアはCを支持しませんでした: Sをやめてください: 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を発生させることができません。
4.4.4 Extended Mode Receivers that are POP3/IMAP4
4.4.4 POP3/IMAP4である拡張Mode Receivers
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]規格と衝突するなら、規格は優先します。
4.4.4.1 Success Case Example
4.4.4.1 成功事例
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解釈における食い違い。
Cancio, et. al. Informational [Page 11] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[11ページ]のRFC3249Implementersガイド
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"
日付: 1999年12月14日の17:48:44+0900From: ken_recipient@example.com Message ID: <19991214174844.98765@example.com>Subject: あなたのメッセージは首尾よく処理されました。 (MDN) To: mary@example.net パントマイムバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは気質通知と等しいです。 境界=「61FD1001_IFAX」
--61FD1001_IFAX
Content-Type: text/plain
--61FD1001_IFAXコンテントタイプ: テキスト/平野
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 "に送ったメールのためのReturn Receiptです。 メッセージと添付ファイルは、印刷されたか、ファックスされたか、または保存されたかもしれません。 これはメッセージが読まれるか、または理解されているという保証ではありません。
--61FD1001_IFAX
Content-Type: message/disposition-notification
--61FD1001_IFAXコンテントタイプ: 気質メッセージ/通知
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: 理解-ifax.example.com。 barmail1999.10Original-受取人: rfc822;ken_recipient@example.com 最終受理者: rfc822;ken_recipient@example.com の元のMessage ID: <19991214174010O. mary@example.net>気質: MDNは自動的に自動動作/発信していました。 急いでいます。
--61FD1001_IFAX--
--61FD1001_IFAX--
4.4.4.2 Failure Case Example
4.4.4.2 失敗事例
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+0900From: ken_recipient@example.com Message ID: <19991214194844.67325@example.com>Subject: あなたのメッセージは拒絶されました。 (MDN) To: mary@example.net パントマイムバージョン: 1.0コンテントタイプ: 複合/レポート。 レポートタイプは気質通知と等しいです。 境界=「84FD1011_IFAX」
Cancio, et. al. Informational [Page 12] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[12ページ]のRFC3249Implementersガイド
--84FD1011_IFAX
Content-Type: text/plain
--84FD1011_IFAXコンテントタイプ: テキスト/平野
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 "に送ったメールのためのReturn Receiptです。 「添付ファイル[s]を解読するのを試みている間、誤りは発生しました。」
--84FD1011_IFAX
Content-Type: message/disposition-notification
--84FD1011_IFAXコンテントタイプ: 気質メッセージ/通知
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: 理解-ifax.example.com。 barmail1999.10Original-受取人: rfc822;ken_recipient@example.com 最終受理者: rfc822;ken_recipient@example.com の元のMessage ID: <199912141823123.mary@example.net>気質: MDNは自動的に自動動作/発信していました。 処理/誤り
--84FD1011_IFAX
Content-Type: message/rfc822
--84FD1011_IFAXコンテントタイプ: メッセージ/rfc822
[original message goes here]
[オリジナルのメッセージはここに行きます]
--84FD1011_IFAX--
--84FD1011_IFAX--
4.4.5 Receiving Multiple Attachments
4.4.5 複数の付属を受けること。
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.
受信されたメールメッセージは複数の付属を含むかもしれません、そして、それぞれの異なった付属は異なったencodingsか解決がある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.
Extended Mode受取人が添付ファイルのどれかを解読できないなら、Extended Mode受取人が全体のメッセージのための解読誤りを返すのは、お勧めです。
5. Implementation Issues Specific to the File Format
5. ファイル形式に特定の導入問題
5.1 IFD Placement & Profile-S Constraints
5.1 IFDプレースメントとプロフィールS規制
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
a) IFDは語境界で始まるようにTIFF6.0によって必要とされて、単語の規定サイズに関してしかしながら、あいまいさがあります。 単語は2バイトの量として解釈されるべきです。 これ
Cancio, et. al. Informational [Page 13] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[13ページ]のRFC3249Implementersガイド
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.
推薦はTIFF6.0のセクション2で見つけられた図1の試験とIFD Entry、Bytes8-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) 低いメモリ素子(必要なProfile-Sより大きい解決を支持する)はメモリで強制的であるかもしれません、それらの装置がTIFFファイルの中で適切にTIFF IFDsの任意のプレースメントを扱うことができないように。
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]で定義されたProfilesのどれかを使用するとき、送付者がいつもイメージ・ファイルの始めにIFDを置くことが強く勧められます。
5.2 Precautions for implementers of RFC 2301 [4]
5.2 RFC2301のimplementersのための注意[4]
5.2.1 Errors encountered during interoperability testing
5.2.1 相互運用性テストの間に遭遇する誤り
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/RFC2301[4]誤りを、相互運用性テストの間、遭遇して、TIFF読者と作家のimplementersが予防策をとることができるように、提供します。
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]のProfile Sは、ファイルがリトルエンディアンオーダーにあるはずであると指定しますが、テストの間何人かの一般的なTIFF作家がビッグエンディアンファイルを作成するのが見つけられました。 できれば、TIFF読者は、ビッグエンディアンファイルを扱うためにコード化されるべきです。 TIFF作家は、規格で言いなりになって、メモリで強制的な装置でinteroperationを許容するためにいつもリトルエンディアンファイルを作成するべきです。
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) Image File Headerのバイト0-1は「II」(4949h)かバイトオーダーを示す「mm」(4d4dh)へのセットであるべきです。 テストの間、他の値は遭遇しました。 読者はバイトオーダー分野が「II」か「mm」を除いた値を含むケースを扱うべきです、そして、作家は正しい値が使用されているのを保証するべきです。
5.2.2 Color Gamut Considerations
5.2.2 色域問題
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.
(PhotometricInterpretation=10)をコード化するITULABはこのcolorspaceに表された整数値によりすばらしい粒状を置く方法が順番に提供される*b*(TIFF分野Decodeを見ます)をL*のための全域の範囲に選ばせます。 しかし、その結果、不十分な全域選択は全域のそばで境界がある色のスペースの中に下がらない色の保存で穴を開けるかもしれません。 そういうものとして、これを批評する価値があります。
Cancio, et. al. Informational [Page 14] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[14ページ]のRFC3249Implementersガイド
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はデータをモニターします。 事実上、ウェブからのイメージに対処して、他の表示がソースを適応させたとき、スキャンされたハードコピーのための色の範囲はおそらく不十分であるかもしれません。 イメージデータの源に合っている全域を使用するのは重要です。
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 Recommendation 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).
2. sRGBソースにおいて、ITU-T Recommendation T.42デフォルトITULAB全域は適切ではありません。 考えるのが、より適切である全域は以下の通りです。 L[0,100]、a[-88、99]、およびb[-108.8、95.2]。 これらは8ビットのデータに以下のDecode値を使用することによって、実感されるかもしれません: (0/1, 100/1, -22440/255, 25245/255, -27744/255, 24276/255).
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. あなたは、L*の範囲であるなら、ITULABに変える前に、効率的に*b*値を前計算できて、次に、この範囲にカスタムである全域を選ぶことによって、最も良い結果を得ることができます。
5.2.3 File format Considerations
5.2.3 ファイル形式Considerations
Implementers should make sure of the contents in the following two sections.
Implementersは以下の2つのセクションでコンテンツについて確かめるはずです。
5.2.3.1 Considerations for greater reader flexibility
5.2.3.1 より大きい読者の柔軟性のための問題
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) 読者は、フレキシブルであって、収容できます: 寄贈されないIFDsはページを昇る際に注文します。 IFDが説明するイメージに先行する位置に置かれないIFDs。 現在のIFDに先行する次のIFDオフセット、現在のIFDsのフィールド・データ、または現在のIFDsのイメージデータ。 他方では、作家はページオーダーを昇る際にIFDsを寄贈している状態でファイルを発生させるべきです。 IFDsはIFDが説明するイメージに先行する位置で入賞しました。 次のIFDはいつもデータの現在のIFDとすべてに続くはずです。
Cancio, et. al. Informational [Page 15] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[15ページ]のRFC3249Implementersガイド
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の代わりにRATIONAL)でタグを発生させます。 読者は、容易に設備されるかもしれない誤伝(例えば、LONGの代わりにSHORT)のそういったタイプの人にフレキシブルであり、高められた丈夫さに通じます。
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の正しいオーダーに現れます、そして、読者はこれらのタイプの誤伝にフレキシブルです。
5.2.3.2 Error considerations
5.2.3.2 誤り問題
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) 読者は42(2Ah)、「マジックナンバー」と等しいImage File Headerのバイト2-3でファイルを受け入れるだけです、有効なTIFFかTIFF-FXファイルであるとして、作家は適切なマジックナンバーでファイルを発生させるだけですが。
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値はPrimary IFDチェーンの中でオーダーに基づいています。 ImageLayer値は層の中でそれぞれ層の注文とイメージ注文に基づいています。 読者はPageNumberかImageLayer値がPrimary IFDsの数と一致していないページを拒絶するかもしれません、層の中のイメージの層か数の数。
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) 1つのエンディアンオーダーだけがファイルの中で使用されます。そうでなければ、レンダリングされたファイルはこわされるでしょう。
Cancio, et. al. Informational [Page 16] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[16ページ]のRFC3249Implementersガイド
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) タグ値はイメージ片の中に含まれているデータと一致しています。 例えば、aがあるPhotometricInterpretationが値にタグ付けをする白地イメージ片での両性愛者のレベルの黒いマーク、「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値はPrimary 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) 適切なCompressionタイプはProfile Mの中の層がファイルするイメージに使用されます、マスク層(すなわち、変な番号付の層)のための両性愛者のレベル符号化器とバックグラウンドのためのマルチレベル(色)符号化器やフォアグランド層のように。 読者はこれが本当でないファイルを拒絶するべきです。
5.3 Content-Type for the file format
5.3 ファイル形式のためのコンテントタイプ
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.
満足しているタイプ「イメージ/いさかい」はProfiles Sに使用されるだけであるべきです、そして、[4]に基づくF.のSomeの既存の実現は他のProfilesに「イメージ/いさかい」を使用するかもしれません。 しかしながら、この用法は現在、非難されます。 代わりに、満足しているタイプ「いさかいイメージ/fx」(登録は[17]で定義されている)は使用されるべきです。
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.
表現Profile SかF、「イメージ/いさかい」SHOULDができるだけである装置による織り込むことを最大にするには、Profile SかFを輸送するときには、使用されてください。
6. Implementation Issues for Internet Fax Addressing
6. インターネットファックスアドレシングのための導入問題
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値)が適切にそうである特別な注意を払わなければなりません。
Cancio, et. al. Informational [Page 17] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[17ページ]のRFC3249Implementersガイド
For example, the following header is valid as-is:
例えば、以下のヘッダーはそのままで有効です:
To: Home Fax <FAX=+390408565@example.com>
To: ホームファックス<ファックスが+ 390408565@example.com と等しい、gt。
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:<ファックスが+ 390408565@example.com と等しい、gt;、\ORCPTはファックス+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]を見てください。
7. Security Considerations
7. セキュリティ問題
With regards to this document, Sections 5 in RFC 2305 [2] and Section 4 in RFC 2532 [3] apply.
このドキュメントへの尊敬で、RFC2305[2]のセクション5とRFC2532[3]のセクション4は適用されます。
8. Acknowledgements
8. 承認
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、ジェームスRafferty、Kensuke山田、ユッタDegener、およびロイド・マッキンタイヤ。
9. References
9. 参照
[1] Masinter, L., "Terminology and Goals for Internet Fax", RFC
2542, March 1999.
[1] より多くのMasinterに、L.と、「インターネットファックスの用語と目標」(RFC2542)は1999を行進させます。
[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.は飛んで行きます、「ファクシミリの簡単なモードはインターネットメールを使用し」て、RFC3205、1998年3月。
[3] Masinter, L. and D. Wing, "Extended Facsimile Using Internet
Mail", RFC 2532, March 1999.
[3] Masinter、L.、およびD.は1999年3月に「拡張ファクシミリはインターネットメールを使用すること」でのRFC2532に翼をつけさせます。
[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.、ヴェナブル、D.、パーソンズ、G.、およびJ.Rafferty)は「インターネットファックスのために形式をファイルします」、RFC2301、1998年3月。
[5] Moore, K., "SMTP Service Extension for Delivery Status
Notification", RFC 1891, January 1996.
[5] ムーア、K.、「配送状態通知のためのSMTPサービス拡張子」、RFC1891、1996年1月。
[6] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
January 1996.
[6] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC1893、1996年1月。
Cancio, et. al. Informational [Page 18] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[18ページ]のRFC3249Implementersガイド
[7] Moore, K. and G. Vaudreuil, "An Extensible Message Format for
Delivery Status Notifications", RFC 1894, January 1996.
[7] ムーアとK.とG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC1894、1996年1月。
[8] Freed, N., "SMTP Service Extension for Returning Enhanced Error
Codes", RFC 2034, October 1996.
解放された[8]、N.、「戻るためのSMTPサービス拡張子はエラーコードを高めた」RFC2034、1996年10月。
[9] Fajman, R., "An Extensible Message Format for Message
Disposition Notifications", RFC 2298, March 1998.
[9]Fajman、R.、「メッセージ気質通知のための広げることができるメッセージ・フォーマット」、RFC2298、1998年3月。
[10] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[10] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[11] Postel, J., "A Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.
[11] ポステル、J.、「シンプルメールトランスファプロトコル」、STD10、RFC821、1982年8月。
[12] Allocchio, C., "Minimal GSTN address format in Internet Mail",
RFC 3191, October 2001.
[12]Allocchio、C.、「インターネットメールにおける最小量のGSTNアドレス形式」、RFC3191、2001年10月。
[13] Allocchio, C., "Minimal FAX address format in Internet Mail",
RFC 3192, October 2001.
[13]Allocchio、C.、「インターネットメールにおける最小量のFAXアドレス形式」、RFC3192、2001年10月。
[14] Allocchio, C., "GSTN Address Element Extensions in E-mail
Services", RFC 2846, June 2000
[14]Allocchio、C.、「メールサービスにおけるGSTNアドレス要素拡張子」、RFC2846、2000年6月
[15] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker,
D., "SMTP Service Extensions", RFC 2846, November 1995
Klensin(J.)が解放した[15]とN.とローズとM.とStefferudとE.とD.クロッカー、D.、「SMTPサービス拡張子」、RFC2846、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を分けます」。 「メディアタイプ」、RFC2046、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.Rafferty、「Image File FormatファックスeXtended(TIFF-FX)にタグ付けをしてください--いさかいイメージ/fx MIME Sub-タイプRegistration」、RFC3250、2002年9月。
[18] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[18]Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[19] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[19] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
Cancio, et. al. Informational [Page 19] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[19ページ]のRFC3249Implementersガイド
10. Authors' Addresses
10. 作者のアドレス
Vivian Cancio 103 Cuesta Drive Los Altos, CA 94022
ケスタDriveロスアルトス、ビビアンCancio103カリフォルニア 94022
Phone: +1-650-948-3135 EMail: vcancio@pacbell.net
以下に電話をしてください。 +1-650-948-3135 メールしてください: vcancio@pacbell.net
Mike Moldovan G3 Nova Technology Inc. 5743 Corsa Avenue, Suite 122 Westlake Village, CA 91362
カリフォルニア マイクMoldovan G3新星技術Inc.5743Corsa Avenue、スイート122ウェストレーク村、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
田村リコー会社Ltd.1-3-6Nakamagome、Hiroshi太田区日本東京143-8555
Phone: +81-3-3777-8124 Fax: +81-3-5742-8859 EMail: tamura@toda.ricoh.co.jp
以下に電話をしてください。 +81-3-3777-8124 Fax: +81-3-5742-8859 メールしてください: tamura@toda.ricoh.co.jp
Dan Wing Cisco Systems, Inc. 170 W. Tasman Drive San Jose, CA 95134-1706 USA
ダン翼のシスコシステムズInc.170W.タスマン・Driveカリフォルニア95134-1706サンノゼ(米国)
Phone: +1-408-525-5314 Fax: +1-408-527-8083 EMail: dwing@cisco.com
以下に電話をしてください。 +1-408-525-5314 Fax: +1-408-527-8083 メールしてください: dwing@cisco.com
Cancio, et. al. Informational [Page 20] RFC 3249 Implementers Guide for Facsimile September 2002
et Cancio、アル。 ファクシミリ2002年9月のための情報[20ページ]のRFC3249Implementersガイド
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Cancio, et. al. Informational [Page 21]
et Cancio、アル。 情報[21ページ]
一覧
スポンサーリンク
