RFC1154 日本語訳

Network Working Group                                        D. Robinson
Request for Comments: 1154                                    R. Ullmann
                                                    Prime Computer, Inc.
                                                              April 1990

コメントを求めるワーキンググループD.ロビンソンの要求をネットワークでつないでください: 1154 R.ウルマンプライムコンピュータInc.1990年4月

              Encoding Header Field for Internet Messages

インターネットメッセージのためのヘッダーフィールドをコード化します。

1. Status of the Memo

1. メモの状態

   This RFC proposes an elective experimental Encoding header field to
   permit the mailing of multi-part, multi-structured messages.

このRFCは、複合の、そして、マルチ構造化されたメッセージの郵送を可能にするために選挙の実験Encodingヘッダーフィールドを提案します。

   The use of Encoding updates RFC 1049 (Content-Type), and is a
   suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement)
   [4,7,8].

Encodingの使用は、RFC1049(コンテントタイプ)をアップデートして、RFCs1113、1114、および1115(プライバシーEnhancement)[4、7、8]への提案されたアップデートです。

   Distribution of this memo is unlimited.

このメモの分配は無制限です。

2. Introduction

2. 序論

   RFC 822 [2] defines an electronic mail message to consist of two
   parts, the message header and the message body, separated by an
   apparently blank line.

RFC822[2]は明らかに空白の線によって切り離された2つの部品から成る電子メールメッセージ、メッセージヘッダー、およびメッセージ本体を定義します。

   The Encoding header field permits the message body itself to be
   further broken up into parts, each part also separated from the next
   by an apparently blank line.

Encodingヘッダーフィールドは、メッセージ本体自体がさらに部品(また、明らかに空白の線によって次と切り離された各部分)に壊れるのを許容します。

   Thus, conceptually, a message has a header part, followed by one or
   more body parts, all separated by blank lines.

このようにして、概念的に、メッセージには、ヘッダー部分があります、続いて、空白行によってすべて切り離された1つ以上の身体の部分を持っています。

   Each body part has an encoding type.  The default (no Encoding field
   in the header) is a message body of one part of type "text".

コード化が部分でタイプする各ボディー。 デフォルト(ヘッダーでEncoding分野がない)はタイプ「テキスト」の一部のメッセージ本体です。

   3. The Encoding Field

3. コード化分野

   The Encoding field consists of one or more subfields, separated by
   commas.  Each subfield corresponds to a part of the message, in the
   order of that part's appearance.  A subfield consists of a line
   count, a keyword defining the encoding, and optional information
   relevant only to the specific encoding.  The line count is optional
   in the last subfield.

Encoding分野はコンマによって切り離された1つ以上の部分体から成ります。 各部分体はその部分の外観の注文におけるメッセージの一部に対応しています。 部分体はラインカウント、コード化を定義するキーワード、および特定のコード化だけに関連している任意の情報から成ります。 ラインカウントは最後の部分体で任意です。

3.1. Format of the Encoding Field

3.1. コード化分野の形式

   The format of the Encoding field is:

Encoding分野の形式は以下の通りです。

Robinson & Ullmann                                              [Page 1]

RFC 1154      Encoding Header Field for Internet Messages     April 1990

1990年4月にインターネットメッセージのためのヘッダーフィールドをコード化するロビンソンとウルマン[1ページ]RFC1154

     [<count> <keyword> [<options>], ]* [<count>] <keyword> [<options>]

[<カウント><キーワード>[<オプション>]]*[<カウント>]<キーワード>。[<オプション>]

     where:

どこ:

        <count>   := a decimal integer
        <keyword> := a single alphanumeric token starting with an alpha
        <options> := keyword-dependent options

アルファ<オプション>:=キーワード扶養家族をきっかけに10進整数の>:=a単一の英数字の<キーワード象徴がゆだねる<カウント>:=

3.2. <count>

3.2. <カウント>。

   The line count is a decimal number specifying the number of text
   lines in the part.  Parts are separated by a blank line, which is not
   included in the count of either the proceeding or following part.
   Because a count always begins with a digit and a keywords always
   begins with an letter, it is always possible to determine if the
   count is present.  (The count is first because it is the only
   information of interest when skipping over the part.)

