RFC934 日本語訳

Network Working Group                        Marshall T. Rose (Delaware)
Request for Comments: 934                       Einar A. Stefferud (NMA)
                                                            January 1985

コメントを求めるワーキンググループのマーシャル・T.ローズ(デラウェア)Requestをネットワークでつないでください: 934 Einar A.Stefferud(NMA)1985年1月

              Proposed Standard for Message Encapsulation

メッセージカプセル化の提案された標準

STATUS OF THIS MEMO

このメモの状態

   This RFC suggests a proposed protocol for the ARPA-Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

このRFCは改良のためにARPA-インターネットコミュニティ、要求議論、および提案のための提案されたプロトコルを勧めます。 このメモの分配は無制限です。

Introduction, Scope, and Motivation

序論、範囲、および動機

   The services that a user agent (UA) can offer are varied.  Although
   all outgoing mail may be thought of as going through a single posting
   slot to connect to the message transport system (MTS), it is possible
   to consider a message draft being posted as described by one of the
   following four types of postings:

ユーザエージェント(UA)が提供できるサービスは様々です。 すべての送信するメールがメッセージ輸送システム(MTS)に接続するために単一の任命スロットを通ると考えられるかもしれませんが、以下の4つのタイプの任命の1つで説明されるように掲示されるメッセージ草稿を考えるのは可能です:

      Originate - a new message is composed from scratch, which, to the
      knowledge of the UA, is unrelated to any message previously
      handled by the user.

由来してください--新しいメッセージは最初から、構成されます(以前にユーザによってどんなメッセージにも扱われた状態で、UAに関する知識に関係ありません)。

      Reply - a message is composed as a reply to a message previously
      received by the user.  In most circumstances, the UA aids the user
      in composing the reply by constructing the header portion of the
      message draft, using components extracted from the received
      message headers.

回答--メッセージに関する回答が以前にユーザのそばで受信されて、メッセージは落ち着いています。 ほとんどの事情では、UAはメッセージ草稿のヘッダー部分を構成することによって回答を構成する際にユーザを支援します、容認されたメッセージヘッダーから抽出されたコンポーネントを使用して。

      Forward - one more more messages previously received by the user
      are formatted by the UA as a part of the body portion of the
      draft.  In this sense, a "digest" for an interest group may be
      considered as forwarding.  Similarly, an argument may be made that
      "blind-carbon-copies" should also be handled in this fashion.

フォワード--より多くのメッセージが以前にユーザで受け取ったもうひとつは草稿のボディー部分の一部としてUAによってフォーマットされます。 この意味で、営利団体のための「ダイジェスト」は推進であるとみなされるかもしれません。 同様に、また、「盲目のカーボンコピー」がこんなやり方で扱われるべきであるという主張をするかもしれません。

      Distribute - a message previously received by the user is
      re-posted to the MTS.  The draft being re-posted is identical to
      the original message with the exception that certain "ReSent-XXX"
      headers are appended to the headers portion of the draft, and the
      "Return-Path" header is reset to reference the re-sender's
      address.  (See [RFC-821] for a discussion of the Return-Path
      header.)

分配、--以前にユーザによって受け取られたメッセージはMTSに再び投函されます。 例外がそんなに確かな状態で再び投函される草稿がオリジナルのメッセージと同じである、「XXXに憤慨する、」 草稿のヘッダー部分にヘッダーを追加して、再送付者のアドレスに参照をつけるために「リターンパス」ヘッダーをリセットします。 (Return-経路ヘッダーの議論に関して[RFC-821]を見てください。)

   Most user agents support the first two of these activities, many
   support the first three, and a few support all four.

ほとんどのユーザエージェントがこれらの2つの最初の活動を支持します、そして、多くが最初の3を支持します、そして、いくつかはすべての4を支持します。

   This memo concerns itself only with the third type, which is message
   forwarding.  (For a brief treatment of the semantics of message
   components with respect to replies, see [RFC-822].) In many ways,

単に3番目のタイプでこのメモはタッチしています(メッセージ推進です)。 (回答に関するメッセージコンポーネントの意味論の簡潔な処理に関して、[RFC-822]を見てください。) 様々な意味で

Rose & Stefferud                                                [Page 1]

ローズとStefferud[1ページ]

RFC 934                                                     January 1985
Message Encapsulation

RFC934 1985年1月のメッセージカプセル化

   forwarding can be thought of as encapsulating one or more messages
   inside another.  Although this is useful for transfer of past
   correspondence to new recipients, without a decapsulation process
   (which this memo terms "bursting"), the forwarded messages are of
   little use to the recipients because they can not be distributed,
   forwarded, replied-to, or otherwise processed as separate individual
   messages.

