RFC1344 日本語訳
1344 Implications of MIME for Internet Mail Gateways. N. Borenstein. June 1992. (Format: TXT=25872, PS=51812, PDF=24430 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group N. Borenstein, Bellcore
Request for Comments: 1344 June 1992
ワーキンググループN.Borenstein、コメントを求めるBellcore要求をネットワークでつないでください: 1344 1992年6月
Implications of MIME for Internet Mail Gateways
インターネットメール・ゲートウェイへのMIMEの含意
Status of This Memo
このメモの状態
This is an informational memo for the Internet community,
and requests discussion and suggestions for improvements.
This memo does not specify an Internet standard.
Distribution of this memo is unlimited.
これは、インターネットコミュニティのための情報のメモであり、改良のために議論と提案を要求します。 このメモはインターネット標準を指定しません。 このメモの分配は無制限です。
Abstract
要約
The recent development of MIME (Multipurpose Internet Mail
Extensions) offers a wide range of new opportunities for
electronic mail system systems. Most of these opportunites
are relevant only to user agents, the programs that interact
with human users when they send and receive mail. However,
some opportunities are also opened up for mail transport
systems. While MIME was carefully designed so that it does
not require any changes to Internet electronic message
transport facilities, there are several ways in which
message transport systems may want to take advantage of
MIME. These opportunities are the subject of this memo.
MIME(マルチパーパスインターネットメールエクステンション)の最近の進展は電子メール・システムシステムのさまざまな新しい機会を提供します。これらのopportunitesの大部分はユーザエージェントだけに関連しています、彼らがメールを送って、受け取るとき人間のユーザと対話するプログラム。 しかしながら、また、いくつかの機会がメール輸送システムのために開けられます。MIMEはインターネットの電子メッセージ運送設備への少しの変化も必要としないように、入念に設計されましたが、メッセージ輸送システムがMIMEを利用したがっているかもしれないいくつかの方法があります。 これらの機会はこのメモの対象です。
Background -- The MIME Format
バックグラウンド--MIME形式
Recently, a new standardized format has been defined for
enhanced electronic mail messages on the Internet. This
format, known as MIME, permits messages to include, in a
standardized manner, non-ASCII text, images, audio, and a
variety of other kinds of interesting data.
最近、新しい標準化された書式はインターネットに関する高められた電子メールメッセージのために定義されました。 MIMEとして知られているこの書式は含んでいるメッセージを可能にします、標準化された方法で、非ASCIIテキストです、イメージ、オーディオ、および他のさまざまな種類の興味ある資料。
The MIME effort was explicitly focused on requiring
absolutely no changes at the message transport level.
Because of this fact, MIME-format mail runs transparently on
all known Internet or Internet-style mail systems. This
means that those concerned solely with the maintenance and
development of message transport services can safely ignore
MIME completely, if they so choose.
MIMEの努力は明らかにメッセージで変化を全く絶対に必要としないのに輸送平らな状態で焦点を合わせられました。 この事実のために、MIME形式郵便配達人は透明にすべての知られているインターネットかインターネットスタイルメールシステムで動きます。これは、唯一メッセージ輸送サービスの維持と開発に関するものが安全にMIMEを完全に無視できることを意味します、そう選ぶなら。
However, the fact that MIME can be ignored, for the purpose
of message transport, does not necessarily mean that it
should be ignored. In particular, MIME offers several
features that should be of interest to those responsible for
message transport services. By exploiting these features,
transport systems can provide certain additional kinds of
service that are currently unavailable, and can alleviate a
few existing problems.
しかしながら、メッセージ転送の目的のためにMIMEを無視できるという事実は、必ずそれが無視されるべきであることを意味するというわけではありません。 特に、MIMEはメッセージ輸送サービスに責任があるそれらに興味があるべきいくつかの特徴を提供します。 これらの特徴を利用することによって、輸送システムは、ある追加種類の現在入手できないサービスを提供できて、いくつかの既存の問題を軽減できます。
The remainder of this document is an attempt to briefly
point out and summarize some important ways in which MIME
このドキュメントの残りはどのMIMEに簡潔にいくつかの重要な道を指摘して、まとめるか試みです。
Borenstein [Page 1]
Borenstein[1ページ]
RFC 1344 MIME and Mail Gateways June 1992
RFC1344MIMEとメール・ゲートウェイ1992年6月
may be of use for message transport systems. This document
makes no attempt to present a complete technical description
of MIME, however. For that, the reader is refered to the
MIME document itself [RFC-1341].
メッセージ輸送システムにおいて役に立つかもしれません。このドキュメントはしかしながら、MIMEの完全な専門的説明を提示する試みを全くしません。それに関して、読者はMIMEドキュメント[RFC-1341]自体にreferedされます。
Mail Transport and Gateway Services: A Key Distinction
輸送とゲートウェイサービスを郵送してください: 主要な区別
Before implementing any of the mechanisms discussed in this
memo, one should be familiar with the distinction between
mail transport service and mail gateway service. Basically,
mail transport software is responsible for moving a message
within a homogeneous electronic mail service network. Mail
gateways, on the other hand, exchange mail between two
significantly different mail environments, including via
non-electronic services, such as postal mail.
このメモで議論したメカニズムのどれかを実行する前に、メール輸送サービスとメール・ゲートウェイサービスの区別になじみ深いはずです。 基本的に、メール輸送ソフトウェアは同次の電子メールサービスネットワークの中でメッセージを動かすのに原因となります。 他方では、メール・ゲートウェイは2つのかなり異なったメール環境、非電子のサービスを通した包含の間でメールを交換します、郵便などのように。
In general, it is widely considered unacceptable for mail
transport services to alter the contents of messages. In
the case of mail gateways, however, such alteration is often
inevitable. Thus, strictly speaking, many of the mechanisms
described here apply only to gateways, and should not be
used in simple mail transport systems. However, it is
possible that some very special situations -- e.g., an SMTP
relay that transports mail across extremely expensive
intercontinental network links -- might need to modify
messages, in order to provide appropriate service for those
situations, and hence must redefine its role to be that of a
gateway.
一般に、それはメール輸送サービスがメッセージのコンテンツを変更するのにおいて容認できないと広く考えられます。 しかしながら、メール・ゲートウェイの場合では、そのような変更はしばしば必然です。 したがって、厳密に言うと、ここで説明されたメカニズムの多くはゲートウェイだけに適用して、簡単なメール輸送システムで使用するべきではありません。しかしながら、いくつかの非常に特別な状況(例えば、非常に高価な大陸間ネットワークリンクの向こう側にメールを輸送するSMTPリレー)がそれらの状況のための適切なサービスを提供するのにメッセージを変更するのが必要であるかもしれなく、したがって、ゲートウェイのものになるように役割を再定義しなければならないのは、可能です。
In this memo, it is assumed that transformations which alter
a message's contents will be performed only by gateways, but
it is recognized that some existing mail transport agents
may choose to reclassify themselves as gateways in order to
perform the functions described here.
このメモでは、メッセージのコンテンツを変更する変化がゲートウェイだけによって実行されますが、何人かの既存のメール輸送エージェントが、ここで説明された機能を実行するためにゲートウェイとして自分たちに分類し直すのを選ぶかもしれないと認められると思われます。
Rejected Messages
拒絶されたメッセージ
An unfortunately frequent duty of message transport services
is the rejection of mail to the sender. This may happen
because the mail was undeliverable, or because it did not
conform to the requirements of a gateway (e.g., it was too
large).
メッセージ輸送サービスの残念ながら頻繁な義務は送付者へのメールの拒絶です。 ゲートウェイの要件に従わないで(例えば、それは大き過ぎました)、メールが「非-提出物」だったので、これは起こるかもしれません。
There has never been a standard format for rejected messages
in the past. This has been an annoyance, but not a major
problem for text messages. For non-text messages, however,
the lack of a standard rejection format is more crucial,
because rejected messages typically appear to be text, and
the user who finds himself viewing images or audio as if
they were text is rarely happy with the result.
過去の拒絶されたメッセージのための標準書式が一度もありませんでした。 これはテキスト・メッセージのための大した問題ではなく、いらだちです。 しかしながら、非テキスト・メッセージに関しては、標準の拒絶形式の不足は、より重要です、拒絶されたメッセージがテキストであるように通常見えて、気付くとまるでそれらがテキストであるかのようにイメージかオーディオを見ているユーザがめったに結果にうれしくないので。
MIME makes it very easy to encapsulate messages in such a
way that their semantics are completely preserved. The
simplest way to do this is to make each rejection notice a
MIMEで、それらの意味論が完全に保存されているような方法でメッセージを要約するのは非常に簡単になります。 これをする最も簡単な方法はそれぞれの拒絶通知をaにすることです。
Borenstein [Page 2]
Borenstein[2ページ]
RFC 1344 MIME and Mail Gateways June 1992
RFC1344MIMEとメール・ゲートウェイ1992年6月
MIME "multipart/mixed" message. That multipart message
would contain two parts, a text part explaining the reason
for the rejection, and an encapsulated message part that
contained the rejected message itself.
MIMEの「複合か混ぜられた」メッセージ。 その複合メッセージは2つの部品、拒絶の理由がわかるテキスト部分、および拒絶されたメッセージ自体を含んだ要約のメッセージ部分を含んでいるでしょう。
It should be stressed that the transport software does not
need to understand the structure of the rejected message at
all. It merely needs to encapsulate it properly. The
following, for example, shows how any MIME message may be
encapsulated in a rejection message in such a way that all
information will be immediately visible in the correct form
if the recipient reads it with a MIME-conformant mail
reader:
輸送ソフトウェアが全く拒絶されたメッセージの構造を理解する必要はないと強調されるべきです。 それは、単に適切にそれを要約する必要があります。 例えば、以下は、受取人がMIME-conformantメール読者と共にそれを読むとすべての情報がすぐに訂正用紙で目に見えるのをどんなMIMEメッセージも拒絶メッセージでどうそのような方法で要約されるかに示します:
From: Mailer-Daemon <daemon@somewhere.com>
Subject: Rejected Message
Content-type: multipart/mixed; boundary=unique-boundary
From: Mailer-Daemon <daemon@somewhere.com 、gt;、Subject: 拒絶されたメッセージ満足しているタイプ: 複合か混ぜられる。 境界はユニークな境界と等しいです。
--unique-boundary
Content-type: text/plain; charset=us-ascii
--ユニークな境界文書内容: テキスト/平野。 charsetが私たちと等しい、-、ASCII
A mail message you sent was rejected. The details of
the rejected message are as follows:
あなたが送ったメール・メッセージは拒絶されました。 拒絶されたメッセージの詳細は以下の通りです:
From: Nathainel Borenstein <nsb@bellcore.com>
Message-ID: <12345@bellcore.com>
To: bush@whitehouse.gov
Subject: I know my rights!
Rejection-reason: No mail from libertarians is
accepted.
From: Nathainel Borenstein <nsb@bellcore.com 、gt;、Message ID: <12345@bellcore.com>To: bush@whitehouse.gov Subject: 私は権利を知っています! 拒絶理由: 自由論者からのメールを全く受け入れません。
The original message follows below.
--unique-boundary
Content-type: message/rfc822
オリジナルのメッセージは以下に従います。 --ユニークな境界文書内容: メッセージ/rfc822
The ENTIRE REJECTED MESSAGE, starting with the headers,
goes here.
ヘッダーから始めて、ENTIRE REJECTED MESSAGEはここに行きます。
--unique-boundary--
In the above example, the ONLY thing that is not
'boilerplate" is the choice of boundary string. The phrase
"unique-boundary" should be replaced by a string that does
not appear (prefixed by two hyphens) in any of the body
parts.
--「ユニークな境界--上記の例では、'決まり文句」でない唯一のものが境界ストリングの選択です。' 「ユニークな境界」という句を身体の部分のいずれにも現れない(2つのハイフンで、前に置かれています)ストリングに取り替えるべきです。
Encapsulating a message in this manner is very easily done,
and will constitute a significant service that message
transport services can perform for MIME users.
メッセージを要約するのは、この様に非常に容易にして、メッセージ輸送サービスがMIMEユーザのために実行できる重要なサービスを構成するでしょう。
IMPORTANT NOTE: The format given above is simply one of
many possible ways to format a rejection message using MIME.
Independent IETF efforts are needed in order to standardize
the format of rejections and acknowledgements.
重要な注意: 上に与えられた書式は単にMIMEを使用することで拒絶メッセージをフォーマットする多くの可能な方法の1つです。 独立しているIETFの努力が、拒絶と承認の形式を標準化するのに必要です。
Borenstein [Page 3]
Borenstein[3ページ]
RFC 1344 MIME and Mail Gateways June 1992
RFC1344MIMEとメール・ゲートウェイ1992年6月
Fragmenting and Reassembling Large Messages
大きいメッセージを断片化して、組み立て直します。
One problem that occurs with increasing frequency in
Internet mail is the rejection of messages because of size
limitations. This problem can be expected to grow
substantially more severe with the acceptance of MIME, as
MIME invites the use of very large objects such as images
and audio clips. Fortunately, MIME also provides mechanisms
that can help alleviate the problem.
インターネット・メールによる増加する頻度で起こる1つの問題がサイズ制限によるメッセージの拒絶です。 この問題が実質的にMIMEの承認により厳しくなると予想できます、MIMEがイメージやオーディオクリップなどの非常に大きい物の使用を招待するとき。 また、幸い、MIMEは問題を軽減するのを助けることができるメカニズムを提供します。
One particularly relevant MIME type is "message/partial",
which can be used for the automatic fragmentation and
reassembly of large mail messages. The message/partial type
can be handled entirely at the user agent level, but message
transport services can also make use of this type to provide
more intelligent behavior at gateways.
1つの特に関連しているMIMEの種類が「メッセージ/部分的である」(大きいメール・メッセージの自動断片化と再アセンブリに、使用できます)。 完全にユーザエージェントレベルでメッセージ/部分的なタイプを扱うことができますが、また、メッセージ輸送サービスは、ゲートウェイで、より知的な振舞いを提供するのにこのタイプを利用できます。
In particular, when gatewaying mail to or from a system or
network known to enforce size limitations that are more or
less stringent than are enforced locally, message transport
services might choose either to break a large message into
fragments, or (perhaps less likely) to reassemble fragments
into a larger message. The combination of these two
behaviors can make the overall Internet mail environment
appear more complete and seamless than it actually is.
システム、または、サイズ制限を実施するのが知られているネットワークかネットワークからのメールをgatewayingして、それが局所的に実施されるより多少厳しいときに、特に、メッセージ輸送サービスは、断片、または(恐らくそれほどありそうでない)により大きいメッセージに断片を組み立て直すのを大きいメッセージを知らせるのを選ぶかもしれません。 これらの2つの振舞いの組み合わせは総合的なインターネット・メール環境を実際により完全でシームレスに見せることができます。
Details on the message/partial format may be found in the
MIME document. What follows is an example of how a simple
short message might be broken into two message/partial
messages. In practice, of course, the message/partial
facility would only be likely to be used for much longer
messages.
メッセージ/部分的な形式に関する詳細はMIMEドキュメントで見つけられるかもしれません。 続くことは2メッセージ/部分的なメッセージがどう簡単な短いメッセージに細かく分けられるかもしれないかに関する例です。 もちろん、実際には、メッセージ/部分的な施設ははるかに長いメッセージに使用されるだけでありそうでしょう。
The following initial message:
以下の初期のメッセージ:
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed: <ned@innosoft.com>
Subject: a test message
Content-type: image/gif
Content-Transfer-Encoding: base64
From: ナザニエル Borenstein <nsb@bellcore.com 、gt;、To: ネッドは解放しました: <ned@innosoft.com>Subject: テストメッセージ文書内容: gif Content転送イメージ/コード化: base64
R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67qkRV
uwARd6q7/ywAAAAAQAGMAUME/hDISau9OOvNu/9gKI6kRJwoUa5s675wLM90l
XW5YKxqPyKRygxv2dr4czwlMCZrQLFTYHBJ2hlyQYFiaz+i0WWBou7fOq1x8vXWfU
qU1fJ2qEhYaHGjhZQmJ2QT1xBW1ak1xUdV0/VjtsbpUEDaEJCQOIpqeoNV+LXo5W
fVN3dZKceAQPvgyhwQ2lqcXGxx5wja59eJIGUNCszF90sYp50CoqFZ4DoqMMo6M
R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67qkRV uwARd6q7/ywAAAAAQAGMAUME/hDISau9OOvNu/9gKI6kRJwoUa5s675wLM90l XW5YKxqPyKRygxv2dr4czwlMCZrQLFTYHBJ2hlyQYFiaz+i0WWBou7fOq1x8vXWfU qU1fJ2qEhYaHGjhZQmJ2QT1xBW1ak1xUdV0/VjtsbpUEDaEJCQOIpqeoNV+LXo5W fVN3dZKceAQPvgyhwQ2lqcXGxx5wja59eJIGUNCszF90sYp50CoqFZ4DoqMMo6M
can be transformed, invertibly, into the following two
message/partial messages:
invertiblyに以下の2メッセージ/部分的なメッセージに変えることができます:
From: Nathaniel Borenstein <nsb@bellcore.com>
From: ナザニエル Borenstein <nsb@bellcore.com 、gt。
Borenstein [Page 4]
Borenstein[4ページ]
RFC 1344 MIME and Mail Gateways June 1992
RFC1344MIMEとメール・ゲートウェイ1992年6月
To: Ned Freed <ned@innosoft.com>
Subject: a test message
Content-type: message/partial; id="xyx@host.com";
number=1; total=2
To: ネッド Freed <ned@innosoft.com 、gt;、Subject: テストメッセージ文書内容: メッセージ/部分的。 イドは" xyx@host.com "と等しいです。 数=1。 =2を合計してください。
Content-type: image/gif
Content-Transfer-Encoding: base64
文書内容: gif Content転送イメージ/コード化: base64
R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67qkRV
R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67qkRV
and
そして
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: a test message
Content-type: message/partial; id="xyx@host.com";
number=2; total=2
From: ナザニエル Borenstein <nsb@bellcore.com 、gt;、To: ネッド Freed <ned@innosoft.com 、gt;、Subject: テストメッセージ文書内容: メッセージ/部分的。 イドは" xyx@host.com "と等しいです。 数=2。 =2を合計してください。
uwARd6q7/ywAAAAAQAGMAUME/hDISau9OOvNu/9gKI6kRJwoUa5s675wLM90l
XW5YKxqPyKRygxv2dr4czwlMCZrQLFTYHBJ2hlyQYFiaz+i0WWBou7fOq1x8vXWfU
qU1fJ2qEhYaHGjhZQmJ2QT1xBW1ak1xUdV0/VjtsbpUEDaEJCQOIpqeoNV+LXo5W
fVN3dZKceAQPvgyhwQ2lqcXGxx5wja59eJIGUNCszF90sYp50CoqFZ4DoqMMo6M
uwARd6q7/ywAAAAAQAGMAUME/hDISau9OOvNu/9gKI6kRJwoUa5s675wLM90l XW5YKxqPyKRygxv2dr4czwlMCZrQLFTYHBJ2hlyQYFiaz+i0WWBou7fOq1x8vXWfU qU1fJ2qEhYaHGjhZQmJ2QT1xBW1ak1xUdV0/VjtsbpUEDaEJCQOIpqeoNV+LXo5W fVN3dZKceAQPvgyhwQ2lqcXGxx5wja59eJIGUNCszF90sYp50CoqFZ4DoqMMo6M
Fragmenting such messages rather than rejecting them might
be a reasonable option for some gateway services, at least
for a certain range of message sizes. Of course, it is
often difficult for a gateway to know what size limitations
will be encountered "downstream", but intelligent guesses
are often possible. Moreover, an IETF working group on SMTP
extensions has proposed augmenting SMTP with a "SIZE" verb
that would facilitate this process, thereby possibly
requiring fragmentation on the fly during message
transmission.
それらを拒絶するよりむしろそのようなメッセージを断片化するのは、いくつかのゲートウェイサービスのための正当な選択であるかもしれません、少なくともある一定の範囲のメッセージサイズのために。 もちろん、ゲートウェイに、どんなサイズ制限が「川下で」遭遇するかを知るのがしばしば難しいのですが、知的な推測はしばしば可能です。 そのうえ、SMTP拡張子でのIETFワーキンググループは、この過程を容易にする「サイズ」動詞でSMTPを増大させるよう提案しました、その結果、ことによると、メッセージ送信の間、急いで断片化を必要とします。
Note also that fragmentation or reassembly might reasonably
be performed, in differing circumstances, by either the
sending or receiving gateway systems, depending on which
system knew more about the capabilities of the other.
また、断片化か再アセンブリが異なった事情で送付かゲートウェイシステムを受け止めることによって合理的に実行されるかもしれないことに注意してください、とどのシステムによるかはもう片方の能力に関してもう少し知っていました。
Using or Removing External-Body Pointers
外部のボディーポインタを使用するか、または取り外します。
Another MIME type oriented to extremely large messages is
the "message/external-body" type. In this type of message,
all or part of the body data is not included in the actual
message itself. Instead, the Content-Type header field
includes information that tells how the body data can be
retrieved -- either via a file system, via anonymous ftp, or
via other mechanisms.
非常に大きいメッセージに適応する別のMIMEの種類は「外部のメッセージ/ボディー」タイプです。 このタイプに関するメッセージでは、ボディーデータのすべてか一部が実際のメッセージ自体に含まれていません。 代わりに、コンテントタイプヘッダーフィールドはどうしたらボディーデータを検索できるかをファイルシステムかアノニマスFTPか他のメカニズムで言う情報を含んでいます。
The message/external-body type provides a new option for
mail transport services that wishes to optimize the way
bandwidth resources are used in a given environment. For
example, the basic use of message/external-body is to reduce
bandwidth in email traffic. However, when email crosses a
外部のメッセージ/ボディータイプはメール輸送サービスのための帯域幅リソースが与えられた環境で使用される方法を最適化したがっている新しいオプションを提供します。 例えば、外部のメッセージ/ボディーの基本的な使用はメール交通における帯域幅を減少させることです。 しかしながら、いつが十字aをメールしますか?
Borenstein [Page 5]
Borenstein[5ページ]
RFC 1344 MIME and Mail Gateways June 1992
RFC1344MIMEとメール・ゲートウェイ1992年6月
slow and expensive boundary -- e.g., a satellite link across
the Pacific -- it might make sense to retrieve the data
itself and transform the external-body reference into the
actual data. Alternately, it might make sense to copy the
data itself to a new location, closer to the message
recipients, and change the location pointed to in the
message. Because the external-body specification can
include an expiration date, message transport services can
trade off storage and bandwidth capabilities to try to
optimize the overall use of resources for very large
messages.
遅くて高価な境界--例えば、太平洋の向こう側の衛星中継--それはデータ自体を検索して、外部のボディー参照を変える意味を実際のデータにするかもしれません。 交互に、新しい位置へのデータ自体をコピーに理解できるかもしれません、位置がメッセージに示したメッセージ受取人、および変化により近いです。 外部のボディー仕様が有効期限を含むことができるので、メッセージ輸送サービスは格納とリソースの非常に大きいメッセージの総合的な使用を最適化しようとする帯域幅能力を交換できます。
Such behaviors by a gateway require careful analysis of
cost/benefit tradeoffs and would be a dramatic departure
from typical mail transport services. However, the
potential benefits are quite significant, so that such the
appropriate use of these service options should be explored.
ゲートウェイのそばでのそのような振舞いは、費用/利益見返りの慎重な分析を必要として、典型的なメール輸送サービスからの劇的な出発でしょう。 しかしながら、潜在的利益がかなり重要であるので、これらのサービスオプションのそのような適切な使用は調査されるべきです。
For example, the following message includes PostScript data
by external reference:
例えば、以下のメッセージは外部参照でポストスクリプトデータを含んでいます:
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: The latest MIME draft
Content-Type: message/external-body;
name="BodyFormats.ps";
site="thumper.bellcore.com";
access-type=ANON-FTP;
directory="pub";
mode="image";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
From: ナザニエル Borenstein <nsb@bellcore.com 、gt;、To: ネッド Freed <ned@innosoft.com 、gt;、Subject: 最新のMIME草稿コンテントタイプ: 外部のメッセージ/ボディー。 「BodyFormats.ps」と=を命名してください。 サイトは"thumper.bellcore.com"と等しいです。 = やがてFTPをアクセスしてタイプする、。 ディレクトリは「パブ」と等しいです。 モードは「イメージ」と等しいです。 満了=「金曜日、1991年6月14日19:13:14 -0400(東部夏時間の)」
Content-type: application/postscript
文書内容: アプリケーション/追伸
A gateway to Australia might choose to copy the file to an
Australian FTP archive, changing the relevant parameters on
the Content-type header field. Alternately, it might choose
simply to transform the message into one in which all the
data were included:
オーストラリアへのゲートウェイは、オーストラリアのFTPアーカイブにファイルをコピーするのを選ぶかもしれません、文書内容ヘッダーフィールドに関する関連パラメタを変えて。 交互に、単にメッセージをすべてのデータが含まれていたものに変えるのを選ぶかもしれません:
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: The latest MIME draft
Content-type: application/postscript
From: ナザニエル Borenstein <nsb@bellcore.com 、gt;、To: ネッド Freed <ned@innosoft.com 、gt;、Subject: 最新のMIME草稿文書内容: アプリケーション/追伸
%!PS-Adobe-1.0
%%Creator: greenbush:nsb (Nathaniel Borenstein,MRE 2A-
274,4270,9938586,21462)
etc...
%PS Adobe1.0%%、創造者: greenbush: nsb(ナザニエルBorenstein、MRE 2A274、4270、9938586、21462)など。
This is an example which suggests both the benefits and the
dangers. There is considerable benefit to having a copy of
the data immediately available, but there also may be
considerable expense involved in transporting it to all of
これは利益と危険の両方を示す例です。 すぐに利用可能なデータをコピーしますが、また、あるかもしれないaを無視できなくすることへの費用がそれをすべてに輸送するコネにかかわったかなりの利益があります。
Borenstein [Page 6]
Borenstein[6ページ]
RFC 1344 MIME and Mail Gateways June 1992
RFC1344MIMEとメール・ゲートウェイ1992年6月
a the members of a list, if only a few will use the data
anytime soon.
リストのメンバーほんのいくつかがすぐいつでもデータを使用するなら。
Alternatively, instead of replacing an external-body message
with its real contents, it might make sense to transform it
into a "multipart/alternative" message containing both the
external body reference and the expanded version. This
means that only the external body part can be forwarded if
desired, and the recipient doesn't lose the information as
to where the data was fetched from, if they want to fetch an
up-to-date version in the future. Such information could be
represented, in MIME, in the following form:
あるいはまた、外部のボディーメッセージを本当のコンテンツに取り替えることの代わりに、それはそれを両方を含む「複合か代替」のメッセージに変える意味を外部のボディー参照と拡張バージョンにするかもしれません。 これは、望んでいるなら外部の身体の部分しか進めることができないで、受取人がデータがとって来られたところに関して情報を失わないことを意味します、将来最新のバージョンをとって来たいなら。 以下のフォームにMIMEでそのような情報を表すことができました:
From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Subject: The latest MIME draft
Content-type: multipart/alternative; boundary=foo
From: ナザニエル Borenstein <nsb@bellcore.com 、gt;、To: ネッド Freed <ned@innosoft.com 、gt;、Subject: 最新のMIME草稿文書内容: 複合/代替手段。 境界=foo
--foo
Content-Type: message/external-body;
name="BodyFormats.ps";
site="thumper.bellcore.com";
access-type=ANON-FTP;
directory="pub";
mode="image";
expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
--fooコンテントタイプ: 外部のメッセージ/ボディー。 「BodyFormats.ps」と=を命名してください。 サイトは"thumper.bellcore.com"と等しいです。 = やがてFTPをアクセスしてタイプする、。 ディレクトリは「パブ」と等しいです。 モードは「イメージ」と等しいです。 満了=「金曜日、1991年6月14日19:13:14 -0400(東部夏時間の)」
Content-type: application/postscript
--foo
Content-type: application/postscript
文書内容: アプリケーション/追伸--foo文書内容: アプリケーション/追伸
%!PS-Adobe-1.0
%%Creator: greenbush:nsb (Nathaniel Borenstein,MRE 2A-
274,4270,9938586,21462)
etc...
--foo--
%PS Adobe1.0%%、創造者: greenbush: nsb(ナザニエルBorenstein、MRE 2A274、4270、9938586、21462)など。 --foo--
Similarly for the case where a message is copied to a local
FTP site, one could offer two external body parts as the
alternatives, allowing the user agent to choose which FTP
site is preferred.
同様に、メッセージが地方のFTPサイトにコピーされるケースのために、1つは代替手段として2つの外部の身体の部分を提供するかもしれません、ユーザエージェントが、どのFTPサイトが好まれるかを選ぶのを許容して。
Image and other Format Conversions
イメージと他のFormat Conversions
MIME currently defines two image formats, image/gif and
image/jpeg. The former is much more convenient for many
users, and can be displayed more quickly on many systems.
The latter is a much more compact representation, and
therfore places less stress on mail transport facilities.
MIMEは現在、2つの画像形式、イメージ/gif、およびイメージ/jpegを定義します。前者を多くのユーザにとってはるかに便利であり、多くのシステムで、よりすばやく表示できます。後者ははるかにコンパクトな表現です、そして、therforeは、より少ない圧力をメール運送設備に置きます。
Message transport services can optimize both transport
bandwidth and user convenience by intelligent translation
between these formats (and other formats that might be added
later). When a message of type image/gif is submitted for
メッセージ輸送サービスはこれらの形式(そして、後で加えられるかもしれない他の書式)の間の知的な翻訳で輸送帯域幅とユーザの便宜の両方を最適化できます。 タイプイメージ/gifに関するメッセージが提出される時
Borenstein [Page 7]
Borenstein[7ページ]
RFC 1344 MIME and Mail Gateways June 1992
RFC1344MIMEとメール・ゲートウェイ1992年6月
long-haul delivery, it might reasonably be translated to
image/jpeg. Conversely, when image/jpeg data is received
for final delivery on a system with adequate storage
resources, it might be translated to image/gif for the
convenience of the recipient. Software to perform these
translations is widely available. It should be noted,
however, that performance of such conversions presumes
support for the new format by the recipient.
長期配送、合理的にイメージ/jpegにそれを翻訳するかもしれません。最終的な配送のために適切な格納リソースがあるシステムでイメージ/jpegデータを受け取るとき、逆に、受取人の都合のためにイメージ/gifにそれを翻訳するかもしれません。 これらの翻訳を実行するソフトウェアは広く利用可能です。 しかしながら、そのような変換の性能が受取人で新しい形式のサポートを推定することに注意されるべきです。
Although MIME currently only defines one audio format, more
are likely to be defined and registered with IANA in the
future. In that case, similar format conversion facilities
might be appropriate for audio.
MIMEが現在1つのオーディオ形式しか定義しませんが、以上は、将来、IANAに定義されて、登録されそうです。 その場合、オーディオには、同様のフォーマット変換施設は適切であるかもしれません。
If format conversion is done, it is STRONGLY RECOMMENDED
that some kind of trace information (probably in the form of
a Received header field) should be added to a message to
document the conversion that has been performed.
フォーマット変換が完了しているなら、ある種のトレース情報(たぶんReceivedヘッダーフィールドの形の)が実行された変換を記録するメッセージに追加されるべきであるのは、STRONGLY RECOMMENDEDです。
Some people have expressed concerns, or even the opinion
that conversions should never be done. To accomodate the
desires of those who dislike the idea of automatic format
conversion. For this reason, it is suggested that such
transformations be generally restricted to gateways rather
than general message transport services, and that services
which perform such conversions should be sensitive to a
header field that indicates that the sender does not wish to
have any such conversions performed. A suggested value for
this header field is:
関心、または変換が決して完了しているべきでないという意見さえ述べた人々もいました。 自動フォーマット変換の考えが嫌である人のaccomodateへの願望。 この理由で、一般に、そのような変化が一般的なメッセージ輸送サービスよりむしろゲートウェイに制限されて、そのような変換を実行するサービスが送付者がどんなそのような変換も実行して頂きたくないのを示すヘッダーフィールドに敏感であるべきであると示唆されます。 このヘッダーフィールドのための提案された値は以下の通りです。
Content-Conversion: prohibited
内容変換: 禁止されています。
User agents that wish to explicitly indicate a willingness
for such conversions to be performed may use:
明らかにそのような変換が実行される意欲を示したがっているユーザエージェントは以下を使用するかもしれません。
Content-Conversion: permitted
内容変換: 受入れられます。
However, this will be the default assumption of many
gateways, so this header field is not strictly necessary.
It also should be noted that such control of conversion
would only be available to the sender, rather than to any of
the recipients.
しかしながら、これが多くのゲートウェイのデフォルト仮定になるので、このヘッダーフィールドは厳密に必要ではありません。 また、受取人のどれかにというよりむしろ送付者だけに、変換のそのようなコントロールが利用可能であることに注意されるべきです。
Borenstein [Page 8]
Borenstein[8ページ]
RFC 1344 MIME and Mail Gateways June 1992
RFC1344MIMEとメール・ゲートウェイ1992年6月
Robust Encoding of Data
強健なデータの記号化
In addition to all the reasons given above for possible
transformation of body data, it will sometimes be the case
that a gateway can tell that the body data, as given, will
not robustly survive the next step of transport. For
example, mail crossing an ASCII-to-EBCDIC gateway will lose
information if certain characters are used. In such cases,
a gateway can make the data more robust simply by applying
one of the MIME Content-Transfer-Encoding algorithms (base64
or quoted-printable) to the body or body part. This will
generally be a loss-less transformation, but care must be
taken to ensure that the resulting message is MIME-
conformant if the inital message was not. (For example, a
MIME-Version header field may need to be added.)
ボディーデータの可能な変化のために上にあげられたすべての理由に加えて、時々与えるボディーデータが輸送の次のステップを強壮に乗り切らないのは、ゲートウェイが言うことができる事実でしょう。 例えば、確信しているキャラクタが使用されていると、ASCIIからEBCDICへのゲートウェイを越える郵便配達人が情報を失うでしょう。 そのような場合、ゲートウェイで、データは、単にボディーへの(base64か引用されて印刷可能)のMIME Content転送コード化アルゴリズムか身体の部分の1つを適用することによって、より強健になる場合があります。 これは一般に損失なしの変化でしょうが、initalメッセージが注意しなかったなら、結果として起こるメッセージがMIME conformantであることを保証するために注意しなければなりません。 (例えば、MIMEバージョンヘッダーフィールドは、加えられる必要があるかもしれません。)
User-oriented concerns
利用者志向関心
If a gateway is going to perform major transformations on a
mail message, such as translating image formats or mapping
between included data and external-reference data, it seems
inevitable that there will be situations in which users will
object to these transformations. This is, in large part, an
implementation issue, but it seems advisable, wherever
possible, to provide a mechanism whereby users can specify,
to the transport system, whether or not they want such
services performed automatically on their behalf. The use of
the "Content-Conversion" header field, as mentioned above,
is suggested for this purpose, since it it least provides
some control by the sender, if not the recipient.
ゲートウェイが必然の状態で画像形式を翻訳するか、または含まれているデータと外部参照の間でデータを写像するのなどように見えるメール・メッセージにおける主要変形を実行すると、ユーザがこれらの変換に反対するそれが状況がいるでしょう。 これは主に導入問題ですが、賢明に思えます、可能です、彼らがそのようなサービスが欲しいか否かに関係なく、ユーザが輸送システムに指定できるメカニズムを提供するのがどこで自動的にそれらの利益に働いたとしても。 「内容変換」ヘッダーフィールドの以上のようである使用はこのために示されて、それ以来、それは送付者、または受取人による何らかのコントロールを最も最少に提供します。
References
参照
[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, June, 1992.
[RFC-1341]Borenstein(N.、および解放されたN.)は「以下をまね(マルチパーパスインターネットメールエクステンション)」。 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1341、Bellcore、1992年6月。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Nathaniel S. Borenstein
MRE 2D-296, Bellcore
445 South St.
Morristown, NJ 07962-1910
ナザニエルS.Borenstein MRE2D-296、南聖モリスタウン、Bellcore445ニュージャージー07962-1910
Email: nsb@bellcore.com
Phone: +1 201 829 4270
Fax: +1 201 829 7019
メール: nsb@bellcore.com 電話: +1 201 829、4270Fax: +1 201 829 7019
Borenstein [Page 9]
Borenstein[9ページ]
一覧
スポンサーリンク