ラインカウントは部分のテキスト線の数を指定する10進数です。 部品は、空白行によって切り離されるか、または部分に続けています。(空白行は進行のカウントに含まれていません)。 カウントがいつもケタで始まって、キーワードが手紙でいつも始まるので、カウントが存在しているかどうか決定するのはいつも可能です。 (部分を飛ばすとき、それが興味がある唯一の情報であるので、カウントは1番目です。)

   The count is not required on the last or only part.

カウントは最終か唯一の部分の上で必要ではありません。

3.3. <keyword>

3.3. <キーワード>。

   The keyword defines the encoding type.  The keyword is a common
   single word name for the encoding type.  The keywords are not case-
   sensitive.

キーワードはコード化しているタイプを定義します。 キーワードはコード化しているタイプのための一般的な一語名です。 キーワードはケース機密ではありません。

   The list of standard keywords is intended to be the same as the list
   used for the Content-Type: header described in [6].  This RFC
   proposes additions to the list.  Implementations can then treat
   "Content-Type" as an alias of "Encoding", which will always have only
   one body part.

標準のキーワードのリストがコンテントタイプに使用されるリストと同じであることを意図します: [6]で説明されたヘッダー。 このRFCはリストへの追加を提案します。 そして、実現はいつも1つの身体の部分しか持たない「コード化」の別名として「コンテントタイプ」を扱うことができます。

3.4. <options>

3.4. <オプション>。

   The optional information is used to specify additional keyword-
   specific information needed for interpreting the contents of the
   encoded part.  It is any sequence of tokens not containing a comma.

任意情報は、コード化された部分のコンテンツを解釈するのに必要である追加キーワード特殊情報を指定するのに使用されます。 それはコンマを含まない象徴のあらゆる系列です。

3.5. Encoding Version Numbers

3.5. バージョン番号をコード化します。

   In general, version numbers for encodings, when not actually
   available within the contents of the encoded information, will be
   handled as options.

実際にコード化された情報のコンテンツの中で利用可能でないときに、一般に、encodingsのバージョン番号はオプションとして扱われるでしょう。

3.6. Comments

3.6. コメント

   Comments enclosed in parentheses may, of course, be inserted anywhere
   in the Encoding field.  Mail reading systems may pass the comments to

括弧に同封されたコメントはもちろんEncoding分野でどこでも挿入されるかもしれません。 システムがコメントを通過するかもしれない読書を郵送してください。

Robinson & Ullmann                                              [Page 2]

RFC 1154      Encoding Header Field for Internet Messages     April 1990

1990年4月にインターネットメッセージのためのヘッダーフィールドをコード化するロビンソンとウルマン[2ページ]RFC1154

   their clients.  Comments must not be used by mail reading systems for
   content interpretation; that is the function of options.

彼らのクライアント。 コメントは満足している解釈のシステムを読む郵便配達人に使用されてはいけません。 それはオプションの機能です。

4. Encodings

4. Encodings

   This section describes some of the defined encodings used.

このセクションはencodingsが使用した定義のいくつかについて説明します。

   As with the other keyword-defined parts of the header format
   standard, extensions in the form of new keywords are expected and
   welcomed.  Several basic principles should be followed in adding
   encodings:

ヘッダー形式規格の他のキーワードで定義された部品のように、新しいキーワードの形における拡大は、予想されて、歓迎されます。 encodingsを加える際にいくつかの基本原理に従うべきです:

      - The keyword should be the most common single word name for the
      encoding, including acronyms if appropriate.  The intent is that
      different implementors will be likely to choose the same name for
      the same encoding.

- キーワードは大部分がコード化のための頭文字語を含む一般的な一語名であるなら適切であるならそうするでしょうに。 意図は異なった作成者を同じコード化のための同じ名前を選びそうであるということです。

      - Keywords not be too general: "binary" would have been a bad
      choice for the "hex" encoding.

- キーワード、一般的過ぎてください: 「バイナリー」は「十六進法」コード化のための下手な選択だったでしょう。

      - The encoding should be as free from unnecessary idiosyncracies
      as possible, except when conforming to an existing standard, in
      which case there is nothing that can be done.

- コード化には、不要な特異性ができるだけあるべきではありません、既存の規格に従って、その場合、できないことがある時を除いて。

      - The encoding should, if possible, use only the 7 bit ASCII
      printing characters if it is a complete transformation of a source
      document (e.g., "hex" or "uuencode").  If it is essentially a text
      format, the full range may be used.  If there is an external
      standard, the character set may already be defined.

