RFC1022 日本語訳

Network Working Group                                      C. Partridge
Request For Comment: 1022                                      BBN/NNSC
                                                             G. Trewitt
                                                               Stanford
                                                           October 1987

コメントを求めるワーキンググループC.ヤマウズラ要求をネットワークでつないでください: 1022 BBN/NNSC G.Trewittスタンフォード1987年10月

          THE HIGH-LEVEL ENTITY MANAGEMENT PROTOCOL (HEMP)

ハイレベルの実体管理プロトコル(大麻)

STATUS OF THIS MEMO

このメモの状態

   An application protocol for managing network entities such as hosts,
   gateways and front-end machines, is presented.  This protocol is a
   component of the High-Level Entity Management System (HEMS) described
   in RFC-1021.  Readers may want to consult RFC-1021 when reading this
   memo.  This memo also assumes a knowledge of the ISO data encoding
   standard, ASN.1.  Distribution of this memo is unlimited.

ホストなどのネットワーク実体を管理するためのアプリケーション・プロトコル(ゲートウェイとフロントエンドマシン)は、提示されます。 このプロトコルはRFC-1021で説明されたHigh-レベルEntity Management System(HEMS)の部品です。 このメモを読むとき、読者はRFC-1021に相談したがっているかもしれません。 ASN.1、また、このメモはISO zデータの符号化に関する知識が標準であると仮定します。 このメモの分配は無制限です。

PROTOCOL OVERVIEW

プロトコル概要

   The High-Level Entity Management Protocol (HEMP) provides an
   encapsulation system and set of services for communications between
   applications and managed entities.  HEMP is an application protocol
   which relies on existing transport protocols to deliver HEMP messages
   to their destination(s).

High-レベルEntity Managementプロトコル(HEMP)はアプリケーションと管理された実体とのコミュニケーションのためのサービスのカプセル化システムとセットを提供します。 HEMPはそれらの目的地へのメッセージをHEMPに提供するために既存のトランスポート・プロトコルを当てにするアプリケーション・プロトコルです。

   The protocol is targeted for management interactions between
   applications and entities.  The protocol is believed to be suitable
   for both monitoring and control interactions.

プロトコルはアプリケーションと実体との管理相互作用のために狙います。 プロトコルがモニターとコントロール相互作用の両方に適当であると信じられています。

   HEMP provides what the authors believe are the three essential
   features of a management protocol:  (1) a standard encapsulation
   scheme for all interactions, (2) an authentication facility which can
   be used both to verify messages and limit access to managed systems,
   and (3) the ability to encrypt messages to protect sensitive
   information.  These features are discussed in detail in the following
   sections.

HEMPは作者が管理プロトコルに関する3つの基本的な特徴であると信じているものを提供します: (1) (2) すべての相互作用の標準のカプセル化体系、ともにメッセージについて確かめるのに使用できる認証施設と限界は機密情報を保護するメッセージを暗号化する能力に管理されたシステム、および(3)にアクセスします。 以下のセクションで詳細にこれらの特徴について議論します。

PROTOCOL OPERATION

プロトコル操作

   HEMP is designed to support messages; where a message is an
   arbitrarily long sequence of octets.

HEMPはメッセージをサポートするように設計されています。 メッセージが八重奏の任意に長い系列であるところ。

   Five types of messages are currently defined: request, event, reply,
   and protocol error, and application error messages.  Reply, protocol
   error and application error messages are only sent in reaction to a
   request message, and are referred to collectively as responses.

5つのタイプに関するメッセージは現在、定義されます: 要求、イベントは、返答して、誤り、およびアプリケーションエラーメッセージについて議定書の中で述べます。 回答、プロトコル誤り、およびアプリケーションエラーメッセージは、要求メッセージに反応で送られるだけであり、応答とまとめて呼ばれます。

Partridge & Trewitt                                             [Page 1]

RFC 1022                     HEMS Protocol                  October 1987

ヤマウズラとTrewitt[1ページ]RFC1022はプロトコル1987年10月にへりを取ります。

   Two types of interaction are envisioned: a message exchange between
   an application and an entity managed by the application, and
   unsolicited messages from an entity to the management centers
   responsible for managing it.

相互作用の2つのタイプが思い描かれます: アプリケーションで管理されたアプリケーションと実体の間の交換処理、および実体からそれを管理するのに責任がある管理センターまでのお節介なメッセージ。

   When an application wants to retrieve information from an entity or
   gives instructions to an entity, it sends a request message to the
   entity.  The entity replies with a response, either a reply message
   if the request was valid, or an error message if the request was
   invalid (e.g., failed authentication).  It is expected that there
   will only be one response to a request message, although the protocol
   does not preclude multiple responses to a single request.

