RFC1049 日本語訳

Network Working Group                                           M. Sirbu
Request for Comments:  1049                                          CMU
                                                              March 1988

コメントを求めるワーキンググループM.シルブの要求をネットワークでつないでください: 1049 1988年の米カーネギーメロン大学の行進

           A CONTENT-TYPE HEADER FIELD FOR INTERNET MESSAGES

インターネットメッセージのためのcontent typeヘッダーフィールド

STATUS OF THIS MEMO

このメモの状態

   This RFC suggests proposed additions to the Internet Mail Protocol,
   RFC-822, for the Internet community, and requests discussion and
   suggestions for improvements.  Distribution of this memo is
   unlimited.

このRFCはインターネットメールプロトコルへの提案された追加、インターネットコミュニティのためのRFC-822を勧めて、改良のための議論と提案を要求します。 このメモの分配は無制限です。

ABSTRACT

要約

   A standardized Content-type field allows mail reading systems to
   automatically identify the type of a structured message body and to
   process it for display accordingly.  The structured message body must
   still conform to the RFC-822 requirements concerning allowable
   characters.  A mail reading system need not take any specific action
   upon receiving a message with a valid Content-Type header field.  The
   ability to recognize this field and invoke the appropriate display
   process accordingly will, however, improve the readability of
   messages, and allow the exchange of messages containing mathematical
   symbols, or foreign language characters.

標準化された文書内容分野で、メール読書システムは、自動的に構造化されたメッセージ本体のタイプを特定して、ディスプレイのためにそれに従って、それを処理します。 構造化されたメッセージ本体は許容できるキャラクタに関してまだRFC-822要件に従わなければなりません。 メール読書システムは有効なコンテントタイプヘッダーフィールドでメッセージを受け取るのに少しの特定の動作も持っていく必要はありません。 この分野を認識して、適切なディスプレイプロセスを呼び出す能力は、それに従って、しかしながら、メッセージの読み易さを改良して、数学記号、または外国語キャラクタを含むメッセージの交換を許容するでしょう。

                             Table of Contents

目次

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 1
   2. Problems with Structured Messages . . . . . . . . . . . . . . . 3
   3. The Content-type Header Field . . . . . . . . . . . . . . . . . 5
        3.1. Type Values  . . . . . . . . . . . . . . . . . . . . . . 5
        3.2. Version Number . . . . . . . . . . . . . . . . . . . . . 6
        3.3. Resource Reference . . . . . . . . . . . . . . . . . . . 6
        3.4. Comment. . . . . . . . . . . . . . . . . . . . . . . . . 7
   4. Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 1 2。 構造化されたメッセージ. . . . . . . . . . . . . . . 3 3に関する問題。 文書内容ヘッダーフィールド. . . . . . . . . . . . . . . . . 5 3.1。 値. . . . . . . . . . . . . . . . . . . . . . 5 3.2をタイプしてください。 バージョンNo.. . . . . . . . . . . . . . . . . . . . . 6 3.3。 リソース参照. . . . . . . . . . . . . . . . . . . 6 3.4。 コメントしてください。 . . . . . . . . . . . . . . . . . . . . . . . . 7 4. 結論. . . . . . . . . . . . . . . . . . . . . . . . . . 7

1. Introduction

1. 序論

   As defined in RFC-822, [2], an electronic mail message consists of a
   number of defined header fields, some containing structured
   information (e.g., date, addresses), and a message body consisting of
   an unstructured string of ASCII characters.

RFC-822、[2]で定義されるように、電子メールメッセージは多くの定義されたヘッダーフィールドから成って、いくつかの含有が情報(例えば、日付、アドレス)、およびASCII文字の不統一なストリングから成るメッセージ本体を構造化しました。

   The success of the Internet mail system has led to a desire to use
   the mail system for sending around information with a greater degree
   of structure, while remaining within the constraints imposed by the
   limited character set.  A prime example is the use of mail to send a