- できれば、コード化はそれがソースドキュメント(例えば、「十六進法」か"uuencode")の完全な変化であるなら7ビットのASCII表示文字だけを使用するべきです。 それが本質的にはテキスト形式であるなら、最大限の範囲は使用されるかもしれません。 外部の規格があれば、文字の組は既に定義されるかもしれません。

   Keywords beginning with "X-" are permanently reserved to
   implementation-specific use.  No standard registered encoding keyword
   will ever begin with "X-".

「X」と共に始まるキーワードは永久に、実現特定的用法に予約されます。 キーワードをコード化しながら示されなかった規格は全く「X」と共に始まるでしょう。

4.1. Text

4.1. テキスト

   This indicates that the message is in no particular encoded format,
   but is to be presented to the user as is.

これは、どんな特定のコード化された形式にもメッセージがないのを示しますが、そのままでユーザに提示されることになっています。

   The full range of the ASCII character set is used.  The message is
   expected to consist of lines of reasonable length (less than 1000
   characters).

ASCII文字の組の最大限の範囲は使用されています。 メッセージが妥当な長さ(1000未満のキャラクタ)の線から成ると予想されます。

   On some transport services, only the 7 bit subset of ASCII can be
   used.  Where full 8 bit transparency is available, the text is
   assumed to be ISO 8859-1 [3] (ASCII-8).

いくつかの輸送サービスのときに、ASCIIの7ビットの部分集合しか使用できません。 8ビットの完全な透明が利用可能であるところでは、テキストはISO8859-1[3](ASCII-8)であると思われます。

Robinson & Ullmann                                              [Page 3]

RFC 1154      Encoding Header Field for Internet Messages     April 1990

1990年4月にインターネットメッセージのためのヘッダーフィールドをコード化するロビンソンとウルマン[3ページ]RFC1154

4.2. Message

4.2. メッセージ

   This encoding indicates that the body part is itself in the format of
   an Internet message, with its own header part and body part(s).  A
   "message" body part's message header may be a full internet message
   header or it may consist only of an Encoding field.

このコード化は、インターネットメッセージの形式には身体の部分がそれ自体であるのを示します、それ自身のヘッダー部分と身体の部分で。 身体の部分のメッセージヘッダーが完全なインターネットメッセージヘッダーであるかもしれないという「メッセージ」かそれがEncoding分野だけから成るかもしれません。

   Using the message encoding on returned mail makes it practical for a
   mail reading system to implement a reliable resending function, if
   the mailer generates it when returning contents.  It is also useful
   in a "copy append" MUA operation.

返されたメールでメッセージコード化を使用するのにメール読書システムが信頼できる再送機能を実行するのが実用的になります、コンテンツを返すとき、郵送者がそれを発生させるなら。 また、それもaで役に立つ、「コピーは」 MUA操作を追加します。

   Message encoding is also used when mapping to X.400 to handle
   recursively included X.400 P2 messages.

また、再帰的に含まれているX.400 P2メッセージを扱うためにX.400に写像するとき、メッセージコード化は使用されます。

4.3. Hex

4.3. 十六進法

   The encoding indicates that the body part contains binary data,
   encoded as 2 hexadecimal digits per byte, highest significant nibble
   first.

コード化は、身体の部分が最初に1バイトあたり2つの16進数字、最も高いかなりの少量としてコード化された2進のデータを含むのを示します。

   Lines consist of an even number of hexadecimal digits.  Blank lines
   are not permitted.  The decode process must accept lines with between
   2 and 1000 characters, inclusive.

線は16進数字の偶数から成ります。 空白行は受入れられません。 2〜1000がキャラクタ的であって、包括的に解読の過程は線を受け入れなければなりません。

4.4. EVFU

4.4. EVFU

   EVFU (Electronic Vertical Format Unit) specifies that each line
   begins with a one-character "channel selector".  The original purpose
   was to select a channel on a paper tape loop controlling the printer.

EVFU(電子Vertical Format Unit)は、各線が1キャラクタ「チャンネル・セレクタ」で始まると指定します。 初心はプリンタを制御しながら紙テープ輪の上でチャンネルを選ぶことでした。

   This encoding is sometimes called "FORTRAN" format. It is the default
   output format of FORTRAN programs on a number of computer systems.