アプリケーションが実体からの情報を検索したいか、または実体に教授するとき、それは要求メッセージを実体に送ります。 実体は、応答で返答して、要求が通信したなら、要求が有効であって、エラーメッセージであったなら通信しますaが、返答する。無効です(例えば、認証に失敗します)。 要求メッセージへの1つの応答しかないと予想されます、プロトコルはただ一つの要求への複数の応答を排除しませんが。

   Protocol error messages are generated if errors are found when
   processing the HEMP encapsulation of the message.  The possible
   protocol error messages are described later in this document.  Non-
   HEMP errors (e.g., errors that occur during the processing of the
   contents of the message) are application errors.  The existence of
   application error messages does not preclude the possibility that a
   reply will have an error message in it.  It is expected that the
   processing agent on the entity may have already started sending a
   reply message before an error in a request message is discovered.  As
   a result, application errors found during processing may show up in
   the reply message instead of a separate application error message.

メッセージのHEMPカプセル化を処理するとき、誤りが見つけられるなら、プロトコルエラーメッセージは発生しています。 可能なプロトコルエラーメッセージは後で本書では説明されます。 非HEMPの誤り(例えばメッセージのコンテンツの処理の間に発生する誤り)はアプリケーションエラーです。 アプリケーションエラーメッセージの存在は回答がそれにエラーメッセージを持つ可能性を排除しません。 実体の処理エージェントが、要求メッセージにおける誤りが発見される前に応答メッセージを送るのを既に出発したかもしれないと予想されます。 その結果、処理の間に見つけられたアプリケーションエラーは別々のアプリケーションエラーメッセージの代わりに応答メッセージに現れるかもしれません。

   Note that in certain situations, such as on secure networks,
   returning error messages may be considered undesirable.  As a result,
   entities are not required to send error messages, although on
   "friendly" networks the use of error messages is encouraged.

安全なネットワークなどのある状況で、戻っているエラーメッセージが望ましくないと考えられるかもしれないことに注意してください。 その結果、実体はエラーメッセージを送るのに必要ではありません、エラーメッセージの使用が「好意的な」ネットワークで奨励されますが。

   Event messages are unsolicited notices sent by an entity to an
   address, which is expected to correspond to one or more management
   centers.  (Note that a single address may correspond to a multicast
   address, and thus reach multiple hosts.)  Event messages are
   typically used to allow entities to alert management centers of
   important changes in their state (for example, when an interface goes
   down or the entity runs out of network buffers).

イベントメッセージは実体によって1つ以上の管理センターに相当すると予想されるアドレスに送られた求められていない通知です。 (ただ一つのアドレスがマルチキャストアドレスに一致するかもしれないことに注意してください、そして、その結果、複数のホストに届いてください。) 実体がそれらの状態の重要な変化の管理センターを警告するのを許容するのにおいてイベントメッセージは通常使用されています(例えば、インタフェースがいつ落ちるか、そして、実体がネットワーク・バッファを使い果たします)。

Partridge & Trewitt                                             [Page 2]

RFC 1022                     HEMS Protocol                  October 1987

ヤマウズラとTrewitt[2ページ]RFC1022はプロトコル1987年10月にへりを取ります。

STANDARD MESSAGE FORMAT

標準のメッセージ・フォーマット

   Every HEMP message is put in the general form shown in Figure 1.

あらゆるHEMPメッセージが図1で見せられた一般的なフォームに入れられます。

                     +-------------------------------+
                     :           leader              :
                     +-------------------------------+
                     :       encryption section      :
                     +-------------------------------+
                     :    reply encryption section   :
                     +-------------------------------+
                     :     authentication section    :
                     +-------------------------------+
                     :          common header        :
                     +-------------------------------+
                     :              data             :
                     +-------------------------------+

+-------------------------------+ : リーダー: +-------------------------------+ : 暗号化部: +-------------------------------+ : 暗号化部は返答します: +-------------------------------+ : 認証部: +-------------------------------+ : 一般的なヘッダー: +-------------------------------+ : データ: +-------------------------------+

                  Figure 1: General Form of HEMP Messages

図1: 一般フォームに関する大麻メッセージ

   Each message has five components: (1) the leader, which is simply the
   ASN.1 tag and message length; (2) the encryption section, which
   provides whatever information the receiver may require to decrypt the
   message; (3) the reply encryption section, in which the requesting
   application may specify the type of encryption to use in the reply;
   (4) the authentication section, which allows the receiver to
   authenticate the message; (5) the common header, which identifies the
   message type, the HEMP version, and the message id; and (6) the data
   section.  All four sections following the leader are also ASN.1
   encoded.  The ASN.1 format of the message is shown in Figure 2.

各メッセージには、5つのコンポーネントがあります: (1) リーダー(そのリーダーは、単にASN.1タグとメッセージ長です)。 (2) 暗号化部((それは、提供します)受信機がメッセージを解読するのを必要とするどんな情報も)。 (3) 回答暗号化部そこでは要求アプリケーションが回答に使用する暗号化のタイプを指定するかもしれません。 (4) 認証部(受信機はそれでメッセージを認証できます)。 (5) 一般的なヘッダー(ヘッダーはメッセージタイプ、HEMPバージョン、およびメッセージイドを特定します)。 (6) そして、資料課。 また、リーダーに続くすべての4つのセクションがコード化されたASN.1です。 メッセージのASN.1書式は図2に示されます。

          HempMessage ::= [0] IMPLICIT SEQUENCE {
              [0] IMPLICIT EncryptSection OPTIONAL,
              [1] IMPLICIT ReplyEncryptSection OPTIONAL,
              [2] IMPLICIT AuthenticateSection OPTIONAL,
              [3] IMPLICIT CommonHeader,
              [4] IMPLICIT Data }

