RFC2049 日本語訳
2049 Multipurpose Internet Mail Extensions (MIME) Part Five:Conformance Criteria and Examples. N. Freed, N. Borenstein. November 1996. (Format: TXT=51207 bytes) (Obsoletes RFC1521, RFC1522, RFC1590) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group N. Freed
Request for Comments: 2049 Innosoft
Obsoletes: 1521, 1522, 1590 N. Borenstein
Category: Standards Track First Virtual
November 1996
ネットワークワーキンググループN.はコメントを求める要求を解放しました: 2049Innosoftは以下を時代遅れにします。 1521、1522、1590N.Borensteinカテゴリ: 標準化過程ファースト・バーチャル1996年11月
Multipurpose Internet Mail Extensions
(MIME) Part Five:
Conformance Criteria and Examples
マルチパーパスインターネットメールエクステンション(MIME)パートFive: 順応評価基準と例
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for
STD11(RFC822)は米国-ASCIIメッセージヘッダーに関するかなりの詳細を指定するメッセージ表現プロトコルを定義して、メッセージ内容、またはメッセージ本体を残します、平坦な米国-ASCIIテキストとして。 このセットのまとめてマルチパーパスインターネットメールエクステンションと呼ばれるドキュメント、またはMIMEが考慮するメッセージの書式を再定義します。
(1) textual message bodies in character sets other than
US-ASCII,
(1) 米国-ASCIIを除いた文字集合における原文のメッセージ本体
(2) an extensible set of different formats for non-textual
message bodies,
(2) 非原文のメッセージ本体のための広げることができる異なった形式
(3) multi-part message bodies, and
そして(3) 複合メッセージ本体。
(4) textual header information in character sets other than
US-ASCII.
(4) 米国-ASCIIを除いて、原文のヘッダー情報はぴったりしたセットします。
These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
これらのドキュメントは、それらをRFC934、STD11、およびRFC1049に記録された以前の仕事に基づいていますが、広げていて、改訂します。 RFC822が、メッセージ本体に関してこれらのドキュメントが主にそうであると直交していた状態でそれほど少ししか言わなかった、(改正よりむしろ、)、RFC822
The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. The second document defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-
このセットにおける初期のドキュメント(RFC2045)はMIMEメッセージの構造について説明するのに使用される様々なヘッダーを指定します。 2番目のドキュメントは、MIMEメディアタイピングシステムの一般構造体を定義して、1人の始発のメディアタイプを定義します。 3番目のドキュメント(RFC2047)が許容するためにRFC822に拡大について説明する、非、-、米国、-
Freed & Borenstein Standards Track [Page 1] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[1ページ]RFC2049は順応1996年11月にまねます。
ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME- related facilities. This fifth and final document describes MIME conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.
インターネットのASCIIテキストデータはヘッダーフィールドを郵送します。 4番目のドキュメント(RFC2048)は様々なIANA登録手順をMIME関連する施設に指定します。 この5番目と最終合意文書は、また、MIME順応評価基準がMIMEメッセージ・フォーマット、承認、および図書目録に関するいくつかの説明に役立つ実例を提供すると記述します。
These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. Appendix B of this document describes differences and changes from previous versions.
これらのドキュメントはRFCs1521、1522、および1590年の改正です。(その改正は自分たちでRFCs1341と1342年の改正でした)。 このドキュメントの付録Bは旧バージョンからの違いと変化について説明します。
Table of Contents
目次
1. Introduction .......................................... 2 2. MIME Conformance ...................................... 2 3. Guidelines for Sending Email Data ..................... 6 4. Canonical Encoding Model .............................. 9 5. Summary ............................................... 12 6. Security Considerations ............................... 12 7. Authors' Addresses .................................... 12 8. Acknowledgements ...................................... 13 A. A Complex Multipart Example ........................... 15 B. Changes from RFC 1521, 1522, and 1590 ................. 16 C. References ............................................ 20
1. 序論… 2 2. 順応をまねてください… 2 3. 送付のためのガイドラインはデータをメールします… 6 4. 正準なコード化はモデル化されます… 9 5. 概要… 12 6. セキュリティ問題… 12 7. 作者のアドレス… 12 8. 承認… 13 A. 複雑な複合例… 15 B.はRFC1521、1522、および1590年から変化します… 16 C.参照… 20
1. Introduction
1. 序論
The first and second documents in this set define MIME header fields and the initial set of MIME media types. The third document describes extensions to RFC822 formats to allow for character sets other than US-ASCII. This document describes what portions of MIME must be supported by a conformant MIME implementation. It also describes various pitfalls of contemporary messaging systems as well as the canonical encoding model MIME is based on.
このセットにおける1番目と2番目のドキュメントはMIMEヘッダーフィールドを定義します、そして、MIMEメディアの始発はタイプされます。 3番目のドキュメントは、米国-ASCIIを除いた文字集合を考慮するためにRFC822形式に拡大について説明します。 このドキュメントは、conformant MIME実装でMIMEのどんな部分をサポートしなければならないかを説明します。 また、それはモデルMIMEをコード化する正準と同様にシステムに基づいている現代のメッセージングの様々な落とし穴を説明します。
2. MIME Conformance
2. MIME順応
The mechanisms described in these documents are open-ended. It is definitely not expected that all implementations will support all available media types, nor that they will all share the same extensions. In order to promote interoperability, however, it is useful to define the concept of "MIME-conformance" to define a certain level of implementation that allows the useful interworking of messages with content that differs from US-ASCII text. In this section, we specify the requirements for such conformance.
これらのドキュメントで説明されたメカニズムは制限のないです。 すべての実装がすべての利用可能なメディアにタイプをサポートして、彼らが皆、同じ拡大を共有しないと確実に予想されます。 しかしながら、相互運用性を促進するために、米国-ASCIIテキストと異なっている内容があるメッセージを役に立つ織り込むことを許すあるレベルの実装を定義するために「MIME順応」の概念を定義するのは役に立ちます。 このセクションでは、私たちはそのような順応のための要件を指定します。
Freed & Borenstein Standards Track [Page 2] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[2ページ]RFC2049は順応1996年11月にまねます。
A mail user agent that is MIME-conformant MUST:
MIME-conformantであるメールユーザエージェントはそうしなければなりません:
(1) Always generate a "MIME-Version: 1.0" header field in
any message it creates.
(1) いつもaを生成してください、「MIMEバージョン:」 それが作成するどんなメッセージの1インチのヘッダーフィールド。
(2) Recognize the Content-Transfer-Encoding header field
and decode all received data encoded by either quoted-
printable or base64 implementations. The identity
transformations 7bit, 8bit, and binary must also be
recognized.
(2) Content転送コード化ヘッダーフィールドを認識してください、そして、印刷可能であるかbase64の引用された実装によってコード化されたすべての受信データを解読してください。 また、8の7が噛み付いた恒等変換、ビット、およびバイナリーを認識しなければなりません。
Any non-7bit data that is sent without encoding must be
properly labelled with a content-transfer-encoding of
8bit or binary, as appropriate. If the underlying
transport does not support 8bit or binary (as SMTP
[RFC-821] does not), the sender is required to both
encode and label data using an appropriate Content-
Transfer-Encoding such as quoted-printable or base64.
8の満足している転送コード化ビットかバイナリーで適切にコード化なしで送られるどんな非7bit dataもラベルしなければなりません、適宜。 基本的な輸送が8のビットかバイナリーをサポートしないなら(SMTP[RFC-821]がそうしないように)、送付者は、ともに引用されて印刷可能であるとして転送をコード化する適切なContentそのようなものを使用するデータかbase64をコード化して、ラベルしなければなりません。
(3) Must treat any unrecognized Content-Transfer-Encoding
as if it had a Content-Type of "application/octet-
stream", regardless of whether or not the actual
Content-Type is recognized.
まるでそれには「アプリケーション/八重奏ストリーム」のコンテントタイプがあるかのように(3)はどんな認識されていないContent転送コード化も扱わなければなりません、実際のコンテントタイプが認識されるかどうかにかかわらず。
(4) Recognize and interpret the Content-Type header field,
and avoid showing users raw data with a Content-Type
field other than text. Implementations must be able
to send at least text/plain messages, with the
character set specified with the charset parameter if
it is not US-ASCII.
(4) コンテントタイプヘッダーフィールドを認識して、解釈してください、そして、テキスト以外のコンテントタイプ分野で生データをユーザに示すのを避けてください。 実装は少なくともテキスト/明瞭なメッセージを送ることができなければなりません、それが米国-ASCIIでないならcharsetパラメタで指定された文字集合で。
(5) Ignore any content type parameters whose names they do
not recognize.
(5) 彼らが名前を認識しないあらゆるcontent typeパラメタを無視してください。
(6) Explicitly handle the following media type values, to
at least the following extents:
(6) 明らかにタイプが少なくとも以下の範囲に評価する以下のメディアを扱ってください:
Text:
テキスト:
-- Recognize and display "text" mail with the
character set "US-ASCII."
-- 文字集合「米国-ASCII」がある「テキスト」メールを認識して、表示してください。
-- Recognize other character sets at least to the
extent of being able to inform the user about what
character set the message uses.
-- 他の文字集合を少なくともメッセージが周囲でどんな文字集合を使用するかをユーザに知らせることができる範囲まで認識してください。
Freed & Borenstein Standards Track [Page 3] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[3ページ]RFC2049は順応1996年11月にまねます。
-- Recognize the "ISO-8859-*" character sets to the
extent of being able to display those characters that
are common to ISO-8859-* and US-ASCII, namely all
characters represented by octet values 1-127.
-- 「ISO8859*」文字集合をISO8859*と米国-ASCIIに共通のそれらのキャラクタは見せることができる範囲まで認識してください、すなわち、八重奏値1-127によって代理をされたすべてのキャラクタ。
-- For unrecognized subtypes in a known character
set, show or offer to show the user the "raw" version
of the data after conversion of the content from
canonical form to local form.
-- 知られている文字集合における認識されていない血液型亜型には、目立つか、または内容の標準形から地方のフォームまでの変換の後にデータの「生」のバージョンをユーザに示すと申し出てください。
-- Treat material in an unknown character set as if
it were "application/octet-stream".
-- まるでそれが「八重奏アプリケーション/ストリーム」であるかのように未知の文字集合で材料を処理してください。
Image, audio, and video:
イメージ、オーディオ、およびビデオ:
-- At a minumum provide facilities to treat any
unrecognized subtypes as if they were
"application/octet-stream".
-- minumumでは、便宜を与えて、まるでそれらが「八重奏アプリケーション/ストリーム」であるかのようにあらゆる認識されていない血液型亜型を扱ってください。
Application:
アプリケーション:
-- Offer the ability to remove either of the quoted-
printable or base64 encodings defined in this
document if they were used and put the resulting
information in a user file.
-- 印刷可能な引用かそれらが本書では使用されたなら定義されたbase64 encodingsを取り外して、結果として起こる情報をユーザ・ファイルに入れる能力を提供してください。
Multipart:
複合:
-- Recognize the mixed subtype. Display all relevant
information on the message level and the body part
header level and then display or offer to display
each of the body parts individually.
-- 混ぜられた「副-タイプ」を認識してください。 メッセージレベルとボディー部分ヘッダーレベルのすべての関連情報を表示して、次に、ディスプレイを表示するか、または個別にそれぞれの身体の部分を表示すると申し出てください。
-- Recognize the "alternative" subtype, and avoid
showing the user redundant parts of
multipart/alternative mail.
-- 「代替」の「副-タイプ」を認めてください、そして、複合の、または、代替のメールのユーザの余分な部分を見せるのを避けてください。
-- Recognize the "multipart/digest" subtype,
specifically using "message/rfc822" rather than
"text/plain" as the default media type for body parts
inside "multipart/digest" entities.
-- 「複合/ダイジェスト」「副-タイプ」を認識してください、デフォルトメディアが「複合/ダイジェスト」実体で身体の部分にタイプされるように明確に「テキスト/平野」よりむしろ「メッセージ/rfc822」を使用して。
-- Treat any unrecognized subtypes as if they were
"mixed".
-- まるでそれらが「混ぜられるかの」ようにあらゆる認識されていない血液型亜型を扱ってください。
Freed & Borenstein Standards Track [Page 4] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[4ページ]RFC2049は順応1996年11月にまねます。
Message:
メッセージ:
-- Recognize and display at least the RFC822 message
encapsulation (message/rfc822) in such a way as to
preserve any recursive structure, that is, displaying
or offering to display the encapsulated data in
accordance with its media type.
-- 少なくともRFC822メッセージカプセル化(メッセージ/rfc822)をすなわち、どんな再帰的な構造、表示も保存するほどそのような方法で、認識して、表示するか、またはメディアによると、カプセル化されたデータを表示すると申し出て、タイプしてください。
-- Treat any unrecognized subtypes as if they were
"application/octet-stream".
-- まるでそれらが「八重奏アプリケーション/ストリーム」であるかのようにあらゆる認識されていない血液型亜型を扱ってください。
(7) Upon encountering any unrecognized Content-Type field,
an implementation must treat it as if it had a media
type of "application/octet-stream" with no parameter
sub-arguments. How such data are handled is up to an
implementation, but likely options for handling such
unrecognized data include offering the user to write it
into a file (decoded from its mail transport format) or
offering the user to name a program to which the
decoded data should be passed as input.
(7) どんな認識されていないコンテントタイプ分野にも遭遇するとき、まるでそれには「八重奏アプリケーション/ストリーム」のメディアタイプがパラメタサブ議論なしであるかのように実装はそれを扱わなければなりません。 そのようなデータがどう扱われるかが実装まで達していますが、そのような認識されていないデータを扱うためのありそうなオプションは、ファイル(メール輸送形式から、解読される)の中にそれを書くためにユーザを提供するか、または解読されたデータが入力されるように通過されるべきであるプログラムを命名するためにユーザを提供するのを含んでいます。
(8) Conformant user agents are required, if they provide
non-standard support for non-MIME messages employing
character sets other than US-ASCII, to do so on
received messages only. Conforming user agents must not
send non-MIME messages containing anything other than
US-ASCII text.
(8) Conformantユーザエージェントが必要です、彼らがなどに受信されたメッセージだけをするのに米国-ASCIIを除いた文字集合を使う非MIMEメッセージの標準的でないサポートを提供するなら。 ユーザエージェントを従わせると、米国-ASCIIテキスト以外の何も含む非MIMEメッセージは送られてはいけません。
In particular, the use of non-US-ASCII text in mail
messages without a MIME-Version field is strongly
discouraged as it impedes interoperability when sending
messages between regions with different localization
conventions. Conforming user agents MUST include proper
MIME labelling when sending anything other than plain
text in the US-ASCII character set.
異なったローカライズコンベンションに伴う領域の間にメッセージを送るとき、それが相互運用性を妨害するとき、メール・メッセージのMIMEバージョン分野のない非米国のASCIIテキストの使用は強く特に、お勧めできないです。 米国-ASCII文字の組のプレーンテキスト以外の何でも送るとき、ユーザエージェントを従わせると、適切なMIMEラベルは包含しなければなりません。
In addition, non-MIME user agents should be upgraded if
at all possible to include appropriate MIME header
information in the messages they send even if nothing
else in MIME is supported. This upgrade will have
little, if any, effect on non-MIME recipients and will
aid MIME in correctly displaying such messages. It
also provides a smooth transition path to eventual
adoption of other MIME capabilities.
さらに、MIMEにおける他に何もがサポートされないでも、非MIMEユーザエージェントは、できれば、それらが送るメッセージに適切なMIMEヘッダー情報を含むようにアップグレードするべきです。 このアップグレードは、非MIME受取人の上に少ししかもしあれば効果を持たないで、正しくそのようなメッセージを表示する際にMIMEを支援するでしょう。 また、それは他のMIME能力の最後の採用にスムーズな移行経路を提供します。
(9) Conforming user agents must ensure that any string of
non-white-space printable US-ASCII characters within a
"*text" or "*ctext" that begins with "=?" and ends with
」 それが「=?」で始まって、終わる「いずれも結ぶユーザエージェントを従わせると確実にされなければならないaの中の非余白の印刷可能な米国-ASCII文字の(9)」*テキスト」 」 *ctext
Freed & Borenstein Standards Track [Page 5] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[5ページ]RFC2049は順応1996年11月にまねます。
"?=" be a valid encoded-word. ("begins" means: At the
start of the field-body or immediately following
linear-white-space; "ends" means: At the end of the
field-body or immediately preceding linear-white-
space.) In addition, any "word" within a "phrase" that
begins with "=?" and ends with "?=" must be a valid
encoded-word.
「=、」 有効なコード化された単語になってください。 (: 分野本体の始めにおけるすぐに次の直線的な余白; 「終わり」が意味する手段: 分野本体の先かすぐに前の直線的に白いスペースを「始まります」。) 「追加、「=?」で始まって、」 =で終わる「句」の中のどんな「単語」も」は有効なコード化された単語であるに違いありません。
(10) Conforming user agents must be able to distinguish
encoded-words from "text", "ctext", or "word"s,
according to the rules in section 4, anytime they
appear in appropriate places in message headers. It
must support both the "B" and "Q" encodings for any
character set which it supports. The program must be
able to display the unencoded text if the character set
is "US-ASCII". For the ISO-8859-* character sets, the
mail reading program must at least be able to display
the characters which are also in the US-ASCII set.
(10) ユーザエージェントを従わせると、「テキスト」、"ctext"、または「単語」sとコード化された単語を区別できなければなりません、セクション4の規則に従っていつでも、それらはメッセージヘッダーの適切な場所に現れます。 それは、サポートするどんな文字集合のためにも両方が「B」と「Q」encodingsであるとサポートしなければなりません。 プログラムは文字集合が「米国-ASCII」であるなら暗号化されていないテキストを表示できなければなりません。 ISO8859*文字集合において、メール読み込みプログラムは米国-ASCIIセットにもあるキャラクタを少なくとも見せることができなければなりません。
A user agent that meets the above conditions is said to be MIME- conformant. The meaning of this phrase is that it is assumed to be "safe" to send virtually any kind of properly-marked data to users of such mail systems, because such systems will at least be able to treat the data as undifferentiated binary, and will not simply splash it onto the screen of unsuspecting users.
上記の条件を満たすユーザエージェントはMIME conformantであると言われています。 この句の意味は実際にはどんな種類の適切に著しいデータもそのようなメールシステムのユーザに送るために「安全である」と思われるということです、そのようなシステムが非差別化されたバイナリーとしてデータを少なくとも扱うことができて、疑いを持たないユーザーのスクリーンにそれを絶対にはねかけないので。
There is another sense in which it is always "safe" to send data in a format that is MIME-conformant, which is that such data will not break or be broken by any known systems that are conformant with RFC 821 and RFC 822. User agents that are MIME-conformant have the additional guarantee that the user will not be shown data that were never intended to be viewed as text.
壊れているというそのようなデータがRFC821とRFC822とconformantであるどんな知られているシステムでも壊さないで、またならないことであるMIME-conformantである形式でデータを送るのがいつも「安全である」別の感覚があります。 MIME-conformantであるユーザエージェントはテキストとして見なされることを決して意図しなかったデータがユーザに示されないという追加保証を持っています。
3. Guidelines for Sending Email Data
3. 送付メールデータのためのガイドライン
Internet email is not a perfect, homogeneous system. Mail may become corrupted at several stages in its travel to a final destination. Specifically, email sent throughout the Internet may travel across many networking technologies. Many networking and mail technologies do not support the full functionality possible in the SMTP transport environment. Mail traversing these systems is likely to be modified in order that it can be transported.
インターネットメールは完全で、同次のシステムではありません。 メールはいくつかの段階で最終的な目的地への旅行で崩壊するようになるかもしれません。 明確に、インターネット中で送られたメールは多くのネットワーク・テクノロジーの向こう側に移動するかもしれません。 多くのネットワークとメール技術はSMTP輸送環境で可能な完全な機能性をサポートしません。 これらのシステムを横断する郵便配達人は、それを輸送できるように変更されそうです。
There exist many widely-deployed non-conformant MTAs in the Internet. These MTAs, speaking the SMTP protocol, alter messages on the fly to take advantage of the internal data structure of the hosts they are implemented on, or are just plain broken.
多くの広く配布している非conformant MTAsがインターネットに存在しています。 これらのMTAsはSMTPプロトコルを話して、彼らが実装されるホストの内部のデータ構造を利用するために飛行中のメッセージを変更するか、またはただ単に壊されます。
Freed & Borenstein Standards Track [Page 6] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[6ページ]RFC2049は順応1996年11月にまねます。
The following guidelines may be useful to anyone devising a data format (media type) that is supposed to survive the widest range of networking technologies and known broken MTAs unscathed. Note that anything encoded in the base64 encoding will satisfy these rules, but that some well-known mechanisms, notably the UNIX uuencode facility, will not. Note also that anything encoded in the Quoted-Printable encoding will survive most gateways intact, but possibly not some gateways to systems that use the EBCDIC character set.
以下のガイドラインは、最も広い範囲のネットワーク・テクノロジーを乗り切るべきであるデータの形式(メディアはタイプされる)について工夫するだれのも役に立って知られている壊れているMTAs無事であるかもしれません。 base64コード化でコード化されたものは何もこれらの規則を満たしますが、いくつかのよく知られるメカニズム、著しくUNIX uuencode施設が満たさないことに注意してください。 また、Quoted印刷可能なコード化でコード化されたものは何も完全な状態でほとんどのゲートウェイを乗り切りますが、ことによるとEBCDlC文字を使用するシステムへの数門がセットしないことに注意してください。
(1) Under some circumstances the encoding used for data may
change as part of normal gateway or user agent
operation. In particular, conversion from base64 to
quoted-printable and vice versa may be necessary. This
may result in the confusion of CRLF sequences with line
breaks in text bodies. As such, the persistence of
CRLF as something other than a line break must not be
relied on.
(1) いくつかの状況で、データに使用されるコード化は正常なゲートウェイかユーザエージェント操作の一部として変化するかもしれません。 base64から引用されて印刷可能になるまでの変換が逆もまた同様に特に、必要であるかもしれません。 これはテキスト本文のラインブレイクへのCRLF系列の混乱をもたらすかもしれません。 そういうものとして、ラインブレイク以外の何かとしてのCRLFの固執に依存してはいけません。
(2) Many systems may elect to represent and store text data
using local newline conventions. Local newline
conventions may not match the RFC822 CRLF convention --
systems are known that use plain CR, plain LF, CRLF, or
counted records. The result is that isolated CR and LF
characters are not well tolerated in general; they may
be lost or converted to delimiters on some systems, and
hence must not be relied on.
(2) 多くのシステムが、地方のニューラインコンベンションを使用することでテキストデータを表して、保存するのを選ぶかもしれません。 地方のニューラインコンベンションはRFC822 CRLFコンベンションに合わないかもしれません--明瞭なCR、明瞭なLF、CRLF、または数えられた記録を使用するシステムが知られています。 結果は孤立しているCRとLFキャラクタがよく一般に許容されないということです。 それらを、失ってはいけないかもしれないか、いくつかのシステムの上でデリミタに変えて、したがって、当てにしてはいけません。
(3) The transmission of NULs (US-ASCII value 0) is
problematic in Internet mail. (This is largely the
result of NULs being used as a termination character by
many of the standard runtime library routines in the C
programming language.) The practice of using NULs as
termination characters is so entrenched now that
messages should not rely on them being preserved.
(3) NULs(米国-ASCII値0)のトランスミッションはインターネット・メールで問題が多いです。 (これは主に行終了文字としてCプログラミング言語における標準のランタイムライブラリ・ルーチンの多くで使用されるNULsの結果です。) 行終了文字としてNULsを使用する習慣が現在非常に確立されるので、メッセージはそれらの上に保存されながら、当てにされるべきではありません。
(4) TAB (HT) characters may be misinterpreted or may be
automatically converted to variable numbers of spaces.
This is unavoidable in some environments, notably those
not based on the US-ASCII character set. Such
conversion is STRONGLY DISCOURAGED, but it may occur,
and mail formats must not rely on the persistence of
TAB (HT) characters.
(4) TAB(HT)キャラクタは、誤解されるか、または自動的に可変数の空間に変換されるかもしれません。 これはいくつかの環境、著しく米国-ASCII文字の組に基づかないもので避けられません。 起こるかもしれません、そして、そのような変換はSTRONGLY DISCOURAGEDですが、メール書式はTAB(HT)キャラクタの固執に依存してはいけません。
(5) Lines longer than 76 characters may be wrapped or
truncated in some environments. Line wrapping or line
truncation imposed by mail transports is STRONGLY
DISCOURAGED, but unavoidable in some cases.
Applications which require long lines must somehow
(5) 76のキャラクタより長い線は、いくつかの環境で包装されるか、または先端を切られるかもしれません。 いくつかの場合、メール輸送で課された線ラッピングか系列トランケーションが、STRONGLY DISCOURAGEDにもかかわらず、避けられません。 長い系列を必要とするアプリケーションはどうにかそうしなければなりません。
Freed & Borenstein Standards Track [Page 7] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[7ページ]RFC2049は順応1996年11月にまねます。
differentiate between soft and hard line breaks. (A
simple way to do this is to use the quoted-printable
encoding.)
柔らかくて困難なラインブレイクを区別してください。 (これをする簡単な方法は引用されて印刷可能なコード化を使用することです。)
(6) Trailing "white space" characters (SPACE, TAB (HT)) on
a line may be discarded by some transport agents, while
other transport agents may pad lines with these
characters so that all lines in a mail file are of
equal length. The persistence of trailing white space,
therefore, must not be relied on.
(6) 系列の引きずっている「余白」キャラクタ(SPACE、TAB(HT))は何人かの輸送エージェントによって捨てられるかもしれません、他の輸送エージェントがこれらのキャラクタと共に系列を水増しするかもしれないので、メールファイルのすべての系列が等しい長さのものですが。 したがって、引きずっている余白の固執に依存してはいけません。
(7) Many mail domains use variations on the US-ASCII
character set, or use character sets such as EBCDIC
which contain most but not all of the US-ASCII
characters. The correct translation of characters not
in the "invariant" set cannot be depended on across
character converting gateways. For example, this
situation is a problem when sending uuencoded
information across BITNET, an EBCDIC system. Similar
problems can occur without crossing a gateway, since
many Internet hosts use character sets other than US-
ASCII internally. The definition of Printable Strings
in X.400 adds further restrictions in certain special
cases. In particular, the only characters that are
known to be consistent across all gateways are the 73
characters that correspond to the upper and lower case
letters A-Z and a-z, the 10 digits 0-9, and the
following eleven special characters:
(7) 多くのメール・ドメインが、米国-ASCII文字の組の変化を使用するか、または米国-ASCII文字の大部分にもかかわらず、すべてを含むというわけではないEBCDICなどの文字集合を使用します。 ゲートウェイを変換するキャラクタの向こう側に「不変式」セットでキャラクタに関する正しい訳に依存できます。 送付がBitnet、EBCDICシステムの向こう側に情報をuuencodedしたとき、例えば、この状況は問題です。 多くのインターネット・ホストが内部的に米国ASCIIを除いた文字集合を使用するのでゲートウェイを越えないで、同様の問題は起こることができます。 X.400とのPrintable Stringsの定義はある特別な場合におけるさらなる制限を加えます。 すべてのゲートウェイの向こう側に一貫しているのが知られている唯一のキャラクタが、特に、上側と小文字A-Zと1zに文通する73のキャラクタと、10ケタ0-9と、以下の11の特殊文字です:
"'" (US-ASCII decimal value 39)
"(" (US-ASCII decimal value 40)
")" (US-ASCII decimal value 41)
"+" (US-ASCII decimal value 43)
"," (US-ASCII decimal value 44)
"-" (US-ASCII decimal value 45)
"." (US-ASCII decimal value 46)
"/" (US-ASCII decimal value 47)
":" (US-ASCII decimal value 58)
"=" (US-ASCII decimal value 61)
"?" (US-ASCII decimal value 63)
「「'」 「「+」 (米国-ASCIIデシマル値39)「(「(米国-ASCIIデシマル値40)」)」(米国-ASCIIデシマル値41)(米国-ASCIIデシマル値43)」、(米国-ASCIIデシマル値44)「-」(米国-ASCIIデシマル値45)」。」' (米国-ASCIIデシマル値46) 「「/」(米国-ASCIIデシマル値47)」:、」 (米国-ASCIIデシマル値58) “?"と「等しい」(米国-ASCIIデシマル値61)。 (米国-ASCIIデシマル値63)
A maximally portable mail representation will confine
itself to relatively short lines of text in which the
only meaningful characters are taken from this set of
73 characters. The base64 encoding follows this rule.
最高に携帯用のメール表現はそれ自体を唯一の重要なキャラクタが73のキャラクタのこのセットから取られるテキストの比較的短い系列に制限するでしょう。 base64コード化はこの規則に従います。
(8) Some mail transport agents will corrupt data that
includes certain literal strings. In particular, a
(8) 何人かのメール輸送エージェントが、ある文字通りのストリングを含んでいるデータを崩壊させるでしょう。 特にa
Freed & Borenstein Standards Track [Page 8] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[8ページ]RFC2049は順応1996年11月にまねます。
period (".") alone on a line is known to be corrupted
by some (incorrect) SMTP implementations, and a line
that starts with the five characters "From " (the fifth
character is a SPACE) are commonly corrupted as well.
A careful composition agent can prevent these
corruptions by encoding the data (e.g., in the quoted-
printable encoding using "=46rom " in place of "From "
at the start of a line, and "=2E" in place of "." alone
on a line).
以上、(「」、)、aでは、単独で、いくつかの(不正確)のSMTP実装、および5つのキャラクタから始まる系列によって系列が崩壊されるのが知られている、「」 (5番目のキャラクタはaスペースです) また、一般的に、崩壊します。 に代わって系列の始めにおいて「に代わって「慎重な構成エージェントがデータをコード化することによってこれらの贈収賄を防ぐことができる、(例えば、「=46rom」を使用する引用された印刷可能なコード化、」、「=2E」、」、」、系列で単独である、)
Please note that the above list is NOT a list of recommended practices for MTAs. RFC 821 MTAs are prohibited from altering the character of white space or wrapping long lines. These BAD and invalid practices are known to occur on established networks, and implementations should be robust in dealing with the bad effects they can cause.
上記のリストはMTAsのための推奨案のリストではありません。 RFC821MTAsは余白のキャラクタを変更するか、または長い系列を包装するのが禁止されています。 これらのBADと無効の習慣が既存のネットワークに起こるのが知られて、実装はそれらが引き起こす場合がある悪い効果に対処するのにおいて強健であるべきです。
4. Canonical Encoding Model
4. 正準なコード化はモデル化されます。
There was some confusion, in earlier versions of these documents, regarding the model for when email data was to be converted to canonical form and encoded, and in particular how this process would affect the treatment of CRLFs, given that the representation of newlines varies greatly from system to system. For this reason, a canonical model for encoding is presented below.
何らかの混乱がありました、これらのドキュメントの以前のバージョンで、メールデータがいつ標準形に変換されて、コード化されるかことであり、特に、このプロセスがどのようにCRLFsの処理に影響するかモデルに関して、システムによってニューラインの表現が大いに異なるなら。 この理由で、コード化のための規範的モデルは以下に提示されます。
The process of composing a MIME entity can be modeled as being done in a number of steps. Note that these steps are roughly similar to those steps used in PEM [RFC-1421] and are performed for each "innermost level" body:
多くのステップでするとしてMIME実体を構成するプロセスをモデル化できます。 これらのステップがおよそPEM[RFC-1421]で使用されるそれらのステップと同様であり、各「最も奥深いレベル」ボディーのために実行されることに注意してください:
(1) Creation of local form.
(1) 地方のフォームの作成。
The body to be transmitted is created in the system's
native format. The native character set is used and,
where appropriate, local end of line conventions are
used as well. The body may be a UNIX-style text file,
or a Sun raster image, or a VMS indexed file, or audio
data in a system-dependent format stored only in
memory, or anything else that corresponds to the local
model for the representation of some form of
information. Fundamentally, the data is created in the
"native" form that corresponds to the type specified by
the media type.
伝えられるべきボディーはシステムのネイティブの形式で作成されます。 ネイティブの文字集合は使用されています、そして、また、適切であるところでは、地方の行末コンベンションが使用されます。 ボディーは、UNIX-スタイルテキストファイルか、Sunラスター・イメージであるかもしれませんVMSがファイルに索引をつけたか、またはシステム依存する形式のオーディオデータが何らかのフォームの情報の表現のためのローカルのモデルに文通されるメモリ、または他の何かだけを蓄えました。 基本的に、データはメディアタイプによって指定されたタイプに文通される「ネイティブ」のフォームで作成されます。
Freed & Borenstein Standards Track [Page 9] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[9ページ]RFC2049は順応1996年11月にまねます。
(2) Conversion to canonical form.
(2) 標準形への変換。
The entire body, including "out-of-band" information
such as record lengths and possibly file attribute
information, is converted to a universal canonical
form. The specific media type of the body as well as
its associated attributes dictate the nature of the
canonical form that is used. Conversion to the proper
canonical form may involve character set conversion,
transformation of audio data, compression, or various
other operations specific to the various media types.
If character set conversion is involved, however, care
must be taken to understand the semantics of the media
type, which may have strong implications for any
character set conversion, e.g. with regard to
syntactically meaningful characters in a text subtype
other than "plain".
「バンドの外に」レコード長やことによるとファイル属性情報の情報を含む全身は普遍的な標準形に変換されます。 関連属性と同様にボディーの特定のメディアタイプは使用された標準形の本質を決めます。 適切な標準形への変換は文字集合変換にかかわるかもしれません、とオーディオデータ、圧縮、または様々なメディアに特定の他の様々な操作の変換がタイプします。 しかしながら、文字集合変換がかかわるなら、メディアタイプの意味論を理解するために注意しなければなりません、例えば、「平野」を除いたテキスト「副-タイプ」のシンタクス上重要なキャラクタに関して。タイプはどんな文字集合変換のための強い意味も持っているかもしれません。
For example, in the case of text/plain data, the text
must be converted to a supported character set and
lines must be delimited with CRLF delimiters in
accordance with RFC 822. Note that the restriction on
line lengths implied by RFC 822 is eliminated if the
next step employs either quoted-printable or base64
encoding.
例えば、テキスト/明瞭なデータの場合では、サポートしている文字集合にテキストを変換しなければなりません、そして、RFC822によると、CRLFデリミタで系列を区切らなければなりません。 次のステップが引用されて印刷可能であるかbase64コード化を使うならRFC822によって含意された行長における制限が排除されることに注意してください。
(3) Apply transfer encoding.
(3) 転送コード化を適用してください。
A Content-Transfer-Encoding appropriate for this body
is applied. Note that there is no fixed relationship
between the media type and the transfer encoding. In
particular, it may be appropriate to base the choice of
base64 or quoted-printable on character frequency
counts which are specific to a given instance of a
body.
これに、適切なContent転送コード化ボディーは適用されています。 メディアタイプと転送コード化との固定関係が全くないことに注意してください。 base64かボディーの与えられたインスタンスに特定のキャラクタで印刷可能な頻度数の選択を基礎づけるのは特に、適切であるかもしれません。
(4) Insertion into entity.
(4) 実体への挿入。
The encoded body is inserted into a MIME entity with
appropriate headers. The entity is then inserted into
the body of a higher-level entity (message or
multipart) as needed.
コード化されたボディーは適切なヘッダーと共にMIME実体に挿入されます。 そして、実体は必要に応じてよりハイレベルの実体(メッセージの、または、複合の)のボディーに挿入されます。
Conversion from entity form to local form is accomplished by reversing these steps. Note that reversal of these steps may produce differing results since there is no guarantee that the original and final local forms are the same.
実体フォームから地方のフォームまでの変換は、これらのステップを逆にすることによって、実行されます。 オリジナル的、そして、最終的な地方のフォームが同じであるという保証が全くないのでこれらのステップの反転が異なった結果を生むかもしれないことに注意してください。
Freed & Borenstein Standards Track [Page 10] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[10ページ]RFC2049は順応1996年11月にまねます。
It is vital to note that these steps are only a model; they are specifically NOT a blueprint for how an actual system would be built. In particular, the model fails to account for two common designs:
これらのステップがモデルにすぎないことに注意するのは重大です。 それらは、明確に実際のシステムがどう構築されるか青写真ではありません。 特に、モデルは2つの一般的なデザインを説明しません:
(1) In many cases the conversion to a canonical form prior
to encoding will be subsumed into the encoder itself,
which understands local formats directly. For example,
the local newline convention for text bodies might be
carried through to the encoder itself along with
knowledge of what that format is.
(1) 多くの場合、コード化の前の標準形への変換はエンコーダ自体に包括されるでしょう。(それは、直接地方の形式を理解しています)。 例えば、テキスト本文のための地方のニューラインコンベンションはその形式が何であるかに関する知識に伴うエンコーダ自体に突き抜けた状態で運ばれるかもしれません。
(2) The output of the encoders may have to pass through one
or more additional steps prior to being transmitted as
a message. As such, the output of the encoder may not
be conformant with the formats specified by RFC 822.
In particular, once again it may be appropriate for the
converter's output to be expressed using local newline
conventions rather than using the standard RFC 822 CRLF
delimiters.
(2) エンコーダの出力はメッセージとして伝えられる前に、1個以上の追加階段を通り抜けなければならないかもしれません。 そういうものとして、エンコーダの出力は形式がRFC822によって指定されているconformantでないかもしれません。 もう一度、コンバータの出力が急送されるのは、標準のRFC822CRLFデリミタを使用するよりむしろ地方のニューラインコンベンションを使用するのにおいて特に、適切であるかもしれません。
Other implementation variations are conceivable as well. The vital aspect of this discussion is that, in spite of any optimizations, collapsings of required steps, or insertion of additional processing, the resulting messages must be consistent with those produced by the model described here. For example, a message with the following header fields:
また、他の実現変化は想像できます。 この議論の重大な局面は必要なステップ、または追加処理の挿入のcollapsings、どんな最適化にもかかわらずも、結果として起こるメッセージがここで説明されたモデルによって生産されるそれらと一致しているに違いないということです。 例えば、以下のヘッダーがあるメッセージは以下をさばきます。
Content-type: text/foo; charset=bar
Content-Transfer-Encoding: base64
文書内容: テキスト/foo。 charsetはバーContent転送コード化と等しいです: base64
must be first represented in the text/foo form, then (if necessary) represented in the "bar" character set, and finally transformed via the base64 algorithm into a mail-safe form.
「バー」文字の組で最初に、テキスト/fooフォームに表されて、次に、(必要なら、)表さなければならなくて、メール安全なフォームへのbase64アルゴリズムで変えられて、最終的に表してください。
NOTE: Some confusion has been caused by systems that represent messages in a format which uses local newline conventions which differ from the RFC822 CRLF convention. It is important to note that these formats are not canonical RFC822/MIME. These formats are instead *encodings* of RFC822, where CRLF sequences in the canonical representation of the message are encoded as the local newline convention. Note that formats which encode CRLF sequences as, for example, LF are not capable of representing MIME messages containing binary data which contains LF octets not part of CRLF line separation sequences.
以下に注意してください。 何らかの混乱がRFC822 CRLFコンベンションと異なっている地方のニューラインコンベンションを使用する形式でメッセージを表すシステムによって引き起こされました。 これらの形式が正準なRFC822/MIMEでないことに注意するのは重要です。 これらの形式は代わりにRFC822の*encodings*です。そこでは、メッセージの正準な表現におけるCRLF系列が地方のニューラインコンベンションとしてコード化されます。 例えば、LFとしてCRLF系列をコード化する形式が部分ではなく、CRLF線分離系列のLF八重奏を含む2進のデータを含むMIMEメッセージを表すことができないことに注意してください。
Freed & Borenstein Standards Track [Page 11] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[11ページ]RFC2049は順応1996年11月にまねます。
5. Summary
5. 概要
This document defines what is meant by MIME Conformance. It also details various problems known to exist in the Internet email system and how to use MIME to overcome them. Finally, it describes MIME's canonical encoding model.
このドキュメントはMIME Conformanceによって意味されることを定義します。 また、それはインターネットメールシステムに存在するのが知られている様々な問題とそれらに打ち勝つのにどうMIMEを使用するかを詳しく述べます。 最終的に、それは、モデルをコード化しながら、正準な状態でMIMEのものについて説明します。
6. Security Considerations
6. セキュリティ問題
Security issues are discussed in the second document in this set, RFC 2046.
このセット、RFC2046における2番目のドキュメントで安全保障問題について議論します。
7. Authors' Addresses
7. 作者のアドレス
For more information, the authors of this document are best contacted via Internet mail:
詳しくは、インターネット・メールでこのドキュメントの作者に連絡するのは最も良いです:
Ned Freed Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790 USA
ネッドは東ガーヴェーアベニューSouth West Innosoftの国際Inc.1050カリフォルニア91790コビーナ(米国)を解放しました。
Phone: +1 818 919 3600 Fax: +1 818 919 3614 EMail: ned@innosoft.com
以下に電話をしてください。 +1 818 919、3600Fax: +1 3614年の818 919メール: ned@innosoft.com
Nathaniel S. Borenstein First Virtual Holdings 25 Washington Avenue Morristown, NJ 07960 USA
ナザニエルS.Borensteinファースト・バーチャル持ち株25ワシントン・Avenueニュージャージー07960モリスタウン(米国)
Phone: +1 201 540 8967 Fax: +1 201 993 3032 EMail: nsb@nsb.fv.com
以下に電話をしてください。 +1 201 540、8967Fax: +1 3032年の201 993メール: nsb@nsb.fv.com
MIME is a result of the work of the Internet Engineering Task Force Working Group on RFC 822 Extensions. The chairman of that group, Greg Vaudreuil, may be reached at:
MIMEはRFC822Extensionsへのインターネット・エンジニアリング・タスク・フォース作業部会の作業の結果です。 そのグループ、グレッグ・ボードルイの議長は以下で連絡されるかもしれません。
Gregory M. Vaudreuil Octel Network Services 17080 Dallas Parkway Dallas, TX 75248-1905 USA
グレゴリーM.ボードルイのOctelネットワーク・サービス17080ダラスParkwayテキサス75248-1905ダラス(米国)
EMail: Greg.Vaudreuil@Octel.Com
メール: Greg.Vaudreuil@Octel.Com
Freed & Borenstein Standards Track [Page 12] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[12ページ]RFC2049は順応1996年11月にまねます。
8. Acknowledgements
8. 承認
This document is the result of the collective effort of a large number of people, at several IETF meetings, on the IETF-SMTP and IETF-822 mailing lists, and elsewhere. Although any enumeration seems doomed to suffer from egregious omissions, the following are among the many contributors to this effort:
このドキュメントはIETF-SMTPとIETF-822メーリングリストの上とほかの場所でのいくつかのIETFミーティングにおける多くの人々の結集した力の結果です。 どんな列挙もとてもひどい省略に苦しむのが運命づけられるように思えますが、以下はこの努力への多くの貢献者の中のひとりです:
Harald Tveit Alvestrand Marc Andreessen
Randall Atkinson Bob Braden
Philippe Brandon Brian Capouch
Kevin Carosso Uhhyung Choi
Peter Clitherow Dave Collier-Brown
Cristian Constantinof John Coonrod
Mark Crispin Dave Crocker
Stephen Crocker Terry Crowley
Walt Daniels Jim Davis
Frank Dawson Axel Deininger
Hitoshi Doi Kevin Donnelly
Steve Dorner Keith Edwards
Chris Eich Dana S. Emery
Johnny Eriksson Craig Everhart
Patrik Faltstrom Erik E. Fair
Roger Fajman Alain Fontaine
Martin Forssen James M. Galvin
Stephen Gildea Philip Gladstone
Thomas Gordon Keld Simonsen
Terry Gray Phill Gross
James Hamilton David Herron
Mark Horton Bruce Howard
Bill Janssen Olle Jarnefors
Risto Kankkunen Phil Karn
Alan Katz Tim Kehres
Neil Katin Steve Kille
Kyuho Kim Anders Klemets
John Klensin Valdis Kletniek
Jim Knowles Stev Knowles
Bob Kummerfeld Pekka Kytolaakso
Stellan Lagerstrom Vincent Lau
Timo Lehtinen Donald Lindsay
Warner Losh Carlyn Lowery
Laurence Lundblade Charles Lynn
John R. MacMillan Larry Masinter
Rick McGowan Michael J. McInerny
Leo Mclaughlin Goli Montaser-Kohsari
Tom Moore John Gardiner Myers
Erik Naggum Mark Needleman
Chris Newman John Noerenberg
ハラルドTveit AlvestrandマークアンドリーセンランドルアトキンソンボブブレーデンフィリップブランドンブライアンCapouchケビンCarosso Uhhyungチェピータークリゼロウデーヴ石炭船ブラウンクリスチャンConstantinofジョンCoonrodは、クリスピン・デーヴ・Crockerスティーブン・Crockerテリー・クローリー・ウォルト・ダニエル・ジム・デイヴィス・フランク・ドーソン・Axel Deininger等・土井・ケビン・ドネリー・スティーブ・デルナー・キース・エドワーズクリス・アイヒ・ダナ・S.Emeryジョニー・エリクソン・クレイグ・エバーハート・パトリク・Faltstromエリックが公正なE.のFajmanアラン・フォンテーヌマーチン・ForssenロジャージェームスMであるとマークします; ガルビン・スティーブン・Gildeaフィリップ・Gladstoneトーマス・ゴードン・Keldシモンセン・タオルグレー・フィルGrossのジェームスハミルトンデヴィッドハーロンマークホートンブルース・ハワード・ビル・ジャンセン・オッレ・Jarnefors Ristoカンクネン・フィル・Karnアラン・キャッツ・ティム・Kehresニール・ケーティン・スティーブ・Kille Kyuhoキム・アンダース・Klemetsジョン・Klensinヴァルディス・Kletniekジム・ノウルズ・Stevノウルズ・ボブ・Kummerfeldペッカ・Kytolaaksoステラン・Lagerstromヴィンセント・ラウ・ティモ・レーティネン・ドナルド・リンゼー・ワーナー・Losh Carlynローリー・ローレンス・Lundbladeチャールズ・リンジョンR; マクミランのラリー・Masinterリック・マガウアン・マイケルJ。McInernyレオMclaughlin Goli Montaser-KohsariトムムーアジョンガーディナーマイアーズエリックNaggumマークニードルマンクリスニューマンジョンNoerenberg
Freed & Borenstein Standards Track [Page 13] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[13ページ]RFC2049は順応1996年11月にまねます。
Mats Ohrman Julian Onions
Michael Patton David J. Pepper
Erik van der Poel Blake C. Ramsdell
Christer Romson Luc Rooijakkers
Marshall T. Rose Jonathan Rosenberg
Guido van Rossum Jan Rynning
Harri Salminen Michael Sanderson
Yutaka Sato Markku Savela
Richard Alan Schafer Masahiro Sekiguchi
Mark Sherman Bob Smart
Peter Speck Henry Spencer
Einar Stefferud Michael Stein
Klaus Steinberger Peter Svanberg
James Thompson Steve Uhler
Stuart Vance Peter Vanderbilt
Greg Vaudreuil Ed Vielmetti
Larry W. Virden Ryan Waldron
Rhys Weatherly Jay Weber
Dave Wecker Wally Wedel
Sven-Ove Westberg Brian Wideen
John Wobus Glenn Wright
Rayan Zachariassen David Zimmerman
マットOhrmanジュリアンアニアンズマイケルパットンデヴィッドJ.PepperエリックバンderポールブレークC.Ramsdell Christer RomsonリュックRooijakkersマーシャルT.ローズジョナサンローゼンバーググイドバンロスム1月のRynningハリーサルミネンマイケルサンダーソンユタカの佐藤・マルック・Savelaリチャード・アラン・シェッフル・正裕・Sekiguchi Mark Sherman・ボブ・Smartピーター・Speckヘンリー・スペンサー・Einar Stefferudマイケル・シタイン・クラウスシュタインバーガー・ピーター・スバンベルク・ジェームス・トンプソンスティーブ・Uhlerスチュアート・ヴァンス・ピーター・バンダービルトのグレッグ・ボードルイエド・VielmettiラリーW; バーデンライアン・ウォルドロン・リスWeatherlyのジェイ・グレン・職人のライアン・Zachariassenデヴィッド・ウェーバーデーヴWeckerウォリーウェデルスベン-OveウェストバーグブライアンWideenジョンWobusジンマーマン
The authors apologize for any omissions from this list, which are certainly unintentional.
作者はこのリストからのどんな省略も謝ります。(確かに、省略は意図的ではありません)。
Freed & Borenstein Standards Track [Page 14] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[14ページ]RFC2049は順応1996年11月にまねます。
Appendix A -- A Complex Multipart Example
付録A--複雑な複合例
What follows is the outline of a complex multipart message. This message contains five parts that are to be displayed serially: two introductory plain text objects, an embedded multipart message, a text/enriched object, and a closing encapsulated text message in a non-ASCII character set. The embedded multipart message itself contains two objects to be displayed in parallel, a picture and an audio fragment.
続くことは複雑な複合メッセージのアウトラインです。 このメッセージは順次表示されることになっている5つの部品を含んでいます: 2個の紹介しているプレーンテキスト物、埋め込まれた複合メッセージ、テキスト/豊かにされた物、および閉鎖は非ASCII文字の組のテキストメッセージを要約しました。 埋め込まれた複合メッセージ自体は平行に表示されるべき2個の物、絵、およびオーディオ断片を含んでいます。
MIME-Version: 1.0
From: Nathaniel Borenstein <nsb@nsb.fv.com>
To: Ned Freed <ned@innosoft.com>
Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
Subject: A multipart example
Content-Type: multipart/mixed;
boundary=unique-boundary-1
MIMEバージョン: 1.0 From: ナザニエル Borenstein <nsb@nsb.fv.com 、gt;、To: ネッド Freed <ned@innosoft.com 、gt;、日付: 金曜日、1994年10月7日16:15:05 -0700(太平洋夏時間の)のSubject: 複合例のコンテントタイプ: 複合か混ぜられる。 ユニークな境界-1の境界=
This is the preamble area of a multipart message.
Mail readers that understand multipart format
should ignore this preamble.
これは複合メッセージの序文部門です。 複合形式がこの序文を無視するべきであるのを理解している読者に郵送してください。
If you are reading this text, you might want to
consider changing to a mail reader that understands
how to properly display multipart messages.
本稿を読んでいるなら、あなたは、適切に複合メッセージを表示する方法を理解しているメール読者に変化すると考えたがっているかもしれません。
--unique-boundary-1
--ユニークな境界1
... Some text appears here ...
... 何らかのテキストがここに現れます…
[Note that the blank between the boundary and the start
of the text in this part means no header fields were
given and this is text in the US-ASCII character set.
It could have been done with explicit typing as in the
next part.]
[この部分のテキストの境界と始まりの間の空白がヘッダーフィールドを全く与えないで、これが米国-ASCII文字の組のテキストであることを意味することに注意してください。 次の部分のように明白なタイプでそれをしたかもしれません。]
--unique-boundary-1
Content-type: text/plain; charset=US-ASCII
--ユニークな境界1文書内容: テキスト/平野。 charsetは米国-ASCIIと等しいです。
This could have been part of the previous part, but
illustrates explicit versus implicit typing of body
parts.
これは、前の部分の一部であったかもしれませんが、身体の部分の暗黙の型宣言に対して明白な状態で例証します。
--unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2
--ユニークな境界1コンテントタイプ: 複合/平行線。 ユニークな境界-2の境界=
--unique-boundary-2
Content-Type: audio/basic
--ユニークな境界2コンテントタイプ: オーディオ的であるか、または基本的です。
Freed & Borenstein Standards Track [Page 15] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[15ページ]RFC2049は順応1996年11月にまねます。
Content-Transfer-Encoding: base64
満足している転送コード化: base64
... base64-encoded 8000 Hz single-channel
mu-law-format audio data goes here ...
… 8000Hzのbase64によってコード化された単独のチャンネルμ法の形式オーディオデータはここに行きます…
--unique-boundary-2
Content-Type: image/jpeg
Content-Transfer-Encoding: base64
--ユニークな境界2コンテントタイプ: jpeg Content転送イメージ/コード化: base64
... base64-encoded image data goes here ...
… base64によってコード化されたイメージデータはここに行きます…
--unique-boundary-2--
--ユニークな境界2--
--unique-boundary-1
Content-type: text/enriched
--ユニークな境界1文書内容: テキスト/豊かにされます。
This is <bold><italic>enriched.</italic></bold>
<smaller>as defined in RFC 1896</smaller>
これによる<の大胆な><イタリック体の>が、よりRFC1896</小さい>で定義されるように. </イタリック体の></大胆な><より小さい>を豊かにしたということです。
Isn't it
<bigger><bigger>cool?</bigger></bigger>
<の、より大きい><より大きい>冷静?それは、よりより</大きい></大きい>ではありませんか?
--unique-boundary-1
Content-Type: message/rfc822
--ユニークな境界1コンテントタイプ: メッセージ/rfc822
From: (mailbox in US-ASCII)
To: (address in US-ASCII)
Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable
From: (米国-ASCIIにおけるメールボックス) To: (米国-ASCIIにおけるアドレス) Subject: (米国-ASCIIにおける対象) コンテントタイプ: テキスト/平野。 charset=ISO-8859-1の満足している転送コード化: 引用されて印刷可能です。
... Additional text in ISO-8859-1 goes here ...
... ISO-8859-1の追加テキストはここに続きます…
--unique-boundary-1--
--ユニークな境界1--
Appendix B -- Changes from RFC 1521, 1522, and 1590
付録B--RFC1521、1522、および1590年からの変化
These documents are a revision of RFC 1521, 1522, and 1590. For the convenience of those familiar with the earlier documents, the changes from those documents are summarized in this appendix. For further history, note that Appendix H in RFC 1521 specified how that document differed from its predecessor, RFC 1341.
これらのドキュメントはRFC1521、1522、および1590年の改正です。 以前のドキュメントになじみ深いそれらの都合のために、それらのドキュメントからの変化はこの付録にまとめられます。 さらなる歴史によって、RFC1521のAppendix Hがそのドキュメントがどう前任者、RFC1341と異なっていたかを指定したことに注意してください。
(1) This document has been completely reformatted and split
into multiple documents. This was done to improve the
quality of the plain text version of this document,
which is required to be the reference copy.
(1) このドキュメントは、完全に再フォーマットされて、複数のドキュメントに分けられました。 このドキュメントのプレーンテキストバージョンの品質を改良するためにこれをしました。ドキュメントが参照コピーであることが必要です。
Freed & Borenstein Standards Track [Page 16] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[16ページ]RFC2049は順応1996年11月にまねます。
(2) BNF describing the overall structure of MIME object
headers has been added. This is a documentation change
only -- the underlying syntax has not changed in any
way.
(2) MIME物のヘッダーの全体的な構造について説明するBNFが加えられます。 これはドキュメンテーション変化専用です--基本的な構文は何らかの方法で変化していません。
(3) The specific BNF for the seven media types in MIME has
been removed. This BNF was incorrect, incomplete, amd
inconsistent with the type-indendependent BNF. And
since the type-independent BNF already fully specifies
the syntax of the various MIME headers, the type-
specific BNF was, in the final analysis, completely
unnecessary and caused more problems than it solved.
(3) MIMEにおける7つのメディアタイプのための特定のBNFは取り外されました。 このBNFはタイプ-indendependent BNFに矛盾した不正確で、不完全なamdでした。 そして、タイプから独立しているBNFが既に構文を完全に指定するので、タイプの特定のBNFは様々なMIMEヘッダーでは、最終分析で完全に不要であり、解決したより多くの問題を引き起こしました。
(4) The more specific "US-ASCII" character set name has
replaced the use of the informal term ASCII in many
parts of these documents.
(4) より特定の「米国-ASCII」文字の組名はこれらのドキュメントの多くの部分でのASCIIという非公式の用語の使用を取り替えました。
(5) The informal concept of a primary subtype has been
removed.
(5) 第一の「副-タイプ」の非公式の概念を取り除いてあります。
(6) The term "object" was being used inconsistently. The
definition of this term has been clarified, along with
the related terms "body", "body part", and "entity",
and usage has been corrected where appropriate.
(6) 「物」という用語は相反して使用されていました。 今期の定義は「ボディー」という関連する用語、「身体の部分」、および「実体」と共にはっきりさせられました、そして、適切であるところで用法を修正してあります。
(7) The BNF for the multipart media type has been
rearranged to make it clear that the CRLF preceeding
the boundary marker is actually part of the marker
itself rather than the preceeding body part.
(7) 複合メディアタイプのためのBNFがそれについて断言するために再配列された、CRLF preceeding、境界マーカーは実際にpreceeding身体の部分よりむしろマーカー自身の一部です。
(8) The prose and BNF describing the multipart media type
have been changed to make it clear that the body parts
within a multipart object MUST NOT contain any lines
beginning with the boundary parameter string.
(8) 複合物の中の身体の部分が境界パラメタひもで始まるどんな線も含んではいけないと断言するために複合メディアタイプについて説明する散文とBNFを変えました。
(9) In the rules on reassembling "message/partial" MIME
entities, "Subject" is added to the list of headers to
take from the inner message, and the example is
modified to clarify this point.
(9) 「メッセージ/部分的な」MIME実体を組み立て直すときの規則で、「対象」は内側のメッセージから連れて行くヘッダーのリストに追加されます、そして、例は、このポイントをはっきりさせるように変更されます。
(10) "Message/partial" fragmenters are restricted to
splitting MIME objects only at line boundaries.
(10) 「メッセージ/部分的な」fragmentersは線限界だけでMIME物を分けるのに制限されます。
(11) In the discussion of the application/postscript type,
an additional paragraph has been added warning about
possible interoperability problems caused by embedding
of binary data inside a PostScript MIME entity.
(11) アプリケーション/追伸タイプの議論では、追加パラグラフは、2進のデータがポストスクリプトMIME実体で埋め込まれていることによって引き起こされた可能な相互運用性問題を警告しながら、加えられます。
Freed & Borenstein Standards Track [Page 17] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[17ページ]RFC2049は順応1996年11月にまねます。
(12) Added a clarifying note to the basic syntax rules for
the Content-Type header field to make it clear that the
following two forms:
(12) 加えられて、コンテントタイプヘッダーフィールドが、以下の2が形成されると断言するように、基本的な構文へのはっきりさせる注意は統治されます:
Content-type: text/plain; charset=us-ascii (comment)
文書内容: テキスト/平野。 charsetが私たちと等しい、-、ASCII(コメント)
Content-type: text/plain; charset="us-ascii"
文書内容: テキスト/平野。 charsetが等しい、「私たち、-、ASCII、」
are completely equivalent.
完全に同等物はそうですか?
(13) The following sentence has been removed from the
discussion of the MIME-Version header: "However,
conformant software is encouraged to check the version
number and at least warn the user if an unrecognized
MIME-version is encountered."
(13) MIMEバージョンヘッダーの議論から以下の文を取り除いてあります: 「しかしながら、認識されていないMIMEバージョンが遭遇するなら、conformantソフトウェアは、バージョン番号をチェックして、ユーザに少なくとも警告するよう奨励されます。」
(14) A typo was fixed that said "application/external-body"
instead of "message/external-body".
(14) 「外部のメッセージ/ボディー」の代わりにその前述の「外部のアプリケーション/ボディー」は誤植に固定されました。
(15) The definition of a character set has been reorganized
to make the requirements clearer.
(15) 文字の組の定義は、要件を明らかにするために再編成されました。
(16) The definition of the "image/gif" media type has been
moved to a separate document. This change was made
because of potential conflicts with IETF rules
governing the standardization of patented technology.
(16) 「イメージ/gif」メディアタイプの定義は別々のドキュメントに動かされました。 この変更は特許で保護された技術の標準化を治めるIETF規則との潜在的闘争のために行われました。
(17) The definitions of "7bit" and "8bit" have been
tightened so that use of bare CR, LF can only be used
as end-of-line sequences. The document also no longer
requires that NUL characters be preserved, which brings
MIME into alignment with real-world implementations.
(17) むき出しのCRのその使用であり「7ビット」と「8ビット」の定義がきびしくされたので、行末系列としてLFを使用できるだけです。 また、ドキュメントは、もうNULキャラクタが保持されるのを必要としません(本当の世界実現に応じて、MIMEを整列に運び込みます)。
(18) The definition of canonical text in MIME has been
tightened so that line breaks must be represented by a
CRLF sequence. CR and LF characters are not allowed
outside of this usage. The definition of quoted-
printable encoding has been altered accordingly.
(18) MIMEとの正準なテキストの定義がきびしくされたので、CRLF系列でラインブレイクを表さなければなりません。 CRとLFキャラクタはこの用法の外に許容されていません。 引用された印刷可能なコード化の定義はそれに従って、変更されました。
(19) The definition of the quoted-printable encoding now
includes a number of suggestions for how quoted-
printable encoders might best handle improperly encoded
material.
(19) 引用されて印刷可能なコード化の定義は現在、引用された印刷可能なエンコーダがどう不適切にコード化された材料を最もよく扱うことができるように多くの提案を含んでいるか。
(20) Prose was added to clarify the use of the "7bit",
"8bit", and "binary" transfer-encodings on multipart or
message entities encapsulating "8bit" or "binary" data.
(20) 散文は、「8ビット」か「2進」のデータを要約しながら複合かメッセージ実体で「7ビット」、「8ビット」、および「2進」の転送-encodingsの使用をはっきりさせるために加えられました。
Freed & Borenstein Standards Track [Page 18] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[18ページ]RFC2049は順応1996年11月にまねます。
(21) In the section on MIME Conformance, "multipart/digest"
support was added to the list of requirements for
minimal MIME conformance. Also, the requirement for
"message/rfc822" support were strengthened to clarify
the importance of recognizing recursive structure.
(21) MIME Conformanceの上のセクションで、「複合/ダイジェスト」サポートは最小量のMIME順応のための要件のリストに追加されました。 また、「メッセージ/rfc822」サポートのための要件は、再帰的な構造を認識する重要性をはっきりさせるために強化されました。
(22) The various restrictions on subtypes of "message" are
now specified entirely on a subtype by subtype basis.
(22) 「メッセージ」の血液型亜型における様々な制限は現在、完全に「副-タイプ」で「副-タイプ」基礎によって指定されます。
(23) The definition of "message/rfc822" was changed to
indicate that at least one of the "From", "Subject", or
"Date" headers must be present.
(23) 少なくとも“From"、「対象」、または「日付」ヘッダーのひとりが存在していなければならないのを示すために「メッセージ/rfc822」の定義を変えました。
(24) The required handling of unrecognized subtypes as
"application/octet-stream" has been made more explicit
in both the type definitions sections and the
conformance guidelines.
(24) 「八重奏アプリケーション/流れ」としての認識されていない血液型亜型の必要な取り扱いを型定義部と順応ガイドラインの両方では、より明白にしました。
(25) Examples using text/richtext were changed to
text/enriched.
(25) テキスト/richtextを使用する例を、テキストに変えたか、または豊かにしました。
(26) The BNF definition of subtype has been changed to make
it clear that either an IANA registered subtype or a
nonstandard "X-" subtype must be used in a Content-Type
header field.
(26) IANAが「副-タイプ」を登録しなければならなかったか、またはコンテントタイプヘッダーフィールドに標準的でない「X」「副-タイプ」を使用しなければならないと断言するために「副-タイプ」のBNF定義を変えました。
(27) MIME media types that are simply registered for use and
those that are standardized by the IETF are now
distinguished in the MIME BNF.
(27) 使用のために単に示されるMIMEメディアタイプとIETFによって標準化されるものは現在、MIME BNFで区別されます。
(28) All of the various MIME registration procedures have
been extensively revised. IANA registration procedures
for character sets have been moved to a separate
document that is no included in this set of documents.
(28) 様々なMIME登録手順のすべてが手広く改訂されました。 文字の組のためのIANA登録手順はこのセットのドキュメントに含まれていない別々のドキュメントに動かされました。
(29) The use of escape and shift mechanisms in the US-ASCII
and ISO-8859-X character sets these documents define
have been clarified: Such mechanisms should never be
used in conjunction with these character sets and their
effect if they are used is undefined.
(29) これらのドキュメントが定義する米国-ASCIIとISO-8859-X文字の組におけるエスケープとシフトメカニズムの使用ははっきりさせられました: それらが使用されているならそのようなメカニズムがこれらの文字の組とそれらの効果に関連して決して使用されるべきでない、未定義です。
(30) The definition of the AFS access-type for
message/external-body has been removed.
(30) 外部のメッセージ/ボディーのためのAFSアクセス型の定義を取り除きました。
(31) The handling of the combination of
multipart/alternative and message/external-body is now
specifically addressed.
(31) 複合/代替手段と外部のメッセージ/ボディーの組み合わせの取り扱いは現在、明確に記述されます。
Freed & Borenstein Standards Track [Page 19] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[19ページ]RFC2049は順応1996年11月にまねます。
(32) Security issues specific to message/external-body are
now discussed in some detail.
(32) 現在、何らかの詳細に外部のメッセージ/ボディーに特定の安全保障問題について議論します。
Appendix C -- References
付録C--参照
[ATK]
Borenstein, Nathaniel S., Multimedia Applications
Development with the Andrew Toolkit, Prentice-Hall, 1990.
[ATK]Borenstein、ナザニエルS.、アンドリューツールキット、新米のホール、1990へのマルチメディア応用開発。
[ISO-2022]
International Standard -- Information Processing --
Character Code Structure and Extension Techniques,
ISO/IEC 2022:1994, 4th ed.
[ISO-2022]国際規格--情報Processing--キャラクターCode StructureとExtension Techniques、ISO/IEC、2022:1994 4番目の教育。
[ISO-8859]
International Standard -- Information Processing -- 8-bit
Single-Byte Coded Graphic Character Sets
- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed.
- Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed.
- Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed.
- Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed.
- Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1st
ed.
- Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed.
- Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed.
- Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed.
- Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1st
ed.
International Standard -- Information Technology -- 8-bit
Single-Byte Coded Graphic Character Sets
- Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992,
1st ed.
[ISO-8859] 世界規格--情報処理--8ビットの単一のバイトコード化された図形文字セット--第1部: ローマ字No.1、ISO8859-1: 1987、最初の教育。 - 第2部: ローマ字No.2、ISO8859-2: 1987、最初の教育。 - パート3: ローマ字No.3、ISO8859-3: 1988、最初の教育。 - パート4: ローマ字No.4、ISO8859-4: 1988、最初の教育。 - パート5: ラテン/キリル文字、ISO8859-5: 1988、最初の教育。 - パート6: ラテン語の、または、アラビアのAlphabet、ISO8859-6: 1987、最初の教育。 - パート7: ラテン語の、または、ギリシアのAlphabet、ISO8859-7: 1987、最初の教育。 - パート8: ラテン語の、または、ヘブライのAlphabet、ISO8859-8: 1988、最初の教育。 - パート9: ローマ字No.5、ISO/IEC8859-9: 1989、最初の教育。 国際規格--情報技術--8ビットの単一のバイトコード化された図形文字セット--パート10: ローマ字No.6、ISO/IEC8859-10: 1992、最初の教育。
[ISO-646]
International Standard -- Information Technology -- ISO
7-bit Coded Character Set for Information Interchange,
ISO 646:1991, 3rd ed..
[ISO-646]国際規格--情報Technology--情報Interchange、ISOのためのISOの7ビットのCoded文字コード、646:1991 3番目の教育。
[JPEG]
JPEG Draft Standard ISO 10918-1 CD.
[JPEG]JPEGは標準のISO10918-1CDを作成します。
[MPEG]
Video Coding Draft Standard ISO 11172 CD, ISO
IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May,
1991.
[MPEG]ビデオ符号化の草稿の標準のISO11172CD、ISO IEC/JTC1/SC2/WG11(エムペグ)、1991年5月。
Freed & Borenstein Standards Track [Page 20] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[20ページ]RFC2049は順応1996年11月にまねます。
[PCM]
CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code
Modulation (PCM) of Voice Frequencies", Geneva, 1972.
推薦G.711、「音声周波数のパルスコードの変調(PCM)」、ジュネーブ、[PCM]CCITT、分冊III.4--1972。
[POSTSCRIPT]
Adobe Systems, Inc., PostScript Language Reference
Manual, Addison-Wesley, 1985.
[追伸]アドビ・システムズInc.、ポストスクリプト言語リファレンスマニュアル、アディソン-ウエスリー、1985。
[POSTSCRIPT2]
Adobe Systems, Inc., PostScript Language Reference
Manual, Addison-Wesley, Second Ed., 1990.
[POSTSCRIPT2]アドビ・システムズInc.、ポストスクリプト言語リファレンスマニュアル、アディソン-ウエスリー、第2エド、1990
[RFC-783]
Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783,
MIT, June 1981.
[RFC-783]Sollins、K.R.、「TFTPプロトコル(改正2)」、RFC-783、MIT、1981年6月。
[RFC-821]
Postel, J.B., "Simple Mail Transfer Protocol", STD 10,
RFC 821, USC/Information Sciences Institute, August 1982.
[RFC-821]ポステル、J.B.、「簡単なメール転送プロトコル」、STD10、RFC821、科学が1982年8月に設けるUSC/情報。
[RFC-822]
Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822, UDEL, August 1982.
[RFC-822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。
[RFC-934]
Rose, M. and E. Stefferud, "Proposed Standard for Message
Encapsulation", RFC 934, Delaware and NMA, January 1985.
[RFC-934] ローズとM.とE.Stefferudと「メッセージカプセル化の提案された標準」とRFC934、デラウェアとNMA、1985年1月。
[RFC-959]
Postel, J. and J. Reynolds, "File Transfer Protocol", STD
9, RFC 959, USC/Information Sciences Institute, October
1985.
[RFC-959] 科学が1985年10月に任命するポステルとJ.とJ.レイノルズ、「ファイル転送プロトコル」、STD9、RFC959、USC/情報。
[RFC-1049]
Sirbu, M., "Content-Type Header Field for Internet
Messages", RFC 1049, CMU, March 1988.
[RFC-1049] シルブ、M.、「インターネットメッセージのためのコンテントタイプヘッダーフィールド」、RFC1049、米カーネギーメロン大学、1988年3月。
[RFC-1154]
Robinson, D., and R. Ullmann, "Encoding Header Field for
Internet Messages", RFC 1154, Prime Computer, Inc., April
1990.
[RFC-1154] ロビンソン、D.とR.ウルマン、「インターネットメッセージのためのヘッダーフィールドをコード化します」、RFC1154、プライムコンピュータInc.、1990年4月。
[RFC-1341]
Borenstein, N., and N. Freed, "MIME (Multipurpose
Internet Mail Extensions): Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", RFC
1341, Bellcore, Innosoft, June 1992.
[RFC-1341]Borenstein(N.、および解放されたN.)は「以下をまね(マルチパーパスインターネットメールエクステンション)」。 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1341、Bellcore、Innosoft、1992年6月。
Freed & Borenstein Standards Track [Page 21] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[21ページ]RFC2049は順応1996年11月にまねます。
[RFC-1342]
Moore, K., "Representation of Non-Ascii Text in Internet
Message Headers", RFC 1342, University of Tennessee, June
1992.
[RFC-1342] ムーア、K.、「インターネットメッセージヘッダーの非アスキーテキストの表現」、RFC1342、テネシー大学、1992年6月。
[RFC-1344]
Borenstein, N., "Implications of MIME for Internet Mail
Gateways", RFC 1344, Bellcore, June 1992.
[RFC-1344] Borenstein、N.、「インターネットメール・ゲートウェイへのMIMEの含意」、RFC1344、Bellcore、1992年6月。
[RFC-1345]
Simonsen, K., "Character Mnemonics & Character Sets", RFC
1345, Rationel Almen Planlaegning, June 1992.
[RFC-1345] シモンセン、K.、「キャラクターニーモニックと文字コード」、RFC1345、Rationel Almen Planlaegning、1992年6月。
[RFC-1421]
Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I -- Message Encryption and Authentication
Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG,
February 1993.
[RFC-1421]リン、J.、「インターネット電子メールのためのプライバシー増進:」 「Iを分けてください--暗号化と認証手順を通信させてください」、RFC1421、IAB IRTF PSRG、IETF PEM WG、1993年2月。
[RFC-1422]
Kent, S., "Privacy Enhancement for Internet Electronic
Mail: Part II -- Certificate-Based Key Management", RFC
1422, IAB IRTF PSRG, IETF PEM WG, February 1993.
[RFC-1422]ケント、S.、「インターネット電子メールのためのプライバシー増進:」 「IIを分けてください--証明書ベースのKey Management」、RFC1422、IAB IRTF PSRG、IETF PEM WG、2月1993日
[RFC-1423]
Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III -- Algorithms, Modes, and
Identifiers", IAB IRTF PSRG, IETF PEM WG, February 1993.
[RFC-1423]Balenson、D.、「インターネット電子メールのためのプライバシー増進:」 「IIIを分けてください--アルゴリズム、モード、および識別子」、IAB IRTF PSRG、IETF PEM WG、2月1993日
[RFC-1424]
Kaliski, B., "Privacy Enhancement for Internet Electronic
Mail: Part IV -- Key Certification and Related
Services", IAB IRTF PSRG, IETF PEM WG, February 1993.
[RFC-1424]Kaliski、B.、「インターネット電子メールのためのプライバシー増進:」 「IVを分けてください--証明と関連サービスを合わせてください」、IAB IRTF PSRG、IETF PEM WG、1993年2月。
[RFC-1521]
Borenstein, N., and Freed, N., "MIME (Multipurpose
Internet Mail Extensions): Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", RFC
1521, Bellcore, Innosoft, September, 1993.
[RFC-1521] Borenstein(N.、およびフリード、N.)は「以下をまね(マルチパーパスインターネットメールエクステンション)」。 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。
[RFC-1522]
Moore, K., "Representation of Non-ASCII Text in Internet
Message Headers", RFC 1522, University of Tennessee,
September 1993.
[RFC-1522] ムーア、K.、「インターネットメッセージヘッダーの非ASCIIテキストの表現」、RFC1522、テネシー大学、1993年9月。
Freed & Borenstein Standards Track [Page 22] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[22ページ]RFC2049は順応1996年11月にまねます。
[RFC-1524]
Borenstein, N., "A User Agent Configuration Mechanism for
Multimedia Mail Format Information", RFC 1524, Bellcore,
September 1993.
[RFC-1524] Borenstein、N.、「マルチメディアメール書式情報のためのユーザエージェント構成メカニズム」、RFC1524、Bellcore、1993年9月。
[RFC-1543]
Postel, J., "Instructions to RFC Authors", RFC 1543,
USC/Information Sciences Institute, October 1993.
[RFC-1543]ポステル、J.、「指示、RFCが書く、」、RFC1543、科学が設けるUSC/情報、10月1993日
[RFC-1556]
Nussbacher, H., "Handling of Bi-directional Texts in
MIME", RFC 1556, Israeli Inter-University Computer
Center, December 1993.
[RFC-1556] Nussbacher、H.、「MIMEにおける双方向のテキストの取り扱い」、RFC1556、イスラエルの相互大学コンピュータセンター、1993年12月。
[RFC-1590]
Postel, J., "Media Type Registration Procedure", RFC
1590, USC/Information Sciences Institute, March 1994.
[RFC-1590] ポステル、J.、「メディアは登録手順をタイプする」RFC1590、科学が1994年3月に設けるUSC/情報。
[RFC-1602]
Internet Architecture Board, Internet Engineering
Steering Group, Huitema, C., Gross, P., "The Internet
Standards Process -- Revision 2", March 1994.
[RFC-1602]インターネット・アーキテクチャ委員会、Huitema(C.)が利益を上げるインターネット工学運営グループ、P.、「インターネット規格は処理されます--改正2インチ、1994年3月。」
[RFC-1652]
Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M.,
Stefferud, E., and Crocker, D., "SMTP Service Extension
for 8bit-MIME transport", RFC 1652, United Nations
University, Innosoft, Dover Beach Consulting, Inc.,
Network Management Associates, Inc., The Branch Office,
March 1994.
[RFC-1652](エディタ)(ローズ)のKlensinとJ.と(WG議長)とフリードとN.とM.とStefferud、E.とクロッカー、D.、「8ビットのMIME輸送のためのSMTP Service Extension」RFC1652、国連大学、Innosoft、ドーヴァービーチConsulting Inc.、Network Management Associates Inc.、支店オフィス(1994年3月)。
[RFC-1700]
Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, USC/Information Sciences Institute, October
1994.
[RFC-1700] 科学が1994年10月に任命するレイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、USC/情報。
[RFC-1741]
Faltstrom, P., Crocker, D., and Fair, E., "MIME Content
Type for BinHex Encoded Files", December 1994.
[RFC-1741] FaltstromとP.とクロッカー、D.とフェア、E.、「ビンヘックスのためのMIMEの満足しているタイプはファイルをコード化した」1994年12月。
[RFC-1896]
Resnick, P., and A. Walker, "The text/enriched MIME
Content-type", RFC 1896, February, 1996.
1996年2月の[RFC-1896]レズニック、P.とA.ウォーカー、「テキスト/豊かにされたMIME文書内容」RFC1896。
Freed & Borenstein Standards Track [Page 23] RFC 2049 MIME Conformance November 1996
解放されるのとBorenstein標準化過程[23ページ]RFC2049は順応1996年11月にまねます。
[RFC-2045]
Freed, N., and and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, Innosoft, First Virtual Holdings,
November 1996.
そして、解放された[RFC-2045]、N.、N.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、Innosoft、ファースト・バーチャル持ち株、1996年11月。
[RFC-2046]
Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
Innosoft, First Virtual Holdings, November 1996.
解放された[RFC-2046]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、Innosoft、ファースト・バーチャル持ち株、1996年11月。
[RFC-2047]
Moore, K., "Multipurpose Internet Mail Extensions (MIME)
Part Three: Representation of Non-ASCII Text in Internet
Message Headers", RFC 2047, University of
Tennessee, November 1996.
[RFC-2047]ムーア、K.、「マルチパーパスインターネットメールエクステンション(MIME)は3を分けます」。 「インターネットメッセージヘッダーの非ASCIIテキストの表現」、RFC2047、テネシー大学、1996年11月。
[RFC-2048]
Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: MIME
Registration Procedures", RFC 2048, Innosoft, MCI,
ISI, November 1996.
解放された[RFC-2048]、N.、Klensin、J.、およびJ.ポステル、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「MIME登録手順」、RFC2048、Innosoft、MCI、ISI、1996年11月。
[RFC-2049]
Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049 (this document), Innosoft, First
Virtual Holdings, November 1996.
解放された[RFC-2049]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は5を分けます」。 「順応CriteriaとExamples」、RFC2049(このドキュメント)、Innosoft、ファースト・バーチャル方式Holdings、11月1996日
[US-ASCII]
Coded Character Set -- 7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[米国-ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。
[X400]
Schicker, Pietro, "Message Handling Systems, X.400",
Message Handling Systems and Distributed Applications, E.
Stefferud, O-j. Jacobsen, and P. Schicker, eds., North-
Holland, 1989, pp. 3-41.
ピエトロ、「メッセージハンドリングシステム、X.400」メッセージハンドリングの[X400]Schickerとシステムと分配されたアプリケーション、E.Stefferud、O-j。 ジェイコブセン、およびP.Schicker、eds、北部オランダ、1989、ページ 3-41.
Freed & Borenstein Standards Track [Page 24]
解放されるのとBorenstein標準化過程[24ページ]
一覧
スポンサーリンク