このコード化は時々「FORTRAN」形式と呼ばれます。 それは多くのコンピュータ・システムの上のFORTRANプログラムのデフォルト出力形式です。

   The legal characters are '0' to '9', '+', '-', and space.  These
   correspond to the 12 rows (and absence of a punch) on a printer
   control tape (used when the control unit was electromechanical).

法的なキャラクタは'9、''+''への'0'です--'スペース。 これらはプリンタコントロールテープ(制御装置が電気機械であったときに、使用される)の上の12の列(そして、パンチの不在)に対応しています。

   The channels that have generally agreed definitions are:

一般に、定義に同意したチャンネルは以下の通りです。

           1     advances to the first print line on the next page
           0     skip a line, i.e., double-space
           +     over-print the preceeding line
           -     skip 2 lines, i.e., triple-space
        (space)  print on the next line, single-space

すなわち、preceeding線をダブルスペースにするか、または重ね打ちしてください--次の0ページの最初の印刷線への1進歩は線をスキップして、スキップ2は立ち並んでいて、すなわち、トリプル・スペース(スペース)は次の線への印刷です、シングルスペース

Robinson & Ullmann                                              [Page 4]

RFC 1154      Encoding Header Field for Internet Messages     April 1990

1990年4月にインターネットメッセージのためのヘッダーフィールドをコード化するロビンソンとウルマン[4ページ]RFC1154

4.5. EDI

4.5. エディ

   The EDI (Electronic Document Interchange) keyword indicates that the
   message or part is a business document, formatted according to ANSI
   X12 or related standards.

EDI(電子Document Interchange)キーワードは、メッセージか部分がANSI X12か関連する規格に従ってフォーマットされたビジネスドキュメントであることを示します。

   The first word after the EDI keyword indicates the particular
   interchange standard.

EDIキーワードの後の最初の単語は特定の置き換え規格を示します。

   A message containing a note and 2 X12 purchase orders might have an
   encoding of:

注意と2つのX12購買注文を含むメッセージは以下のコード化を持っているかもしれません。

       Encoding: 17 TEXT, 146 EDI X12, 69 EDI X12

コード化します: 17 テキスト、146エディX12、69エディX12

4.6. X.400

4.6. X.400

   The Encoding header field provides a mechanism for mapping multi-part
   messages between CCITT X.400 [1] and RFC 822.

EncodingヘッダーフィールドはCCITT X.400[1]とRFC822の間で複合メッセージを写像するのにメカニズムを提供します。

   The X.400 keyword specifies a section that is converted from an X.400
   body part type not known to the gateway, or not corresponding to a
   useful internet encoding.

X.400キーワードはゲートウェイに知られないか、または役に立つインターネットコード化に文通しないX.400ボディー部分タイプから変換されるセクションを指定します。

   If the message transits another gate, or if the receiving user has
   the appropriate software, it can be decoded and used.

メッセージが別のゲートを通過するか、または受信ユーザに適切なソフトウェアがあるなら、それを解読して、使用できます。

   The X.400 keyword is followed by a second token indicating the method
   used.  The simplest form is "X.400 HEX", with the complete X.409
   encoding of the body part in hexadecimal.  More compact is "X.400
   3/4", using the 3-byte to 4-character encoding as specified in RFC
   1113, section 4.3.2.4.

方法が使用したのを示す2番目の象徴はX.400キーワードを支えています。 最も簡単なフォームは16進における、身体の部分の完全なX.409コード化がある「X.400十六進法」です。 よりコンパクトであるのは、「RFC1113、セクション4.3.2における指定されるとしての4キャラクタのコード化への3バイトの.4を使用するX.400 3/4インチ」です。

4.7. uuencode

4.7. uuencode

   The uuencode keyword specifies a section consisting of the output of
   the uuencode program supplied as part of uucp.

uuencodeキーワードはuucpの一部として提供されたuuencodeプログラムの出力から成るセクションを指定します。

4.8. encrypted

4.8. コード化されています。

   The encrypted keyword indicates that the section is encrypted with
   the methods in RFC 1115 [8].  This replaces the possible use of RFC
   934 [5] encapsulation.

コード化されたキーワードは、方法がRFC1115[8]にある状態でセクションがコード化されるのを示します。 これはRFC934[5]カプセル化の活用可能性を取り替えます。

References

参照

  [1]  International Telegraph and Telephone Consultative Committee,
       "Data Communication Networks: Message Handling Systems", In CCITT
       Recommendations X.400 to X.430, VIIIth Plenary Assembly, Malaga-