別のものに1つ以上のメッセージを要約すると推進を考えることができます。 これは新しい受取人への過去の通信の転送の役に立ちますが、被膜剥離術の過程(このメモが「はち切れ」ながら呼ぶ)がなければ、転送されたメッセージは、彼らを分配できませんし、進めることができませんし、答えることができませんし、また別の方法で別々の個々のメッセージとして処理できないので、ほとんど受取人の役に立ちません。

      NOTE: RFC-822 mistakenly refers to distribution as forwarding
      (section 4.2).  This memo suggests below, that these two
      activities can and should be the same.

以下に注意してください。 RFC-822は(セクション4.2)を進めると分配を誤って呼びます。 これらの2つの活動が、同じであることができ、このメモは以下に示されて、同じであるべきです。

   In the case of an interest group digest, a bursting capability is
   especially useful.  Not only does the ability to burst a digest
   permit a recipient of the digest to reply to an individual digested
   message, but it also allows the recipient to selectively process the
   other messages encapsulated in the digest.  For example, a single
   digest issue usually contains more than one topic.  A subscriber may
   only be interested in a subset of the topics discussed in a
   particular issue.  With a bursting capability, the subscriber can
   burst the digest, scan the headers, and process those messages which
   are of interest.  The others can be ignored, if the user so desires.

営利団体ダイジェストの場合では、はち切れる能力は特に役に立ちます。 また、ダイジェストを押し破く能力は、ダイジェストの受取人が個々の読みこなされたメッセージに答えることを許可するだけではなく、受取人がそれで選択的にダイジェストで要約された他のメッセージを処理できます。 例えば、通常、ただ一つのダイジェスト問題は1つ以上の話題を含んでいます。 加入者は特定の問題で議論した話題の部分集合に興味を持っているだけであるかもしれません。 はち切れる能力で、加入者は、ダイジェストを押し破いて、ヘッダーをスキャンして、それらの興味があるメッセージを処理できます。 ユーザがそう望んでいるなら、他のものを無視できます。

   This memo is motivated by three concerns:

このメモは3回の関心によって動機づけられています:

      In order to burst a message it is necessary to know how the
      component messages were encapsulated in the draft.  At present
      there is no unambiguous standard for interest group digests.  This
      memo proposes such a standard for the ARPA-Internet.  Although
      interest group digests may appear to conform to a pseudo-standard,
      there is a serious ambiguity in the implementations which produce
      digests.  By proposing this standard, the authors hope to solve
      this problem by specifically addressing the implementation
      ambiguity.

メッセージを押し破くために、コンポーネントメッセージが草稿でどのように要約されたかを知るのが必要です。 現在のところ、営利団体ダイジェストのどんな明白な規格もありません。 このメモはARPA-インターネットのそのような規格を提案します。 営利団体ダイジェストは疑似規格に従うように見えるかもしれませんが、ダイジェストを製作する実現には重大なあいまいさがあります。 この規格を提案することによって、作者は、明確に実現のあいまいさを記述することによってこの問題を解決することを望んでいます。

      Next, there is much confusion as to how "blind-carbon-copies"
      should be handled by UAs.  It appears that each agent in the
      ARPA-Internet which supports a "bcc:" facility does so
      differently. Although this memo does not propose a standard for
      the generation of blind-carbon-copies, it introduces a formalism
      which views the "bcc:" facility as a special case of the
      forwarding activity.

次に、「盲目のカーボンコピー」がUAsによってどう扱われるはずであるかに関して多くの混乱があります。 それがそれに見える、「bcc:」を支持するARPA-インターネットの各エージェント 施設はそれほど異なってします。 このメモは盲目のカーボンコピーの世代の規格を提案しませんが、それは「bcc:」を見る形式を紹介します。 施設、特殊なものとして、推進活動について。

      Finally, both forwarding and distribution can be accomplished with
      the same forwarding procedure, if a distributed message can be
      extracted as a separate individually processable message.  With a
      proper bursting agent, it will be difficult to distinguish between

最終的に、同じ推進手順で推進と分配の両方を実行できます、別々の個別に処理可能なメッセージとして分配されたメッセージを抜粋できるなら。 見分けるのはそれが適切なはち切れているエージェントにとって、難しくなるでしょう。

Rose & Stefferud                                                [Page 2]

ローズとStefferud[2ページ]

RFC 934                                                     January 1985
Message Encapsulation

RFC934 1985年1月のメッセージカプセル化

      a message which has been distributed and a message which has been
      extracted from a forwarded message. This memo argues that there is
      no valuable distinction to be made, between forwarding and
      distribution, and that in the interests of simplicity,
      distribution facilities should not be generally available to the
      ordinary users of a message system.  However, this memo also
      argues that such facilities should be available to certain trusted
      entities within the MTS.