HempMessage:、:= [0] 暗黙の系列[4] [0] 内在しているEncryptSection任意の、そして、[1]の暗黙のReplyEncryptSection任意の、そして、[2]の内在しているAuthenticateSection任意の[3]内在しているCommonHeader、暗黙のデータ

                  Figure 2: ASN.1 Format of HEMP Messages

図2: 大麻メッセージのASN.1形式

   The ordering of the sections is significant.  The encryption section
   comes first so that all succeeding sections (which may contain
   sensitive information) may be encrypted.  The authentication section
   precedes the header so that messages which fail authentication can be
   discarded without header processing.

セクションの注文は重要です。 暗号化部は最初に、続くすべてのセクション(機密情報を含むかもしれない)が暗号化されるかもしれないようになります。 認証部は、ヘッダー処理なしで認証に失敗するメッセージを捨てることができるようにヘッダーに先行します。

Partridge & Trewitt                                             [Page 3]

RFC 1022                     HEMS Protocol                  October 1987

ヤマウズラとTrewitt[3ページ]RFC1022はプロトコル1987年10月にへりを取ります。

THE ENCRYPTION SECTION

暗号化部

Need For Encryption

暗号化の必要性

   Encryption must be supported in any management scheme.  In
   particular, a certain amount of monitoring information is potentially
   sensitive.  For example, imagine that an entity maintains a traffic
   matrix, which shows the number of packets it sent to other entities.
   Such a traffic matrix can reveal communications patterns in an
   organization (e.g., a corporation or a government agency).
   Organizations concerned with privacy may wish to employ encryption to
   protect such information.  Access control ensures that only people
   entitled to request the data are able to retrieve it, but does not
   protect from eavesdroppers reading the messages.  Encryption protects
   against eavesdropping.

どんな管理体系でも暗号化をサポートしなければなりません。 ある量の監視情報が潜在的に特に、機密です。 例えば、実体がトラフィックマトリクスを維持すると想像してください。(マトリクスはそれが他の実体に発信したのをパケットの数に示します)。 そのようなトラフィックマトリクスは組織(例えば、会社か政府機関)でコミュニケーションパターンを明らかにすることができます。 プライバシーに関する組織は、そのような情報を保護するのに暗号化を使いたがっているかもしれません。 アクセスコントロールは、データを要求する権利を与えられた人々だけがそれを検索できるのを確実にしますが、メッセージを読んでいる立ち聞きする者から保護されません。 暗号化は盗聴から守ります。

   Note that encryption in HEMP does not protect against traffic
   analysis.  It is expected that HEMP interactions will have distinct
   signatures such that a party which can observe traffic patterns may
   guess at the sort of interactions being performed, even if the data
   being sent is encrypted.  Organizations concerned with security at
   this level should additionally consider link-level encryption.

HEMPの暗号化がトラヒック分析から守らないことに注意してください。 トラフィック・パターンを観測できるパーティーが実行される相互作用の種類を推測できるようにHEMP相互作用には異なった署名があると予想されます、送られるデータが暗号化されていても。 このレベルにおけるセキュリティに関する組織は、リンク・レベルが暗号化であるとさらに、考えるべきです。

Format of the Encryption Section

暗号化部の形式

   The encryption section contains any data required to decrypt the
   message.  The ASN.1 format of this section is shown in Figure 3.

暗号化部はメッセージを解読するのに必要であるデータを含みます。 このセクションのASN.1書式は図3に示されます。

          EncryptSection :: = IMPLICIT SEQUENCE {
                encryptType INTEGER,
                encryptData ANY
          }

EncryptSection:、: = 暗黙の系列少しも整数、encryptDataをencryptTypeします。

                Figure 3: ASN.1 Format of Encryption Section

図3: 暗号化部のASN.1形式

   If the section is omitted, then no decryption is required.  If the
   section is present, then the encryptType field contains a number
   defining the encryption method in use and encryptData contains
   whatever data, for example a key, which the receiver must have to
   decrypt the remainder of the message using the type of encryption
   specified.

セクションが省略されるなら、復号化は全く必要ではありません。 セクションが存在しているなら、encryptType分野は使用中の暗号化メソッドとencryptDataを定義するとデータ、例えば、キー(受信機には指定された暗号化のタイプを使用することでメッセージの残りを解読するために、なければならない)が何であっても含む数を含んでいます。

   Currently no encryption types are assigned.

現在の、暗号化タイプは全く選任されません。

   If the message has been encrypted, data is encrypted starting with
   the first octet after the encryption section.

メッセージを暗号化してあるなら、暗号化部の後に最初の八重奏から始まって、データは暗号化されています。

Partridge & Trewitt                                             [Page 4]

RFC 1022                     HEMS Protocol                  October 1987

ヤマウズラとTrewitt[4ページ]RFC1022はプロトコル1987年10月にへりを取ります。

THE REPLY ENCRYPTION SECTION

回答暗号化部

Need for Reply Encryption