インターネット・メールシステムの成功は限られた文字集合によって課された規制に残っている間、情報の周りで、より大きい度合いの構造で発信するメールシステムを使用する願望につながりました。 主要例はaを送るメールの使用です。

Sirbu                                                           [Page 1]

RFC 1049                   Mail Content Type                  March 1988

シルブ[1ページ]RFC1049は1988年のcontent type行進を郵送します。

   document with embedded TROFF formatting commands.  A more
   sophisticated example would be a message body encoded in a Page
   Description Language (PDL) such as Postscript.  In both cases, simply
   mapping the ASCII characters to the screen or printer in the usual
   fashion will not render the document image intended by the sender; an
   additional processing step is required to produce an image of the
   message text on a display device or a piece of paper.

埋め込まれたTROFFと共に書式付けコマンドを記録してください。 より洗練された例はPostscriptなどのページ記述Language(PDL)でコード化されたメッセージ本体でしょう。 どちらの場合も、普通のファッションで単にスクリーンかプリンタへのASCII文字を写像するのは、送付者がドキュメントイメージを意図するようにレンダリングしないでしょう。 追加処理ステップが、ディスプレイ装置に関するメッセージ・テキストのイメージか1枚の紙を製作するのに必要です。

   In both of these examples, the message body contains only the legal
   character set, but the content has a structure which produces some
   desirable result after appropriate processing by the recipient.  If a
   message header field could be used to indicate the structuring
   technique used in the message body, then a sophisticated mail system
   could use such a field to automatically invoke the appropriate
   processing of the message body.  For example, a header field which
   indicated that the message body was encoded using Postscript could be
   used to direct a mail system running under Sun Microsystem's NEWS
   window manager to process the Postscript to produce the appropriate
   page image on the screen.

これらの例の両方では、メッセージ本体は法的な文字集合だけを含んでいますが、内容には、受取人による適切な処理の後に何らかの望ましい結果を生む構造があります。 メッセージ本体で使用される構造のテクニックを示すのにメッセージヘッダーフィールドを使用できるなら、精巧なメールシステムは、自動的にメッセージ本体の適切な処理を呼び出すのにそのような分野を使用するかもしれないでしょうに。 例えば、適切なページイメージをスクリーンに作り出すためにPostscriptを処理するようSun MicrosystemのNEWSウィンドウマネージャの下を走るメールシステムに指示するのにメッセージ本体がPostscriptを使用することでコード化されたのを示したヘッダーフィールドは使用できました。

   Private header fields (beginning with "X-") are already being used by
   some systems to affect such a result (e.g., the Andrew Message System
   developed at Carnegie Mellon University).  However, the widespread
   use of such techniques will require general agreement on the name and
   allowed parameter values for a header field to be used for this
   purpose.

個人的なヘッダーフィールド(「X」と共に始まる)はいくつかのシステムによって既に使用されていて(例えばアンドリューメッセージシステムはカーネギーメロン大学で展開しました)、そのような結果に影響します。 しかしながら、そのようなテクニックの普及使用は、ヘッダーフィールドがこのために使用されるために名前と許容パラメタ値で一般協定を必要とするでしょう。

   We propose that a new header field, "Content-type:"  be recognized as
   the standard field for indicating the structure of the message body.
   The contents of the "Content-Type:"  field are parameters which
   specify what type of structure is used in the message body.

私たちがそのa新しいヘッダーフィールドを提案する、「文書内容:」 メッセージ本体の構造を示すための標準の分野として、認識されてください。 コンテンツ、「コンテントタイプ:」 分野はどんなタイプの構造がメッセージ本体で使用されるかを指定するパラメタです。

   Note that we are not proposing that the message body contain anything
   other than ASCII characters as specified in RFC-822.  Whatever
   structuring is contained in the message body must be represented
   using only the allowed ASCII characters.  Thus, this proposal should
   have no impact on existing mailers, only on mail reading systems.