分配されたメッセージと転送されたメッセージから抜粋されたメッセージ。 このメモは推進と分配の間でされるどんな貴重な区別もなくて、メッセージシステムの一般ユーザには、簡単さのために一般に、分配施設が利用可能であるべきでないと主張します。 しかしながら、また、このメモは、MTSの中のある信じられた実体について、そのような施設があるはずであると主張します。

         NOTE: this memo does not propose that the distribution facility
         be abolished.  Rather it argues the case forcefully in the hope
         that other interested parties in the ARPA-Internet will join
         this discussion.

以下に注意してください。 このメモは、分配施設が撤廃されるよう提案しません。 むしろそれはARPA-インターネットの他の利害関係者がこの議論に参加するという望みで力強くケースについて論争します。

Message Encapsulation

メッセージカプセル化

   This memo proposes the following encapsulation protocol: two agents
   act on behalf of the user, a forwarding agent, which composes the
   message draft prior to posting, and a bursting agent which decomposes
   the message after delivery.

このメモは以下のカプセル化プロトコルを提案します: 2人のエージェントがユーザ、任命の前にメッセージ草稿を構成する小口運送業者、およびはち切れているエージェントを代表して行動します(配送の後にメッセージを分解します)。

   Definitions: a draft forwarding message consists of a header portion
   and a text portion.  If the text portion is present, it is separated
   from the header portion by a blank line.  Inside the text portion a
   certain character string sequence, known as an "encapsulation
   boundary", has special meaning.  Currently (in existing
   digestification agents), an encapsulation boundary (EB) is defined as
   a line in the message which starts with a dash (decimal code 45,
   "-").  Initially, no restriction is placed on the length of the
   encapsulation boundary, or on the characters that follow the dash.

定義: 草稿推進メッセージはヘッダー部分とテキスト部分から成ります。 テキスト部分が存在していると、それは空白行によってヘッダー部分と切り離されます。 テキスト部分の中では、「カプセル化境界」として知られているある文字列系列は特別な意味を持っています。 現在(既存のdigestificationエージェントで)、カプセル化(EB)境界はダッシュ(10進コード45、「-」)から始まるメッセージで線と定義されます。 初めは、制限は全くカプセル化境界の長さ、またはダッシュの後をつけるキャラクタに関して課されません。

   1. The Header Portion

1. ヘッダー部分

   This memo makes no restriction on the header portion of the draft,
   although it should conform to the RFC-822 standard.

RFC-822規格に従うべきですが、このメモは草稿のヘッダー部分で制限を全くしません。

   2. The Text Portion

2. テキスト部分

   The text of the draft forwarding message consists of three parts: an
   initial text section, the encapsulated messages, and the final text
   section.

草稿推進メッセージのテキストは3つの部品から成ります: 初期のテキスト部、要約のメッセージ、および最終版の教科書部。

      2.1. The Initial Text Section

2.1. 初期のテキスト部

      All text (if any) up to the first EB comprises the initial text
      section of the draft.  This memo makes no restrictions on the

最初のEBまでのすべてのテキスト(もしあれば)が草稿の初期のテキスト部を包括します。 このメモは制限を全くしません。

Rose & Stefferud                                                [Page 3]

ローズとStefferud[3ページ]

RFC 934                                                     January 1985
Message Encapsulation

RFC934 1985年1月のメッセージカプセル化

      format of the initial text section of the draft.  In the case of a
      digest, this initial text is usually the "table of contents" of
      the digest.

草稿の初期のテキスト部の形式。 ダイジェストの場合では、通常、この初期のテキストはダイジェストの「目次」です。

      2.2. The Final Text Section

2.2. 最終版の教科書部

      All text (if any) after the last EB composes the final text
      section of the draft.  This memo makes no restrictions on the
      format of the final text section of the draft.  In the case of a
      digest, this final text usually contains the sign-off banner for
      the digest (e.g., "End of FOO Digest").

最後のEBの後のすべてのテキスト(もしあれば)が草稿の最終版の教科書部を構成します。 このメモは草稿の最終版の教科書部の形式で制限を全くしません。 ダイジェストの場合では、通常、この最終版の教科書はダイジェスト(例えば、「FOOダイジェストの終わり」)のための下にサインするバナーを含んでいます。

      2.3. Encapsulated Messages

2.3. 要約のメッセージ

      Each encapsulated message is bounded by two EBs: a pre-EB, which
      occurs before the message; and, a post-EB, which occurs after the
      message.  For two adjacent encapsulated messages, the post-EB of
      the first message is also the pre-EB of the second message.
      Consistent with this, two adjacent EBs with nothing between them
      should be treated as enclosing a null message, and thus two or
      more adjacent EBs are equivalent to one EB.