回答暗号化の必要性

   The reasons for encrypting messages have already been discussed.

既にメッセージを暗号化する理由について議論しました。

   The reply encryption section provides the ability for management
   agents to request that responses be encrypted even though the
   requests are not encrypted, or that responses be encrypted using a
   different key or even a different scheme from that used to encrypt
   the request.  A good example is a public key encryption system, where
   the requesting application needs to pass its public key to the
   processing agent.

回答暗号化部が異なったキーを使用することで管理エージェントが、要求が暗号化されていませんが、応答が暗号化されるか、または応答が暗号化されるよう要求する能力を提供するか、またはそれからの異なった体系さえ以前はよく要求を暗号化していました。 好例は公開鍵暗号化システムです。(そこでは、要求アプリケーションが処理エージェントに公開鍵を渡す必要があります)。

Format of the Reply Encryption Section

回答暗号化部の形式

   The reply encryption section contains any data required to encrypt
   the reply message.  The ASN.1 format of this section is shown in
   Figure 4.

回答暗号化部は応答メッセージを暗号化するのに必要であるデータを含みます。 このセクションのASN.1書式は図4に示されます。

          ReplyEncryptSection :: = IMPLICIT SEQUENCE {
                replyEncryptType INTEGER,
                replyEncryptData ANY
          }

ReplyEncryptSection:、: = 暗黙の系列replyEncryptType整数、replyEncryptData、いずれも

          Figure 4: ASN.1 Format of Reply Encryption Section

図4: 回答暗号化部のASN.1形式

   If the section is omitted, then the reply should be encrypted in the
   manner specified by the encryption section.  If the section is
   present, then the replyEncryptType field contains a number defining
   the encryption method to use and replyEncryptData contains whatever
   data, for example a key, which the receiver must have to encrypt the
   reply message.

セクションが省略されるなら、回答は暗号化部によって指定された方法で暗号化されるべきです。 セクションが存在しているなら、replyEncryptType分野は使用する暗号化メソッドとreplyEncryptDataを定義するとデータ、例えば、キー(受信機には応答メッセージを暗号化するために、なければならない)が何であっても含む数を含んでいます。

   If the reply encryption section is present, then the reply message
   must contain an appropriate encryption section, which indicates the
   encryption method requested in the reply encryption section is in
   use.  The reply message should be encrypted starting with the first
   octet after the encryption section.

回答暗号化部が存在しているなら、応答メッセージは適切な暗号化部を含まなければなりません。(それは、回答暗号化部で要求された暗号化メソッドが使用中であることを示します)。 暗号化部の後に最初の八重奏から始まって、応答メッセージは暗号化されるべきです。

   If the reply encryption method requested is not supported by the
   entity, the entity may not send a reply.  It may, at the discretion
   of the implementor, send a protocol error message.  (See below for
   descriptions of protocol error messages.)

メソッドが要求した回答暗号化が実体で後押しされていないなら、実体は返信しないかもしれません。 作成者の裁量では、それはプロトコルエラーメッセージを送るかもしれません。 (プロトコルエラーメッセージの記述に関して以下を見てください。)

   Currently no encryption types are assigned.

現在の、暗号化タイプは全く選任されません。

Partridge & Trewitt                                             [Page 5]

RFC 1022                     HEMS Protocol                  October 1987

ヤマウズラとTrewitt[5ページ]RFC1022はプロトコル1987年10月にへりを取ります。

THE AUTHENTICATION SECTION

認証部

Need for Authentication

認証の必要性

   It is often useful for an application to be able to confirm either
   that a message is indeed from the entity it claims to have originated
   at, or that the sender of the message is accredited to make a
   monitoring request, or both.  An example may be useful here.
   Consider the situation in which an entity sends a event message to a
   monitoring center which indicates that a trunk link is unstable.
   Before the monitoring center personnel take actions to re-route
   traffic around the bad link (or makes a service call to get the link
   fixed), it would be nice to confirm that the event was indeed sent by
   the entity, and not by a prankster.  Authentication provides this
   facility by allowing entities to authenticate their event messages.

アプリケーションが、メッセージが本当に起因したそれが、主張する実体からあるか、またはメッセージ送信者がモニターしている要求、または両方を作るために信任されると確認できるのは、しばしば役に立ちます。 例はここで役に立つかもしれません。 実体がトランク・リンクが不安定であることを示すモニターしているセンターにイベントメッセージを送る状況を考えてください。 モニターしているセンター人員が悪いリンク(または、リンクが修理されるのをさせるという業務通話をする)で交通ルートを変更するために行動を取るとき、本当に、イベントがいたずら者で送るのではなく、実体によって送られたと確認してうれしいだろうです。 実体がそれらのイベントメッセージを認証するのを許容することによって、認証はこの施設を提供します。

   Another use of the authentication section is to provide access
   control.  Requests demand processing time from the entity.  In cases
   where the entity is a critical node, such as a gateway, we would like
   to be able to limit requests to authorized applications.  We can use
   the authentication section to provide access control, by only
   allowing specially authenticated applications to request processing
   time.