私たちが、メッセージ本体がRFC-822の指定されるとしてのASCII文字以外の何も含むよう提案していないことに注意してください。 許容ASCII文字だけを使用することでメッセージ本体に含まれているいかなる構造も表さなければなりません。 したがって、この提案は既存の郵送者の上と、そして、メール読書システムだけの上に影響力を全く持つべきではありません。

   At the same time, this restriction eliminates the use of more general
   structuring techniques such as Abstract Syntax Notation, (CCITT
   Recommendation X.409) as used in the X.400 messaging standard, which
   are octet-oriented.

同時に、この制限は抽象的なSyntax Notation、X.400メッセージング規格に使用される八重奏指向であることの(CCITT Recommendation X.409)などの、より一般的な構造のテクニックの使用を排除します。

   This is not the first proposal for structuring message bodies.
   RFC-767 discusses a proposed technique for structuring multi-media
   mail messages.  We are also aware that many users already employ mail
   to send TROFF, SCRIBE, TEX, Postscript or other structured
   information.  Such postprocessing as is required must be invoked

これは、メッセージ本体を構造化するための最初の提案ではありません。 RFC-767はマルチメディアメール・メッセージを構造化するための提案されたテクニックについて議論します。 また、私たちも多くのユーザがTROFF、SCRIBE、TEX、Postscriptまたは他の構造化された情報を送るのに既にメールを使うのを意識しています。 必要であるような後処理を呼び出さなければなりません。

Sirbu                                                           [Page 2]

RFC 1049                   Mail Content Type                  March 1988

シルブ[2ページ]RFC1049は1988年のcontent type行進を郵送します。

   manually by the message recipient who looks at the message text
   displayed as conventional ASCII and recognizes that it is structured
   in some way that requires additional processing to be properly
   rendered.  Our proposal is designed to facilitate automatic
   processing of messages by a mail reading system.

手動で、だれが、メッセージ受取人で、従来のASCIIとして表示されたメッセージ・テキストを見て、それが追加処理が適切にレンダリングされるのを必要とする何らかの方法で構造化されると認めますか? 私たちの提案は、メール読書システムでメッセージの自動処理を容易にするように設計されています。

2. Problems with Structured Messages

2. 構造化されたメッセージに関する問題

   Once we introduce the notion that a message body might require some
   processing other than simply painting the characters to the screen we
   raise a number of fundamental questions.  These generally arise due
   to the certainty that some receiving systems will have the facilities
   to process the received message and some will not.  The problem is
   what to do in the presence of systems with different levels of
   capability.

一度、私たちはメッセージ本体がいくつかを必要とするかもしれないという単に私たちが上げるスクリーンへのキャラクタを塗装するのを除いて、多くの基本的な質問を処理する概念を紹介します。 一般に、これらはいくつかの受電方式には施設があるという確実性のため受信されたメッセージを処理するために起こります、そして、何かはそのように起こらないでしょう。 問題はシステムがあるとき何をするかという異なったレベルの能力があることです。

   First, we must recognize that the purpose of structured messages is
   to be able to send types of information, ultimately intended for
   human consumption, not expressable in plain ASCII.  Thus, there is no
   way in plain ASCII to send the italics, boldface, or greek characters
   that can be expressed in Postscript.  If some different processing is
   necessary to render these glyphs, then that is the minimum price to
   be paid in order to send them at all.

まず最初に、私たちは、構造化されたメッセージの目的が明瞭なASCIIで「言い表-可能」するのではなく、結局人間の消費で意図した情報のタイプを送ることであることができると認めなければなりません。 したがって、Postscriptで示すことができるキャラクタをイタリック、肉太活字、またはgreekに送る明瞭なASCIIにおける方法が全くありません。 何らかの異なった処理がこれらのglyphsをレンダリングするのに必要であるなら、それは、彼らを全く送る最小の代価です。

   Second, by insisting that the message body contain only ASCII, we
   insure that it will not "break" current mail reading systems which
   are not equipped to process the structure; the result on the screen
   may not be readily interpretable by the human reader, however.