それぞれの要約のメッセージは2EBsで境界があります: プレEB(EBはメッセージの前に起こります)。 aポスト-EB、そして、どれがメッセージの後に起こりますか? 2つの隣接している要約のメッセージに関しては、また、最初のメッセージについてEBを掲示するのは、2番目のメッセージのプレEBです。 これと一致しています、彼らの間には、何もない2隣接しているEBsがヌルメッセージを同封するとして扱われるべきです、そして、その結果、2隣接しているEBsが1EBに同等です。

      Each encapsulated message consists of two parts: a headers portion
      and a text portion.  If the text portion is present, it is
      separated from the header portion by a blank line.

それぞれの要約のメッセージは2つの部品から成ります: ヘッダー部分とテキスト部分。 テキスト部分が存在していると、それは空白行によってヘッダー部分と切り離されます。

         2.3.1. The Header Portion

2.3.1. ヘッダー部分

         Minimally, there must be two header items in each message being
         forwarded, a "Date:" field and a "From:" field. This differs
         from RFC-822, which requires at least one destination address
         (in a "To:" or "cc:" field) or a possibly empty "Bcc:" field.
         Any addresses occuring in the header items for a message being
         forwarded must be fully qualified.

最少量で、2つのヘッダーの品目が転送される各メッセージ、「日付:」にあるに違いありません。 分野と「From:」 さばきます。 これはRFC-822、どれが少なくとも1つの送付先アドレス(「To:」か「cc:」分野の)を必要とするか、そして、またはことによると空の「Bcc:」と異なっています。 さばきます。 いずれも完全に進めるのに資格がなければならないというメッセージのためにヘッダーの品目における存在を記述します。

         2.3.2. The Text Portion

2.3.2. テキスト部分

         This memo makes no restrictions on the format of the text
         portion of each encapsulated message.  (Actually, this memo
         does restrict the format of the text portion of each
         encapsulated message, but these restrictions are discussed
         later.)

このメモはそれぞれの要約のメッセージのテキスト部分の形式で制限を全くしません。 (実際に、このメモはそれぞれの要約のメッセージのテキスト部分の形式を制限しますが、後でこれらの制限について議論します。)

   Before summarizing the generation/parsing rules for message
   encapsulation, two issues are addressed.

メッセージカプセル化のために世代/構文解析規則をまとめる前に、2冊は記述されます。

Rose & Stefferud                                                [Page 4]

ローズとStefferud[4ページ]

RFC 934                                                     January 1985
Message Encapsulation

RFC934 1985年1月のメッセージカプセル化

Compatibility with Existing User Agents

既存のユーザエージェントとの互換性

   The above encapsulation protocol is presently used by many user
   agents in the ARPA-Internet, and was specifically designed to
   minimize the amount of changes to existing implementations of
   forwarding agents in the ARPA-Internet.

上のカプセル化プロトコルは、現在ARPA-インターネットの多くのユーザエージェントによって使用されて、ARPA-インターネットでの小口運送業者の既存の実現への変化の量を最小にするように明確に設計されました。

   However, the protocol is not exactly like the pseudo-standard used by
   those forwarding agents that compose digests.  In particular, the
   post-EB of all messages encapsulated in a digest is preceeded and
   followed by by a blank line.  In addition, the first message
   encapsulated in a digest has a pre-EB that is followed by a blank
   line, but usually isn't preceeded by a blank line (wonderful).

しかしながら、プロトコルはちょうどダイジェストを構成するそれらの小口運送業者によって使用された疑似規格に似ていません。 空白行は、ダイジェストで要約されたすべてのメッセージのポスト-EBが特に、preceededされて、あとに続いています。 さらに、ダイジェストで要約された最初のメッセージは空白行があとに続いていますが、空白行(素晴らしい)によって通常、preceededされないプレEBを持っています。

   This memo recommends that implementors of forwarding agents wishing
   to remain compatible with existing bursting agents consider
   surrounding each EB with a blank line.  It should be noted that blank
   lines following a pre-EB for an encapsulated message must be ignored
   by bursting agents.  Further, this memo suggests that blank lines
   preceeding a post-EB also be ignored by bursting agents.

このメモは、エージェントを押し破く存在と互換性があったままで残りたがっている小口運送業者の作成者が、各EBを空白行に取り巻くと考えることを勧めます。 エージェントを押し破くことによって要約のメッセージのためのプレEBに続く空白行を無視しなければならないことに注意されるべきです。 さらに、このメモは、また、ポスト-EBをpreceedingする空白行がエージェントを押し破くことによって無視されるのを示します。

      NOTE: This recommendation is made in the interest of
      backwards-compatibility.  A forwarding agent wishing to strictly
      adhere to this memo, should not generate blank lines surrounding
      EBs.