認証部の別の使用はアクセスコントロールを提供することです。 要求は実体からの処理時間を要求します。 実体がゲートウェイなどの重大なノードである場合では、要求を認可されたアプリケーションに制限したいと思います。 私たちは、特に、認証されたアプリケーションが処理時間を要求するのを許容するだけでアクセスコントロールを提供するのに認証部を使用できます。

   It should also be noted that, in certain cases, the encryption method
   may also implicitly authenticate a message.  In such situations, the
   authentication section should still be present, but uses a type code
   which indicates that authentication was provided by the encryption
   method.

また、また、暗号化メソッドが、ある場合でそれとなくメッセージを認証するかもしれないことに注意されるべきです。 そのような状況で、認証部は、まだ存在しているべきですが、認証が暗号化メソッドで提供されたのを示すタイプコードを使用します。

Format of the Authentication Section

認証部の形式

   The authentication section contains any data required to allow the
   receiver to authenticate the message.  The ASN.1 format of this
   section is shown in Figure 5.

認証部は受信機がメッセージを認証するのを許容するのに必要であるデータを含みます。 このセクションのASN.1書式は図5に示されます。

         AuthenticateSection :: = IMPLICIT SEQUENCE {
                authenticateType INTEGER,
                authenticateData ANY
               }

AuthenticateSection:、: = 暗黙の系列少しも整数、authenticateDataをauthenticateTypeします。

             Figure 5: ASN.1 Format of Authentication Section

図5: 認証部のASN.1形式

   If the section is omitted, then the message is not authenticated.  If
   the section is present, then the authenticateType defines the type of
   authentication used and the authenticateData contains the
   authenticating data.

セクションが省略されるなら、メッセージは認証されません。 セクションが存在しているなら、authenticateTypeは使用される認証のタイプを定義します、そして、authenticateDataは認証データを含んでいます。

Partridge & Trewitt                                             [Page 6]

RFC 1022                     HEMS Protocol                  October 1987

ヤマウズラとTrewitt[6ページ]RFC1022はプロトコル1987年10月にへりを取ります。

   This memo defines two types of authentication, a password scheme and
   authentication by encryption method.  For the password scheme, the
   AuthenticateSection has the form shown in Figure 6.

このメモは暗号化メソッドで2つのタイプの認証、パスワード体系、および認証を定義します。 パスワード体系のために、AuthenticateSectionには、図6で見せられたフォームがあります。

         AuthenticateSection :: = IMPLICIT SEQUENCE {
                authenticateType INTEGER { password(1) },
                authenticateData OCTETSTRING
          }

AuthenticateSection:、: = 暗黙の系列authenticateType INTEGERパスワード(1)、authenticateData OCTETSTRING

          Figure 6: ASN.1 Format of Password Authentication Section

図6: パスワード認証部のASN.1形式

   The authenticateType is 1, and the password is an octet string of any
   length.  The system is used to validate requests to an entity.  Upon
   receiving a request, an entity checks the password against an entity
   specific password which has been assigned to the entity.  If the
   passwords match, the request is accepted for processing.  The scheme
   is a slightly more powerful password scheme than that currently used
   for monitoring on the Internet.

authenticateTypeは1歳です、そして、パスワードはどんな長さの八重奏ストリングです。 システムは、要求を実体に有効にするのに使用されます。 要求を受け取ると、実体は実体に割り当てられた実体の特定のパスワードに対してパスワードをチェックします。 パスワードが合っているなら、処理のために要求を受け入れます。 体系は現在インターネットでのモニターに使用されているそれよりわずかに強力なパスワード体系です。

   For authentication by encryption, the AuthenticateSection has the
   format shown in Figure 7.

暗号化による認証のために、AuthenticateSectionには、図7に示された書式があります。

         AuthenticateSection :: = IMPLICIT SEQUENCE {
                authenticateType INTEGER { encryption(2) },
                authenticateData NULL
          }

AuthenticateSection:、: = 暗黙の系列authenticateType INTEGER暗号化(2)、authenticateData NULL

          Figure 7: ASN.1 Format of Encryption Authentication Section

図7: 暗号化認証部のASN.1形式

   This section simply indicates that authentication was implicit in the
   encryption method.  Recipients of such messages should confirm that
   the encryption method does indeed provide authentication.

このセクションは、認証が暗号化メソッドで暗黙であったのを単に示します。 そのようなメッセージの受取人は、本当に、暗号化メソッドが認証を提供すると確認するべきです。

   No other authentication types are currently defined.

他の認証タイプは全く現在、定義されません。

   If a message fails authentication, it should be discarded.  If the
   type of authentication used on the message is unknown or the section
   is omitted, the message may be discarded or processed at the
   discretion of the implementation.  It is recommended that requests
   with unknown authentication types be logged as potential intrusions,
   but not processed.

メッセージが認証に失敗するなら、それは捨てられるべきです。 メッセージで使用される認証のタイプが未知である、またはセクションが省略されるなら、メッセージは、実装の裁量で捨てられるか、または処理されるかもしれません。 未知の認証タイプとの要求が潜在的侵入として登録されますが、処理されないのは、お勧めです。

THE COMMON HEADER

一般的なヘッダー

   The common header contains generic information about the message such
   as the protocol version number and the type of request.  The ASN.1
   format of the common header is shown in Figure 8.