[1] 国際電信電話諮問委員会、「データ通信は以下をネットワークでつなぎます」。 X.430へのCCITT推薦X.400、VIIIth総会、マラガの「メッセージハンドリングシステム」

Robinson & Ullmann                                              [Page 5]

RFC 1154      Encoding Header Field for Internet Messages     April 1990

1990年4月にインターネットメッセージのためのヘッダーフィールドをコード化するロビンソンとウルマン[5ページ]RFC1154

       Torremolinos, 1984, Fascicle VIII.7 ("Red Book").

トレモリノス、1984、分冊VIII.7(「職員録」)。

  [2]  Crocker, D., "Standard for the Format of ARPA Internet Text
       Messages", RFC 822, University of Delaware, August 1982.

[2] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、RFC822、デラウエア大学、1982年8月。

  [3]  International Organization for Standardization, "Information
       processing - 8-bit single-byte coded graphic character sets -
       Part 1: Latin alphabet No. 1", ISO 8859-1, ISO, 1987.

[3] 国際標準化機構、「情報処理--8ビットの単一のバイトコード化された図形文字セット--第1部:、」 ローマ字No.1インチ、ISO8859-1、ISO、1987。

  [4]  Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
       I -- Message Encipherment and Authentication Procedures", RFC
       1113, IAB Privacy Task Force, August 1989.

[4] リン、J.、「インターネット電子メールのためのプライバシー増進:」 「Iを分けてください--暗号文と認証手順を通信させてください」、RFC1113、IABプライバシー特別委員会、1989年8月。

  [5]  Rose, M., and E. Stefferud, "Proposed Standard for Message
       Encapsulation", RFC 943, University of Delaware and NMA, January
       1985.

[5] ローズ、M.とE.Stefferud、「メッセージカプセル化の提案された標準」RFC943とデラウエア大学とNMA、1985年1月。

  [6]  Sirbu, M., "Content-type Header Field for Internet Messages", RFC
       1049, CMU, March 1988.

[6] シルブ、M.、「インターネットメッセージのための文書内容ヘッダーフィールド」、RFC1049、米カーネギーメロン大学、1988年3月。

  [7]  Kent, S., and J. Linn, "Privacy Enhancement for Internet
       Electronic Mail: Part II -- Certificate-Based Key Management",
       RFC 1114, IAB Privacy Task Force, August 1989.

[7] ケント、S.、およびJ.リン、「インターネット電子メールのためのプライバシー増進:」 「IIを分けてください--証明書ベースのKey Management」、RFC1114、IABプライバシー特別委員会、8月1989

  [8]  Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
       III -- Algorithms, Modes, and Identifiers", RFC 1115, IAB Privacy
       Task Force, August 1989.

[8] リン、J.、「インターネット電子メールのためのプライバシー増進:」 「IIIを分けてください--アルゴリズム、モード、および識別子」、RFC1115、IABプライバシー特別委員会、8月1989

Security Considerations

セキュリティ問題

   Security issues are not addressed in this memo.

安全保障問題はこのメモに記述されません。

Authors' Addresses

作者のアドレス

   David Robinson 10-30
   Prime Computer, Inc.
   500 Old Connecticut Path
   Framingham, MA 01701

デイビッド・ロビンソン10-30プライムコンピュータInc.500の古いコネチカットPathフレイミングハム、MA 01701

   Phone: +1 508 879 2960 x1774

以下に電話をしてください。 +1 508 879、2960x1774

   Email: DRB@Relay.Prime.COM

メール: DRB@Relay.Prime.COM

   Robert Ullmann 10-30
   Prime Computer, Inc.
   500 Old Connecticut Path
   Framingham, MA 01701

ロバート・ウルマン10-30プライムコンピュータInc.500の古いコネチカットPathフレイミングハム、MA 01701

Robinson & Ullmann                                              [Page 6]

RFC 1154      Encoding Header Field for Internet Messages     April 1990

1990年4月にインターネットメッセージのためのヘッダーフィールドをコード化するロビンソンとウルマン[6ページ]RFC1154

   Phone: +1 508 879 2960 x1736

以下に電話をしてください。 +1 508 879、2960x1736

   Email: Ariel@Relay.Prime.COM

メール: Ariel@Relay.Prime.COM

Robinson & Ullmann                                              [Page 7]

ロビンソンとウルマン[7ページ]