以下に注意してください。 遅れている互換性のためにこの推薦状をします。 小口運送業者が厳密にこのメモを固く守りたい場合、空白行の周囲のEBsを発生させるべきではありません。

Character-Stuffing the Encapsulation Boundary

カプセル化境界をキャラクターで詰めます。

   It should be noted that the protocol is general enough to support
   both general forwarding of messages and the specific case of digests.
   Unfortunately, there is one issue of message encapsulation which
   apparently is not addressed by any forwarding agent (to the authors'
   knowledge) in the ARPA-Internet: what action does the forwarding
   agent take when the encapsulation boundary occurs within a the text
   portion of a message being forwarded?  Without exception, this
   circumstance is ignored by existing forwarding agents.

プロトコルがメッセージの一般的な推進とダイジェストの特定のケースの両方を支えるほど一般的であることに注意されるべきです。 残念ながら、どんな小口運送業者(作者のものが知っている限り、)によっても明らかに記述されないメッセージカプセル化の1冊がARPA-インターネットにあります: カプセル化境界がテキストが分配する転送されるメッセージのaの中に起こると、小口運送業者はどんな行動を取りますか? 例外がなければ、この状況は既存の小口運送業者によって無視されます。

   To address this issue, this memo proposes the following
   character-stuffing scheme: the encapsulation boundary is defined as a
   line which starts with a dash.  A special case is made for those
   boundaries which start with a dash and are followed by a space
   (decimal code 32, " ").

この問題を記述するために、このメモは以下のキャラクタを詰める計画を提案します: カプセル化境界はダッシュから始まる線と定義されます。 特別な弁護をダッシュから始まるそれらの境界にされて、スペースはあとに続いています。(小数が32をコード化する、「「)、」

      During forwarding, if the forwarding agent detects a line in the
      text portion of a message being forwarded which starts with the
      encapsulation boundary, the forwarding agent outputs a dash
      followed by a space prior to outputting the line.

推進の間、小口運送業者がカプセル化境界から始まる転送されるメッセージのテキスト部分に線を検出するなら、小口運送業者はダッシュを出力します、続いて、線を出力する前に、スペースを出力します。

Rose & Stefferud                                                [Page 5]

ローズとStefferud[5ページ]

RFC 934                                                     January 1985
Message Encapsulation

RFC934 1985年1月のメッセージカプセル化

      During bursting, if the bursting agent detects an encapsulation
      boundary which starts with a dash followed by a space, then the
      bursting agent does not treat the line as an encapsulation
      boundary, and outputs the remainder of the line instead.

はち切れている間、はち切れているエージェントがスペースがあとに続いたダッシュから始まるカプセル化境界を検出するなら、はち切れているエージェントは、カプセル化境界として線を扱わないで、代わりに線の残りを出力します。

   This simple character-stuffing scheme permits recursive forwardings.

この簡単なキャラクタを詰める計画は再帰的な推進を可能にします。

Generation/Parsing Rules for Message Encapsulation

メッセージカプセル化のための世代/構文解析規則

   The rules for forwarding/bursting are described in terms of regular
   expressions.  The first author originally derived simple finite-state
   automata for the rules, but was unable to legibly represent them in
   this memo.  It is suggested that the implementors sketch the automata
   to understand the grammar.

進めるか、またははち切れるための規則は正規表現で説明されます。 第1代作者は、元々規則のために簡単な有限州のオートマトンを引き出しましたが、このメモにそれらを読みやすく表すことができませんでした。 作成者が文法を理解するためにオートマトンについてスケッチすることが提案されます。

   The conventions used for the grammar are simple.  Each state is
   followed by one or more alternatives, which are separated by the "|"
   character.  Each alternative starts with a character that is received
   as input. (CRLF, although two characters is treated as one character
   herein.)  The last alternative for a state is the character "c",
   which represents any character not specified in the preceeding
   alternatives.  Optionally following the input character is an output
   string enclosed by curly-braces.  Following this is the state that
   the automata enters.  The reader should note that these grammars are
   extremely simple to implement (and, in most cases, can be implemented
   quite efficiently).