一般的なヘッダーはプロトコルバージョン番号や要求のタイプのメッセージのジェネリック情報を含んでいます。 一般的なヘッダーのASN.1書式は図8に示されます。

Partridge & Trewitt                                             [Page 7]

RFC 1022                     HEMS Protocol                  October 1987

ヤマウズラとTrewitt[7ページ]RFC1022はプロトコル1987年10月にへりを取ります。

           CommonHeader ::= IMPLICIT SEQUENCE {
               link IMPLICIT INTEGER,
               messageType IMPLICIT INTEGER,
               messageId IMPLICIT INTEGER,
               resourceId ANY
           }

CommonHeader:、:= 暗黙の系列少しもIMPLICIT INTEGER、messageType IMPLICIT INTEGER、messageId IMPLICIT INTEGER、resourceIdをリンクしてください。

                  Figure 8: ASN.1 Format of Common Header

エイト環: 一般的なヘッダーのASN.1形式

   The link indicates which version of HEMS is in use.

リンクは、HEMSのどのバージョンが使用中であるかを示します。

   The messageType is a value indicating whether the message is a
   request (0), reply (1), event (2), protocol error (3) or application
   error (4) message.

messageTypeはメッセージが要求(0)、回答(1)、イベント(2)、プロトコル誤り(3)またはアプリケーションエラー(4)メッセージであるかを示す値です。

   The messageId is a unique bit identifier, which is set in the request
   message, and echoed in the response.  It allows applications to match
   responses to their corresponding request.  Applications should choose
   messageIds such that a substantial period of time elapses before a
   messageId is re-used by a particular application (even across machine
   crashes).

messageIdはユニークな噛み付いている識別子です。(その識別子は、要求メッセージに設定されて、応答で反映されます)。 それで、アプリケーションは彼らの対応する要求への応答に合うことができます。 アプリケーションがmessageIdsを選ぶべきであるので、特定用途(マシンクラッシュの向こう側のさえ)でmessageIdが再使用される前に、かなりの期間が経過します。

   Event messages also use the messageId field to indicate the number of
   the current event message.  By comparing messageId fields from events
   lost, event values may be detected.  The event messageId should be
   reset to 0 on every reboot, and by convention, the event message with
   messageId of 0 should always be a "reboot" event.  (Facilities should
   be provided in the event message definition to allow entities which
   are capable of storing messageIds across reboots to send the highest
   messageId reached before the reboot.)

また、イベントメッセージは、現在のイベントメッセージの数を示すのにmessageId分野を使用します。 イベントからの分野がなくしたmessageIdを比較することによって、イベント値は検出されるかもしれません。 イベントmessageIdはあらゆるリブートのときに0にリセットされるべきです、そして、コンベンションで、いつも0のmessageIdがあるイベントメッセージは「リブート」イベントであるべきです。 (リブートの向こう側にmessageIdsを保存できる実体がリブートの前に達した中で最も高いmessageIdを送るのを許容するためにイベントメッセージ定義に施設を提供するべきです。)

   The resourceId is defined for ISO compatibility and corresponds to
   the resource ID used by the Common Management Information Protocol to
   identify the relevant ISO resource.

resourceIdはISOの互換性のために定義されて、IDが関連ISOリソースを特定するのに共通管理情報プロトコルで使用したリソースに対応しています。

DATA SECTION

資料課

   The data section contains the message specific data.  The format of
   the data section is shown in Figure 9.

資料課はメッセージの特定のデータを含みます。 資料課の書式は図9に示されます。

                   Data ::= ANY

データ:、:= 少しも

                  Figure 9: ASN.1 Format of Data Section

図9: 資料課のASN.1形式

   The contents of the data section is application specific and, with
   the exception of protocol error messages, is outside the scope of
   this memo.

プロトコルエラーメッセージを除いて、資料課のコンテンツは、アプリケーション特有であり、このメモの範囲の外にあります。

Partridge & Trewitt                                             [Page 8]

RFC 1022                     HEMS Protocol                  October 1987

ヤマウズラとTrewitt[8ページ]RFC1022はプロトコル1987年10月にへりを取ります。

TRANSPORT PROTOCOL

トランスポート・プロトコル

   There has been considerable debate about the proper transport
   protocol to use under HEMP.  Part of the problem is that HEMP is
   being used for two different types of interactions:  request-response
   exchanges and event messages.  Request-response interactions may
   involve arbitrary amounts of data being sent in both directions, and
   is believed to require a reliable transport mechanism.  Event
   messages are typically small and need not be reliably delivered.

HEMPの下で使用する適切なトランスポート・プロトコルのかなりの討論がありました。 問題の一部はHEMPが2つの異なったタイプの相互作用に使用されているということです: 要求応答交換とイベントメッセージ。 相互作用がかかわるかもしれない要求応答の任意の量のデータが、両方の方向に送られて、信頼できる移送機構を必要とすると信じられています。 イベントメッセージは、通常小さく、確かに提供される必要はありません。

   Public opinion seems to lean towards running HEMP over a transaction
   protocol (see RFC-955 for a general discussion).  Unfortunately, the
   community is still experimenting with transaction protocols, and many
   groups would like to be able to implement HEMP now.  Accordingly,
   this memo defines two transport protocols for use with HEMP.

