RFC1343 日本語訳
1343 A User Agent Configuration Mechanism for Multimedia Mail FormatInformation. N. Borenstein. June 1992. (Format: TXT=29295, PS=59978, PDF=28495 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group N. Borenstein, Bellcore
Request for Comments: 1343 June 1992
ワーキンググループN.Borenstein、コメントを求めるBellcore要求をネットワークでつないでください: 1343 1992年6月
A User Agent Configuration Mechanism
ユーザエージェント構成メカニズム
For Multimedia Mail Format Information
マルチメディアメール書式情報のために
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
要約
This memo suggests a file format to be used to inform
multiple mail reading user agent programs about the
locally-installed facilities for handling mail in various
formats. The mechanism is explicitly designed to work with
mail systems based Internet mail as defined by RFC's 821,
822, 934, 1049, 1113, and the Multipurpose Internet Mail
Extensions, known as MIME. However, with some extensions it
could probably be made to work for X.400-based mail systems
as well. The format and mechanism are proposed in a manner
that is generally operating-system independent. However,
certain implementation details will inevitably reflect
operating system differences, some of which will have to be
handled in a uniform manner for each operating system. This
memo makes such situations explicit, and, in an appendix,
suggests a standard behavior under the UNIX operating
system.
このメモは、取り扱いメールのために様々な形式で局所的にインストールされた施設に関する複数のメール読み込みユーザエージェントプログラムを知らせるのに使用されるためにファイル形式を示します。 メカニズムは、MIMEとして知られているRFCの821、822、934、1049、1113、およびマルチパーパスインターネットメールエクステンションによって定義されるようにメールシステムでベースのインターネット・メールを扱うように明らかに設計されています。 しかしながら、いくつかの拡大で、それはまた、X.400ベースのメールシステムのためにたぶん働かされることができました。 形式とメカニズムは一般に、オペレーティングシステム独立者である方法で提案されます。 しかしながら、ある実装の詳細は必然的にオペレーティングシステム差を反映するでしょう。その或るものは一定の方法で各オペレーティングシステムのために扱われなければならないでしょう。 付録では、このメモは、そのような状況を明白にして、Unixオペレーティングシステムの下で標準の振舞いを示します。
Introduction
序論
The electronic mail world is in the midst of a transition
from single-part text-only mail to multi-part, multi-media
mail. In support of this transition, various extensions to
RFC 821 and RFC 822 have been proposed and/or adopted,
notably including MIME [RFC-1341]. Various parties have
demonstrated extremely high-functionality multimedia mail,
but the problem of mail interchange between different user
agents has been severe. In general, only text messages have
been shared between user agents that were not explicitly
designed to work together. This limitation is not
compatible with a smooth transition to a multi-media mail
world.
電子メール世界がただ一つの部分テキストのみメールから複合マルチメディアメールまでの変遷の中にあります。 この変遷を支持して、RFC821とRFC822への様々な拡大は、提案される、そして/または、採用されました、MIME[RFC-1341]を著しく含んでいて。 様々なパーティーは非常に高い機能性のマルチメディアメールを示しましたが、異なったユーザエージェントの間のメール置き換えの問題は厳しいです。 一般に、テキスト・メッセージだけが一緒に働くように明らかに設計されなかったユーザエージェントの間で共有されました。 この制限はマルチメディアメール世界にスムーズな移行と互換性がありません。
One approach to this transition is to modify diverse sets of
mail reading user agents so that, when they need to display
mail of an unfamiliar (non-text) type, they consult an
external file for information on how to display that file.
That file might say, for example, that if the content-type
この変遷への1つのアプローチがさまざまのセットのメール読書ユーザエージェントを変更することであるので、なじみのない(非テキストの)タイプのメールを表示する必要があると、彼らはどうそのファイルを表示するかの情報のための外部のファイルに相談します。 そのファイルはcontent typeであるなら例えば、それを示すかもしれません。
Borenstein [Page 1]
Borenstein[1ページ]
RFC 1343 Multimedia Mail Configuration June 1992
RFC1343マルチメディアは構成1992年6月を郵送します。
of a message is "foo" it can be displayed to the user via
the "displayfoo" program.
aでは、メッセージは"displayfoo"プログラムを通して「fooに」ユーザにそれを表示できるということです。
This approach means that, with a one-time modification, a
wide variety of mail reading programs can be given the
ability to display a wide variety of types of message.
Moreover, extending the set of media types supported at a
site becomes a simple matter of installing a binary and
adding a single line to a configuration file. Crucial to
this scheme, however, is that all of the user agents agree
on a common representation and source for the configuration
file. This memo proposes such a common representation.
このアプローチは、1回の変更と共にさまざまなタイプに関するメッセージを表示する能力をさまざまなメール読み込みプログラムに与えることができることを意味します。 そのうえ、サイトでサポートされたメディアタイプのセットを広げるのは構成ファイルにバイナリーをインストールして、単線を追加する簡単な事柄になります。 しかしながら、この体系に重要であるのは、ユーザエージェントが皆、構成ファイルのために共通表現とソースに同意するということです。 このメモはそのような共通表現を提案します。
Location of Configuration Information
設定情報の位置
Each user agent must clearly obtain the configuration
information from a common location, if the same information
is to be used to configure all user agents. However,
individual users should be able to override or augment a
site's configuration. The configuration information should
therefore be obtained from a designated set of locations.
The overall configuration will be obtained through the
virtual concatenation of several individual configuration
files known as mailcap files. The configuration information
will be obtained from the FIRST matching entry in a mailcap
file, where "matching" depends on both a matching content-
type specification, an entry containing sufficient
information for the purposes of the application doing the
searching, and the success of any test in the "test=" field,
if present.
それぞれのユーザエージェントは一般的な位置から設定情報を明確に得なければなりません、同じ情報がすべてのユーザエージェントを構成するのに使用されることであるなら。 しかしながら、個々のユーザは、サイトの構成をくつがえすべきであるか、または増大させることができるべきです。 したがって、指定されたセットの位置から設定情報を得るべきです。 メールキャップファイルとして知られているいくつかの個々の構成ファイルの仮想の連結で総合的な構成を得るでしょう。 「マッチング」が合っている内容タイプ仕様、アプリケーションが探すことをする目的のための十分な情報を含むエントリーと「テスト=」分野でのどんなテストの成功の両方にもよるメールキャップファイルにおけるFIRSTの合っているエントリーから設定情報を得るでしょう、存在しているなら。
The precise location of the mailcap files is operating-
system dependent. A standard location for UNIX is specified
in Appendix A.
メールキャップファイルの正確な位置は操作システムに依存しています。 UNIXのための標準の位置はAppendix Aで指定されます。
Overall Format of a Mailcap File
メールキャップファイルの総合的な形式
Each mailcap file consists of a set of entries that describe
the proper handling of one media type at the local site.
For example, one line might tell how to display a message in
Group III fax format. A mailcap file consists of a sequence
of such individual entries, separated by newlines (according
to the operating system's newline conventions). Blank lines
and lines that start with the "#" character (ASCII 35) are
considered comments, and are ignored. Long entries may be
continued on multiple lines if each non-terminal line ends
with a backslash character ('\', ASCII 92), in which case
the multiple lines are to be treated as a single mailcap
entry. Note that for such "continued" lines, the backslash
must be the last character on the line to be continued.
各メールキャップファイルはローカル・サイトの1つのメディアタイプの適切な取り扱いについて説明する1セットのエントリーから成ります。 例えば、1つの系列がGroup IIIファックス形式におけるメッセージを表示する方法を教えるかもしれません。 メールキャップファイルはニューライン(オペレーティングシステムのニューラインコンベンションによると)によって切り離されたそのような個人出場者の系列から成ります。 「#」キャラクタ(ASCII35)から始まる空白行と系列が、コメントであると考えられて、無視されます。 それぞれの非端末線がバックスラッシュキャラクタ('\'、ASCII92)と共に終わるなら、長いエントリーは複数の系列で続けられるかもしれません、その場合、複数の系列が単一のmailcapエントリーとして扱われることです。 バックスラッシュがそのような「続ける」系列のための、続けられるようになるように危うい最後のキャラクタでなければならないことに注意してください。
Thus the overall format of a mailcap file is given, in the
modified BNF of RFC 822, as:
したがって、以下としてRFC822の変更されたBNFでメールキャップファイルの総合的な書式を与えます。
Borenstein [Page 2]
Borenstein[2ページ]
RFC 1343 Multimedia Mail Configuration June 1992
RFC1343マルチメディアは構成1992年6月を郵送します。
Mailcap-File = *Mailcap-Line
メールキャップファイル=*Mailcap-線
Mailcap-Line = Comment / Mailcap-Entry
Mailcap-線はMailcapコメント/エントリーと等しいです。
Comment = NEWLINE / "#" *CHAR NEWLINE
コメントはニューライン/「#」*炭のニューラインと等しいです。
NEWLINE = <newline as defined by OS convention>
OSコンベンション>によって定義されるようにNEWLINEは<ニューラインと等しいです。
Note that the above specification implies that comments must
appear on lines all to themselves, with a "#" character as
the first character on each comment line.
各注釈行の最初のキャラクタとしての「#」キャラクタと共に上記の仕様が、コメントが系列に自分たちにとってみな、現れなければならないのを含意することに注意してください。
Format of a Mailcap Entry
Mailcapエントリーの形式
Each mailcap entry consists of a number of fields, separated
by semi-colons. The first two fields are required, and must
occur in the specified order. The remaining fields are
optional, and may appear in any order.
それぞれのmailcapエントリーはセミコロンによって切り離された多くの野原から成ります。 最初の2つの分野が、必要であり、指定された順序で起こらなければなりません。 残っているフィールドは、任意であり、順不同に現れるかもしれません。
The first field is the content-type, which indicates the
type of data this mailcap entry describes how to handle. It
is to be matched against the type/subtype specification in
the "Content-Type" header field of an Internet mail message.
If the subtype is specified as "*", it is intended to match
all subtypes of the named content-type.
最初の分野はcontent typeです。(そのcontent typeはこのmailcapエントリーが扱うためにその方法を説明するデータのタイプを示します)。 それはインターネットメール・メッセージの「コンテントタイプ」ヘッダーフィールドにおけるタイプ/「副-タイプ」仕様に取り組まされることになっています。 「副-タイプ」が「*」として指定されるなら、命名されたcontent typeのすべての血液型亜型を合わせるのは意図しています。
The second field, view-command, is a specification of how
the message or body part can be viewed at the local site.
Although the syntax of this field is fully specified, the
semantics of program execution are necessarily somewhat
operating system dependent. UNIX semantics are given in
Appendix A.
2番目の分野(視点コマンド)はローカル・サイトでどうメッセージか身体の部分を見ることができるかに関する仕様です。 この分野の構文は完全に指定されますが、プログラム実行の意味論は必ずオペレーティングシステムにいくらか依存しています。 Appendix AでUNIX意味論を与えます。
The optional fields, which may be given in any order, are as
follows:
任意の野原(順不同に与えられるかもしれない)は以下の通りです:
-- The "compose" field may be used to specify a program that
can be used to compose a new body or body part in the given
format. Its intended use is to support mail composing
agents that support the composition of multiple types of
mail using external composing agents. As with the view-
command, the semantics of program execution are operating
system dependent, with UNIX semantics specified in Appendix
A. The result of the composing program may be data that is
not yet suitable for mail transport -- that is, a Content-
Transfer-Encoding may need to be applied to the data.
-- 「構成してください」という分野は、与えられた形式で新しいボディーか身体の部分を構成するのに使用できるプログラムを指定するのに使用されるかもしれません。 意図されて、そのは、エージェントを構成しながら外部であることの形で複数のタイプのメール使用の構成をサポートするエージェントをメール構成にサポートすることになっているために使用されます。 プログラム実行の意味論が視点コマンドについてオペレーティングシステムに依存しているUNIX意味論がAppendix A.で指定されている状態で、構成プログラムの結果はまだメール輸送に適していないデータであるかもしれません--すなわち、Content転送コード化は、データに適用される必要があるかもしれません。
-- The "composetyped" field is similar to the "compose"
field, but is to be used when the composing program needs to
specify the Content-type header field to be applied to the
composed data. The "compose" field is simpler, and is
preferred for use with existing (non-mail-oriented) programs
for composing data in a given format. The "composetyped"
field is necessary when the Content-type information must
-- "composetypedする"の分野は、「構成してください」という分野と同様ですが、構成プログラムが、落ち着いたデータに適用されるために文書内容ヘッダーフィールドを指定する必要があるとき、使用されていることです。 「構成してください」という分野は、より簡単であり、既存(非メール指向の)のプログラムによる与えられた形式でデータを構成する使用のために好まれます。 文書内容情報が必要でなければならないときに、"composetypedする"の分野が必要です。
Borenstein [Page 3]
Borenstein[3ページ]
RFC 1343 Multimedia Mail Configuration June 1992
RFC1343マルチメディアは構成1992年6月を郵送します。
include auxilliary parameters, and the composition program
must then know enough about mail formats to produce output
that includes the mail type information.
auxilliaryパラメタを含めてください。そうすれば、次に、構成プログラムは、情報をメール書式に関してメールを含んでいる出力は起こすことができるくらいタイプするのを知らなければなりません。
-- The "edit" field may be used to specify a program that
can be used to edit a body or body part in the given format.
In many cases, it may be identical in content to the
"compose" field, and shares the operating-system dependent
semantics for program execution.
-- 「編集」分野は、与えられた形式でボディーか身体の部分を編集するのに使用できるプログラムを指定するのに使用されるかもしれません。 多くの場合、それは、内容が「構成してください」という分野と同じであるかもしれなく、プログラム実行のためにオペレーティングシステムに依存する意味論を共有します。
-- The "print" field may be used to specify a program that
can be used to print a message or body part in the given
format. As with the view-command, the semantics of program
execution are operating system dependent, with UNIX
semantics specified in Appendix A.
-- 「印刷」分野は、与えられた形式でメッセージか身体の部分を印刷するのに使用できるプログラムを指定するのに使用されるかもしれません。 視点コマンドのように、UNIX意味論がAppendix Aで指定されている状態で、プログラム実行の意味論はオペレーティングシステムに依存しています。
-- The "test" field may be used to test some external
condition (e.g. the machine architecture, or the window
system in use) to determine whether or not the mailcap line
applies. It specifies a program to be run to test some
condition. The semantics of execution and of the value
returned by the test program are operating system dependent,
with UNIX semantics specified in Appendix A. If the test
fails, a subsequent mailcap entry should be sought.
Multiple test fields are not permitted -- since a test can
call a program, it can already be arbitrarily complex.
-- 「テスト」分野は、mailcap系列が適用されるかどうか決定する何らかの外部の条件(例えば、マシンアーキテクチャ、または使用中のウィンドウシステム)をテストするのに使用されるかもしれません。 それは、何らかの状態をテストするために実行されるためにプログラムを指定します。 テストプログラムで返された実行と価値の意味論はオペレーティングシステムに依存しています、UNIX意味論がテストが失敗するAppendix A.Ifで指定されている状態でその後のmailcapエントリーが求められるべきです。 複数のテスト分野は受入れられません--テストがそうすることができるので、プログラムに電話をしてください、そして、それは既に任意に複雑である場合があります。
-- The "needsterminal" field indicates that the view-command
must be run on an interactive terminal. This is needed to
inform window-oriented user agents that an interactive
terminal is needed. (The decision is not left exclusively
to the view-command because in some circumstances it may not
be possible for such programs to tell whether or not they
are on interactive terminals.) The needsterminal command
should be assumed to apply to the compose and edit commands,
too, if they exist. Note that this is NOT a test -- it is a
requirement for the environment in which the program will be
executed, and should typically cause the creation of a
terminal window when not executed on either a real terminal
or a terminal window.
-- "needsterminal"分野は、視点コマンドを会話型端末装置に実行しなければならないのを示します。 これが、会話型端末装置が必要であることを窓指向のユーザエージェントに知らせるのに必要です。 (そのようなプログラムが、会話型端末装置の上にそれらがあるかどうか言うのが、いくつかの事情で可能でないかもしれないので、決定は排他的に視点コマンドに任せません。) needsterminalコマンドが、申し込むと思われるべきである、存在するなら、また、コマンドを構成して、編集してください。 これがテストでないことに注意してください--それはプログラムが実行されて、本当の端末か端末の窓のどちらかの上で実行されないと端末の窓の作成を通常引き起こすはずである環境のための要件です。
-- The "copiousoutput" field indicates that the output from
the view-command will be an extended stream of output, and
is to be interpreted as advice to the UA (User Agent mail-
reading program) that the output should be either paged or
made scrollable. Note that it is probably a mistake if
needsterminal and copiousoutput are both specified.
-- "copiousoutput"分野は、視点コマンドからの出力が出力の延長川になるのを示して、出力が呼び出されるべきであるというUA(プログラムを読んでいるユーザエージェントメール)へのアドバイスとして解釈されていて、スクロール可能に作られていることです。 needsterminalとcopiousoutputがともに指定されるならそれがたぶん誤りであることに注意してください。
-- The "description" field simply provides a textual
description, optionally quoted, that describes the type of
data, to be used optionally by mail readers that wish to
describe the data before offering to display it.
-- 「記述」分野は単にそれを表示すると申し出る前にデータについて説明したがっているメール読者によって任意に使用されるようにデータのタイプについて説明する任意に引用された原文の記述を提供します。
Borenstein [Page 4]
Borenstein[4ページ]
RFC 1343 Multimedia Mail Configuration June 1992
RFC1343マルチメディアは構成1992年6月を郵送します。
-- The "x11-bitmap" field names a file, in X11 bitmap (xbm)
format, which points to an appropriate icon to be used to
visually denote the presence of this kind of data.
-- 「x11-ビットマップ」フィールド名aはファイルされます、X11ビットマップ(xbm)形式で。(それは、目視によりこの種類に関するデータの存在を指示するのに使用されるために適切なアイコンを示します)。
-- Any other fields beginning with "x-" may be included for
local or mailer-specific extensions of this format.
Implementations should simply ignore all such unrecognized
fields to permit such extensions, some of which might be
standardized in a future version of this document.
-- 「x」で始まるいかなる他の分野もこの形式の地方の、または、郵送者特有の拡大のために含まれるかもしれません。 実装は、そのような拡大を可能にするために単にそのようなすべての認識されていない分野を無視するべきです。その或るものはこのドキュメントの将来のバージョンで標準化されるかもしれません。
Some of the fields above, such as "needsterminal", apply to
the actions of the view-command, edit-command, and compose-
command, alike. In some unusual cases, this may not be
desirable, but differentiation can be accomplished via
separate mailcap entries, taking advantage of the fact that
subsequent mailcap entries are searched if an earlier
mailcap entry does not provide enough information:
"needsterminal"などの上の分野のいくつかが視点コマンド、および編集命令も、構成コマンドについても動作に適用されます。 いくつかの珍しい場合では、これは望ましくないかもしれませんが、別々のmailcapエントリーを通って分化を実行できます、以前のmailcapエントリーが十分な情報を提供しないならその後のmailcapエントリーが捜されるという事実を利用して:
application/postscript; ps-to-terminal %s; \
needsterminal
application/postscript; ps-to-terminal %s; \
compose=idraw %s
アプリケーション/追伸。 psから端末への%s。 \needsterminalアプリケーション/追伸。 psから端末への%s。 \は=idraw%sを構成します。
In RFC 822 modified BNF, the following grammar describes a
mailcap entry:
RFC822の変更されたBNFでは、以下の文法はmailcapエントリーについて説明します:
Mailcap-Entry = typefield ; view-command
[";" 1#field]
Mailcap-エントリーはtypefieldと等しいです。 視点コマンド[「」、;、1#分野]
typefield = propertype / implicit-wild
typefieldは暗黙のpropertype/荒野と等しいです。
propertype = type "/" wildsubtype
」 「propertypeはタイプと等しく」/wildsubtype
implicitwild = type
implicitwildはタイプと等しいです。
wildsubtype = subtype / "*"
wildsubtypeは「副-タイプ」/「*」と等しいです。
view-command = mtext
視点コマンドはmtextと等しいです。
mtext = *mchar
mtextは*mcharと等しいです。
mchar = schar / qchar
mcharはschar / qcharと等しいです。
schar = * <any CHAR except
";", "\", and CTLS>
「scharはどんなCHARも除く*<と等しい」;、」、「\」、およびCTLS>。
qchar = "\" CHAR ; may quote any char
qcharは「\」炭と等しいです。 どんな炭も引用するかもしれません。
field = flag / namedfield
分野=旗/namedfield
namedfield = fieldname "=" mtext
namedfield=fieldnameはmtextと「等しいです」。
flag = "needsterminal" ; All these literals are to
="needsterminal"に旗を揚げさせてください。 これらのリテラルがあるすべて
Borenstein [Page 5]
Borenstein[5ページ]
RFC 1343 Multimedia Mail Configuration June 1992
RFC1343マルチメディアは構成1992年6月を郵送します。
/ "copiousoutput" ; be interpreted as
/ x-token ; case-insensitive
/"copiousoutput"。 /x-トークンとして、解釈されてください。 大文字と小文字を区別しない
fieldname = / "compose" ;Also all of these
/ "composetyped" ;are case-insensitive.
/ "print"
/ "edit"
/ "test"
/ "x11-bitmap"
/ "description"
/ x-token
fieldname=/「構成; /が「composetypedした」これらのすべても;」は大文字と小文字を区別しないです。 x/「印刷」/「編集」/「テスト」/「x11ビットマップ」/「記述」/トークン
Note that "type", "subtype", and "x-token" are defined in
MIME. Note also that while the definition of "schar"
includes the percent sign, "%", this character has a special
meaning in at least the UNIX semantics, and will therefore
need to be quoted as a qchar to be used literally.
「タイプ」、"「副-タイプ」"、および「x-トークン」がMIMEで定義されることに注意してください。 また、"schar"の定義がパーセント記号、「%」を含む間、このキャラクタが、少なくともUNIX意味論において格別の意味があって、したがって、文字通り使用されるためにqcharとして引用される必要に注意してください。
Appendix A: Implementation Details for UNIX
付録A: UNIXのための実装の詳細
Although this memo fully specifies a syntax for "mailcap"
files, the semantics of the mailcap file are of necessity
operating-system dependent in four respects. In order to
clarify the intent, and to promote a standard usage, this
appendix proposes a UNIX semantics for these four cases. If
a mailcap mechanism is implemented on non-UNIX systems,
similar semantic decisions should be made and published.
このメモは"mailcap"ファイルに構文を完全に指定しますが、メールキャップファイルの意味論が必要です。4つの点で依存するオペレーティングシステム。 意図をはっきりさせて、標準的用法を促進するために、この付録はこれらの4つのケースのためにUNIX意味論を提案します。 非UNIXシステムの上でmailcapメカニズムを実装するなら、同様の意味決定をして、発行するべきです。
Location of the Mailcap File(s)
メールキャップファイルの位置(s)
For UNIX, a path search of mailcap files is specified. The
default path search is specified as including at least the
following:
UNIXとして、メールキャップファイルの経路検索は指定されます。 デフォルト経路検索は少なくとも以下を含んでいると指定されます:
$HOME/.mailcap:/etc/mailcap:/usr/etc/mailcap:/usr/local/etc/mailcap
$ホーム/.mailcap:/etc/mailcap:/usr/etc/mailcap: /usr/local/etc/mailcap
However, this path may itself be overridden by a path
specified by the MAILCAPS environment variable.
しかしながら、この経路がそうするかもしれない、それ自体、MAILCAPS環境変数によって指定された経路で、くつがえされてください。
Semantics of executable commands
実行可能なコマンドの意味論
Several portions of a mailcap entry specify commands to be
executed. In particular, the mandatory second field, the
view-command, takes a command to be executed, as do the
optional print, edit, test, and compose fields.
mailcapエントリーの数個の部分が実行されるべきコマンドを指定します。 特に、2番目の義務的な分野(視点コマンド)は任意の印刷、編集、テストのように実行されて、分野を構成するコマンドを取ります。
On a UNIX system, such commands will each be a full shell
command line, including the path name for a program and its
arguments. (Because of differences in shells and the
implementation and behavior of the same shell from one
system to another, it is specified that the command line be
intended as input to the Bourne shell, i.e. that it is
implicitly preceded by "/bin/sh -c " on the command line.)
UNIXシステムの上では、そのようなコマンドはそれぞれ完全なシェルコマンドラインになるでしょう、プログラムとその議論のためのパス名を含んでいて。 (同じシェルのシェルの違い、実装、および別の1台のシステムからシステムまでの働きのために、コマンドラインがBourneシェルに入力されるように意図して、すなわち、それがコマンドラインの「/bin/sh-c」によってそれとなく先行されていると指定されます。)
Borenstein [Page 6]
Borenstein[6ページ]
RFC 1343 Multimedia Mail Configuration June 1992
RFC1343マルチメディアは構成1992年6月を郵送します。
The two characters "%s", if used, will be replaced by the
name of a file for the actual mail body data. In the case
of the edit adn view-command, the body part will be passed
to this command as standard input unless one or more
instances of "%s" appear in the view-command, in which case
%s will be replaced by the name of a file containing the
body part, a file which may have to be created before the
view-command program is executed. (Such files cannot be
presumed to continue to exist after the view-command program
exits. Thus a view-command that wishes to exit and continue
processing in the background should take care to save the
data first.) In the case of the compose and composetyped
commands, %s should be replaced by the name of a file to
which the composed data should be written by the programs
named in the compose or composedtyped commands. Thus, the
calling program will look in that file later in order to
retrieve the composed data. If %s does not appear in the
compose or composetyped commands, then the composed data
will be assumed to be written by the composing programs to
standard output.
使用するなら、「2つのキャラクタ」%s」を実際のメールボディーデータのためのファイルの名前に取り替えるでしょう。 「編集adn視点命令の場合では、」 %s」の1つ以上のインスタンスが視点コマンドに現れないなら、標準の入力として身体の部分をこのコマンドに通過して、その場合、%sを身体の部分(視点コマンドプログラムが実行される前に作成されなければならないかもしれないファイル)を含むファイルの名前に取り替えるでしょう。 (視点コマンドプログラムが出た後にそのようなファイルはあえて存続できません。 したがって、出て、バックグラウンドで処理し続けたがっている視点コマンドは、最初にデータを保存するために注意されるべきです。) そして、ケース、構成、composetypedコマンド、%sを落ち着いたデータが中で指定されたプログラムで書かれているべきであるファイルの名前に取り替えるべきである、構成したか、またはコマンドをcomposedtypedしました。 したがって、呼ぶプログラムは、後で落ち着いたデータを検索するためにそのファイルの中を見るでしょう。 sが現れない%である、コマンド(構成プログラムで標準の出力に書かれている落ち着いたデータが思われるその時)を構成したか、またはcomposetypedしました。
Furthermore, any occurrence of "%t" will be replaced by the
content-type and subtype specification. (That is, if the
content-type is "text/plain", then %t will be replaced by
"text/plain".) A literal % character may be quoted as \%.
Finally, named parameters from the Content-type field may be
placed in the command execution line using "%{" followed by
the parameter name and a closing "}" character. The entire
parameter should appear as a single command line argument,
regardless of embedded spaces. Thus, if the message has a
Content-type line of:
「その上、」 %t」のどんな発生もcontent typeと「副-タイプ」仕様に取り替えるでしょう。 (すなわち、content typeが「テキスト/明瞭である」なら、「テキスト/平野」で%tを取り替えるでしょう。) 文字通りの%、キャラクタは\%として引用されるかもしれません。 「最終的に、文書内容分野からの命名されたパラメタは」 「パラメタ名と閉鎖によってあとに続かれている」%を使用することでコマンド実行系列に置かれるかもしれなく」キャラクタ。 全体のパラメタは埋め込まれた空間にかかわらずただ一つのコマンドライン議論として現れるべきです。 したがって、メッセージに文書内容があるなら、以下に立ち並んでください。
Content-type: multipart/mixed; boundary=42
文書内容: 複合か混ぜられる。 境界=42
and the mailcap file has a line of:
そして、メールキャップファイルには、以下の系列があります。
multipart/*; /usr/local/bin/showmulti \
%t %{boundary}
複合/*。 /usr/local/bin/showmulti\%t、%境界
then the equivalent of the following command should be
executed:
次に、以下のコマンドの同等物は実行されるべきです:
/usr/local/bin/showmulti multipart/mixed 42
/usr/local/bin/showmultiの複合/は42を混ぜました。
Semantics of the "test" field
「テスト」分野の意味論
The "test" field specifies a program to be used to test
whether or not the current mailcap line applies. This can
be used, for example, to have a mailcap line that only
applies if the X window system is running, or if the user is
running on a SPARCstation with a /dev/audio. The value of
the "test" field is a program to run to test such a
condition. The precise program to run and arguments to give
it are determined as specified in the previous section. The
「テスト」分野は、現在のmailcap系列が適用されるか否かに関係なく、テストするのに使用されるためにプログラムを指定します。 例えば、Xウィンドウシステムが走っているか、またはユーザが/dev/audioでSPARCstationの上で作業している場合にだけ適用されるmailcap系列を持つのにこれを使用できます。 「テスト」分野の値はそのような状態をテストするために動かすプログラムです。 動かす正確なプログラムとそれを与える議論は前項で指定されるように決定しています。 The
Borenstein [Page 7]
Borenstein[7ページ]
RFC 1343 Multimedia Mail Configuration June 1992
RFC1343マルチメディアは構成1992年6月を郵送します。
test program should return an exit code of zero if the
condition is true, and a non-zero code otherwise.
そうでなければ、テストプログラムは状態が本当であるか、そして、非ゼロコードをゼロの出口コードに返すはずです。
Semantics of the "compose" field
「構成してください」という分野の意味論
On UNIX, the composing program is expected to produce a data
stream for such a body part as its standard output. The
program will be executed with the command line arguments
determined as specified above. The data returned via its
standard output will be given a Content-Type field that has
no supplementary parameters. For example, the following
mailcap entry:
UNIXの上では、構成プログラムが規格が出力したような身体の部分のためのデータ・ストリームを起こすと予想されます。 コマンドライン議論が決定していた状態で、プログラムは上で指定されるとして実行されるでしょう。 どんな補っているパラメタも持っていないコンテントタイプ野原を標準の出力で返されたデータに与えるでしょう。 例えば、以下のmailcapエントリー:
audio/basic; /usr/local/bin/showaudio %t
compose = /usr/local/bin/recordaudio
オーディオ的か基本的。 /usr/local/bin/showaudio%tは=/usr/local/bin/recordaudioを構成します。
would result in tagging the data composed by the
"recordaudio" program as:
以下として"recordaudio"プログラムで構成されたデータにタグ付けをするようになるでしょう。
Content-Type: audio/basic
コンテントタイプ: オーディオ的であるか、または基本的です。
If this is unacceptable -- for example, in the case of
multipart mail a "boundary" parameter is required -- then
the "compose" field cannot be used. Instead, the
"composetyped" field should be used in the mailcap file.
これが容認できないなら(例えば、複合メールの場合では、「境界」パラメタが必要です)、「構成してください」という分野を使用できません。 代わりに、"composetypedする"の分野はメールキャップファイルで使用されるべきです。
Semantics of the "composetyped" field
"composetypedする"の分野の意味論
The "composetyped" filed is much like the "compose" field,
except that it names a composition program that produces,
not raw data, but data that includes a MIME-conformant type
specification. The program will be executed with the
command line arguments determined as specified above. The
data returned via its standard output must begin with a
Content-Type header, followed optionally by other Content-*
headers, and then by a blank line and the data. For
example, the following mailcap entry:
ファイルされた"composetypedする"は「構成してください」という分野に似ています、生データではなく、作り出される構成プログラムにもかかわらず、MIME-conformantタイプ仕様を含んでいるデータを命名するのを除いて。 コマンドライン議論が決定していた状態で、プログラムは上で指定されるとして実行されるでしょう。 標準の出力で返されたデータはそして、他のContent-*ヘッダーによって任意について来られたコンテントタイプヘッダーと空白行とデータで始まらなければなりません。 例えば、以下のmailcapエントリー:
multipart/mixed; /usr/local/bin/showmulti %t \
%{boundary}; \
composetyped = /usr/local/bin/makemulti
複合か混ぜられる。 /usr/local/bin/showmulti%、t\%、境界。 \は=/usr/local/bin/makemultiをcomposetypedしました。
would result in executing the "makemulti" program, which
would be expected to begin its output with a line of the
form:
フォームの系列で出力を始めると予想されるだろう"makemulti"プログラムを実行するようになるでしょう:
Content-Type: multipart/mixed; boundary=foobar
コンテントタイプ: 複合か混ぜられる。 境界=foobar
Note that a composition program need not encode binary data
in base64 or quoted-printable. It remains the responsibility
of the software calling the composition program to encode
such data as necessary. However, if a composing program
does encode data, which is not encouraged, it should
announce that fact using a Content-Transfer-Encoding header
構成プログラムがbase64か引用されて印刷可能でバイナリ・データをコード化する必要はないことに注意してください。 ソフトウェアが構成プログラムを呼ぶ責任のままで、必要であるようなデータをコード化するのは残っています。 しかしながら、構成プログラム(奨励されない)がデータを暗号化するなら、それは、Contentがコード化を移しているヘッダーを使用することでその事実を発表するべきです。
Borenstein [Page 8]
Borenstein[8ページ]
RFC 1343 Multimedia Mail Configuration June 1992
RFC1343マルチメディアは構成1992年6月を郵送します。
in the standard manner defined by MIME. Because such
encodings must be announced by such a header, they are an
option only for composetyped programs, not for compose
programs.
MIMEによって定義された標準の方法で。 そのようなヘッダーがそのようなencodingsを発表しなければならないので、それらがcomposetypedプログラムのためだけのオプションである、プログラムを構成してください。
Appendix B: Sample Mailcap File
付録B: メールキャップファイルのサンプル
The following is an example of a mailcap file for UNIX that
demonstrates most of the syntax above. It contains
explanatory comments where necessary.
↓これは上の構文の大部分を示すUNIXのためのメールキャップファイルに関する例です。 それは必要であるところに説明しているコメントを保管しています。
# Mailcap file for Bellcore lab 214.
#
# The next line sends "richtext" to the richtext
program
text/richtext; richtext %s; copiousoutput
#
# Next, basic u-law audio
audio/*; showaudio; test=/usr/local/bin/hasaudio
#
# Next, use the xview program to handle several image
formats
image/*; xview %s; test=/usr/local/bin/RunningX
#
# The ATOMICMAIL interpreter uses curses, so needs a
terminal
application/atomicmail; /usr/local/bin/atomicmail %s; \
needsterminal
#
# The next line handles Andrew format,
# if ez and ezview are installed
x-be2; /usr/andrew/bin/ezview %s; \
print=/usr/andrew/bin/ezprint %s ; \
compose=/usr/andrew/bin/ez -d %s \;
edit=/usr/andrew/bin/ez -d %s; \;
copiousoutput
#
# The next silly example demonstrates the use of
quoting
application/*; echo "This is \\"%t\\" but \
is 50 \% Greek to me" \; cat %s; copiousoutput
# Bellcore研究室214のためのメールキャップファイル。 # # 次の系列はrichtextプログラム・テキスト/richtextに"richtext"を送ります。 richtext%s。 copiousoutput##Next、基本的なu-法のオーディオオーディオ/*。 showaudio。 =/usr/local/bin/hasaudio##Nextをテストしてください、そして、xviewプログラムを使用して、いくつかの画像形式イメージ/*を扱ってください。 xview%s。 ATOMICMAILインタプリタが使用するテスト=/usr/local/bin/RunningX##は、呪うので、端末のアプリケーション/atomicmailを必要とします。 /usr/local/bin/atomicmail%s。 次の系列ハンドルアンドリューが#ezとezviewがインストールされたx-be2であるならフォーマットする\needsterminal##。 /usr/andrew/bin/ezview%s。 /usr/andrew/bin/ezprint\印刷=%s。 \が=/usr/andrew/bin/ez-d%sを構成する、\。 =/usr/andrew/bin/ez-d%sを編集してください。 \; 次の愚かな例がアプリケーション/*を引用しながら使用を示すcopiousoutput##。 「「これは\\です」という%を反響してください、」 \が50\%ギリシアのであるt\\、私、」 \。 猫%s。 copiousoutput
Appendix C: A Note on Format Translation
付録C: 形式翻訳に関する注
It has been suggested that another function of a mailcap-
like mechanism might be to specify the locally available
tools for document format translation. For example, the
file could designate a program for translating from format A
to format B, another for translating from format B to format
C, and finally a mechanism for displaying format C.
Although this mechanism would be somewhat richer than the
current mailcap file, and might conceivably also have
utility at the message transport layer, it significantly
メカニズムのようなmailcapの別の機能が局所的に利用可能なツールをドキュメント・フォーマット翻訳に指定することであるかもしれないことが提案されました。 例えば、ファイルはそれを形式Bによってメッセージトランスポート層の形式C.Althoughを表示して、このメカニズムが現在のメールキャップファイルよりいくらか豊かであるだろう、また、力にはユーティリティが多分あるので形式C、および形式Bから最終的にメカニズムまで翻訳するのにおける別かなり翻訳するためのプログラムを指定するかもしれません。
Borenstein [Page 9]
Borenstein[9ページ]
RFC 1343 Multimedia Mail Configuration June 1992
RFC1343マルチメディアは構成1992年6月を郵送します。
complicates the processing effort necessary for a user agent
that simply wants to display a message in format A. Using
the current, simpler, mailcap scheme, a single line could
tell such a user agent to display A-format mail using a
pipeline of translators and the C-format viewer. This memo
resists the temptation to complicate the necessary
processing for a user agent to accomplish this task. Using
the mailcap format defined here, it is only necessary to
find the correct single line in a mailcap file, and to
execute the command given in that line.
現在で、より簡単な形式A.Usingのメッセージ、mailcap体系を表示する単に必需品であり、単線が、翻訳者のパイプラインとC-形式ビューアーを使用することでA-形式メールを表示するようにそのようなユーザエージェントに言うかもしれないのがユーザエージェントに必要な処理取り組みを複雑にします。 このメモはユーザエージェントがこのタスクを達成するように必要な処理を複雑にする誘惑に抵抗します。 ここで定義されたmailcap書式を使用して、メールキャップファイルで正しい単線を見つけて、単にその系列で与えられたコマンドを実行するのが必要です。
References
参照
[RFC 822] Crocker, D., "Standard for the format of ARPA
Internet text messages", RFC 822, UDEL, August, 1982.
[RFC822] クロッカー、D.、「ARPAインターネット・テキスト・メッセージの形式の規格」、RFC822、UDEL、1982年8月。
[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.
[RFC1341] Borenstein(N.、および解放されたN.)は「以下をまね(マルチパーパスインターネットメールエクステンション)」。 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1341、Bellcore、1992年6月。
Acknowledgements
承認
The author wishes to thank Malcolm Bjorn Gillies, Dan
Heller, Olle Jaernefors, Keith Moore, Luc Rooijakkers, and
the other members of the IETF task force on mail extensions
for their comments on earlier versions of this draft. If
other acknowledgements were neglected, please let me know,
as it was surely accidental.
マルコム・ビヨン・ギリース、ダンHeller、オッレJaernefors、キース・ムーアに感謝するという作者願望、リュックRooijakkers、およびこの草稿の以前のバージョンの彼らのコメントのためのメール拡張子でのIETF特別委員会の他のメンバー。 他の承認が無視されたなら、それが確実に偶然であったときに、私にお知らせください。
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo. However,
the use of the mechanisms described in this memo can make
it easier for implementations to slip into the kind of
security problems discussed in the MIME document.
Implementors and mailcap administrators should be aware of
these security considerations, and in particular should
exercise caution in the choice of programs to be listed in a
mailcap file for automatic execution.
このメモで安全保障問題について議論しません。 しかしながら、このメモで説明されたメカニズムの使用で、実装がMIMEドキュメントで議論した警備上の問題の種類に陥るのが、より簡単になる場合があります。 作成者とmailcap管理者は、これらのセキュリティ問題を意識しているべきであり、自動実行のためのメールキャップファイルに記載されているためにプログラムの選択で特に警戒するべきです。
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 10]
Borenstein[10ページ]
一覧
スポンサーリンク