2番目に、メッセージ本体がASCIIだけを含むと主張することによって、私たちは、それが構造を処理するために備えていないシステムを読みながら現在のメールを「壊さないこと」を保障します。 しかしながら、スクリーンの結果は人間の読者が容易に解明できないかもしれません。

   If a message sender knows that the recipient cannot process
   Postscript, he or she may prefer that the message be revised to
   eliminate the use of italics and boldface, rather than appear
   incomprehensible.  If Postscript is being used because the message
   contains passages in Greek, there may be no suitable ASCII
   equivalent, however.

メッセージ送付者が、受取人がPostscriptを処理できないのを知っているなら、その人は、メッセージが不可解に見えるよりむしろイタリックと肉太活字の使用を排除するために改訂されるのを好むかもしれません。 しかしながら、メッセージがギリシア語で通路を含んでいるのでPostscriptが使用されているなら、どんな適当なASCII同等物もないかもしれません。

   Ideally, the details of structuring the message (or not) to conform
   to the capabilities of the recipient system could be completely
   hidden from the message sender.  The distributed Internet mail system
   would somehow determine the capabilities of the recipient system, and
   convert the message automatically; or, if there was no way to send
   Greek text in ASCII, inform the sender that his message could not be
   transmitted.

理想的に、受取人システムの能力に従うメッセージ(or not)を構造化する詳細にメッセージ送付者から完全に隠すことができました。 分配されたインターネット・メールシステムは、自動的にどうにか受取人システムの能力を決定して、メッセージを変換するでしょう。 または、ASCIIにギリシアのテキストを送る方法が全くなかったなら、彼のメッセージを送ることができなかったことを送付者に知らせてください。

Sirbu                                                           [Page 3]

RFC 1049                   Mail Content Type                  March 1988

シルブ[3ページ]RFC1049は1988年のcontent type行進を郵送します。

   In practice, this is a difficult task.  There are three possible
   approaches:

実際には、これは厄介な問題です。 3つの可能なアプローチがあります:

      1. Each mail system maintains a database of capabilities of
         remote systems it knows how to send to.  Such a database
         would be very difficult to keep up to date.

1. それぞれのメールシステムはそれがどのようにが発信するかを知っているリモートシステムの能力に関するデータベースを維持します。 そのようなデータベースは時代について行かせるのが非常に難しいでしょう。

      2. The mail transport service negotiates with the receiving
         system as to its capabilities.  If the receiving system
         cannot support the specified content type, the mail is
         transformed into conventional ASCII before transmission.
         This would require changes to all existing SMTP
         implementations, and could not be implemented in the case
         where RFC-822 type messages are being forwarded via Bitnet or
         other networks which do not implement SMTP.

2. メール輸送サービスは能力に関して受電方式と交渉されます。 受電方式が指定されたcontent typeをサポートすることができないなら、メールはトランスミッションの前に従来のASCIIに変えられます。 これは、すべての既存のSMTP実装への変化を必要として、RFC-822タイプメッセージがBitnetを通して転送されている場合かSMTPを実装しない他のネットワークで実装することができませんでした。

      3. An expanded directory service maintains information on mail
         processing capabilities of receiving hosts.  This eliminates
         the need for real-time negotiation with the final
         destination, but still requires direct interaction with the
         directory service.  Since directory querying is part of mail
         sending as opposed to mail composing/reading systems, this
         requires changes to existing mailers as well as a major
         change to the domain name directory service.

3. 拡張ディレクトリサービスは受信ホストのメール処理能力の情報を保守します。 これは、最終的な目的地でリアルタイムの交渉の必要性を排除しますが、ディレクトリサービスでまだ直接的な相互作用を必要としています。 ディレクトリ質問がメール構成/読書システムと対照的に発信するメールの一部であるので、これはドメイン名ディレクトリサービスへの大きな変化と同様に既存の郵送者への変化を必要とします。

   We note in passing that the X.400 protocol implements approach number
   2, and that the Draft Recommendations for X.DS, the Directory
   Service, would support option 3.