世論はトランザクションプロトコルの上で実行しているHEMPに傾くように思えます(一般的な議論に関してRFC-955を見てください)。 残念ながら、共同体はまだトランザクションプロトコルを実験しています、そして、多くのグループが現在、HEMPを実装したがっています。 それに従って、このメモはHEMPとの使用のために2つのトランスポート・プロトコルを定義します。

   Groups interested in using an implementation of HEMP and the HEMS in
   the near future should use a combination of the Transmission Control
   Protocol (TCP) and the User Datagram Protocol (UDP) under HEMP.  TCP
   should be used for all request-response interactions and UDP should
   be used to send event messages.  Using UDP to support the request-
   response interactions is strongly discouraged.

近い将来HEMPとHEMSの実装を使用するのに関心があるグループはHEMPの下で通信制御プロトコル(TCP)とユーザー・データグラム・プロトコル(UDP)の組み合わせを使用するべきです。 TCPはすべての要求応答相互作用に使用されるべきです、そして、UDPは、イベントメッセージを送るのに使用されるべきです。 要求応答が相互作用であるとサポートするのにUDPを使用するのは強くお勧めできないです。

   More forward looking groups are encouraged to implement HEMP over a
   transaction protocol, in particular, experiments are planned with the
   Versatile Message Transaction Protocol (VMTP).

トランザクションプロトコルの上でHEMPを実装するグループが奨励されるより前進の見る、特に、実験はVersatile Message Transactionプロトコル(VMTP)で計画されています。

PROTOCOL ERROR MESSAGES

プロトコルエラーメッセージ

   Protocol error messages are so closely tied to the definition of HEMP
   that it made sense to define the contents of the data section for
   protocol error messages in this memo, even though the data section is
   generally considered application specific.

プロトコルエラーメッセージが密接にHEMPの定義に非常に結ばれるので、このメモによるプロトコルエラーメッセージのために資料課のコンテンツを定義する意味になりました、資料課はアプリケーション特有であると一般に考えられますが。

   The data section of all protocol error messages has the same format,
   which is shown in Figure 10.  This format has been chosen to agree
   with the error message format and ASN.1 type used for language
   processing errors in RFC-1024, and the error codes have been chosen
   such that they do not overlap.

すべてのプロトコルエラーメッセージの資料課には、図10に示されるのと同じ書式があります。 この形式がエラーメッセージ書式に同意するために選ばれて、ASN.1タイプが言語にRFC-1024で整理過程の誤差を使用して、エラーコードが選ばれたので、それらは重なりません。

           ProtocolError ::= [APPLICATION 0] implicit sequence {
               protoErrorCode INTEGER,
               protoErrorOffset INTEGER,
               protoErrorDescribed IA5String,
           }

ProtocolError:、:= [APPLICATION0] 暗黙の系列protoErrorCode整数、protoErrorOffset整数、protoErrorDescribed IA5String

            Figure 10: Data Section For Protocol Error Messages

図10: プロトコルエラーメッセージのための資料課

Partridge & Trewitt                                             [Page 9]

RFC 1022                     HEMS Protocol                  October 1987

ヤマウズラとTrewitt[9ページ]RFC1022はプロトコル1987年10月にへりを取ります。

   The protoErrorCode is a number which specifies the particular type of
   error encountered.  The defined codes are:

protoErrorCodeは遭遇する誤りの特定のタイプを指定する数です。 定義されたコードは以下の通りです。

           0 - reserved <not used>

0--予約された<は>を使用しませんでした。

           1 - ASN.1 format error.  Some error has been encountered
           in parsing the message.  Examples of such an error are an
           unknown type or a violation of the ASN.1 syntax.

1--ASN.1は誤りをフォーマットします。 何らかの誤りがメッセージを分析する際に遭遇しました。 そのような誤りに関する例は、ASN.1構文の未知のタイプか違反です。

           2 - Wrong HEMP version number.  The version number in
           the common header is invalid.  Note that this may
           be an indication of possible network intrusion and
           should be logged at sites concerned with security.

2--間違ったHEMPバージョン番号。 一般的なヘッダーのバージョン番号は無効です。 これが可能なネットワーク侵入のしるしであるかもしれなく、セキュリティに関するサイトに登録されるべきであることに注意してください。

           3 - Authentication error.  Authentication has failed.
           This error code is defined for completeness, but
           implementations are *strongly* discouraged from using
           it.  Returning authentication failure information may
           aid intruders in cracking the authentication system.
           It is recommended taht authentication errors be logged
           as possible security problems.

3--認証誤り。 認証は失敗しました。 このエラーコードは完全性のために定義されますが、実装は*強く定義されます。それを使用してがっかりする*。 戻っている認証失敗情報は認証システムを解く際に侵入者を支援するかもしれません。 それはお勧めのtaht認証誤りです。可能な警備上の問題として、登録されます。

           4 - ReplyEncryption type not supported.  The entity
           does not support the encryption method requested in the
           ReplyEncryption section.