文法に使用されるコンベンションは簡単です。 「1つ以上の選択肢が各状態のあとに続いている、」。(選択肢は切り離されます)。|「キャラクタ。」 各選択肢は入力されるように受け取られていているキャラクタから始まります。 (CRLF、2ですが、キャラクタはここに1つのキャラクタとして扱われます。) 状態への最後の代替手段はキャラクタ「c」です。(そのキャラクタはpreceeding代替手段で指定されなかった少しのキャラクタも代理をします)。 任意に入力キャラクタに続くのは、巻き毛の支柱によって同封された出力ストリングです。 これに続くのは、オートマトンが入る状態です。 読者は、これらの文法は実行するのが(そして、多くの場合、全く効率的に実行できます)非常に簡単であることに注意するべきです。

   When the forwarding agent encapsulates a message, it should apply the
   following finite-state automaton.  The initial state is S1.

小口運送業者がメッセージを要約するとき、それは以下の有限状態オートマトンを適用するべきです。 初期状態はS1です。

      S1 ::   CRLF {CRLF} S1
            | "-" {"- -"} S2
            | c {c} S2

S1:、: CRLF CRLF、S1| 「--」、「--、--、」、S2| c c S2

      S2 ::   CRLF {CRLF} S1
            | c {c} S2

S2:、: CRLF CRLF、S1| c c S2

   This simply says that anytime a "-" is found at the beginning of a
   line, a "- " is output prior to outputting the line.

これは、いつでも、「-」が線の始めに見つけられると単に言って、「-」は線を出力する前の出力です。

Rose & Stefferud                                                [Page 6]

ローズとStefferud[6ページ]

RFC 934                                                     January 1985
Message Encapsulation

RFC934 1985年1月のメッセージカプセル化

   When the bursting agent decapsulates the text portion of a draft, it
   should apply the following finite-state automaton.  The initial state
   is S1.

はち切れているエージェントが草稿のテキスト一部をdecapsulatesするとき、それは以下の有限状態オートマトンを適用するべきです。 初期状態はS1です。

      S1 ::   "-" S3
            | CRLF {CRLF} S1
            | c {c} S2

S1:、: 「--」S3| CRLF CRLF、S1| c c S2

      S2 ::   CRLF {CRLF} S1
            | c {c} S2

S2:、: CRLF CRLF、S1| c c S2

      S3 ::   " " S2
            | c S4

S3:、: 「"S2"| c S4

      S4 ::   CRLF S5
            | c S4

S4:、: CRLF S5| c S4

      S5 ::   CRLF S5
            | c {c} S2

S5:、: CRLF S5| c c S2

   Although more complicated than the grammar used by the forwarding
   agent to encapsulate a single message, this grammer is still quite
   simple.  Let us make the simplifying assumption that both the initial
   and final text sections of the draft are messages in addition to the
   encapsulated messages.

ただ一つのメッセージを要約するのに小口運送業者によって使用された文法より複雑ですが、このgrammerはまだかなり簡単です。 草稿の両方の初期的、そして、最終的なテキスト部が要約のメッセージに加えたメッセージであるという簡素化仮定をしましょう。

   To begin, the current message being burst is scanned at state S1. All
   characters are output until the EB is found (state S3).  If "- " is
   found, the automaton enters state S2 and characters from the current
   message are continued to be output.  Finally, a true EB is found
   (state S4).  As the automaton traverses from state S3 to S4, the
   bursting agent should consider the current message ended.  The
   remainder of the EB is discarded (states S4 and S5).  As the
   automaton traverses from state S5 to S2, the bursting agent should
   consider a new message started and output the first character.  In
   state S2, all characters are output until the EB is found.

始まるように、押し破かれる現在のメッセージは州のS1でスキャンされます。 (州のS3)がEBに見つけられるまで、すべてのキャラクタが出力されます。 「-」が見つけられるなら、オートマトンは州のS2に入ります、そして、現在のメッセージからのキャラクタは、出力になるように続けられています。 最終的に、(州のS4)は本当のEBに見つけられます。 オートマトンがS3を状態からS4に横断するとき、はち切れているエージェントは、現在のメッセージが終わったと考えるべきです。 EBの残りは捨てられます(S4とS5を述べます)。 オートマトンがS5を状態からS2に横断するのに従って、はち切れているエージェントは、新しいメッセージが出発したと考えて、最初のキャラクタを出力するべきです。 州のS2では、EBが見つけられるまで、すべてのキャラクタが出力されます。

Blind Carbon Copies

盲目のカーボンコピー

   Many user agents support a blind-carbon-copy facility.  With this
   facility a draft has two types of addressees: visible and blind
   recipients.  The visible recipients are listed as addresses in the
   "To:" and "cc:" fields of the draft, and the blind recipients are
   listed as addresses in the "Bcc:" fields of the draft.  The basis of
   this facility is that copies of the draft which are delivered to the
   recipients list the visible recipients only.