私たちは、通過でX.400プロトコルが、アプローチがNo.2であると実装して、X. DSのためのDraft Recommendations(ディレクトリサービス)が、オプションが3であるとサポートすることに注意します。

   In the interest of facilitating early usage of structured messages,
   we choose not to recommend any of the three approaches described
   above at the present time.  In a forthcoming RFC we will propose a
   solution based on option 2, requiring modification to mailers to
   support negotiation over capabilities.  For the present, then, users
   would be obliged to keep their own private list of capabilities of
   recipients and to take care that they do not send Postscript, TROFF
   or other structured messages to recipients who cannot process them.
   The penalty for failure to do so will be the frustration of the
   recipient in trying to read a raw Postscript or TROFF file painted on
   his or her screen.  Some System Administrators may attempt to
   implement option 1 for the benefit of their users, but this does not
   impose a requirement for changes on any other mail system.

構造化されたメッセージの早めの用法を容易にすることのために、私たちは、現在で上で説明された3つのアプローチのいずれも推薦しないのを選びます。 今度のRFCでは、私たちはオプション2に基づくソリューションを提案するつもりです、能力の上の交渉をサポートするために郵送者への変更を必要として。 当分、そして、それら自身の受取人の能力の個人的なリストを保って、ユーザが、彼らがPostscript、TROFFまたは他の構造化されたメッセージを彼らを処理できない受取人に送らないことに注意するのが強いられるでしょう。 そうしないことのための刑罰はその人のスクリーンに塗装された生のPostscriptかTROFFファイルを読もうとする際に受取人のフラストレーションになるでしょう。 いくつかのSystem Administratorsが、彼らのユーザの利益のためのオプション1を実装するのを試みるかもしれませんが、これはいかなる他のメールシステムにも変化のための要件を課しません。

   We recognize that the long-term solution must require changes to
   mailers.  However, in order to begin now to standardize the header
   fields, and to facilitate experimentation, we issue the present RFC.

私たちは、長期的な解決法が郵送者への変化を必要としなければならないと認めます。 しかしながら、ヘッダーフィールドを標準化して、現在実験を容易にし始めるために、私たちは現在のRFCを発行します。

Sirbu                                                           [Page 4]

RFC 1049                   Mail Content Type                  March 1988

シルブ[4ページ]RFC1049は1988年のcontent type行進を郵送します。

3. The Content-type Header Field

3. 文書内容ヘッダーフィールド

   Whatever structuring technique is specified by the Content-type
   field, it must be known precisely to both the sender and the
   recipient of the message in order for the message to be properly
   interpreted.  In general, this means that the allowed parameter
   values for the Content-type:  field must identify a well-defined,
   standardized, document structuring technique.  We do not preclude,
   however, the use of a Content-type:  parameter value to specify a
   private structuring technique known only to the sender and the
   recipient.

どんな構造のテクニックも文書内容分野によって指定されても、それは適切に解釈されるべきメッセージにおいて、整然としているメッセージをまさに送付者と受取人の両方に知っていなければなりません。 一般に、これは、許容パラメタが文書内容のために以下を評価することを意味します。 分野はテクニックを構造化する明確で、標準化されたドキュメントを特定しなければなりません。 しかしながら、私たちは文書内容の使用を排除しません: 送付者と受取人だけにおいて知られている個人的な構造のテクニックを指定するパラメタ値。

   More precisely, we propose that the Content-type:  header field
   consist of up to four parameter values.  The first, or type parameter
   names the structuring technique; the second, optional, parameter is a
   version number, ver-num, which indicates a particular version or
   revision of the standardized structuring technique.  The third
   parameter is a resource reference, resource-ref, which may indicate a
   standard database of information to be used in interpreting the
   structured document.  The last parameter is a comment.

より正確に、私たちがそれを提案する、文書内容: ヘッダーフィールドは最大4つのパラメタ値から成ります。 パラメタが構造のテクニックを命名する1番目、またはタイプ。 2番目、任意です、パラメタはバージョン番号、ver-numです。(そのver-numは標準化された構造のテクニックの特定のバージョンか改正を示します)。 3番目のパラメタはリソース参照、リソース審判です。(その審判は、構造化されたドキュメントを解釈する際に使用されるために情報の標準のデータベースを示すかもしれません)。 最後のパラメタはコメントです。

   In the Extended Backus Naur Form of RFC-822, we have:

RFC-822のExtendedバッカスナウアFormでは、私たちは以下を持っています。

   Content-Type:= type [";" ver-num [";" 1#resource-ref]] [comment]

コンテントタイプ: = タイプしてください、[「」、;、ver-num、[「」、;、1#リソース審判][コメント]

3.1. Type Values

3.1. 値をタイプしてください。

   Initially, the type parameter would be limited to the following set
   of values:

初めは、型引数は以下のセットの値に制限されるでしょう:

   type:=           "POSTSCRIPT"/"SCRIBE"/"SGML"/"TEX"/"TROFF"/
                    "DVI"/"X-"atom

タイプ: =「追伸」/「筆記者」/「SGML」/「テックス」/"TROFF"/"DVI"/「X」原子

   These values are not case sensitive.  POSTSCRIPT, Postscript, and
   POStscriPT are all equivalent.

これらの値は大文字と小文字を区別していません。 POSTSCRIPT、Postscript、およびPOStscriPTはすべて同等です。

   POSTSCRIPT      Indicates the enclosed document consists of
                   information encoded using the Postscript Page
                   Definition Language developed by Adobe Systems,
                   Inc. [1]

同封が記録するPOSTSCRIPT Indicatesはアドビ・システムズInc.によって開発されたPostscriptページDefinition Languageを使用することでコード化された情報から成ります。[1]

   SCRIBE          Indicates the document contains embedded formatting
                   information according to the syntax used by the
                   Scribe document formatting language distributed by
                   the Unilogic Corporation. [6]

Unilogic社によって分配されたScribeドキュメント形式言語によって使用される構文によると、ドキュメントが含むSCRIBE Indicatesは形式情報を埋め込みました。 [6]

   SGML            Indicates the document contains structuring
                   information to according the rules specified for

ドキュメントが指定された規則構造情報を含むSGML Indicates

Sirbu                                                           [Page 5]

RFC 1049                   Mail Content Type                  March 1988

シルブ[5ページ]RFC1049は1988年のcontent type行進を郵送します。

                   the Standard Generalized Markup Language, IS 8879,
                   as published by the International Organization for
                   Standardization. [3] Documents structured according
                   to the ISO DIS 8613--Office Docment Architecture and
                   Interchange Format--may also be encoded using SGML
                   syntax.

Standard Generalized Markup Language、発行されるとしての8879が国際標準化機構のそばにありますか? [3] また、ISO DIS8613によると、構造化されたドキュメント(オフィスDocment ArchitectureとInterchange Format)は、SGML構文を使用することでコード化されるかもしれません。

   TEX             Indicates the document contains embedded formatting
                   information according to the syntax of the TEX
                   document production language. [4]

TEXドキュメント生産言語の構文によると、ドキュメントが含むTEX Indicatesは形式情報を埋め込みました。 [4]

   TROFF           Indicates the document contains embedded formatting
                   information according to the syntax specified for the
                   TROFF formatting package developed by AT&T Bell
                   Laboratories. [5]

AT&Tベル研究所によって開発されたTROFF形式パッケージに指定された構文によると、ドキュメントが含むTROFF Indicatesは形式情報を埋め込みました。 [5]

   DVI             Indicates the document contains information according
                   to the device independent file format produced by
                   TROFF or TEX.

DVI Indicates、TROFFかTEXによって作り出されたデバイスの独立しているファイル形式に従って、ドキュメントは情報を含んでいます。

   "X-"atom        Any type value beginning with the characters "X-" is
                   a private value.

キャラクタ「X」と共に始まる「X」原子Anyタイプ価値は個人的な値です。

3.2. Version Number

3.2. バージョン番号

   Since standard structuring techniques in fact evolve over time, we
   leave room for specifying a version number for the content type.
   Valid values will depend upon the type parameter.

標準の構造のテクニックが時間がたつにつれて事実上発展するので、私たちはcontent typeのバージョン番号を指定する余地を残します。 有効値は型引数に依存するでしょう。

   ver-num:=      local-part

ver-num: =地方の部分

     In particular, we have the following valid values:

私たちには、特に、以下の有効値があります:

     For type=POSTSCRIPT

タイプ=追伸のために

   ver-num:= "1.0"/"2.0"/"null"

ver-num: = 「1インチ/」2インチ/「ヌル」

     For type=SCRIBE

タイプ=筆記者のために

   ver-num:= "3"/"4"/"5"/"null"

「ver-num: =「3インチ/」の4インチ/「5インチ/」ヌル」

     For type=SGML

タイプ=SGMLのために

   ver-num:="IS.8879.1986"/"null"

「ver-num: =が「何0.1986インチ/も.8879である」というヌル」

3.3. Resource Reference

3.3. リソース参照

   resource-ref:=  local-part

リソース審判: =地方の部分

Sirbu                                                           [Page 6]

RFC 1049                   Mail Content Type                  March 1988

シルブ[6ページ]RFC1049は1988年のcontent type行進を郵送します。

   As Apple has demonstrated with their implementation of the
   Laserwriter, a very general document structuring technique can be
   made more efficient by defining a set of macros or other similar
   resources to be used in interpreting any transmitted stream.  The
   Macintosh transmits a LaserPrep file to the Laserwriter containing
   font and macro definitions which can be called upon by subsequent
   documents.  The result is that documents as sent to the Laserwriter
   are considerably more compact than if they had to include the
   LaserPrep file each time.  The Resource Reference parameter allows
   specification of a well known resource, such as a LaserPrep file,
   which should be used by the receiving system when processing the
   message.

アップルがそれらのLaserwriterの実装で示したように、どんな伝えられたストリームも解釈する際に使用されるためにマクロか他の同様のリソースの1セットを定義することによって、テクニックを構造化する非常に一般的なドキュメントは、より効率的にすることができます。 マッキントッシュはその後のドキュメントで訪問できるフォントとマクロ定義を含むLaserwriterにLaserPrepファイルを送ります。 結果は発信して、LaserwriterがインクルードにそうしたならLaserPrepがファイルするよりかなりコンパクトな状態で多いときにドキュメントにそれぞれ調節されるということです。 Resource Referenceパラメタはよく知られているリソースの仕様を許容します、LaserPrepファイルのように。(メッセージを処理するとき、それは、受電方式によって使用されるべきです)。

   Resource references could also include macro packages for use with
   TEX or references to preprocessors such as eqn and tbl for use with
   troff.  Allowed values will vary according to the type parameter.

また、リソース参照はeqnやtblなどのプリプロセッサのtroffとの使用のTEXか参照で使用のためのマクロ・パッケージを含むかもしれません。 型引数によると、許容値は異なるでしょう。

     In particular, we propose the following values:

特に、私たちは以下の値を提案します:

     For type = POSTSCRIPT

タイプ=POSTSCRIPTのために

   resource-ref:=  "laserprep2.9"/"laserprep3.0"/"laserprep3.1"/
                   "laserprep4.0"/local-part

リソース審判: =、「laserprep2.9"/、「laserprep3.0"/、「laserprep3.1"/「laserprep4.0"/地方の部分」

     For type = TROFF

タイプ=TROFFのために

   resource-ref:=  "eqn"/"tbl"/"me"/local-part

リソース審判: ="eqn"/"tbl"/、/がローカルと同じくらい分ける「私」

3.4. Comment

3.4. コメント

   The comment field can be any additional comment text the user
   desires.  Comments are enclosed in parentheses as specified in
   RFC-822.

注釈欄はユーザが望んでいるどんな追加コメントテキストであるかもしれません。 コメントはRFC-822の指定されるとしての括弧に同封されます。

4. Conclusion

4. 結論

   A standardized Content-type field allows mail reading systems to
   automatically identify the type of a structured message body and to
   process it for display accordingly.  The strcutured message body must
   still conform to the RFC-822 requirements concerning allowable
   characters.  A mail reading system need not take any specific action
   upon receiving a message with valid Content-Type header field.  The
   ability to recognize this field and invoke the appropriate display
   process accordingly will, however, improve the readability of
   messages, and allow the exchange of messages containing mathematical
   symbols, or foreign language characters.

標準化された文書内容分野で、メール読書システムは、自動的に構造化されたメッセージ本体のタイプを特定して、ディスプレイのためにそれに従って、それを処理します。 strcuturedメッセージ本体は許容できるキャラクタに関してまだRFC-822要件に従わなければなりません。 メール読書システムは有効なコンテントタイプヘッダーフィールドでメッセージを受け取るのに少しの特定の動作も持っていく必要はありません。 この分野を認識して、適切なディスプレイプロセスを呼び出す能力は、それに従って、しかしながら、メッセージの読み易さを改良して、数学記号、または外国語キャラクタを含むメッセージの交換を許容するでしょう。

Sirbu                                                           [Page 7]

RFC 1049                   Mail Content Type                  March 1988

シルブ[7ページ]RFC1049は1988年のcontent type行進を郵送します。

   In the near term, the major use of a Content-Type:  header field is
   likely to be for designating the message body as containing a Page
   Definition Language representation such as Postscript.

近いうちにコンテントタイプの主用途: ヘッダーフィールドが、PostscriptなどのページDefinition Language表現を含むとメッセージ本体を指定するためにありそうです。

   Additional type values shall be registered with Internet Assigned
   Numbers Coordinator at USC-ISI.  Please contact:

追加タイプ値はUSC-ISIのインターネットAssigned民数記Coordinatorに示されるものとします。 連絡してください:

                   Joyce K. Reynolds
                   USC Information Sciences Institute
                   4676 Admiralty Way
                   Marina del Rey, CA  90292-6695

ジョイスK.レイノルズUSC情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア90292-6695

                   213-822-1511    JKReynolds@ISI.EDU

213-822-1511 JKReynolds@ISI.EDU

                                REFERENCES

参照

   1.  Adobe Systems, Inc.  Postscript Language Reference Manual.
       Addison-Wesley, Reading, Mass., 1985.

1. アドビ・システムズInc.追伸言語リファレンスマニュアル。 アディソン-ウエスリー、読書、マサチューセッツ州、1985。

   2.  Crocker, David H.  RFC-822:  Standard for the Format of ARPA
       Internet Text Messages.  Network Information Center,
       August 13, 1982.

2. クロッカー、デヴィッドH.RFC-822: アルパインターネットテキスト・メッセージの形式において、標準です。 インフォメーション・センター、1982年8月13日をネットワークでつないでください。

   3.  ISO TC97/SC18.  Standard Generalized Markup Language.
       Tech. Rept. DIS 8879, ISO, 1986.

3. ISO TC97/SC18。 マークアップ言語。 科学技術。 Rept。 不-8879、ISO、1986。

   4.  Knuth, Donald E.  The TEXbook.  Addison-Wesley, Reading, Mass.,
       1984.

4. クヌース、ドナルドE.TEXbook。 アディソン-ウエスリー、読書、マサチューセッツ州、1984。

   5.  Ossanna, Joseph F. NROFF/TROFF User's Manual.  Bell
       Laboratories, Murray Hill, New Jersey, 1976.  Computing Science
       Technical Report No.54.

5. Ossanna、ジョゼフF.NROFF/TROFFユーザマニュアル。 ベル研究所、マリー・ヒル(ニュージャージー)1976。 科学技術報告書No.54を計算します。

   6.  Unilogic.  SCRIBE Document Production Software.  Unilogic, 1985.
       Fourth Edition.

6. Unilogicである。 書類の提出ソフトウェアの線を引いてください。 Unilogic、1985。 第4版。

Sirbu                                                           [Page 8]

シルブ[8ページ]