4--サポートされないで、ReplyEncryptionはタイプします。 実体は、暗号化がReplyEncryption部で要求されたメソッドであるとサポートしません。

           5 - Decryption failed.  The entity could not decrypt the
           encrypted message.  Note that this means that the
           entity could not read the CommonHeader to find the
           messageId for the reply.  In this case, the messageId
           field should be set to 0.

5--復号化は失敗しました。 実体は暗号化メッセージを解読することができませんでした。 これが、実体が回答に関してmessageIdを見つけるためにCommonHeaderを読むことができなかったことを意味することに注意してください。 この場合、messageId分野は0に設定されるべきです。

           6 - Application Failed.  Some application failure made it
           impossible to process the message.

6--アプリケーションは失敗しました。 何らかのアプリケーション失敗で、メッセージを処理するのは不可能になりました。

   The protoErrorOffset is the number of the octet in which the error
   was discovered.  The first octet in the message is octet number 0.

protoErrorOffsetは誤りが発見された八重奏の数です。 メッセージにおける最初の八重奏は八重奏No.0です。

   The protoErrorDescribed field is a string which describes the
   particular error.  This description is expected to give a more
   detailed description of the particular error encountered.

protoErrorDescribed分野は特別の誤りについて説明するストリングです。 この記述が遭遇する特別の誤りの、より詳細な記述を与えると予想されます。

APPENDIX OF TYPES

タイプの付録

   This section lists all ASN.1 types defined in this document.

このセクションは本書では定義されたすべてのASN.1タイプを記載します。

Partridge & Trewitt                                            [Page 10]

RFC 1022                     HEMS Protocol                  October 1987

ヤマウズラとTrewitt[10ページ]RFC1022はプロトコル1987年10月にへりを取ります。

   HEMP Types

大麻タイプ

          HempMessage ::= [0] IMPLICIT SEQUENCE {
              [0] IMPLICIT EncryptSection OPTIONAL,
              [1] IMPLICIT ReplyEncryptSection OPTIONAL,
              [2] IMPLICIT AuthenticateSection OPTIONAL,
              [3] IMPLICIT CommonHeader,
              [4] IMPLICIT Data }

HempMessage:、:= [0] 暗黙の系列[4] [0] 内在しているEncryptSection任意の、そして、[1]の暗黙のReplyEncryptSection任意の、そして、[2]の内在しているAuthenticateSection任意の[3]内在しているCommonHeader、暗黙のデータ

       EncryptSection :: = IMPLICIT SEQUENCE {
           encryptType INTEGER,
           encryptData ANY
       }

EncryptSection:、: = 暗黙の系列少しも整数、encryptDataをencryptTypeします。

       ReplyEncryptSection :: = IMPLICIT SEQUENCE {
           replyEncryptType INTEGER,
           replyEncryptData ANY
       }

ReplyEncryptSection:、: = 暗黙の系列replyEncryptType整数、replyEncryptData、いずれも

       AuthenticateSection :: = IMPLICIT SEQUENCE {
           authenticateType INTEGER,
           authenticateData ANY
       }

AuthenticateSection:、: = 暗黙の系列少しも整数、authenticateDataをauthenticateTypeします。

       CommonHeader ::= IMPLICIT SEQUENCE {
           link IMPLICIT INTEGER,
           messageType IMPLICIT INTEGER {
               request(0), reply(1), event(2),
               protocol error (3), application error(4)
           }
           messageId IMPLICIT INTEGER,
           resourceId ANY
       }

CommonHeader:、:= 暗黙の系列リンクIMPLICIT INTEGER、messageType IMPLICIT INTEGERが(0)、回答(1)、イベント(2)、プロトコル誤り(3)、アプリケーションエラー(4)を要求する、messageId IMPLICIT INTEGER、resourceId、いずれも

       Data ::= ANY

データ:、:= 少しも

Protocol Error Types

プロトコル誤りタイプ

       ProtocolError ::= [APPLICATION 0] implicit sequence {
           protoErrorCode INTEGER,
           protoErrorOffset INTEGER,
           protoErrorDescribed OCTETSTRING
       }

ProtocolError:、:= [APPLICATION0] 暗黙の系列protoErrorCode整数、protoErrorOffset整数、protoErrorDescribed OCTETSTRING

Partridge & Trewitt                                            [Page 11]

RFC 1022                     HEMS Protocol                  October 1987

ヤマウズラとTrewitt[11ページ]RFC1022はプロトコル1987年10月にへりを取ります。

REFERENCES

参照

   ISO Standard ASN.1 (Abstract Syntax Notation 1).  It comes in two
   parts:
      International Standard 8824 -- Specification (meaning, notation)
      International Standard 8825 -- Encoding Rules (representation)

ISOの標準のASN.1(抽象構文記法1)。 それは2つの部品に入ります: 国際規格8824--仕様(意味、記法)国際規格8825--Rulesをコード化すること。(表現)

   The current VMTP specification is available from David Cheriton of
   Stanford University.

現在のVMTP仕様はスタンフォード大学のデヴィッドCheritonから利用可能です。

Partridge & Trewitt                                            [Page 12]

ヤマウズラとTrewitt[12ページ]