多くのユーザエージェントが盲目のカーボンコピー施設を支持します。 この施設があるので、草稿には、2つのタイプの受け取り人がいます: 目に見えて盲目の受取人。 目に見える受取人はアドレスとして「To:」に記載されています。 そして、「cc:」 アドレスとして「Bcc:」で記載された受取人を草稿、および盲人としてさばきます。 草稿の分野。 この施設の基礎は受取人に届けられる草稿のコピーが目に見える受取人だけを記載するということです。

Rose & Stefferud                                                [Page 7]

ローズとStefferud[7ページ]

RFC 934                                                     January 1985
Message Encapsulation

RFC934 1985年1月のメッセージカプセル化

   One method of achieving this is to post a single draft, which lacks
   any "Bcc:" fields, and, during posting, to interact with the MTS in
   such a way that copies are sent to both the visible and blind
   recipients.

これを達成する1つの方法はただ一つの草稿を掲示することです。(それは、どんな「Bcc:」も欠いています)。 分野、任命の間、中にMTSがあるそのような方法でそれを相互作用させるように、両方の目に見えて盲目の受取人にコピーを送ります。

   Unfortunately, a key problem with this arrangement is that the blind
   recipients can accidently reply to the draft in such a way that the
   visible recipients are included as addressees in the reply. This is
   socially unacceptable!  To avoid this problem, the message which the
   visible recipients receive must be different than the message which
   the blind recipients receive.

残念ながら、このアレンジメントに関する主要な問題は盲目の受取人が事故に回答における受け取り人のような目に見える受取人が含まれている方法で草稿に答えることができるということです。 これは社会的に容認できません! この問題を避けるために、目に見える受取人が受け取るメッセージは盲目の受取人が受け取るメッセージと異なっていなければなりません。

   A second method is to post two drafts.  The first, which goes to the
   visible recipients, is simply the draft without any "Bcc:" fields.
   The second, which goes to the blind recipients, is simply the draft
   with some string prepended to any "To:" and "cc:" field. For example,
   the user agent might prepend "BCC-" to these fields, so that the
   blind recipients get a draft with "BCC-To:" and "Bcc-cc:" fields and
   no "To:" or "cc:" fields. Unfortunately, this is often very confusing
   to the blind recipients.  Although accidental replies are not
   possible, it is often difficult to tell that the draft received is
   the result of a blind-carbon-copy.

2番目の方法は2つの草稿を掲示することです。 1(目に見える受取人のものになる)番目が単に少しも「Bcc:」のない草稿です。 分野。 2番目(盲目の受取人のものになる)が単に何らかのストリングがどんな「To:」にもprependedされている草稿です。 そして、「cc:」 さばきます。 例えば、ユーザエージェントはこれらの分野への「BCC」をprependするかもしれません、盲目の受取人が「BCC To:」との草稿を得るように そして、「Bcc-cc:」 分野にもかかわらず、「To:」がありません。 または、「cc:」 分野。 残念ながら、盲目の受取人には、これはしばしば非常に紛らわしいです。 偶然の回答は可能ではありませんが、受け取られた草稿が盲目のカーボンコピーの結果であると言うのはしばしば難しいです。

   The method which this memo suggests is to post two drafts, a visible
   draft for the visible recipients, and a blind draft for the blind
   recipients.  The visible draft consists of the original draft without
   any "Bcc:" fields.  The blind draft contains the visible message as a
   forwarded message.  The headers for the blind draft contain the
   minimal RFC-822 headers and, if the original draft had a "Subject:"
   field, then this header field is also included.  In addition, the
   user agent might explicitly show that the blind draft is the result
   of a blind-carbon-copy, with a "Bcc" header or prior to the first
   encapsulating boundary in the body.

このメモが示す方法は2つの草稿、目に見える受取人にとって、目に見える草稿、および盲目の受取人にとっての盲目の草稿を掲示することです。 目に見える草稿は少しも「Bcc:」なしでオリジナルの草稿から成ります。 分野。 盲目の草稿は転送されたメッセージとして目に見えるメッセージを含んでいます。 そして、盲目の草稿のためのヘッダーが最小量のRFC-822ヘッダーを含んでいる、オリジナルの草稿には、「Subject:」がありました。 また、分野、次にこのヘッダーフィールドは含まれています。 さらに、ユーザエージェントは、盲目の草稿がボディーの盲目のカーボンコピーしている"Bcc"ヘッダーか最初の要約の前に境界の結果であることを明らかに示すかもしれません。

Message Distribution

メッセージの振分け

   The main purpose of message distribution (often called redistribution
   or resending) is to provide to a secondary recipient, perhaps not
   included among the original addressees, with a "true original" copy
   that can be treated like an original in every respect.

メッセージの振分け(しばしば再分配か再送と呼ばれる)の主な目的はすべての点でオリジナルのように扱うことができる「本当のオリジナル」コピーで恐らく元の受け取り人の中に含まれていなかった二次受取人に提供することです。

   Such distribution is most often done by discussion group moderators
   who use automated agents to simply repost received messages to a
   distribution list.  The better automatic distribution agents insert a
   new "Return-Path" header field to direct address failure notices to
   the discussion group address list maintainer, rather than to the
   original author.  This form of distribution is encouraged because it

単に受信されたメッセージを発送先リストに再び投函するのに自動化されたエージェントを使用するディスカッション・グループ議長がそのような分配をたいてい完了しています。 より良い自動販売代理人は原作者にというよりむしろディスカッション・グループ住所録維持装置への直接アドレス失敗通知に新しい「リターンパス」ヘッダーフィールドを挿入します。 この形式の分配が奨励される、それ

Rose & Stefferud                                                [Page 8]

ローズとStefferud[8ページ]

RFC 934                                                     January 1985
Message Encapsulation

RFC934 1985年1月のメッセージカプセル化

   most simply serves to deliver messages to discussion group recipients
   as processable originals.  It is performed by trusted pseudo-MTS
   agents.

最も単に、メッセージを議論に送るサーブは処理可能オリジナルとして受取人を分類します。 それは信じられた疑似MTSエージェントによって実行されます。

   A second kind of distribution is that done by individuals who wish to
   transfer a processable copy of a received message to another
   recipient. This second form is discouraged in various new standards
   for message transfer.  These include the NBS Standard for Mail
   Interchange [FIPS-98], and the recent CCITT draft MHS (Mail Handling
   Systems) X.400 standards [X.400]. In place of direct reposting of
   received messages as though they are new drafts, the recommendation
   is to forward the received message in the body of a new draft from
   which is can be extracted by its secondary recipient for further
   processing.

受信されたメッセージの処理可能コピーを別の受取人に移したがっている個人によって行われて、第2種の分配はそれです。 この2番目のフォームはメッセージ転送の様々な新しい規格でがっかりしています。 これらはメールInterchangeのためのNBS Standard[FIPS-98]、および最近のCCITT草稿MHS(Handling Systemsに郵送する)X.400規格[X.400]を含んでいます。 推薦がそれらが新しい草稿であるのにフォワードに似ているという受信されたメッセージのダイレクト再び投函に代わって、どれがあるかから二次受取人はさらなる処理のために新しい草稿のボディーの受信されたメッセージを抜粋できます。

   It is in support of this recommendation that this standard for
   encapsulation/decapsulation is proposed.

それはカプセル化/被膜剥離術のこの規格が提案されるというこの推薦を支持しています。

Rose & Stefferud                                                [Page 9]

ローズとStefferud[9ページ]

RFC 934                                                     January 1985
Message Encapsulation

RFC934 1985年1月のメッセージカプセル化

References

参照

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

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

   [RFC-821]    J.B. Postel.  "Simple Mail Transfer Protocol",
                USC/Information Sciences Institute.  (August, 1982).

[RFC-821]J.B.ポステル。 USC/情報科学は、「簡単なメール転送プロトコル」と設けます。 (1982年8月。)

   [FIPS-98]    National Bureau of Standards.  "Specification for
                Message Format for Computer Based Message Systems."
                (January, 1983).

[FIPS-98]規格基準局。 「コンピュータのためのメッセージ・フォーマットのための仕様はメッセージシステムを基礎づけました」。. (1月、1983。)

   [X.400]      Consultative Committee on International Telephone and
                Telegraph.  "DRAFT Recommendation X.400.  Message
                Handling Systems: System Model-Service Elements."

国際電話と電報の[X.400]諮問委員会。 「推薦X.400を作成してください。」 メッセージハンドリングシステム: 「システムモデルサービス要素。」

Authors' Addresses

作者のアドレス

   Marshall T. Rose

マーシャルT.は上昇しました。

      Department of Computer and Information Sciences
      University of Delaware
      Newark, DE 19716

コンピュータの部とデラウエア大学ニューアーク、情報科学DE 19716

      MRose@UDel.ARPA

MRose@UDel.ARPA

   Einar A. Stefferud

Einar A.Stefferud

      Network Management Associates, Inc.
      17301 Drey Lane
      Huntington Beach, CA 92647

ネットワークマネージメントはLaneハンティントンビーチ、Inc.17301Dreyカリフォルニア 92647を関連づけます。

      Stef@UCI.ARPA

Stef@UCI.ARPA

Rose & Stefferud                                               [Page 10]

ローズとStefferud[10ページ]