RFC1076 日本語訳
1076 HEMS monitoring and control language. G. Trewitt, C. Partridge. November 1988. (Format: TXT=98774 bytes) (Obsoletes RFC1023) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Trewitt
Request for Comments: 1076 Stanford University
Obsoletes: RFC 1023 C. Partridge
BBN/NNSC
November 1988
Trewittがコメントのために要求するワーキンググループG.をネットワークでつないでください: 1076 スタンフォード大学は以下を時代遅れにします。 RFC1023C.ヤマウズラBBN/NNSC1988年11月
HEMS Monitoring and Control Language
モニターと制御言語のへりを取ります。
TABLE OF CONTENTS
目次
1. Status of This Memo 1
Introduction 2
2. Overview and Scope 2
3. Overview of Query Processor Operation 4
4. Encoding of Queries and Responses 5
4.1 Notation Used in This Proposal 5
5. Data Organization 6
5.1 Example Data Tree 7
5.2 Arrays 8
6. Components of a Query 9
7. Reply to a Query 10
8. Query Language 12
8.1 Moving Around in the Data Tree 14
8.2 Retrieving Data 15
8.3 Data Attributes 16
8.4 Examining Memory 18
8.5 Control Operations: Modifying the Data Tree 19
8.6 Associative Data Access: Filters 21
8.7 Terminating a Query 26
9. Extending the Set of Values 27
10. Authorization 27
11. Errors 28
I. ASN.1 Descriptions of Query Language Components 29
I.1 Operation Codes 30
I.2 Error Returns 31
I.3 Filters 33
I.4 Attributes 34
I.5 VendorSpecific 36
II. Implementation Hints 36
III. Obtaining a Copy of the ASN.1 Specification 42
1. このメモ1序論2 2の状態。 概要と範囲2 3。 質問プロセッサ操作4 4の概要。 4.1記法がこの提案5 5に使用した質問と応答5はコード化されます。 データ編成6 5.1例のデータ木7の5.2の配列8 6。 質問9 7のコンポーネント。 質問10 8に答えてください。 照会言語、12、8.1が移行する、データ木14の8.2で検索する周りでは、メモリ18 8.5を調べるデータ15 8.3のデータ属性16 8.4が操作を制御します: データ木19を変更して、8.6の結合しやすいデータが以下にアクセスします。 質問26 9を終えるフィルタ21 8.7。 値27 10のセットを広げています。 承認27 11。 照会言語コンポーネント29I.1命令コード30I.2誤りの.1の記述が31I.3を返す誤り28I.ASNが33のI.4属性34I.5 VendorSpecificをフィルターにかける、36、II 実装ヒント36III。 ASN.1仕様42のコピーを入手します。
1. STATUS OF THIS MEMO
1. このメモの状態
This RFC specifies a query language for monitoring and control of network entities. This RFC supercedes RFC-1023, extending the query language and providing more discussion of the underlying issues.
このRFCはネットワーク実体のモニターとコントロールに照会言語を指定します。 このRFC supercedes RFC-1023、照会言語を広げて、および基本的さより多くの議論が発行する提供。
Trewitt & Partridge [Page 1] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[1ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
This language is a component of the High-Level Entity Monitoring System (HEMS) described in RFC-1021 and RFC-1022. Readers may wish to consult these RFCs when reading this memo. RFC-1024 contains detailed assignments of numbers and structures used in this system. Portions of RFC-1024 that define query language structures are superceded by definitions in this memo. This memo assumes a knowledge of the ISO data encoding standard, ASN.1.
この言語はRFC-1021とRFC-1022で説明されたHigh-レベルEntity Monitoring System(HEMS)の部品です。 このメモを読むとき、読者はこれらのRFCsに相談したがっているかもしれません。 RFC-1024はこのシステムで使用される数と構造の詳細な課題を含んでいます。 照会言語構造を定義するRFC-1024の一部がこのメモとの定義でスーパー割譲されます。 ASN.1、このメモはISO zデータの符号化に関する知識が標準であると仮定します。
Distribution of this memo is unlimited.
このメモの分配は無制限です。
INTRODUCTION
序論
This RFC specifies the design of a general-purpose, yet efficient, monitoring and control language for managing network entities. The data in the entity is modeled as a hierarchy and specific items are named by giving the path from the root of the tree. Most items are read-only, but some can be "set" in order to perform control operations. Both requests and responses are represented using the ISO ASN.1 data encoding rules.
このRFCは汎用の、そして、しかし、効率的なモニターと制御言語のデザインをネットワーク実体を管理するのに指定します。 階層構造と特定の項目が木の根から経路を与えることによって命名されるように実体におけるデータはモデル化されます。 ほとんどの項目が書き込み禁止ですが、制御機能を実行するためにいくつかを「設定できます」。 要求と応答の両方が、ISO ASN.1データ符号化規則を使用することで表されます。
2. OVERVIEW AND SCOPE
2. 概要AND範囲
The basic model of monitoring and control used in this memo is that a query is sent to a monitored entity and the entity sends back a response. The term query is used in the database sense -- it may request information, modify data, or both. We will use gateway- oriented examples, but it should be understood that this query- response mechanism is applicable to any IP entity.
このメモで使用されるモニターとコントロールの基本型はモニターされた実体に質問を送って、実体が応答を返送するということです。 用語質問はデータベース意味で使用されます--情報を要求するかもしれなくて、データ、または両方を変更してください。 私たちはゲートウェイ指向の例を使用するつもりですが、この質問反応機構がどんなIP実体にも適切であることが理解されるべきです。
In particular, there is no notion of an interactive "conversation" as in SMTP [RFC-821] or FTP [RFC-959]. A query is a complete request that stands on its own and elicits a complete response.
特に、対話的な「会話」の概念が全くSMTP[RFC-821]やFTP[RFC-959]のようにありません。 質問はそれ自身のところに立って、完全な応答を引き出す完全な要求です。
In order to design the query language, we had to define a model for the data to be retrieved by the queries, which required some understanding of and assumptions to be made about the data. We ended up with a fairly flexible data model, which places few limits on the type or size of the data.
私たちが照会言語を設計するためにデータが質問で検索されるモデルを定義しなければならなかった、そして、データに関してされる仮定。質問は何らかの理解を必要としました。 私たちはかなりフレキシブルなデータモデルで終わりました。(モデルはデータのタイプかサイズにわずかな限界を置きます)。
Wherever possible, we give motivations for the design decisions or assumptions that led to particular features or definitions. Some of the important global considerations and assumptions are:
どこでも、可能であるところに、私たちは特定の特徴か定義につながったデザイン決定か仮定に関する動機を与えます。 重要なグローバルな問題と仮定のいくつかは以下の通りです。
- The query processor should place as little computational
burden on the monitored entity as possible.
- 質問プロセッサはできるだけほとんどモニターされた実体でのコンピュータの負担をかけるはずがありません。
- It should not be necessary for a monitored entity to store
the complete query. Nothing in the query language should
- モニターされた実体が完全な質問を保存するのは必要であるべきではありません。 照会言語の無はそうするべきです。
Trewitt & Partridge [Page 2] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[2ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
preclude an implementation from being able to process the
query on the fly, producing portions of the response while
the query is still being read and parsed. There may be
other constraints that require large amounts of data to be
buffered, but the query language design must not be one.
急いで質問を処理できるので、実装を排除してください、質問がまだ読まれて、分析されている間、応答の部分を生産して。 多量のデータがバッファリングされるのを必要とする他の規制があるかもしれませんが、照会言語デザインは1であるはずがありません。
- It is assumed that there is some mechanism to transport a
sequence of octets to a query processor within the
monitored entity and that there is some mechanism to return
a sequence of octets to the entity making the query. In
HEMS, this is provided by HEMP and its underlying transport
layer. The query language design is independent of these
details, however, and could be grafted onto some other
protocol.
- モニターされた実体の中で八重奏の系列を質問プロセッサに輸送するために何らかのメカニズムがあって、質問をしながら八重奏の系列を実体に返すために何らかのメカニズムがあると思われます。 HEMSに、HEMPとその基本的なトランスポート層のそばでこれを提供します。 照会言語デザインは、しかしながら、これらの詳細から独立していて、ある他のプロトコルに接ぎ木できました。
- The data model must provide organization for the data, so
that it can be conveniently named.
- データモデルは、便利にそれを命名できるようにデータのための組織を提供しなければなりません。
- Much of the data to be monitored will be contained in
tables. Some tables may contain other tables. The query
language should be able to deal with such tables.
- モニターされるべきデータの多くがテーブルに含まれるでしょう。 いくつかのテーブルが他のテーブルを含むかもしれません。 照会言語はそのようなテーブルに対処できるべきです。
- We don't provide capabilities for data reduction in the
query language. We will provide for data selection, for
example, only retrieving certain table entries, but we will
not provide general facilities for processing data, such as
computing averages.
- 私たちは照会言語で能力をデータ整理に提供しません。 例えば、あるテーブル項目を検索するだけでありながら、データ選択に備えるつもりですが、私たちは一般的な施設を処理データに提供するつもりではありません、平均を計算するのなどように。
- Because one monitoring center may be querying many
(possibly hetrogenous) hosts, it must be possible to write
generic queries that can be sent to all hosts, and have the
query elicit as much information as is available from each
host. i.e., queries must not be aborted just because they
requested non-existent data.
- 1つのモニターしているセンターが多くの(ことによるとhetrogenous)ホストについて質問しているかもしれないので、すべてのホストに送ることができるジェネリック質問を書いて、質問に各ホストから利用可能であるのと同じくらい多くの情報を聞き出させるのは、可能であるに違いありません。ただ実在しないデータを要求したので、すなわち、質問は中止されてはいけません。
There were some assumptions that we specifically did not make:
私たちが明確に以下を作らなかったといういくつかの仮定がありました。
- It is up to the implementation to choose what degree of
concurrency will be allowed when processing queries. By
locking only portions of the database, it should be
possible to achieve good concurrency while still preventing
deadlock.
- 質問を処理するとき、どの度合いの並行性が許容されるかを選ぶのが実装まで達しています。 データベースの部分だけをロックすることによって、良い並行性を達成するのはまだ行き詰まりを防いでいる間、可能であるべきです。
- This specification makes no statement about the use of the
"definite" and "indefinite" length forms in ASN.1. There
is currently some debate about this usage in the ISO
community; implementors should note the recommendations in
the ASN.1 specification.
- この仕様はASN.1における「明確で」「無期」の長さのフォームの使用に関する声明を全く出しません。 現在、この用法の何らかの討論がISO共同体にあります。 作成者はASN.1仕様で推薦に注意するべきです。
Trewitt & Partridge [Page 3] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[3ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
Other RFCs associated with HEMS are:
HEMSに関連している他のRFCsは以下の通りです。
RFC-1021 Overview;
RFC-1022 Transport protocol and message encapsulation;
RFC-1024 Precise data definitions.
RFC-1021概要。 RFC-1022 Transportプロトコルとメッセージカプセル化。 RFC-1024 Preciseデータ定義。
The rest of this report is organized as follows:
このレポートの残りは以下の通り組織化されます:
Section 3 Gives a brief overview of the data model and the
operation of the query processor.
セクション3 データの簡潔な概要がモデル化するGivesと質問プロセッサの操作。
Section 4 Describes the encoding used for queries and
responses, and the notation used to represent them
in this report.
セクション4 コード化が質問、応答、および記法に使用したDescribesは以前はこのレポートによくそれらを表していました。
Section 5 Describes how the data is organized in the
monitored entity, and the view provided of it by
the query processor.
セクション5 データがモニターされた実体、および視点で組織化されるDescribesは質問プロセッサでそれを提供しました。
Section 6 Describes the basic data types that may be given
to the query processor as input.
セクション6 入力されるように質問プロセッサに与えられるかもしれない基礎データタイプのDescribes。
Section 7 Describes how a reply to a query is organized.
セクション7 質問に関する回答が組織化されているDescribes。
Section 8 Describes the operations available in the query
language.
8Describesを区分してください。照会言語で利用可能な操作。
Section 9 Describes how the set of data in the tree may be
extended.
セクション9 木のデータのセットが広げられるかもしれないDescribes。
Section 10 Describes how authorization issues affect the
execution of a query.
セクション10 承認問題が質問の実行に影響するDescribes。
Section 11 Describes how errors are reported, and their
effect on the processing of the query.
セクション11 誤りが報告されるDescribes、および質問の処理へのそれらの効果。
Appendix I Gives precise ASN.1 definitions of the data types
used by the query processor.
データ型のGivesの正確なASN.1定義が質問プロセッサで使用した付録I。
Appendix II Gives extensive implementation hints for the core
of the query processor.
付録のIIのGivesの大規模な実装は質問プロセッサのコアに暗示します。
3. OVERVIEW OF QUERY PROCESSOR OPERATION
3. 質問プロセッサ操作の概要
In this section, we give an overview of the operation of the query processor, to provide a framework for the later sections.
このセクションでは、私たちは、後のセクションにフレームワークを供給するために質問プロセッサの操作の概要を与えます。
The query language models the manageable data as a tree, with each
照会言語は木としてそれぞれで処理しやすいデータをモデル化します。
Trewitt & Partridge [Page 4] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[4ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
branch representing a different aspect of the entity, such as different layers of protocols. Subtrees are further divided to provide additional structure to the data. The leaves of the tree contain the actual data.
実体の異なった層のプロトコルなどの異なった局面を表しながら、分岐してください。 下位木は、追加構造をデータに提供するためにさらに分割されます。 木の葉は実際のデータを含みます。
Given this data representation, the task of the query processor is to traverse this tree and retrieve (or modify) data specified in a query. A query consists of instructions to move around in the tree and to retrieve (or modify) named data. The result of a query is an exact image of the parts of the tree that the query processor visited.
質問プロセッサに関するタスクがこのデータ表現を考えて、この木を横断することである、検索、(変更、)、データは質問で指定しました。 質問が木で移行して、検索する指示から成る、(変更、)、命名されたデータ。 質問の結果は質問プロセッサが訪問した木の部分の正確なイメージです。
The query processor is very simple -- it only understands eight commands, most of which share the same structure. It is helpful to think of the query processor as an automaton that walks around in the tree, directed by commands in the query. As it moves around, it copies the tree structure it traverses to the query result. Data that is requested by the query is copied into the result as well. Data that is changed by a query is copied into the result after the modification is made.
質問プロセッサは非常に簡単です--それは8つのコマンドしか理解していません。その大部分は同じ構造を共有します。 質問におけるコマンドで指示された木を歩き回るオートマトンとして質問プロセッサを考えるのは役立っています。 動き回るとき、それは質問結果に横断する木構造をコピーします。 質問で要求されているデータはまた、結果にコピーされます。 変更をした後に質問で変えられるデータを結果にコピーします。
4. ENCODING OF QUERIES AND RESPONSES
4. 質問と応答のコード化
Both queries and responses are encoded using the representation defined in ISO Standard ASN.1 (Abstract Syntax Notation 1). ASN.1 represents data as sequences of <tag,length,contents> triples that are encoded as a stream of octets. The data tuples may be recursively nested to represent structured data such as arrays or records. For a full description, see the ISO standards IS 8824 and IS 8825. See appendix for information about obtaining these documents.
質問と応答の両方が、ISO Standard ASN.1(抽象的なSyntax Notation1)で定義された表現を使用することでコード化されます。 ASN.1は<タグ、長さ、八重奏のストリームとしてコード化されるコンテンツ>三重の系列としてデータを表します。 データtuplesは、配列か記録などの構造化されたデータを表すために再帰的に入れ子にされるかもしれません。 余すところのない解説に関しては、ISO規格が8824であり、8825であることを確実にしてください。 これらのドキュメントを入手することの情報に関して付録を見てください。
4.1 Notation Used in This Proposal
4.1 この提案に使用される記法
The notation used in this memo is similar to that used in ASN.1, but less formal, smaller, and (hopefully) easier to read. We will refer to a <tag,length,contents> tuple as a "data object". In this RFC, we will not be concerned with the details of the object lengths. They exist in the actual ASN.1 encoding, but will be omitted in the examples here.
このメモで使用される記法は、ASN.1で使用されるそれと同様ですが、それほど正式でなくて、より小さい、そして、(希望をいだいて)より読みやすいです。 私たちは<タグ、長さ、コンテンツ>tupleを「データ・オブジェクト」と呼ぶつもりです。 このRFCでは、私たちはオブジェクトの長さの詳細に関係がないでしょう。 それらは、実際のASN.1コード化で存在していますが、ここで例で省略されるでしょう。
Data objects that have no internal ASN.1 structure such as integer or octet string are referred to as "simple types" or "simple objects". Objects which are constructed out of other ASN.1 data objects will be referred to as "composite types" or "composite objects".
整数か八重奏ストリングなどのどんな内部のASN.1構造も持っていないデータ・オブジェクトが「純真なタイプ」か「簡単なオブジェクト」と呼ばれます。 他のASN.1データ・オブジェクトから組み立てられるオブジェクトは「合成型」か「合成オブジェクト」と呼ばれるでしょう。
Trewitt & Partridge [Page 5] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[5ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
The notation
ID(value)
represents a simple object whose tag is "ID" with the given value. A
composite object is represented as
ID{ ... contents ... }
where contents is a sequence of data objects. The contents may
include both simple and structured types, so the structure is fully
recursive.
記法ID(値)はタグが与えられた値がある「ID」である簡単なオブジェクトを表します。 合成オブジェクトはID…コンテンツとして…コンテンツがデータ・オブジェクトの系列であるところに表されます。 コンテンツが簡単なものと同様に構造化されたタイプを含むかもしれないので、構造は完全に再帰的です。
The difference between simple and composite types is close to the
meaning of the "constructor" bit in ASN.1. For the uses here, the
distinction is made based upon the semantics of the data, not the
representation. Therefore, even though an OctetString can be
represented in ASN.1 using either constructed or non-constructed
forms, it is conceptually a simple type, with no internal structure,
and will always be written as
ID("some arbitrary string")
in this RFC.
ASN.1の「建設者」ビットの意味の近くに簡単で合成しているタイプの違いがあります。 ここの用途において、区別を表現ではなく、データの意味論に基づくようにします。 したがって、構成されたASN.1使用か非組み立てられたフォームでOctetStringを表すことができますが、それは、内部の構造がなければ概念的にa純真なタイプであり、ID(「何らかの任意のストリング」)としていつもこのRFCに書かれるでしょう。
There are situations where it is necessary to specify a type but give
no value, such as when referring to the name of the data. In this
situation, the same notation is used, but with the value omitted:
ID or ID() or ID{}
Such objects have zero length and no contents. The latter two forms
are used when a distinction is being made between simple and
composite data, but the difference is just notation -- the
representation is the same.
状況がタイプを指定するのが必要であるところにありますが、どんな値をお願いします、いつのように、データの名前を示しながら、そうしないか。 この状況で、同じ記法は、使用されますが、値で省略されます: ID、ID()またはID、そのようなオブジェクトには、ゼロ・レングスを持っていますが、どんなコンテンツもありません。 違いはただ記法です--簡単で合成しているデータの間で区別をしているとき、後者の2つのフォームが使用されていますが、表現は同じです。
ASN.1 distinguishes between four "classes" of tags: universal, application-specific, context-dependent, and reserved. HEMS and this query language use the first three. Universal tags are assigned in the ASN.1 standard and its addendums for common types, and are understood by any application using ASN.1. Application-specific tags are limited in scope to a particular application. These are used for "well-known" identifiers that must be recognizable in any context, such as derived data types. Finally, context-dependent tags are used for objects whose meaning is dependent upon where they are encountered. Most tags that identify data are context-dependent.
ASN.1は4「クラス」のタグを見分けます: 普遍的で、アプリケーション特有で、文脈依存して、予約されています。 HEMSとこの照会言語は最初の3を使用します。 普遍的なタグは、普通形のためにASN.1規格とその補遺で割り当てられて、ASN.1を使用することでどんなアプリケーションにも解釈されます。 アプリケーション特有のタグは範囲で特定用途に制限されます。 これらは導き出されるデータの形式などの「よく知られる」どんな文脈でも認識可能であるに違いない識別子に使用されます。 最終的に、文脈依存するタグは意味がそれらが遭遇するところに依存しているオブジェクトに使用されます。 データを特定するほとんどのタグが文脈依存しています。
5. DATA ORGANIZATION
5. データ編成
Data in a monitored entity is modeled as a hierarchy. Implementations are not required to organize the data internally as a hierarchy, but they must provide this view of the data through the query language. A hierarchy offers useful structure for the following operations:
モニターされた実体におけるデータは階層構造としてモデル化されます。 実装は階層構造として内部的に資料をまとめるのに必要ではありませんが、それらは照会言語を通してデータに関するこの意見を提供しなければなりません。 階層構造は以下の操作のために役に立つ構造を提供します:
Trewitt & Partridge [Page 6] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[6ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
Organization A hierarchy allows related data to be grouped
together in a natural way.
A階層構造が許す組織は、一緒に自然な方法で分類されるためにデータについて話しました。
Naming The name of a piece of data is just the path from the
root to the data of interest.
根から興味があるデータまで1つのデータの名前を挙げるのは、ただ経路です。
Mapping onto ASN.1
ASN.1 can easily represent a hierarchy by using a
"constructor" type as an envelope for an entire
subtree.
ASN.1をASN.1に写像すると、全体の下位木に封筒として「建設者」タイプを使用することによって、容易に階層構造を表すことができます。
Efficient Representation
Hierarchical structures are compact and can be
traversed quickly.
効率的なRepresentation Hierarchical構造は、コンパクトであり、すばやく横断できます。
Safe Locking If it is necessary to lock part of the hierarchy (for
example, when doing an update), locking an entire
subtree can be done efficiently and safely, with no
danger of deadlock.
安全なLocking Ifは階層構造を錠に離れさせて(例えばアップデートするとき)それが必要である、効率的に安全に全体の下位木はロックできます、行き詰まりという危険なしで。
We will use the term "data tree" to refer to this entire structure. Note that this internal model is completely independent of the external ASN.1 representation -- any other suitable representation would do. For the sake of efficiency, we do make a one-to-one mapping between ASN.1 tags and the (internal) names of the nodes. The same could be done for any other external representation.
私たちは、この全体の構造を示すのに「データ木」という用語を使用するつもりです。 この内部のモデルが外部のASN.1表現から完全に独立していることに注意してください--いかなる他の適当な表現も大丈夫です。 効率のために、私たちはノードのASN.1タグと(内部)の名前の間で1〜1つのマッピングを作ります。 いかなる他の外部の表現のためにも同じくらいができました。
Each node in the hierarchy must have names for its component parts. Although we would normally think of names as being ASCII strings such as "input errors", the actual name is just an ASN.1 tag. Such names are small integers (typically, less than 30) and so can easily be mapped by the monitored entity onto its internal representation.
階層構造の各ノードには、コンポーネントの部品への名前がなければなりません。 私たちは「入力誤り」などのASCIIストリングであるとして通常名前を考えるでしょうが、実際の名前はただASN.1タグです。 わずかな整数(通常30未満)であるのでモニターされた実体で容易にそのような名前を内部の表現に写像できます。
We use the term "dictionary" to mean an internal node in the hierarchy. Leaf nodes contain the actual data. A dictionary may contain both leaf nodes and other dictionaries.
私たちは、階層構造で内部のノードを意味するのに「辞書」という用語を使用します。 葉のノードは実際のデータを含みます。 辞書は葉のノードと他の辞書の両方を含むかもしれません。
5.1 Example Data Tree
5.1 例のデータ木
Here is a possible organization of the hierarchy in an entity that has several network interfaces and does IP routing. The exact organization of data in entities is specified in RFC-1024. This skeletal data tree will be used throughout this RFC in query examples.
ここに、いくつかのネットワーク・インターフェースを持って、IPルーティングをする実体における、階層構造の可能な組織があります。 実体における、データの正確な組織はRFC-1024で指定されます。 この骨格のデータ木は質問の例のこのRFC中で使用されるでしょう。
System {
name -- host name
clock-msec -- msec since boot
システム、名前--ホスト名時計msec--ブーツ以来のmsec
Trewitt & Partridge [Page 7] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[7ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
interfaces -- # of interfaces
memory
}
Interfaces { -- one per interface
InterfaceData{ address, mtu, netMask, ARP{...}, ... }
InterfaceData{ address, mtu, netMask, ARP{...}, ... }
:
}
IPRouting {
Entry{ ip-addr, interface, cost, ... }
Entry{ ip-addr, interface, cost, ... }
:
}
インタフェース--、インタフェースメモリの# インタフェース、--1インタフェースあたり1つに、InterfaceDataが、netMask、ARPが…、…であるとmtuに扱う InterfaceDataは、netMask、ARPが…、…であるとmtuに扱います。 : } IPRoutingエントリー、ip-addr、インタフェース、費用、… エントリー、ip-addr、インタフェース、費用、… : }
There are three top-level dictionaries in this hierarchy (System,
Interfaces, and IPRouting) and three other dictionary types
(InterfaceData, Entry, and ARP), each with multiple instances.
この階層構造(システム、Interfaces、およびIPRouting)には3冊のトップレベル辞書があります、そして、他の3辞書は(InterfaceData、Entry、およびARP)をタイプします、それぞれ複数のインスタンスで。
The "name" of the clock in this entity would be:
system{ clock-msec }
and the name of a routing table entry's IP address would be:
IPRouting{ Entry{ ip-addr } }.
この実体における時計の「名前」は以下の通りでしょう。 システム時計msecと経路指定テーブルエントリーのIPアドレスの名前は以下の通りでしょう。 IPRoutingエントリーip-addr。
More than one piece of data can be named by a single ASN.1 object.
The entire collection of system information is named by:
system
and the name of a routing table's IP address and cost would be:
IPRouting{ Entry{ ip-addr, cost } }.
独身のASN.1オブジェクトは1つ以上のデータを命名できます。 システム情報の全体の収集は以下によって命名されます。 経路指定テーブルのIPアドレスと費用のシステムと名前は以下の通りでしょう。 IPRouting、エントリー、ip-addr、費用
5.2 Arrays
5.2 配列
There is one sub-type of a dictionary that is used as the basis for tables of objects with identical types. We call these dictionaries arrays. In the example above, the dictionaries for interfaces, routing tables, and ARP tables are all arrays.
オブジェクトのテーブルの基礎として同じタイプで使用される辞書の1つのサブタイプがあります。 私たちは、これらを辞書配列と呼びます。 例では、インタフェースへの辞書、経路指定テーブル、およびARPテーブルはすべて上では、配列です。
In the examples above, the "ip-addr" and "cost" fields are named. In fact, these names refer to the field values for ALL of the routing table entries -- the name doesn't (and can't) specify which routing table entry is intended. This ambiguity is a problem wherever data is organized in tables. If there was a meaningful index for such tables (e.g., "routing table entry #1"), there would be no problem. Unfortunately, there usually isn't such an index. The solution to this problem requires that the data be accessed on the basis of some of its content. Filters, discussed in section 8.6, provide this mechanism.
例では、上では、"ip-addr"と「費用」分野が命名されます。 事実上、これらの名前はルーティングテーブル項目のすべてについて分野値について言及します--名前は指定しません。(and can't)は、どの経路指定テーブルエントリーが意図するかを指定します。 データがテーブルでどこで組織化されても、このあいまいさは問題です。 そのようなテーブルのための重要なインデックスがあった、(例えば、「経路指定テーブルエントリー#1インチ)、問題が全くないだろう、」 残念ながら、通常、そのようなインデックスはありません。 この問題への解決は、データが内容のいくつかに基づいてアクセスされるのを必要とします。 セクション8.6で議論したフィルタはこのメカニズムを提供します。
The primary difference between arrays and plain dictionaries is that
配列と明瞭な辞書のプライマリ違いはそれです。
Trewitt & Partridge [Page 8] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[8ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
arrays may contain only one type of item, while dictionaries, in general, will contain many different types of items. For example, the dictionary IPRouting (which is an array) will contain only items of type Entry.
配列は1つのタイプの項目だけを含むかもしれません、辞書が一般に多くの異なったタイプの項目を含むでしょうが。例えば、辞書IPRouting(配列である)はタイプEntryの唯一の項目を含むでしょう。
The fact that these objects are viewed externally as arrays or tables does not mean that they are represented in an implementation as linear lists of objects. Any collection of same-typed objects is viewed as an array, even though it might be stored internally in some other format, for example, as a hash table.
これらのオブジェクトが配列かテーブルとして外部的に見なされるという事実は、それらがオブジェクトの直線的なリストとして実装で表されることを意味しません。 同じようにタイプされたオブジェクトのどんな収集も配列として見なされます、例えば、それはハッシュ表としてある他の形式で内部的に保存されるかもしれませんが。
6. COMPONENTS OF A QUERY
6. 質問のコンポーネント
A HEMS query consists of a sequence of ASN.1 objects, interpreted by a simple stack-based interpreter. [Although we define the query language in terms of the operations of a stack machine, the language does not require an implementation to use a stack machine. This is a well-understood model, and is easy to implement.] One ASN.1 tag is reserved for operation codes; all other tags indicate data that will eventually be used by an operation. These objects are pushed onto the stack when received. Opcodes are immediately executed and may remove or add items to the stack. Because ASN.1 itself provides tags, very little needs to be done to the incoming ASN.1 objects to make them suitable for use by the query interpreter.
HEMS質問は純真なスタックベースのインタプリタによって解釈されたASN.1オブジェクトの系列から成ります。 [私たちはスタック・マシンの操作で照会言語を定義しますが、言語は、スタック・マシンを使用するために実装を必要としません。 これは、よく理解されているモデルであり、実装しやすいです。] 1ASN.1のタグは命令コードのために予約されます。 他のすべてのタグが結局操作で使用されるデータを示します。 受け取ると、これらのオブジェクトをスタックに押します。 Opcodesはスタックに商品をすぐに、実行されて、取り外すか、または加えるかもしれません。 ASN.1自身がタグを提供するので、わずか、が、それらを質問インタプリタによる使用に適するようにするように入って来るASN.1オブジェクトにする必要があります。
Each ASN.1 object in a query will fit into one of the following categories:
質問におけるそれぞれのASN.1オブジェクトは以下のカテゴリの1つに収まるでしょう:
Opcode An opcode tells the query interpreter to perform an action.
They are described in detail in section 8. Opcodes are
represented by an application-specific type whose value
determines the operation.
Opcode An opcodeは、動作を実行するように質問インタプリタに言います。 それらはセクション8で詳細に説明されます。 Opcodesは値が操作を決定するアプリケーション特定のタイプによって表されます。
Template These are objects that name one or more items in the data
tree. Named items may be either simple items (leaf nodes)
or entire dictionaries, in which case the entire subtree
"underneath" the dictionary is understood. Templates are
used to select specific data to be retrieved from the data
tree. A template may be either simple or structured,
depending upon what it is naming. A template only names
the data -- there are no values contained in it. Therefore
the leaf objects in a template will all have a length of
zero.
テンプレートTheseはデータ木の1つ以上の項目を命名するオブジェクトです。 項目と命名されているのは、簡単な項目(葉のノード)か全体の辞書、その場合、全体の下位木“underneath"のどちらかであるかもしれません。辞書は理解されています。 テンプレートは、特定のデータがデータ木から検索されるのを選択するのに使用されます。 それが命名していることによって、テンプレートは、簡単であるか構造化されているかもしれません。 テンプレートはデータを命名するだけです--それに含まれた値が全くありません。 したがって、テンプレートの葉のオブジェクトにはすべて、ゼロの長さがあるでしょう。
Examples of very simple templates are:
name() or System{}
Each of these is just one ASN.1 data object, with zero
length. The first names a single data item in the "System"
非常に簡単なテンプレートに関する例は以下の通りです。 ()かSystemを命名してください、それぞれのこれらはゼロ・レングスがあるちょうど1ASN.1のデータ・オブジェクトです。 名は「システム」のただ一つのデータ項目です。
Trewitt & Partridge [Page 9] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[9ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
dictionary (and must appear in that context), and the
second names the entire "System" dictionary. A more
complex template such as:
Interfaces{ InterfaceData{ address, netMask, ARP } }
names two simple data items and a dictionary, iterated over
all occurrences of "InterfaceData" within the Interfaces
array.
辞書(そして、その文脈に現れなければならない)、および辞書という2番目の名前全体「システム」。 以下などの、より複雑なテンプレート インタフェース、InterfaceData、アドレス、netMask、ARP、Interfaces配列の中で"InterfaceData"のすべての発生の上で繰り返された2つの簡単なデータ項目と辞書を命名します。
Path A path is a special case of a template that names only a
single node in the tree. It specifies a path down into the
dictionary tree and names exactly one node in the
dictionary tree.
経路A経路は木でただ一つのノードだけを命名するテンプレートの特別なケースです。 それは、辞書木に経路を指定して、辞書木でまさに1つのノードを命名します。
Value These are used to give data values when needed in a query,
for example, when changing a value in the data tree. A
value can be thought of as either a filled-in template or
as the ASN.1 representation some part of the data tree.
データ木で値を変えるとき、例えば、質問で必要であると、値のTheseは、データ値を与えるのに使用されます。 記入しているテンプレートとして、または、或るものが分けるデータ木のASN.1表現として値を考えることができます。
Filter A boolean expression that can be executed in the context of
a particular dictionary that is used to select or not
select items in the dictionary. The expressions consist of
the primitives "equal", "greater-or-equal",
"less-or-equal", and "present" possibly joined by "and",
"or", and "not". (See section 8.6.)
選択するのにおいて使用された特定の辞書の文脈で実行できないか、辞書で項目を選択できないA論理演算子式をフィルターにかけてください。 式は「同輩」という基関数から成りました、そして、「以下」、「よりすばらしいか等しく」て、「プレゼント」はことによると“and"、“or"、および“not"で接合しました。 (セクション8.6を見てください。)
Values, Paths, and Templates usually have names in the context- dependent class, except for a few special cases, which are in the application-specific class.
通常、値、Paths、およびTemplatesは文脈に依存するクラスで名前を持っています、いくつかの特別なケースを除いて。(アプリケーション特有のクラスにはケースがあります)。
7. REPLY TO A QUERY
7. 疑問に答えてください。
The data returned to the monitoring entity is a sequence of ASN.1 data items. Conceptually, the reply is a subset of the data tree, where the query selects which portions are to be included. This is exactly true for data retrieval requests, and essentially true for data modification requests -- the reply contains the data after it has been modified. The key point is that the data in a reply represents the state of the data tree immediately after the query was executed.
モニターしている実体に返されたデータはASN.1データ項目の系列です。概念的に、回答はデータ木の部分集合です。(そこでは、質問が、含まれるように部分がどれであるかを選択します)。 これは、まさにデータの検索要求には本当であって、データ変更要求には、本質的には本当です--それが変更された後に回答はデータを含んでいます。 要所は質問が実行された直後回答におけるデータがデータ木の状態を表すということです。
The sequence of the data is determined by the sequence of query language operations and the order of data items within Templates and Values given as input to these operations. If a query requests data from two of the top-level dictionaries in the data tree, by giving two templates such as:
データの系列はこれらの操作に入力されるように与えられているTemplatesとValuesの中で照会言語操作の系列とデータ項目の注文で決定します。 質問がデータの2冊のトップレベル辞書からデータを要求するなら、以下などの2個のテンプレートを与えることによって、木に登ってください。
System{ name, interfaces }
Interfaces{
システム、名前、インタフェースは連結します。
Trewitt & Partridge [Page 10] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[10ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
InterfaceData { address, netMask, mtu }
}
アドレス、netMaskがmtuするInterfaceData
then the response will consist of two ASN.1 data objects, as follows:
次に、応答は以下の通り2ASN.1データ・オブジェクトから成るでしょう:
System {
name("system name"),
interfaces(2)
}
Interfaces {
InterfaceData { address(36.8.0.1),
netMask(FFFF0000),
mtu(1500)
}
InterfaceData { address(10.1.0.1),
mtu(1008),
netMask(FF000000)
}
}
名義(「システム名」)のシステムインタフェース(2)は連結します。InterfaceData、アドレス、(36.8、.1(netMask(FFFF0000))が)mtuする.0(1500)、InterfaceData、アドレス、(10.1、.0、.1、)mtu(1008)、netMask(FF000000)
With few exceptions, each of the data items in the hierarchy is named in the context-specific ASN.1 type space. Because of this, the returned objects must be fully qualified. For example, the name of the entity must always be returned encapsulated inside an ASN.1 object for "System". If it were not, there would be no way to tell if the object that was returned was "name" inside the "System" dictionary or "address" inside the "interfaces" dictionary (assuming in this case that "name" and "address" were assigned the same integer as their ASN.1 tags).
ほとんど例外はなく、階層構造のそれぞれのデータ項目は文脈特有のASN.1タイプスペースで命名されます。 これのために、完全に返されたオブジェクトに資格がなければなりません。 例えば、いつもASN.1が「システム」のために反対させるカプセル化された内部を実体の名前に返さなければなりません。 それがないなら、「インタフェース」辞書の中に返されたオブジェクトが「システム」という辞書か「アドレス」で「名前」であったかどうか言う方法が全くないでしょうに(それらのASN.1タグと同じ整数はこの場合その「名前」を仮定して、「アドレス」に割り当てられました)。
Having fully-qualified data simplifies decoding of the data at the receiving end and allows the tags to be locally chosen. Definitions for tags within routing tables won't conflict with definitions for tags within interfaces. Therefore, the people doing the name assignments are less constrained. In addition, most of the identifiers will be fairly small integers, which is an advantage because ASN.1 can fit tag numbers up to 30 in a one-octet tag field. Larger numbers require a second octet.
データに完全に資格を与えたのは、犠牲者にデータの解読を簡素化して、タグが局所的に選ばれるのを許容します。 経路指定テーブルの中のタグのための定義はインタフェースの中のタグのための定義と衝突しないでしょう。 したがって、課題という名前をしている人々はそれほど抑制されません。 さらに、識別子の大部分はかなりわずかな整数になるでしょう(ASN.1が1八重奏のタグ・フィールドでタグNo.最大30に合うことができるので、利点です)。 より大きい数は2番目の八重奏を必要とします。
If data is requested that doesn't exist, either because the tag is not defined, or because an implementation doesn't provide that data (such as when the data is optional), the response will contain an ASN.1 object that is empty. The tag will be the same as in the query, and the object will have a length of zero.
タグが定義されないか、または実装がそのデータ(データが任意である時などの)を提供しないので存在しないデータが要求されると、応答は空のASN.1オブジェクトを含むでしょう。 タグは質問と同じになるでしょう、そして、オブジェクトには、ゼロの長さがあるでしょう。
The same response is given if the requested data does exist, but the invoker of the query does not have authorization to access it. See section 10 for more discussion of authorization mechanisms.
要求されたデータが存在しているなら、同じ応答を与えますが、質問の呼び出し元には、それにアクセスする承認がありません。 承認メカニズムの、より多くの議論に関してセクション10を見てください。
Trewitt & Partridge [Page 11] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[11ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
This allows completely generic queries to be composed without regard to whether the data is defined or implemented at all of the entities that will receive the query. All of the available data will be returned, without generating errors that might otherwise terminate the processing of the query.
これは、ジェネリック質問が関係なしでデータが定義されるかどうかに構成されるか、または質問を受ける実体について全く実装されるのを完全に許容します。 そうでなければ質問の処理を終えるかもしれない誤りを生成しないで、利用可能なデータのすべてを返すでしょう。
8. QUERY LANGUAGE
8. 照会言語
The query language is designed to be expressive enough to write useful queries with, yet simple enough to be easy to implement. The query processor should be as simple and fast as possible, in order to avoid placing a burden on the monitored entity, which may be a critical node such as a gateway.
照会言語は、道具に役に立つ質問を書くほど表現していますが、簡単であるほど簡単になるように設計されています。 質問プロセッサは、できるだけ簡単であって、速いはずです、ゲートウェイなどの重大なノードであるかもしれないモニターされた実体に負担をかけるのを避けるために。
Although queries are formed in a flexible way using what we term a "language", this is not a programming language. There are operations that operate on data, but most other features of programming languages are not present. In particular:
質問がことを使用することでフレキシブルな方法で形成される、私たち、「言語」という用語、これはプログラミング言語ではありません。 データを作動させる操作がありますが、プログラミング言語の他のほとんどの特徴は存在していません。 特に:
- Programs are not stored in the query processor.
- プログラムは質問プロセッサに保存されません。
- The only form of temporary storage is a stack, of limited
depth.
- 唯一のフォームに関する一時記憶領域は限られた深さのスタックです。
- There are no subroutines.
- サブルーチンが全くありません。
- There are no explicit control structures defined in the
language.
- 言語で定義されたどんな明白な制御構造もありません。
The central element of the language is the stack. It may contain templates, (and therefore paths), values, and filters taken from the query. In addition, it can contain dictionaries (and therefore arrays) from the data tree. At the beginning of a query, it contains one item, the root dictionary.
言語の主要な要素はスタックです。 それがテンプレートを含むかもしれない、(そして、したがって、経路)、値、および質問から取られたフィルタ。 さらに、それはデータ木からの辞書(そして、したがって、配列)を含むことができます。 質問の始めに、それは1つの項目、根の辞書を含みます。
The overall operation consists of reading ASN.1 objects from the input stream. All objects that aren't opcodes are pushed onto the stack as soon as they are read. Each opcode is executed immediately and may remove items from the stack, may generate ASN.1 objects and send them to the output stream, and may leave items on the stack. Because each input object is dealt with immediately, portions of the response may be generated while the query is still being received.
総合的な操作はオブジェクトを入力ストリームからASN.1に読み込むのから成ります。 それらが読まれるとすぐに、opcodesでないすべてのオブジェクトがスタックに押されます。 各opcodeはすぐに、実行されて、スタックから商品を取り外して、ASN.1にオブジェクトを生成して、それらを出力ストリームに送って、スタックの上に商品を残すかもしれません。 それぞれの入力オブジェクトがすぐに対処されているので、まだ質問を受けている間、応答の部分を生成するかもしれません。
In the descriptions below, operator names are in capital letters, preceded by the arguments used from the stack and followed by results left on the stack. For example:
以下での記述では、オペレータ名に大文字にはあって、スタックから使用される議論で先行されていて、スタックの上に残っている結果はあとに続いています。 例えば:
Trewitt & Partridge [Page 12] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[12ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
OP a b OP a t
means that the OP operator takes <a> and <b> off of the
stack and leaves <t> on the stack. Most of the operators
in the query language leave the first operand (<a> in this
example) on the stack for future use.
OP a b OP a tは、OPオペレータがスタックから<a>と<b>を連れて行って、スタックの上に<tを>に残すことを意味します。 照会言語のオペレータの大部分は今後の使用のためにスタックの上に(この例の<a>)に最初のオペランドを残します。
If both <a> and <b> were received as part of the query (as opposed to
being calculated by previous operations), then this part of the query
would have consisted of the sequence:
<a>
<b>
OP
So, like other stack-based languages, the arguments and operators
must be presented in postfix order, with an operator following its
operands.
両方であるなら、>と<b>が受け取られた<は質問(古い手術痕で計算されることと対照的に)を離れさせます、次に、質問のこの部分は系列から成ったでしょう: <は他のスタックベースの言語のようにポストフィックスオーダー(オペレータが続いているオペランド)に議論とオペレータを提示しなければならない><b>OP Soです。
Here is a summary of all of the operators defined in the query language. Most of the operators can take several different sets of operands and behave differently based upon the operand types. Details and examples are given later.
ここに、照会言語で定義されたオペレータのすべての概要があります。 オペレータの大部分は、異なった数セットのオペランドを取って、オペランドタイプに異なって基づいた状態で振る舞うことができます。 詳細と例は後で出されます。
BEGIN dict1 path BEGIN dict1 dict
array path filter BEGIN array dict
Move down in the data tree, establishing a context for
future operations.
BEGIN dict1経路BEGIN dict1 dict配列経路フィルタBEGIN配列dict Moveはデータ木にダウンします、今後の操作のための文脈を確立して。
END dict END --
Undo the most recent BEGIN.
END dict END--最新のBEGINを元に戻してください。
GET dict GET dict
dict template GET dict
array template filter GET array
Retrieve data from the data tree.
GET dict GET dict dictテンプレートGET dict配列テンプレートフィルタGETはデータ木からのRetrieveデータを整列させます。
GET-ATTRIBUTES
dict GET-ATTRIBUTES dict
dict template GET-ATTRIBUTES dict
array template filter GET-ATTRIBUTES array
Retrieve attribute information about data in the data tree.
GET-ATTRIBUTES dict GET-ATTRIBUTES dict dictテンプレートGET-ATTRIBUTES dict配列テンプレートフィルタGET-ATTRIBUTES配列Retrieveはデータ木でデータの情報を結果と考えます。
GET-RANGE dict path start length GET-RANGE dict
Retrieve a subrange of an OctetString. Used for reading
memory.
OctetStringのGET-RANGE dict経路スタート長さのGET-RANGE dict Retrieve aサブレンジ。 読書メモリにおいて、使用されています。
SET dict value SET dict
array value filter SET array
Change values in the data tree, possibly performing control
functions.
ことによるとコントロール機能を実行して、SET dict値のSET dict配列値のフィルタSETはデータ木でChange値を整列させます。
Trewitt & Partridge [Page 13] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[13ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
CREATE array value CREATE dict
Create new table entries.
CREATEは値のCREATE dict Create新しいテーブル項目を整列させます。
DELETE array filter DELETE array
Delete table entries.
DELETE配列フィルタDELETEはDeleteテーブル項目を整列させます。
These operators are defined so that it is impossible to generate an invalid query response. Since a response is supposed to be a snapshot of a portion (or portions) of the data tree, it is important that only data that is actually in the tree be put in the response. Two features of the language help guarantee this:
これらのオペレータが定義されるので、無効の質問が応答であると生成するのは不可能です。 応答がデータ木の一部(または、部分)のスナップであるべきであるので、実際に木にないデータしか応答に入れられるのは、重要です。 言語の2つの特徴が、これを保証するのを助けます:
- Data is put in the response directly from the tree (by
GET-*). Data does not go from the tree to the stack and
then into the response.
- データは直接木から応答に入れられます(GET-*で)。 データは木からスタックまでそして、応答の中に行きません。
- Dictionaries on the stack are all derived from the initial,
root dictionary. The operations that manipulate
dictionaries (BEGIN and END) also update the response with
the new location in the tree.
- 初期の根の辞書からスタックの上の辞書をすべて得ます。 また、新しい位置が木にある状態で、辞書(BEGINとEND)を操る操作は応答をアップデートします。
8.1 Moving Around in the Data Tree
8.1 データ木では動き回ること。
The initial point of reference in the data tree is the root. That is, operators name data starting at the root of the tree. It is useful to be able to move to some other dictionary in the tree and then name data from that point. The BEGIN operator moves down in the tree and END undoes the last unmatched BEGIN.
データ木での参照の初期のポイントは根です。 すなわち、オペレータは、木の根で始まるとデータを命名します。 木のある他の辞書と次に、そのポイントからの名前データに移行できるのは役に立ちます。 BEGINオペレータは木に下がります、そして、ENDは最後の優れたBEGINを元に戻します。
BEGIN is used for two purposes:
BEGINは2つの目的に使用されます:
- By moving to a dictionary closer to the data of interest,
the name of the data can be shorter than if the full name
(from the root) were given.
- 辞書に移行することによって、興味があるデータの、より近くでは、データの名前が完全であるなら名前(根からの)を与えたより短い場合があります。
- It is used to establish a context for filtered operations
to operate in. Filters are discussed in section 8.6.
- それは、フィルターにかけることの操作が作動する文脈を証明するのに使用されます。 セクション8.6でフィルタについて議論します。
BEGIN dict1 path BEGIN dict1 dict
Follow <path> down the dictionary starting from <dict1>.
Push the final dictionary named by <path> onto the stack.
<path> must name a dictionary (not a leaf node). At the
same time, produce the beginning octets of an ASN.1 object
corresponding to the new dictionary. It is up to the
implementation to choose between using the "indefinite
length" representation or the "definite length" form and
going back and filling the length in later.
<dict1>から始める辞書の下側へのBEGIN dict1経路BEGIN dict1 dict Follow<経路>。 <経路>によってスタックといわれた最終的な辞書を押してください。 <経路>は(葉のノードでない)と辞書を命名しなければなりません。 同時に、新しい辞書に対応するASN.1オブジェクトの始めの八重奏を起こしてください。 それは後で「無期長さ」表現か「明確な長さ」フォームを使用して、戻って、長さをいっぱいにするとき選ぶ実装まで達しています。
Trewitt & Partridge [Page 14] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[14ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
END dict END --
Pop <dict> off of the stack and terminate the open ASN.1
object(s) started by the matching BEGIN. Must be paired
with a BEGIN. If an END operation pops the root dictionary
off of the stack, the query is terminated.
END dict END--スタックから<dict>を飛び出させてください、そして、合っているBEGINによって始動された開いているASN.1オブジェクトを終えてください。 BEGINと対にしなければなりません。 END操作がスタックから根の辞書を飛び出させるなら、質問は終えられます。
<path> must point to a regular dictionary. If any part of it refers to a non-existent node, if it points to a leaf node, or if it refers to a node inside an array-type dictionary, then it is in error, and the query is terminated immediately.
<経路>は通常の辞書を示さなければなりません。 葉のノードを示すならそれのどんな部分も実在しないノードを示すか、または配列型辞書におけるノードを参照するなら、間違っています、そして、質問はすぐに、終えられます。
An additional form of BEGIN, which takes a filter argument, is described later.
BEGINの追加フォームは後で説明されます。(BEGINはフィルタ議論を取ります)。
8.2 Retrieving Data
8.2 データを検索すること。
The basic model that all of the data retrieval operations follow is that they take a template and fill in the leaf nodes of the template with the appropriate data values.
データの検索操作のすべてが従う基本型はテンプレートを取って、適切なデータ値でテンプレートの葉のノードに記入するということです。
GET dict template GET dict
Emit an ASN.1 object with the same "shape" as the given
template, except with values filled in for each node. The
first ASN.1 tag of <template> should refer to an object in
<dict>. If a dictionary tag is supplied anywhere in
<template>, the entire dictionary contents are emitted to
the response. Any items in the template that are not in
<dictionary> (or its components) are represented as objects
with a length of zero.
ASN.1が値を除いて、与えられたテンプレートとして同じくらいで「形成すること」を反対させるGET dictテンプレートGET dict Emitは各ノードの代理をしました。 .1がタグ付けをする<テンプレート>の最初のASNは<dict>のオブジェクトについて言及するはずです。 <テンプレート>で何処かに辞書タグを供給するなら、全体の辞書内容を応答に放ちます。 テンプレートの<辞書>(または、コンポーネント)にないどんな項目もオブジェクトとしてゼロの長さで表されます。
dict GET dict
If there is no template, get all of the items in the
dictionary. This is equivalent to providing a template
that lists all of the items in the dictionary.
そこのdict GET dict Ifはテンプレートでなく、辞書で項目のすべてを手に入れてください。 これは辞書に項目のすべてを記載するテンプレートを提供するのに同等です。
An additional form of GET, which takes a filter argument, is described later.
GETの追加フォームは後で説明されます。(GETはフィルタ議論を取ります)。
Here is an example of using the BEGIN operator to move down the data tree to the TCP dictionary and then using the GET operator to retrieve 5 data values from the TCP Stats dictionary:
ここに、データ木をTCP辞書に下げるのにBEGINオペレータを使用して、次に、TCP Stats辞書から5つのデータ値を検索するのにGETオペレータを使用する例があります:
IPTransport{ TCP } BEGIN
Stats{ octetsIn, octetsOut, inputPkts, outputPkts, badtag } GET
END
IPTransport TCP、octetsIn(octetsOut、inputPkts、outputPkts)がbadtagするBEGIN Stats、GET END
Trewitt & Partridge [Page 15] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[15ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
This might return:
これは戻るかもしれません:
IPTransport{ TCP
Stats{ octetsIn(13255), octetsOut(82323),
inputPkts(9213), outputPkts(12425), badtag() }
}
IPTransportTCP Stats、octetsIn(13255)、octetsOut(82323)、inputPkts(9213)、outputPkts(12425)、badtag()
"badtag" is a tag value that is undefined. No value is returned for it, indicating that there is no data value associated with it.
"badtag"は未定義のタグ値です。 それに関連しているどんなデータ値もないのを示して、それのために値を全く返しません。
8.3 Data Attributes
8.3 データ属性
Although ASN.1 "self-describes" the structure and syntax of the data, it gives no information about what the data means. For example, by looking at the raw data, it is possible to tell that an item is of type [context 5] and is 4 octets long. That does not tell how to interpret the data (is this an integer, an IP address, or a 4- character string?) or what the data means (IP address of what?). Even if the data were "tagged", in ASN.1 parlance, that would only give the base type (e.g., IP-address or counter) and not the meaning.
ASN.1はデータの構造と構文について「自己に説明します」が、それはデータが意味することの情報を全く教えません。 例えば、生データを見ることによって、項目がタイプ[文脈5]にはあって、長い間4つの八重奏であると言うのは可能です。 それは、どのように、データ(これは、整数、IPアドレス、または4文字列ですか?)を解釈するか、そして、またはデータが何を意味するか(何に関するIPアドレス?)を言いません。 データが「タグ付けされた」としても、ASN.1話法で、それは意味ではなく、ベースタイプ(例えば、IPアドレスかカウンタ)に与えるだけでしょうに。
Most of the time, this information will come from RFC-1024, which defines the ASN.1 tags and their precise meaning. When extensions have been made, it may not be possible to get documentation on the extensions. (Extensions are discussed in section 9.)
たいてい、この情報はRFC-1024から来るでしょう。(RFC-1024はASN.1タグとそれらの正確な意味を定義します)。 拡大をしたとき、拡大に関するドキュメンテーションを得るのは可能でないかもしれません。 (セクション9で拡大について議論します。)
The GET-ATTRIBUTES operator is similar to the GET operator, but returns a set of attributes describing the data rather than the data itself. This information is intended to be sufficient to let a human understand the meaning of the data and to let a sophisticated application treat the data appropriately. Such an application could use the attribute information to format the data on a display and decide whether it is appropriate to subtract one sample from another.
GET-ATTRIBUTESオペレータは、データ自体よりむしろGETオペレータと同様ですが、データについて説明する1セットの属性を返します。 人間にデータの意味を理解させて、高性能のアプリケーションにデータを適切に扱わせるようにこの情報が十分であることを意図します。 そのようなアプリケーションは、ディスプレイのときにデータをフォーマットして、別のものから1個のサンプルを引き算するのが適切であるかどうか決めるのに属性情報を使用するかもしれません。
Some of the attributes are textual descriptions to help a human understand the nature of the data and provide meaningful labels for it. Extensive descriptions of standard data are optional, since they are defined in RFC-1024. Complete descriptions of extensions must be available, even if they are documented in a user's manual. Network firefighters may not have a current manual handy when the network is broken.
属性のいくつかが人間がデータの本質を理解して、重要なラベルをそれに提供するのを助ける原文の記述です。 それらがRFC-1024で定義されるので、標準のデータの大規模な記述は任意です。 それらがユーザマニュアルに記録されても、拡大の完全な記述は利用可能であるに違いありません。 ネットワークが壊れているとき、ネットワーク消防士は現在のマニュアルを便利にしないかもしれません。
The format of the attributes is not as simple as the format of the data itself. It isn't possible to use the data's tag, since that would look exactly like the data itself. The format is:
属性の形式はデータ自体の形式ほど簡単ではありません。 それはちょうどデータ自体に似ているでしょう、したがって、データのタグを使用するのが可能ではありません。 形式は以下の通りです。
Attributes ::= [APPLICATION 3] IMPLICIT SEQUENCE {
tagASN1 [0] IMPLICIT INTEGER,
属性:、:= [アプリケーション3]暗黙の系列、tagASN1の[0]の暗黙の整数
Trewitt & Partridge [Page 16] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[16ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
valueFormat [1] IMPLICIT INTEGER,
longDesc [2] IMPLICIT IA5String OPTIONAL,
shortDesc [3] IMPLICIT IA5String OPTIONAL,
unitsDesc [4] IMPLICIT IA5String OPTIONAL,
precision [5] IMPLICIT INTEGER OPTIONAL,
properties [6] IMPLICIT BITSTRING OPTIONAL,
valueSet [7] IMPLICIT SET OF valueDesc OPTIONAL
}
valueFormat[1]IMPLICIT INTEGER、longDesc[2]IMPLICIT IA5String OPTIONAL、shortDesc[3]IMPLICIT IA5String OPTIONAL、unitsDesc[4]IMPLICIT IA5String OPTIONAL、精度[5]IMPLICIT INTEGER OPTIONAL、特性の[6]IMPLICIT BITSTRING OPTIONAL、valueSet[7]IMPLICIT SET OF valueDesc OPTIONAL
The GET-ATTRIBUTES operator is similar to the GET operator. The major difference is that dictionaries named in the template do not elicit data for the entire subtree.
GET-ATTRIBUTESオペレータはGETオペレータと同様です。 主要な違いはテンプレートで指定された辞書が全体の下位木のためのデータを引き出さないということです。
GET-ATTRIBUTES
dict template GET-ATTRIBUTES dict
Emit a single ASN.1 Attributes object for each of the
objects named in <template>. For each of these, the
tagASN1 field will be set to the corresponding tag from the
template. The rest of the fields are set as appropriate
for the data object. Any items in the template that are
not in <dictionary> (or its components) elicit an
Attributes object with a valueFormat of NULL, and no other
descriptive information.
GET-ATTRIBUTES dict Emitのa独身のASN.1Attributesがそれぞれのオブジェクトのために反対させるGET-ATTRIBUTES dictテンプレートは<でテンプレートを>と命名しました。 それぞれのこれらにおいて、tagASN1分野はテンプレートから対応するタグに設定されるでしょう。 分野の残りは適宜データ・オブジェクトに設定されます。 テンプレートの<辞書>(または、コンポーネント)にないどんな項目もNULLにもかかわらず、他の記述的な情報がないvalueFormatと共にAttributesオブジェクトを引き出します。
or
dict GET-ATTRIBUTES dict
If there is no template, emit Attribute objects for all of
the items in the dictionary. This is equivalent to
providing a template that lists all of the items in the
dictionary. This allows a complete list of a dictionary's
contents to be obtained.
または、そこのdict GET-ATTRIBUTES dict Ifはテンプレートでなく、辞書で項目のすべてのためのAttributeオブジェクトを放ってください。 これは辞書に項目のすべてを記載するテンプレートを提供するのに同等です。 これは、辞書のコンテンツに関する全リストが得られるのを許容します。
An additional form of GET-ATTRIBUTES, which takes a filter argument, is described later.
GET-ATTRIBUTESの追加フォームは後で説明されます。(GET-ATTRIBUTESはフィルタ議論を取ります)。
Here is an example of using the GET-ATTRIBUTES operator to request attributes for three objects in the System dictionary:
ここに、System辞書には3個のオブジェクトのために属性を要求するのにGET-ATTRIBUTESオペレータを使用する例があります:
System{ name, badtag, clock-msec } GET-ATTRIBUTES
システムの名義の、そして、badtagな時計msec GET-ATTRIBUTES
"badtag" is some unknown tag. The result might be:
"badtag"はある未知のタグです。 結果は以下の通りです。
System{
Attributes{
tagASN1(name),
valueFormat(IA5String),
longDesc("The primary hostname."),
システム、属性、tagASN1(名前)、valueFormat(IA5String)、longDesc(「プライマリホスト名」)
Trewitt & Partridge [Page 17] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[17ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
shortDesc("hostname")
},
Attributes{
tagASN1(badtag), valueFormat(NULL)
}
Attributes{
tagASN1(clock-msec),
valueFormat(Integer),
longDesc("milliseconds since boot"),
shortDesc("uptime"), unitsDesc("ms")
precision(4294967296),
properties(1)
}
shortDesc(「ホスト名」)、tagASN1(badtag)、valueFormat(ヌル)を結果と考えます。 属性tagASN1(時計msec)、valueFormat(整数)、longDesc(「ブーツ以来のミリセカンド」)、shortDesc(「動作可能時間」)、unitsDesc("ms")精度(4294967296)、特性(1)
Note that in this example "name" and "clock-msec" are integer values for the ASN.1 tags for the two data items. "badtag" is an integer value that has no corresponding name in this context.
「名前」と「時計msec」が2つのデータ項目のためのASN.1タグのためのこの例では、整数値であることに注意してください。"badtag"はどんな対応する名前もこのような関係においてはない整数値です。
There will always be exactly as many Attributes items in the result as there are objects in the template. Attributes objects for items which do not exist in the entity will have a valueFormat of NULL and none of the optional elements will appear.
結果におけるオブジェクトがテンプレートにあるのとちょうど同じくらい多くのAttributesの品目がいつもあるでしょう。 実体で存在しない項目のための属性オブジェクトにはNULLのvalueFormatがあるでしょう、そして、随意的な要素のいずれも現れないでしょう。
[ A much cleaner method would be to store the attributes as
sub-components of the data item of interest. For example,
requesting
System{ clock-msec } GET
would normally just get the value of the data. Asking for an
additional layer down the tree would now get its attributes:
System{ clock-msec{ shortDesc, unitsDesc } GET
would get the named attributes. (The attributes would be
named with application-specific tags.) Unfortunately, ASN.1
doesn't provide a notation to describe this type of
organization. So, we're stuck with the GET-ATTRIBUTES
operator. However, if a cleaner organization were possible,
this decision would have been made differently. ]
[ はるかに清潔なメソッドはデータ項目のサブコンポーネントとしての興味がある属性を保存するだろうことです。 例えば、System時計msec GETを要求すると、通常、データの値はただ得られるでしょう。 木の下側に追加層を求めると、属性は現在、得られるでしょう: システム、時計msec、shortDesc、GETが命名された属性を得るunitsDesc。 (属性はアプリケーション特有のタグで命名されるでしょう。) 残念ながら、ASN.1は、このタイプの組織について説明するために記法を提供しません。 それで、私たちはGET-ATTRIBUTESオペレータと共に刺されます。 しかしながら、クリーナー組織が可能であったなら、異なってこの決定をしたでしょう。 ]
8.4 Examining Memory
8.4 メモリを調べること。
Even with the ability to symbolically access all of this information in an entity, there will still be times when it is necessary to get to very low levels and examine memory, as in remote debugging operations. The building blocks outlined so far can easily be extended to allow memory to be examined.
それでも、実体で象徴的にこの情報のすべてにアクセスする能力があっても、非常に低いレベルを始めて、メモリを調べるのが必要である回があるでしょう、遠隔デバッギング操作のように。 メモリが調べられるのを許容するために容易に今までのところ概説されているブロックは広げることができます。
Memory is modeled as an ordinary object in the data tree, with an ASN.1 representation of OctetString. Because of the variety of addressing architectures in existence, the conversion from the
メモリは普通のオブジェクトとしてデータ木でOctetStringのASN.1表現でモデル化されます。 現存するアドレッシング体系、変換のバラエティー
Trewitt & Partridge [Page 18] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[18ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
internal memory model to OctetString is very machine-dependent. The only simple case is for byte-addressed machines with 8 bits per byte.
OctetStringの内部のメモリモデルはマシン非常に依存しています。 唯一の簡単なケースが1バイトあたり8ビットがあるバイトで扱われたマシンのためのものです。
Each address space in an entity is represented by one "memory" data item. In a one-address-space situation, this dictionary will probably be in "System" dictionary. If each process has its own address space, then one "memory" item might exist for each process. Again, this is very machine-dependent.
実体における各アドレス空間は1「メモリ」のデータ項目によって表されます。 1アドレス空間の状況に、この辞書がたぶん「システム」という辞書にあるでしょう。 各プロセスにそれ自身のアドレス空間があるなら、1つの「メモリ」項目が各プロセスのために存在するかもしれません。 一方、これはマシン非常に依存しています。
Although the GET-RANGE operator is provided primarily for the purpose of retrieving the contents of memory, it can be used on any object whose base type is OctetString.
主としてメモリのコンテンツを検索する目的にGET-RANGEオペレータを提供しますが、ベースタイプがOctetStringであるどんなオブジェクトの上にもそれを使用できます。
GET-RANGE dict path start length GET-RANGE dict
Get <length> elements of the OctetString, starting at
<start>. <start> and <length> are both ASN.1 INTEGER type.
<path>, starting from <dict>, must specify a node
representing memory, or some other OctetString.
<スタート>で始まるOctetStringのGET-RANGE dict経路スタート長さのGET-RANGE dict Get<長さの>要素。 <スタート>と<の長さの>はASN.1INTEGERがタイプする両方です。 <dict>から始めて、<経路>はメモリを表すノード、またはある他のOctetStringを指定しなければなりません。
The returned data may not be <length> octets long, since it may take more than one octet to represent one memory location.
長い間、返されたデータは<長さの>八重奏でないかもしれません、1つの記憶域を表すのに1つ以上の八重奏を要するかもしれないので。
Memory items in the data tree are special in that they will not
automatically be returned when the entire contents of a dictionary
are requested. e.g., If memory is part of the "System" dictionary,
then the query
System GET
will emit the entire contents of the System dictionary, but not the
memory item.
辞書の全体の中身が要求されているとき、それらが自動的に返されないので、データ木のメモリ項目は特別です。例えば、Ifメモリが「システム」という辞書の一部である、次に、質問System GETはメモリ項目ではなく、System辞書の全体のコンテンツを放つでしょう。
8.5 Control Operations: Modifying the Data Tree
8.5 操作を制御してください: データ木を変更します。
All of the operators defined so far only allow data in an entity to be retrieved. By replacing the template argument used in the GET operators with a value, data in the entity can be changed. Very few items in the data tree can be changed; those that can are noted in RFC-1024.
今までのところ定義されているオペレータは皆、実体におけるデータが検索されるのを許すだけです。 GETオペレータで値で使用されるテンプレート議論を置き換えることによって、実体におけるデータを変えることができます。 データ木のほんのわずかな項目を変えることができます。 そうすることができるものはRFC-1024に述べられます。
Values in the data tree can modified in order to change configuration parameters, patch routing tables, etc. Control functions, such as bringing an interface "down" or "up", do not usually map directly to changing a value. In such cases, an item in the tree can be defined to have arbitrary side-effects when a value is assigned to it. Control operations then consist of "setting" this item to an appropriate command code. Reading the value of such an item might return the current status. Again, details of such data tree items are given in RFC-1024.
設定パラメータ、パッチ経路指定テーブルなどを変えるように変更されて、データ木の値はそうすることができます。 通常、インタフェース“down"か“up"を持って来ることなどのコントロール機能は直接変化への値を写像しません。 そのような場合、値がそれに割り当てられるとき、任意の副作用を持つために木の項目を定義できます。 そして、制御機能はこの項目が適切なコマンドコードに「設定」であるのから成ります。 そのような項目の値を読むと、現在の状態は返されるかもしれません。 一方、そのようなデータ木の項目の詳細はRFC-1024で明らかにされます。
Trewitt & Partridge [Page 19] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[19ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
This "virtual command-and-status register" model is very powerful, and can be extended by an implementation to provide whatever controls are needed. It has the advantage that the control function is associated with the controlled object in the data tree. In addition, no additional language features are required to support control functions, and the same operations used to locate data for retrieval are used to describe what is being controlled.
この「仮想のコマンドとステータスレジスタ」モデルは非常に強力であり、実装によって広げられて、必要であるどんなコントロールも提供できます。 それはデータ木に制御対象に関連していた状態でコントロール機能がそうである利点を持っています。 さらに、どんな追加言語機能もコントロールが機能であるとサポートするのに必要ではありません、そして、検索のためのデータの場所を見つけるのに使用される同じ操作は、制御されていることについて説明するのに使用されます。
For all of the control and data modification operations, the fill- in-the-blank model used for data retrieval is extended: the response to an operation is the affected part of the data tree, after the operation has been executed. Therefore, for normal execution, SET and CREATE will return the object given as an argument, and DELETE will return nothing (because the affected portion was deleted).
コントロールとデータ変更操作のすべてに関しては、空白のデータの検索に使用される中詰めモデルは拡張されています: 操作が実行された後に操作への応答はデータ木の患部です。 したがって、通常の実行のために、SETとCREATEは議論として与えられたオブジェクトを返すでしょう、そして、DELETEは何も返さないでしょう(影響を受ける部分が削除されたので)。
SET dict value SET dict
Set the value(s) of data in the entity to the value(s)
given in <value>. The result will be the value of the data
after the SET. Attempting to set a non-settable item will
not produce an error, but will yield a result in the reply
different from what was sent.
SET dictはSET dict Setを評価します。<で与えられた値への実体における、データの値は>を評価します。 結果はSETの後のデータの値になるでしょう。 非「舗装用敷石-可能」の品目を設定するのを試みるのが、誤りを起こしませんが、送られたものと異なった回答における結果をもたらすでしょう。
CREATE array value CREATE dict
Insert a new entry into <array>. Depending upon the
context, there may be severe restrictions about what
constitutes a valid <value>. The result will be the actual
item added to the <array>. Note that only one item can be
added per CREATE operation.
CREATEは値のCREATE dict Insertのa新しいエントリーを<配列>に整列させます。 文脈によって、有効な<値の>を構成することに関する厳しい制限があるかもしれません。 結果は<配列>に加えられた実際の項目になるでしょう。 CREATE操作単位で1つの項目しか加えることができないことに注意してください。
DELETE array filter DELETE array
Delete the entry(s) in <array> that match <filter>.
Filters are described later in this document. Normally, no
data items will be produced in the response, but if any of
the items that matched the filter could not be deleted,
they will be returned in the response.
DELETE配列フィルタDELETEはDeleteを整列させます。<配列>の<フィルタ>に合っているエントリー。 フィルタは後で本書では説明されます。 通常、応答ではデータ項目を全く生産しないでしょうが、フィルタに合っていた項目のどれかを削除できないと、応答でそれらを返すでしょう。
An additional form of SET, which takes a filter argument, is described later.
SETの追加フォームは後で説明されます。(SETはフィルタ議論を取ります)。
Here is an example of attempting to use SET to change the number of
interfaces in an entity:
System{ interfaces(5) } SET
Since that is not a settable parameter, the result would be:
System{ interfaces(2) }
giving the old value.
ここに、実体における、インタフェースの数を変えるのにSETを使用するのを試みる例があります: 「舗装用敷石-可能」パラメタ、結果でないシステムインタフェース(5)SET Sinceは以下の通りでしょう。 システムは、古い値を与えながら、(2)を連結します。
Here is an example of how CREATE would be used to add a routing table entry for net for 128.89.0.0.
ここに、CREATEが128.89のためにネットのためのルーティングテーブル項目を加えるのにどう使用されるだろうかに関する例があります。.0 .0。
Trewitt & Partridge [Page 20] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[20ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
IPRouting BEGIN -- get dictionary
Entries{ DestAddr(128.89.0.0), ... } -- entry to insert
CREATE
END -- finished with dict
IPRouting BEGIN--辞書Entriesを手に入れてください、DestAddr、(128.89 .0 .0、)… -- CREATE END--dictを使い終わるのを挿入するエントリー
The result would be what was added:
IPRouting{ Entries{ DestAddr(128.89.0.0), ... } }
結果は加えられたものでしょう: IPRoutingエントリー、DestAddr、(128.89 .0 .0、)…
The results in the response of these operators is consistent of the global model of the response: it contains a subset of the data in the tree immediately after the query is executed.
これらのオペレータの応答における結果は応答のグローバルなモデルで一貫しています: 質問が実行される直後それは木にデータの部分集合を含んでいます。
Note that CREATE and DELETE only operate on arrays, and then only on arrays that are specifically intended for it. For example, it is quite reasonable to add and remove entries from routing tables or ARP tables, both of which are arrays. However, it doesn't make sense to add or remove entries in the "Interfaces" dictionary, since the contents of that array is dictated by the hardware. For each array in the data tree, RFC-1024 indicates whether CREATE and DELETE are valid.
CREATEとDELETEが配列、およびそして、それのために明確に意図する配列だけを作動させるだけであることに注意してください。 例えば、経路指定テーブルかARPテーブルからエントリーを加えて、取り除くのはかなり妥当です。その両方が配列です。 しかしながら、「インタフェース」辞書におけるエントリーを加えるか、または取り除く意味になりません、その配列のコンテンツがハードウェアによって書き取られるので。 データ木の各配列のために、RFC-1024は、CREATEとDELETEが有効であるかどうかを示します。
CREATE and DELETE are always invalid in non-array contexts. If DELETE were allowed on monitored data, then the deleted data would become unmonitorable to the entire world. Conversely, if it were possible to CREATE arbitrary dictionary entries, there would be no way to give such entries any meaning. Even with the data in place, there is nothing that would couple the data to the operation of the monitored entity. [Creation and deletion would also add considerable complication to an implementation, because without them, all of the data structures that represent the data tree are essentially static, with the exception of dynamic tables such as the ones mentioned, which already have mechanisms in place for adding and removing entries.]
CREATEとDELETEは非配列文脈でいつも無効です。 DELETEがモニターされたデータに許容されているなら、削除されたデータは全世界に非モニター可能になるでしょうに。 逆に、それがCREATEの任意の辞書エントリーに可能であるなら、どんな意味もそのようなエントリーに与える方法が全くないでしょうに。 データさえ適所にあった状態で、何もモニターされた実体の操作とデータを結合するものがありません。 [また、作成と削除はかなりの複雑さを実装に加えるでしょう、データ木を表すデータ構造のすべてがそれらなしで本質的には静的であるので、エントリーを加えて、取り除くために適所に既にメカニズムを持っている言及されたものなどのダイナミックなテーブルを除いて。]
8.6 Associative Data Access: Filters
8.6 結合しやすいデータ・アクセス: フィルタ
One problem that has not been dealt with was alluded to earlier: When dealing with array data, how do you specify one or more entries based upon some value in the array entries? Consider the situation where there are several interfaces. The data might be organized as:
対処されていない1つの問題が、より早く暗示されました: 配列データに対処するとき、あなたはどのように配列エントリーにおける何らかの値に基づく1つ以上のエントリーを指定しますか? いくつかのインタフェースがある状況を考えてください。 データは以下として組織化されるかもしれません。
Interfaces { -- one per interface
InterfaceData { address, mtu, netMask, ARP{...}, ... }
InterfaceData { address, mtu, netMask, ARP{...}, ... }
:
}
インタフェース1インタフェースあたり1つに、InterfaceDataは、netMask、ARPが…、…であるとmtuに扱います。--、InterfaceDataは、netMask、ARPが…、…であるとmtuに扱います:
If you only want information about one interface (perhaps because
1時頃に情報が欲しいだけであるなら連結してください、(恐らく。
Trewitt & Partridge [Page 21] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[21ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
there is an enormous amount of data about each), then you have to
have some way to name it. One possibility would be to just number
the interfaces and refer to the desired interface as
InterfaceData(3)
for the third one.
およそそれぞれデータの巨額がある、)、そして、あなたには、それを命名する何らかの方法がなければなりません。 1つの可能性が、まさしく数へのインタフェースであり、3番目のもののためのInterfaceData(3)に必要なインタフェースについて言及するでしょう。
But this is not sufficient, because interface numbers may change over time, perhaps from one reboot to the next. It is even worse when dealing with arrays with many elements, such as routing tables, TCP connections, etc. Large, changing arrays are probably the more common case, in fact. Because of the lack of utility of indexing in this context, there is no general mechanism provided in the language for indexing.
しかし、インタフェース番号が時間がたつにつれて恐らく1つのリブートから次に変化するかもしれないので、これは十分ではありません。 経路指定テーブル、TCP接続などの多くの要素がある配列に対処するとき、それはさらに悪いです。 大きくて、変化している配列はたぶん事実上より一般的なケースです。 このような関係においては索引をつけるユーティリティの不足のために、言語で索引をつけるのに提供された一般的機構が全くありません。
A better scheme is to select objects based upon some value contained in them, such as the IP address. The query language uses filters to select specific table entries that an operator will operate on. The operators BEGIN, GET, GET-ATTRIBUTES, SET, and DELETE can take a filter argument that restricts their operation to entries that match the filter.
それらに含まれたIPアドレスなどの何らかの値に基づく選択オブジェクトには、より良い体系があります。 照会言語は、オペレータが働かせる特定のテーブル項目を選択するのにフィルタを使用します。 オペレータのBEGIN、GET、GET-ATTRIBUTES、SET、およびDELETEは彼らの操作をフィルタに合っているエントリーに制限するフィルタ議論を取ることができます。
A filter is a boolean expression that is executed for each element in an array. If an array entry "matches" the filter (i.e., if the filter produces a "true" result), then it is used by the operation. A filter expression is very restricted: it can only compare data contained in the array element and the comparisons are only against constants. Comparisons may be connected by AND, OR and NOT operators.
フィルタは配列で各要素のために実行される論理演算子式です。 配列エントリーがフィルタに「合わせている」なら(すなわち、フィルタが「本当」の結果を生むなら)、それは操作で使用されます。 フィルタ式は非常に制限されています: それは配列の要素に含まれたデータを比較できるだけです、そして、比較は定数だけに反対しています。 比較はオペレータではなく、AND、ORによって接続されるかもしれません。
The ASN.1 definition of a filter is:
フィルタのASN.1定義は以下の通りです。
Filter ::= [APPLICATION 2] CHOICE {
present [0] DataPath,
equal [1] DataValue,
greaterOrEqual [2] DataValue,
lessOrEqual [3] DataValue,
and [4] SEQUENCE OF Filter,
or [5] SEQUENCE OF Filter,
not [6] Filter
}
以下をフィルターにかけてください:= [アプリケーション2] 選択[6]ではなく、等しい[1]DataValue、greaterOrEqual[2]DataValue、lessOrEqual[3]DataValue、および[4]のDataPath、SEQUENCE OF Filter、または[5]SEQUENCE OF Filterがフィルターにかけるプレゼント[0]
DataPath ::= ANY -- Path with no value
DataPath:、:= いずれ--値のない経路
DataValue ::= ANY -- Single data value
DataValue:、:= いずれ--ただ一つのデータ値
This definition is similar to the filters used in the ISO monitoring protocol (CMIP) and was derived from that specification.
この定義はISOのモニターしているプロトコル(CMIP)とそれから派生している仕様で使用されるフィルタと同様です。
Trewitt & Partridge [Page 22] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[22ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
"DataPath" is the name of a single data item; "DataValue" is the value of a single data item. The three comparisons are all of the form "data OP constant", where "data" is the value from the tree, "constant" is the value from the filter expression, and "OP" is one of equal, greater-than-or-equal, or less-than-or-equal. The last operation, "present", tests to see if the named item exists in the data tree. By its nature, it requires no value, so only a path needs to be given.
"DataPath"はただ一つのデータ項目の名前です。 "DataValue"はただ一つのデータ項目の値です。 「データ」が木からの値であり、「定数」がフィルタ式からの値であり、「オプアート」が1であるところで3つの比較が同輩フォーム「データOP定数」のすべて、すばらしさ、同輩、以下か等しいです。 最後の「現在」の操作は、命名された項目がデータ木に存在するかどうか確認するためにテストされます。 本質的に、値を全く必要としないので、経路だけが、与えられている必要があります。
Here is an example of a filter that matches an Interface whose IP
address is 10.1.0.1:
Filter{ equal{ address(10.0.0.51) } }
Note that the name of the data to be compared is relative to the
"InterfaceData" dictionary.
IPアドレスが10.1であるInterfaceに合っているフィルタに関する例がここの、.0である、.1: フィルタ、等しさ、アドレス、(10.0、.0、.51)、比較されるべきデータの名前が"InterfaceData"という辞書に比例していることに注意してください。
Each operator, when given a filter argument, takes an array (dictionary containing only one type of item) as its first argument. In the current example, this would be "Interfaces". The items in it are all of type "InterfaceData". This tag is referred to as the "iteration tag".
フィルタ議論を与えるとき、各オペレータは最初の議論として配列(1つのタイプの項目だけを含む辞書)をみなします。 現在の例では、これは「インタフェース」でしょう。 それの項目はタイプ"InterfaceData"のすべてです。 このタグは「繰り返しタグ」と呼ばれます。
Before a filtered operation is used, BEGIN must be used to put the array (dictionary) on top of the stack, to establish it as the context that the filter iterates over. The general operation of a filtered operation is then:
次に、フィルタが. フィルターにかけることの操作の一般的な操作の上で繰り返す背景はスタックの上に配列(辞書)を置いて、それを設立するのにおいて使用されていますが、フィルターにかけることの操作が使用されている前にBEGINは以下の通りであるに違いありません。
1. Iterate over the items in the array.
1. 項目の上で配列で繰り返します。
2. For each element in the array, execute the filter.
2. 配列における各要素には、フィルタを実行してください。
3. If the filter succeeds, do the requested operation
(GET/SET/etc.) on the matched element, using the
template/value/path as input to the operation. At this
point, the execution of the operation is the same as in
the non-filtered case.
3. フィルタが成功するなら、取り組んでいる要素で要求された操作(GET/SET/など)をしてください、操作に入力されるようにテンプレート/値/経路を使用して。 ここに、操作の実行は非フィルターにかけることのケースと同じです。
This is a model of operation; actual implementations may take advantage of whatever lookup techniques are available for the particular table (array) involved.
これは操作のモデルです。 実際の実装はどんな(配列)がかかわった特定のテーブルに利用可能なルックアップのテクニックも利用するかもしれません。
Therefore, there are three inputs to a filtered operation:
したがって、フィルターにかけることの操作への3つの入力があります:
1. The "current dictionary" on the stack. This is the
array-type dictionary to be searched, set by an earlier
BEGIN.
1. スタックの「現在の辞書。」 以前のBEGINによって設定されて、これは捜されるべき配列型辞書です。
2. A filter, to test each item in the array. Each path or
value mentioned in the filter must be named in the context
2. 配列におけるテスト各個条へのフィルタ。 文脈でフィルタで言及された各経路か値を命名しなければなりません。
Trewitt & Partridge [Page 23] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[23ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
of an item in the array, as if it was the current
dictionary. For example, in the case where a filtered
operation iterates over the set of "InterfaceData" items
in the "Interfaces" array, each value or path in the
filter should name an item in the "InterfaceData"
dictionary, such as "address".
まるでそれが配列における項目現在の辞書であるかのように。 例えばケース、フィルターにかけることの操作が"InterfaceData"のセットについて上フィルタの各「インタフェース」配列、値または経路の項目が"InterfaceData"という辞書(「アドレス」としてのそのようなもの)で項目を命名するはずである繰り返すどこ
3. A template, path, or value associated with the operation
to be performed. The leading ASN.1 tag in this must match
the iteration tag. In the current example where the
filter is searching the "Interfaces" dictionary, the first
tag in the template/tag/value must be "InterfaceData".
3. 実行されるために操作に関連づけられたテンプレート、経路、または値。 これの主なASN.1タグは繰り返しタグに合わなければなりません。 フィルタが「インタフェース」辞書を捜している現在の例では、テンプレート/タグ/値における最初のタグは"InterfaceData"であるに違いありません。
The operators which take filters as arguments are:
議論としてフィルタをみなすオペレータは以下の通りです。
BEGIN array path filter BEGIN array dict
Find a dictionary in <array> that matches <filter>. Use
that as the starting point for <path> and push the
dictionary corresponding to <path> onto the stack. If more
than one dictionary matches <filter>, then any of the
matches may be used. This specification does not state how
the choice is made. At least one dictionary must match; it
is an error if there are no matches. (Perhaps it should be
an error for there to be multiple matches; actual
experience is needed to decide.)
BEGINは<フィルタ>に合っている<配列>の経路フィルタBEGIN配列dict Find a辞書を整列させます。 <経路>に出発点としてそれを使用してください、そして、スタックに辞書を押して、<経路>に対応してください。 1冊以上の辞書が<フィルタ>に合っているなら、マッチのいずれも使用されるかもしれません。 この仕様はどう選択をするかを述べません。 少なくとも1冊の辞書が合わなければなりません。 マッチが全くなければ、それは誤りです。 (複数がそこで合っているので、恐らく、それは誤りであるべきです; 実地経験が決めるのに必要です。)
GET array template filter GET array
For each item in <array> that matches <filter>, fill in the
template with values from the data tree and emit the
result. The first tag of <template> must be equal to the
iteration tag. Selected parts of matched items are emitted
based upon <template>, just as in a non-filtered GET
operation.
GETは<フィルタ>に合っている<配列>でテンプレートフィルタGET配列For各個条を整列させて、値でデータ木からテンプレートに記入して、結果を放ちます。 <テンプレート>の最初のタグは繰り返しタグと等しいに違いありません。 取り組んでいる項目の選択された部分はちょうど非フィルターにかけることのGET操作のように<テンプレート>に基づいた状態で放たれています。
GET-ATTRIBUTES
array template filter GET-ATTRIBUTES array
Same as GET, except emit attributes rather than data
values.
GET-ATTRIBUTES配列テンプレートフィルタGET-ATTRIBUTESはGETとしてSameを整列させて、データ値よりむしろ属性を放ちます。
SET array value filter SET array
Same as GET, except set the values in <value> rather than
retrieving values. Several values in the data tree will be
changed if the filter matches more than one item in the
array.
SET配列値のフィルタSETがGETとしてSameを整列させて、セットを除いて、<の値は値を検索するよりむしろ>を評価します。 フィルタが配列で1つ以上の項目に合っていると、データ木のいくつかの値を変えるでしょう。
DELETE array filter DELETE array
Delete the entry(s) in <array> that match <filter>.
DELETE配列フィルタDELETEはDeleteを整列させます。<配列>の<フィルタ>に合っているエントリー。
Trewitt & Partridge [Page 24] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[24ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
Notes about filter execution:
フィルタ実行に関する注:
- Expressions are executed by inorder tree traversal.
- 式は「不-オーダー」木の縦断で実行されます。
- Since the filter operations are all GETs and comparisons,
there are no side-effects to filter execution, so an
implementation is free to execute only as much of the
filter as required to produce a result (e.g., don't execute
the rest of an AND if the first comparison turns out to be
false).
- フィルタ操作がすべてのGETsと比較であるので、実行をフィルターにかけるために副作用が全くないので、実装は結果を生むために必要に応じて自由にフィルタの同じくらい多くしか実行できません(例えば、最初の比較が誤っていると判明するなら、ANDの残りを実行しないでください)。
- It is not an error for a filter to test a data item that
isn't in the data tree. In this situation, the comparison
just fails (is false). This means that filters don't need
to test for the existence of optional data before
attempting to compare it.
- データ木にないのは、フィルタがデータ項目をテストする誤りではありません。 この状況で、比較はただ失敗します(誤っています)。 これは、フィルタがそれを比較するのを試みる前に任意のデータの存在がないかどうかテストする必要はないことを意味します。
Here is an example of how filtering would be used to obtain the input and output packet counts for the interface with IP address 10.0.0.51.
フィルタリングがIPアドレスとのインタフェースのための入出力パケットカウントを得るのにどう使用されるだろうかに関する例がここにある、10.0、.0、.51
Interfaces BEGIN -- dictionary
InterfaceData{ pktsIn, pktsOut } -- template
Filter{ equal{ address(10.0.0.51) } }
GET
END -- finished with dict
BEGINを連結します--、辞書InterfaceData、pktsIn、pktsOut--、テンプレートFilter、等しさ、アドレス、(10.0、.0、.51)、GET END--dictを使い終わります。
The returned value would be something like:
戻り値は以下に似ているでしょう。
Interfaces{ -- BEGIN
InterfaceData{ pktsIn(1345134), pktsOut(1023729) }
-- GET
} -- END
インタフェース、--、InterfaceDataが始まってくださいpktsIn(1345134)、pktsOut(1023729)--得てください、--終わりになってください
The annotations indicate which part of the response is generated by the different operators in the query.
注釈は、応答のどの部分が質問で異なったオペレータによって生成されるかを示します。
Here is an example of accessing a table contained within some other table. Suppose we want to get at the ARP table for the interface with IP address 36.8.0.1 and retrieve the entire ARP entry for the host with IP address 36.8.0.23. In order to retrieve a single entry in the ARP table (using a filtered GET), a BEGIN must be used to get down to the ARP table. Since the ARP table is contained within the Interfaces dictionary (an array), a filtered BEGIN must be used.
ここに、ある他のテーブルの中に含まれたテーブルにアクセスする例があります。 IPアドレスとのインタフェースへのARPテーブルに届きたいと思うと仮定してください、36.8、.0、.1、IPアドレスでホストにとっての全体のARPエントリーを検索してください、36.8、.0、.23 ARPテーブルで単一のエントリーを検索して(フィルターにかけることのGETを使用して)、ARPテーブルを仕留めるのにBEGINを使用しなければなりません。 ARPテーブルがInterfaces辞書(配列)の中に含まれているので、フィルターにかけることのBEGINを使用しなければなりません。
Interfaces BEGIN -- dictionary
InterfaceData{ ARP } -- path
Filter{ equal{ address(36.8.0.1) } } -- filter
BEGIN -- filtered BEGIN
BEGIN--辞書InterfaceData ARP--経路Filterを連結する、等しさ、アドレス、(36.8、.0、.1)、BEGINをフィルターにかけます(フィルタBEGIN)。
Trewitt & Partridge [Page 25] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[25ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
-- Now in ARP table for 38.0.0.1; get entry for 38.8.0.23.
addrMap -- whole entry
Filter{ equal{ ipAddr(36.8.0.23) } } -- filter
GET -- filtered GET
END
END
-- 中では、現在、ARPが38.0のために.0を見送る、.1。 38.8.0.23addrMapには、入国許可を得てください--、全体のエントリーFilter、等しさ、ipAddr、(36.8、.0、.23)、GET END ENDをフィルターにかけます(フィルタGET)。
The result would be:
結果は以下の通りでしょう。
Interfaces{ -- first BEGIN
InterfaceData{ ARP{ -- second BEGIN
addrMap{ ipAddr(36.8.0.23), physAddr(..) } -- from GET
} } -- first END
} -- second END
インタフェース、--、最初に、BEGIN InterfaceData、ARP、--、BEGIN addrMapを後援してくださいipAddr、(36.8 .0 .23、)physAddr、()、GET、--、最初に、END、--ENDを後援してください
Note which parts of the output are generated by different parts of the query.
出力のどの部分が質問の異なった部品によって生成されるかに注意してください。
Here is an example of how the SET operator would be used to shut down the interface with ip-address 10.0.0.51 by changing its status to "down".
SETオペレータがip-アドレスとのインタフェースを止めるのにどう使用されるだろうかに関する例がここにある、10.0、.0、.51、状態を“down"に変えることによって。
Interfaces BEGIN -- get dictionary
Interface{ Status(down) } -- value to set
Filter{ equal{ IP-addr(10.0.0.51) } }
SET
END
BEGIN--辞書Interface状態(down)--Filterをセットに評価させるのを連結する、等しさ、IP-addr、(10.0、.0、.51)、SET END
If the SET is successful, the result would be:
SETがうまくいくなら、結果は以下の通りでしょう。
Interfaces{ -- BEGIN
Interface{ Status(down) } -- from SET
} -- END
インタフェース、--、セットからインタフェース状態(down)が始まってください--終わりになってください
8.7 Terminating a Query
8.7 質問を終えること。
A query is implicitly terminated when there are no more ASN.1 objects to be processed by the interpreter. For a perfectly-formed query, the interpreter would be back in the state it was when it started: the stack would have only the root dictionary on it, and all of the ASN.1 objects in the result would be terminated.
インタプリタによって処理されるようにそれ以上のASN.1オブジェクトが全くないとき、質問はそれとなく終えられます。 完全に形成された質問のために、インタプリタによる状態では、それが始まった時であるということでしょう: スタックには、それの根の辞書しかないでしょう、そして、結果におけるASN.1オブジェクトのすべてが終えられるでしょう。
If there are still "open" ASN.1 objects in the result (caused by leaving ENDs off of the query), then these are closed, as if a sufficient number of ENDs were provided. This condition would be indicated by the existence of dictionaries other than the root dictionary on the stack.
「開いている」ASN.1オブジェクトがまだ結果(質問からENDsを外すことによって、引き起こされる)にあれば、これらは閉じられます、まるでENDsの十分な数を提供するかのように。 この状態はスタックの上の根の辞書以外の辞書の存在によって示されるでしょう。
Trewitt & Partridge [Page 26] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[26ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
If an extra END is received that would pop the root dictionary off of the stack, the query is terminated immediately. No error is generated.
付加的なENDが受け取られているなら、それはスタックから根の辞書を飛び出させて、質問はすぐに、終えられます。 どんな誤りも発生していません。
9. EXTENDING THE SET OF VALUES
9. 値のセットを広げています。
There are two ways to extend the set of values understood by the query language. The first is to register the data and its meaning and get an ASN.1 tag assigned for it. This is the preferred method because it makes that data specification available for everyone to use.
照会言語に解釈された値のセットを広げる2つの方法があります。 1番目は、データとその意味を登録して、それのためにASN.1タグを割り当てさせることです。 そのデータ指定を皆が使用するように利用可能にするので、これは適した方法です。
The second method is to use the VendorSpecific application type to "wrap" the vendor-specific data. Wherever an implementation defines data that is not in RFC-1024, the "VendorSpecific" tag should be used to label a dictionary containing the vendor-specific data. For example, if a vendor had some data associated with interfaces that was too strange to get standard numbers assigned for, they could, instead represent the data like this:
2番目のメソッドはベンダー特有のデータを「包装すること」にVendorSpecificアプリケーションタイプを使用することです。 実装がどこでRFC-1024にないデータを定義しても、"VendorSpecific"タグは、ベンダー特有のデータを含む辞書を分類するのに使用されるべきです。 例えば、ベンダーがまた、そうであったインタフェースに関連しているいくつかのデータを標準の数を割り当てさせるために奇妙にするなら、することができる、代わりにこのようにデータを表してください:
interfaces {
interface {
in-pkts, out-pkts, ...
VendorSpecific { ephemeris, declination }
}
}
インタフェースインタフェース、pktsの、そして、出ているpktsの…VendorSpecific、位置推算歴、傾き
In this case, ephemeris and declination correspond to two context- dependent tags assigned by the vendor for their non-standard data.
この場合、位置推算歴と傾きは依存するタグがそれらの標準的でないデータのためにベンダーで割り当てた2文脈に対応します。
If the vendor-specific method is chosen, the private data MUST have descriptions available through the GET-ATTRIBUTES operator. Even with this descriptive ability, the preferred method is to get standard numbers assigned if possible.
ベンダー特有のメソッドが選ばれているなら、個人的なデータには、GET-ATTRIBUTESオペレータを通して利用可能な記述がなければなりません。 適した方法はできれば、標準の数を割り当てさせるこの描写的である能力があっても、ことです。
10. AUTHORIZATION
10. 承認
This specification does not state what type of authorization system is used, if any. Different systems may have needs for different mechanisms (authorization levels, capability sets, etc.), and some systems may not care about authorization at all. The only effect that an authorization system has on a query is to restrict what data items in the tree may be retrieved or modified.
この仕様は、どんなタイプの承認システムがもしあれば使用されるかを述べません。 異系統には、異なったメカニズム(承認レベル、能力セットなど)の必要性があるかもしれません、そして、いくつかのシステムは全く承認を心配しないかもしれません。 承認システムが質問のときに持っている唯一の効果は検索されるか変更されていて、木の項目がそうするかもしれないすべてのデータを制限することです。
Therefore, there are no explicit query language features that deal with protection. Instead, protection mechanisms are implicit and may make some of the data invisible (for GET) or non-writable (for SET):
したがって、保護に対処するどんな明白な照会言語機能もありません。 代わりに、保護メカニズムは、暗黙であり、いくつかのデータが目に見えなさ(GETのための)か非書き込み可能に(SETのための)なるかもしれません:
Trewitt & Partridge [Page 27] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[27ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
- Each query runs with some level of authorization or set of
capabilities, determined by its environment (HEMS and the
HEMP header).
- 各質問は、環境(HEMSとHEMPヘッダー)で決定する能力を、何らかのレベルの承認で実行したか、またはセットしました。
- Associated with each data item in the data tree is some
sort of test to determine if a query's authorization should
grant it access to the item.
- データ木の各データ項目に関連づけられているのは、クエリーの承認が項目へのアクセスをそれに承諾するべきであるかどうか決定するある種のテストです。
Authorization tests are only applied to query language operations that retrieve information (GET, GET-ATTRIBUTES, and GET-RANGE) or modify it (SET, CREATE, DELETE). An authorization system must not affect the operation of BEGIN and END. In particular, the authorization must not hide entire dictionaries, because that would make a BEGIN on such a dictionary fail, terminating the entire query.
承認テストは情報(GET、GET-ATTRIBUTES、およびGET-RANGE)を検索するか、またはそれ(SET、CREATE、DELETE)を変更する照会言語操作に適用されるだけです。 承認システムはBEGINとENDの操作に影響してはいけません。 特に、承認は全体の辞書を隠してはいけません、それが辞書が失敗するそのようなものでBEGINを作るでしょう、したがって、全体の質問を終えて。
11. ERRORS
11. 誤り
If some particular information is requested but is not available, it will be returned as "no-value" by giving the ASN.1 length as 0.
何らかの特定の情報が要求されていますが、利用可能でないなら、「値がありません」として0としてASN.1の長さを与えることによって、それを返すでしょう。
When there is any other kind of error, such as having improper arguments on the top of the stack or trying to execute BEGIN when the path doesn't refer to a dictionary, an ERROR object is emitted.
いかなる他の種類の誤りもあるとき、経路が辞書を引かないときスタックの先端に不適当な議論を持っていようとするか、またはBEGINを実行しようとするのなどようなERRORオブジェクトは放たれています。
The contents of this object identify the exact nature of the error:
このオブジェクトの内容は誤りの正確な本質を特定します:
Error ::= [APPLICATION 0] IMPLICIT SEQUENCE {
errorCode INTEGER,
errorInstance INTEGER,
errorOffset INTEGER
errorDescription IA5String,
errorOp INTEGER,
}
誤り:、:= [アプリケーション0] 暗黙の系列errorCode整数、errorInstance整数、errorOffset整数errorDescription IA5String、errorOp整数
errorCode identifies what the error was, and errorInstance is an implementation-dependent code that gives a more precise indication of where the error occured. errorOffset is the location within the query where the error occurred. If an operation was being executed, errorOp contains its operation code, otherwise zero. errorDescription is a text string that can be printed that gives some description of the error. It will at least describe the errorCode, but may also give details implied by errorInstance. Detailed definitions of all of the fields are given in appendix I.2.
errorCodeは、誤りが何であったかを特定します、そして、errorInstanceは誤りoccured. errorOffsetが質問の中の位置であるところの、より正確なしるしを誤りが発生したところに与える実装依存するコードです。 実行されています、errorOpは命令コード、そうでなければゼロを含んでいます。操作がerrorDescriptionが印刷できるテキスト文字列であるということであったなら、それは誤りの何らかの記述を与えます。 それは、errorCodeについて少なくとも説明しますが、また、errorInstanceによって含意された詳細を述べるかもしれません。 付録I.2で分野のすべての詳細な定義を与えます。
Since there may be several unterminated ASN.1 objects in progress at the time the error occurs, each one must be terminated. Each unterminated object will be closed with a copy of the ERROR object. Depending upon the type of length encoding used for this object, this
数個があるかもしれないので、誤りが発生するとき、unterminated ASN.1は進行中であることで反対して、それぞれを終えなければなりません。 それぞれの「非-終え」られたオブジェクトはERRORオブジェクトのコピーで閉じられるでしょう。 このオブジェクトに使用される長さのコード化のタイプに頼っている、これ
Trewitt & Partridge [Page 28] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[28ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
will involve filling the value for the length (definite length form) or emitting two zero octets (indefinite length form). After all objects are terminated, a final copy of the ERROR object will be emitted. This structure guarantees that the error will be noticed at every level of interpretation on the receiving end.
長さ(明確な長さのフォーム)のために値をいっぱいにすることを伴うか、または放って、2は八重奏(無期長さのフォーム)のゼロに合っています。 すべてのオブジェクトが終えられた後に、ERRORオブジェクトの校正刷は放たれるでしょう。 この構造は、あらゆるレベルの解釈で受ける側になって誤りに気付くのを保証します。
In summary, if there was an error before any ASN.1 objects were
generated, then the result would simply be:
error{...}
概要では、どんなASN.1オブジェクトも生成される前に誤りがあれば、結果は単に以下の通りでしょうに。 誤り{...}
If a couple of ASN.1 objects were unterminated when the error
occurred, the result might look like:
interfaces{
interface { name(...) type(...) error{...} }
error{...}
}
error{...}
誤りが発生したとき、一組のASN.1オブジェクトが「非-終え」られるなら、結果に似ているでしょうに: インタフェース、インタフェースがタイプ(…)誤りを…と命名する、(…)誤り、…、誤り{...}
It would be possible to define a "WARNING" object that has a similar (or same) format as ERROR, but that would be used to annotate responses when a non-fatal "error" occurs, such as attempting to SET/CREATE/DELETE and the operation is denied. This would be an additional complication, and we left it out in the interests of simplicity.
同様の、そして、(同じ)の形式を誤りに持っていますが、非致命的な「誤り」が設定するか、作成する、または削除する試みなどのように起こって、操作が否定されるとき応答を注釈するのに使用される「警告」オブジェクトを定義するのは可能でしょう。 これは追加複雑さでしょう、そして、私たちは簡単さのためにそれを省きました。
I. ASN.1 DESCRIPTIONS OF QUERY LANGUAGE COMPONENTS
I. 照会言語コンポーネントのASN.1記述
A query consists of a sequence of ASN.1 objects, as follows:
質問は以下の通りASN.1オブジェクトの系列から成ります:
Query := IMPLICIT SEQUENCE of QueryElement;
QueryElementの:=の暗黙の系列について質問してください。
QueryElement ::= CHOICE {
Operation,
Filter,
Template,
Path,
InputValue
}
QueryElement:、:= 選択操作、フィルタ、テンプレート、経路、InputValue
Operation and Filter are defined below. The others are:
操作とFilterは以下で定義されます。 他のものは以下の通りです。
Template ::= any
Path ::= any
InputValue ::= any
テンプレート:、:= どんなPathも:、:= どんなInputValueも:、:= いくらか
These three are all similar, but have different restrictions on their structure:
これらの3はすべて同様ですが、それらの構造の上に異なった制限を持ってください:
Trewitt & Partridge [Page 29] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[29ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
Template Specifies a portion of the tree, naming one or more
values, but not containing any values.
いずれも含むのではなく、木、命名1または、より多くの値の部分が評価するテンプレートSpecifies。
Path Specifies a single path from one point in the tree to
another, naming exactly one value, but not containing
a value.
値を評価しますが、含まないとちょうど1を命名して、1からのただ一つの経路が木で別のものに指す経路Specifies。
InputValue Gives a value to be used by a query language
operator.
照会言語オペレータによって使用されるべきInputValue Gives a価値。
A query response consists of a sequence of ASN.1 objects, as follows:
質問応答は以下の通りASN.1オブジェクトの系列から成ります:
Response := IMPLICIT SEQUENCE of ResponseElement;
ResponseElementの応答の:=の暗黙の系列。
ResponseElement ::= CHOICE {
ResultValue,
Error
}
ResponseElement:、:= 選択ResultValue、誤り
Error is defined below. The others are:
誤りは以下で定義されます。 他のものは以下の通りです。
ResultValue ::= any
ResultValue:、:= いくらか
ResultValue is similar to Template, above:
ResultValueは以下の上でTemplateと同様です。
ResultValue Specifies a portion of the tree, naming and
containing one or more values.
木と、命名と1つ以上を含む部分が評価するResultValue Specifies。
The distinctions between these are elaborated in section 6.
これらの区別はセクション6に詳しく説明されます。
I.1 Operation Codes
I.1命令コード
Operation codes are all encoded in a single application-specific type, whose value determines the operation to be performed. The definition is:
命令コードは値が、操作が実行されることを決定する単独のアプリケーション特定のタイプですべてコード化されます。 定義は以下の通りです。
Operation ::= [APPLICATION 1] IMPLICIT INTEGER {
reserved(0),
begin(1),
end(2),
get(3),
get-attributes(4),
get-range(5),
set(6),
操作:、:= [APPLICATION1]IMPLICIT INTEGER、(0)を予約して、(1)、終わりの(2)を始めて、範囲(5)、セット(6)を得るのに属性(4)を得ている(3)を得ます。
Trewitt & Partridge [Page 30] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[30ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
create(7),
delete(8)
}
(7)を作成してください、そして、(8)を削除してください。
I.2 Error Returns
I.2誤りは戻ります。
An Error object is returned within a reply when an error is encountered during the processing of a query. Note that the definition this object is similar to that of the HEMP protocol error structure. The error codes have been selected to keep the code spaces distinct between the two. This is intended to ease the processing of error messages. See section 11 for more information.
質問の処理の間誤りに遭遇するとき、回答の中でErrorオブジェクトを返します。 これは、定義がHEMPプロトコル誤り構造のものと同様であることに注意してくださいというように反対します。 エラーコードが2つの間で異なるようにコード空間を保つのが選択されました。 これがエラーメッセージの処理を緩和することを意図します。 詳しい情報に関してセクション11を見てください。
Error ::= [APPLICATION 0] IMPLICIT SEQUENCE {
errorCode INTEGER,
errorInstance INTEGER,
errorOffset INTEGER
errorDescription IA5String,
errorOp INTEGER,
}
誤り:、:= [アプリケーション0] 暗黙の系列errorCode整数、errorInstance整数、errorOffset整数errorDescription IA5String、errorOp整数
The fields are defined as follows:
分野は以下の通り定義されます:
errorCode Identifies the general cause of the error.
司令官が引き起こす誤りのerrorCode Identifies。
errorInstance An implementation-dependent code that gives a more
precise indication of where the error occured in the
query processor. This is most useful when internal
errors are reported.
どこの、より正確なしるしに誤りを与えるerrorInstance Anの実装依存するコードが質問プロセッサでoccuredされました。 内部エラーが報告されるとき、これは最も役に立ちます。
errorOffset The location within the query where the error was
detected. The first octet of the query is numbered
zero.
errorOffset、質問の中の誤りが検出された位置。 質問の最初の八重奏は番号付のゼロです。
errorOp If an operation was being executed, this contains its
operation code, otherwise zero.
errorOp If、操作は存在が実行されて、これが命令コード、そうでなければゼロを含んでいるということでした。
errorDescription
A text string that can be printed that gives some
description of the error. It will at least describe
the errorCode, but may also give details implied by
errorInstance.
印刷されて、それが誤りの何らかの記述を与えるということであるかもしれないerrorDescription Aテキスト文字列。 それは、errorCodeについて少なくとも説明しますが、また、errorInstanceによって含意された詳細を述べるかもしれません。
Some errors are associated with the execution of specific operations, and others with the overall operation of the query interpreter. The errorCodes are split into two groups.
いくつかの誤りが特定の操作の実行、および質問インタプリタの総合的な操作の他のものに関連しています。 errorCodesは2つのグループに分割されます。
The first group deals with overall interpreter operation. Except for
最初のグループは総合的なインタプリタ操作に対処します。 except for
Trewitt & Partridge [Page 31] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[31ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
"unknown operation", these do not set errorOp.
これらは、「未知の操作」とどんなセットerrorOpもしません。
100 Other error.
Any error not listed below.
100 他の誤り。 少しの誤りも以下に記載しませんでした。
101 Format error.
An error has been detected in the format of the input
stream, preventing further interpretation of the
query.
101は誤りをフォーマットします。 質問のさらなる解釈を防いで、誤りは入力ストリームの形式で検出されました。
102 System error.
The query processor has failed in some way due to an
internal error.
102 システム誤り。 質問プロセッサは内部エラーのため何らかの道に失敗しました。
103 Stack overflow.
Too many items were pushed on the stack.
103はオーバーフローを積み重ねます。 あまりに多くの商品がスタックに押されました。
104 Unknown operation.
The operation code is invalid. errorOp is set.
104 未知の操作。 命令コードは無効です。errorOpは用意ができています。
The second group is errors that are associated with the execution of particular operations. errorOp will always be set for these.
2番目のグループは特定の操作の実行に関連している誤りです。errorOpはいつもこれらに用意ができるでしょう。
200 Other operation error.
Any error, associated with an operation, not listed
below.
200 他の操作誤り。 操作に関連している少しの誤りも以下に記載しませんでした。
201 Stack underflow.
An operation expected to see some number of operands
on the stack, and there were fewer items on the
stack.
201はアンダーフローを積み重ねます。 操作は、スタックの上で何らかの数のオペランドを見ると予想して、スタックの上により少ない項目があったなら、そこで予想しました。
202 Operand error.
An operation expected to see certain operand types on
the stack, and something else was there.
202 オペランド誤り。 スタック、および他の何かで、あるオペランドタイプに会うと予想された操作はそこのそうでした。
203 Invalid path for BEGIN.
A path given for BEGIN was invalid, because some
element in the path didn't exist.
203のBEGINに、無効の経路。 経路の何らかの要素が存在しなかったので、BEGINのために与えられた経路は無効でした。
204 Non-dictionary for BEGIN.
A path given for BEGIN was invalid, because the given
node was a leaf node, not a dictionary.
204、非辞書、始まってください。 与えられたノードが辞書ではなく、葉のノードであったので、BEGINのために与えられた経路は無効でした。
205 BEGIN on array element.
The path specified an array element. The path must
point at a single, unique, node. A filtered BEGIN
should have been used.
205 配列の要素のBEGIN。 経路は配列の要素を指定しました。 経路は単一の、そして、ユニークなノードを指し示さなければなりません。 フィルターにかけることのBEGINは使用されるべきでした。
Trewitt & Partridge [Page 32] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[32ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
206 Empty filter for BEGIN.
The filter for a BEGIN didn't match any array
element.
206はBEGINのためのフィルタを空にします。 BEGINのためのフィルタはどんな配列の要素にも合っていませんでした。
207 Filtered operation on non-array.
A filtered operation was attempted on a regular
dictionary. Filters can only be used on arrays.
207は非配列で操作をフィルターにかけました。 フィルターにかけることの操作は通常の辞書の上で試みられました。 配列でフィルタを使用できるだけです。
208 Index out of bounds.
The starting address or length for a GET-RANGE
operation went outside the bounds for the given
object.
208は区域外に索引をつけます。 GET-RANGE操作のための開始アドレスか長さが与えられたオブジェクトのために領域の外で続きました。
209 Bad object for GET-RANGE.
GET-RANGE can only be applied to objects whose base
type is OctetString.
209のGET-RANGEに、悪いオブジェクト。 ベースタイプがOctetStringであるオブジェクトにGET-RANGEを適用できるだけです。
This list is probably not quite complete, and would need to be extended, based upon implementation experience.
このリストは、たぶん全く完全であるというわけではなく、実装経験に広げられて、基づく必要があるでしょう。
I.3 Filters
I.3フィルタ
Many of the operations can take a filter argument to select among elements in an array. They are discussed in section 8.6.
操作の多くが要素の中で配列で選択するフィルタ議論を取ることができます。 セクション8.6でそれらについて議論します。
Filter ::= [APPLICATION 2] CHOICE {
present [0] DataPath,
equal [1] DataValue,
greaterOrEqual [2] DataValue,
lessOrEqual [3] DataValue,
and [4] SEQUENCE OF Filter,
or [5] SEQUENCE OF Filter,
not [6] Filter
}
以下をフィルターにかけてください:= [アプリケーション2] 選択[6]ではなく、等しい[1]DataValue、greaterOrEqual[2]DataValue、lessOrEqual[3]DataValue、および[4]のDataPath、SEQUENCE OF Filter、または[5]SEQUENCE OF Filterがフィルターにかけるプレゼント[0]
DataPath ::= ANY -- Path with no value
DataPath:、:= いずれ--値のない経路
DataValue ::= ANY -- Single data value
DataValue:、:= いずれ--ただ一つのデータ値
A filter is executed by inorder traversal of its ASN.1 structure.
フィルタはASN.1構造の間順走査で実行されます。
The basic filter operations are:
基本的なフィルタ操作は以下の通りです。
present tests for the existence of a particular data item in
the data tree
データ木の特定のデータ項目の存在のための現在のテスト
Trewitt & Partridge [Page 33] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[33ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
equal tests to see if the named data item is equal to the
given value.
同輩は、命名されたデータ項目が与えられた値と等しいかどうか確認するためにテストします。
greaterOrEqual tests to see if the named data item is greater than
or equal to the given value.
greaterOrEqualは、命名されたデータ項目がそう以上かどうか確認するためにテストします。与えられた値。
lessOrEqual tests to see if the named data item is less than or
equal to the given value.
lessOrEqualは、命名されたデータ項目が与えられたより値以下であるかどうか確認するためにテストします。
These may be combined with "and", "or", and "not" operators to form arbitrary boolean expressions. The "and" and "or" operators will take any number of terms. Terms are only evaluated up to the point where the outcome of the expression is determined (i.e., an "and" term's value is false or an "or" term's value is true).
これらは、任意の論理演算子式を形成するために“and"、“or"、および“not"オペレータに結合されるかもしれません。 “and"と“or"オペレータはいろいろな用語でかかるでしょう。用語は式の結果が決定している(すなわち、“and"タームの値が誤っているか、または“or"タームの値は本当です)ポイントまで評価されるだけです。
I.4 Attributes
I.4属性
One or more Attributes structure is returned by the GET-ATTRIBUTES operator. This structure provides descriptive information about items in the data tree. See the discussion in section 8.3.
1つ以上のAttributes構造がGET-ATTRIBUTESオペレータによって返されます。 この構造は項目の描写的である情報をデータ木に提供します。 セクション8.3の議論を見てください。
Attributes ::= [APPLICATION 3] IMPLICIT SEQUENCE {
tagASN1 [0] IMPLICIT INTEGER,
valueFormat [1] IMPLICIT INTEGER,
longDesc [2] IMPLICIT IA5String OPTIONAL,
shortDesc [3] IMPLICIT IA5String OPTIONAL,
unitsDesc [4] IMPLICIT IA5String OPTIONAL,
precision [5] IMPLICIT INTEGER OPTIONAL,
properties [6] IMPLICIT BITSTRING OPTIONAL,
valueSet [7] IMPLICIT SET OF valueDesc OPTIONAL
}
valueDesc ::= IMPLICIT SEQUENCE {
value [0] ANY, -- Single data value
desc [1] IA5String
}
属性:、:= [APPLICATION3]IMPLICIT SEQUENCE、tagASN1[0]IMPLICIT INTEGER、valueFormat[1]IMPLICIT INTEGER、longDesc[2]IMPLICIT IA5String OPTIONAL、shortDesc[3]IMPLICIT IA5String OPTIONAL、unitsDesc[4]IMPLICIT IA5String OPTIONAL、精度[5]IMPLICIT INTEGER OPTIONAL、特性の[6]IMPLICIT BITSTRING OPTIONAL、valueSet[7]IMPLICIT SET OF valueDesc OPTIONAL、valueDesc:、:= 暗黙の系列{少しも[0]を評価してください--独身のデータ値のdesc[1]IA5String}
The meanings of the various attributes are given below.
様々な属性の意味を以下に与えます。
tagASN1 The ASN.1 tag for this object. This attribute is
required.
.1がこれのためにタグ付けをするtagASN1ASNは反対します。 この属性が必要です。
valueFormat The underlying ASN.1 type of the object (e.g.,
SEQUENCE or OCTETSTRING or Counter). This is not
just the tag number, but the entire tag, as it would
appear in an ASN.1 object. As such, it includes the
class, which should be either UNIVERSAL or
APPLICATION. Applications receiving this should
基本的なASN.1がタイプするオブジェクト(例えば、SEQUENCE、OCTETSTRINGまたはCounter)のvalueFormat。 これはタグ番号だけではなく、ASN.1オブジェクトに現れるように全体のタグでもあります。 そういうものとして、それはクラスを含んでいます。(それは、UNIVERSALかAPPLICATIONのどちらかであるべきです)。 これを受けるアプリケーションはそうするべきです。
Trewitt & Partridge [Page 34] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[34ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
ignore the constructor bit. This attribute is
required.
建設者ビットを無視してください。 この属性が必要です。
longDesc A potentially lengthy text description which fully
defines the object. This attribute is optional for
objects defined in this memo and required for
entity-specific objects.
longDesc A、オブジェクトを完全に定義する潜在的に長いテキスト記述。 このメモで定義されて、実体特有のオブジェクトに必要であるオブジェクトに、この属性は任意です。
shortDesc A short mnemonic string of less than 15 characters,
suitable for labeling the value on a display. This
attribute is optional.
ディスプレイの上の値をラベルするのに適当な15未満のキャラクタのshortDescのA脆い簡略記憶ストリング。 この属性は任意です。
unitsDesc A short string used for integer values to indicate
the units in which the value is measured (e.g., "ms",
"sec", "pkts", etc.). This attribute is optional.
unitsDescのA脆いストリングは整数に値が測定されるユニットを示す値を使用しました(例えば、"ms"、「秒」、"pkts"など)。 この属性は任意です。
precision For Counter objects, the value at which the Counter
will roll-over. Required for all Counter objects.
精度For Counterオブジェクト、Counterがロールオーバーがそうする値がすべてのCounterオブジェクトに必要です。
properties A bitstring of boolean properties of the object. If
the bit is on, it has the given property. This
attribute is optional. The bits currently defined
are:
オブジェクトの論理演算子の特性をbitstringする特性A。 ビットがオンであるなら、それには、与えられた特性があります。 この属性は任意です。 現在定義されているビットは以下の通りです。
0 If true, the difference between two values of
this object is significant. For example, the
changes of a packet count is always significant,
it always conveys information. In this case, the
0 bit would be set. On the other hand, the
difference between two readings of a queue length
may be meaningless.
0 本当であるなら、このオブジェクトの2つの値の違いは重要です。 例えば、パケットカウントの変化がいつも重要である、それはいつも情報を伝達します。 この場合、0ビットは設定されるでしょう。 他方では、待ち行列の長さの2つの読書の違いは無意味であるかもしれません。
1 If true, the value may be modified with SET,
CREATE, and DELETE. Applicability of CREATE and
DELETE depends upon whether the object is in an
array.
1 本当であるなら、値はSET、CREATE、およびDELETEと共に変更されるかもしれません。 CREATEとDELETEの適用性は配列にはオブジェクトがあるかによります。
2 If true, the object is a dictionary, and a BEGIN
may be used on it. If false, the object is leaf
node in the data tree.
2 本当であるなら、目的は辞書であり、BEGINはそれで使用されるかもしれません。 誤っているなら、オブジェクトはデータ木の葉のノードです。
3 If true, the object is an array-type dictionary,
and filters may be used to traverse it. (Bit 2
will be true also.)
3 本当であるなら、目的は配列型辞書であり、フィルタは、それを横断するのに使用されるかもしれません。 (また、ビット2は真になるでしょう。)
valueSet For data that is defined as an ASN.1 CHOICE type (an
enumerated type), this gives descriptions for each of
the possible values that the data object may assume.
ASN.1CHOICEタイプ(列挙型)と定義されるvalueSet Forデータ、これはデータ・オブジェクトが仮定するかもしれないそれぞれの可能な値のための記述を与えます。
Trewitt & Partridge [Page 35] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[35ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
Each valueDesc is a <value,description> pair. This
information is especially important for control
items, which are very likely to appear in
VendorSpecific dictionaries, exactly the situation
where descriptive information is needed.
記述>組、各valueDescは<値です。 管理項目に、この情報は特に重要です、まさに描写的である情報が必要である状況。(管理項目はVendorSpecific辞書に非常に載っていそうです)。
I.5 VendorSpecific
I.5 VendorSpecific
See the discussion in section 9.
セクション9の議論を見てください。
VendorSpecific ::= [APPLICATION 4] IMPLICIT SET
of ANY
VendorSpecific:、:= [アプリケーション4] 内在しているセットのいずれも
II. IMPLEMENTATION HINTS
II。 実装ヒント
Although it is not normally in the spirit of RFCs to define an implementation, the authors feel that some suggestions will be useful to implementors of the query language. This list is not meant to be complete, but merely to give some hints about how the authors imagine that the query processor might be implemented efficiently.
実装を定義するために、通常、RFCsの精神にはそれがありませんが、作者は、いくつかの提案が照会言語の作成者の役に立つと感じます。 完全であることが意味されるのではなく、このリストは、単に作者が、質問プロセッサが効率的に実装されるかもしれないとどう想像するかに関していくつかのヒントを与えるために意味されます。
- It should be understood that the stack is of very limited
depth. Because of the nature of the query language, it can
get only about 4 entries (for arguments) plus the depth of
the tree (up to one BEGIN per level in the tree). This
comes out to about a dozen entries in the stack, a modest
requirement.
- スタックが非常に限られた深さのものであることが理解されるべきです。 照会言語の本質のために、それはおよそ4つのエントリー(議論のための)と木の深さ(木のレベルあたり最大1BEGIN)しか得ることができません。 これはスタック、穏やかな要件におけるおよそ1ダースのエントリーに出て来ます。
- The stack is an abstraction -- it should be implemented
with pointers, not by copying dictionaries, etc.
- スタックは抽象化です--それは辞書などをコピーすることで実装されるのではなく、指針で実装されるべきです。
- An object-oriented approach should make implementation
fairly easy. Changes to the "shape" if the data items
(which will certainly occur, early on) will also be easier
to make.
- オブジェクト指向アプローチで、実装はかなり簡単になるべきです。 また、「形」への変化はデータ項目(確かに、早くから起こる)であるなら、より作りやすいようになるでしょう。
- Only a few "messages" need to be understood by objects. By
having pointers to action routines for each basic operation
(GET,SET,...) associated with each node in the tree, common
routines (e.g., emit a long integer located at address X)
can be shared, and special routines (e.g., set the interface
state for interface X) can be implemented in a common
framework. Higher levels need know nothing about what data
is being dealt with.
- ほんのいくつかの「メッセージ」が、オブジェクトに解釈される必要があります。 木に各ノードに関連しているそれぞれの基本的な操作(GET、SET)のためのアクションルーチンに指針を持っていることによって、一般的なルーチン(例えば、アドレスXに位置する長整数型を放つ)を共有できます、そして、一般的なフレームワークで特別なルーチン(例えば、インタフェースXに界面準位を設定する)を実装することができます。 どんなデータが対処されているかに関して、より高いレベルは何も知る必要はありません。
- Most interesting objects are dictionaries, each of which
can be implemented using pointers to the data and procedure
"hooks" to perform specific operations such as GET, SET,
- ほとんどのおもしろいオブジェクトが辞書です、SET。GETなどの特定の操作を実行するためにデータへの指針を使用して、手順「フック」であるとそれぞれそれを実装することができます。
Trewitt & Partridge [Page 36] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[36ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
filtering, etc.
フィルタリングなど
- The hardest part is actually extracting the data from
existing TCP/IP implementations that weren't designed with
detailed monitoring in mind. Query processors interfacing
to a UNIX kernel will have to make many system calls in
order to extract some of the more intricate structures,
such as routing tables. This should be less of a problem
if a system is designed with easy monitoring as a goal.
- 最大の難所は実際に詳細なモニターで設計されなかった既存のTCP/IPインプリメンテーションからのデータを念頭に抜粋しています。 UNIXカーネルに連結する質問プロセッサはいくつかの、より複雑な構造を抜粋するために多くのシステムコールをしなければならないでしょう、経路指定テーブルなどのように。 システムが目標としての簡単なモニターで設計されるなら、問題ではこれは、より少ないはずです。
A Skeletal Implementation
骨格の実装
This section gives a rather detailed example of the core of a query processor. This code has not been tested, and is intended only to give implementors ideas about how to tackle some aspects of query processor implementation with finesse, rather than brute force.
このセクションは質問プロセッサのコアのかなり詳細な例を出します。 このコードは、テストされていなくて、単に馬鹿力よりむしろ鋭さがある質問プロセッサ実装のいくつかの局面を道具へのどのようにに関する作成者考えに与えるかを意図します。
The suggested architecture is for each dictionary to have a "traverse" routine associated with it, which is called when any sort of operation has to be done on that dictionary. Most nodes will share the same traversal routine, but array dictionaries will usually have routines that know about whatever special lookup mechanisms are required.
提案されたアーキテクチャは各辞書にはそれに関連している「横断」ルーチンがあることです。(その辞書でどんな種類の操作もしなければならないと、それを呼びます)。 配列辞書には、ほとんどのノードが同じ縦断ルーチンを共有するでしょうが、通常、いかなる特別なルックアップメカニズムに関しても知っているルーチンがあるでしょう。必要です。
Non-dictionary nodes would have two routines, "action", and "compare", which implement query language operations and filter comparisons, respectively. Most nodes would share these routines.
非辞書ノードには、2つのルーチン、「動作」、および「比較してください」があるでしょう。(それは、それぞれ照会言語操作とフィルタ比較を実装します)。 ほとんどのノードがこれらのルーチンを共有するでしょう。
For example, there should be one "action" routine that does query language operations on 32-bit integers, and another that works on 16-bit integers, etc.
例えば、32ビットの整数で照会言語操作をして、16ビットの整数などで働いている別のことをする1つの「動作」ルーチンがあるべきです。
Any traversal procedure would take arguments like:
どんな縦断手順も以下のように議論を取るでしょう。
traverse(node, mask, op, filter)
Treenode node; /* generic node-in-tree */
ASN mask; /* internal ASN.1 form */
enum opset op; /* what to do */
Filter filter; /* zero if no filter */
(ノード、マスク、オプアート、フィルタ)Treenodeノードを横断してください。 *ジェネリック木のノード*/ASNがマスクをかける/。 /*内部のASN.1フォーム*/enum opsetオプアート。 /、**/をするべきことはフィルタをフィルターにかけます。 /*ゼロはいいえなら*/をフィルターにかけます。
enum opset { begin, get, set, create, delete, geta,
c_le, c_ge, c_eq, c_exist };
enum opset、始まってくださいといって、得てくださいといって、セットしてください、作成、削除、下駄、c_le、c_ge、c_eq、c_が存在している、。
The traversal procedure is called whenever anything must be done within a dictionary. The arguments are:
辞書の中で何でもしなければならないときはいつも、縦断手順は呼ばれます。 議論は以下の通りです。
node the current dictionary.
ノード、現在の辞書。
Trewitt & Partridge [Page 37] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[37ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
mask is either the template, path, or value, depending
upon the operation being performed. The top-level
identifier of this object will be looked up in the
context of <node>.
実行される操作によって、マスクは、テンプレート、経路、または値です。 この物に関するトップレベル識別子は<ノード>の文脈で調べられるでしょう。
op is the operation to be performed, either one of the
basic operations, or a filter operation.
オプアートは、実行されるべき操作、基本的な操作のどちらか、またはフィルタ操作です。
filter is the filter to be applied, or zero if none. There
will be no filter when <op> is a filter-comparison
operation.
フィルタは、適用されるべきフィルタ、またはゼロです。なにもであるなら。 <オプアート>がフィルタ比較操作であるときに、フィルタが全くないでしょう。
The general idea is that the traversal proc associated with a node has all of the knowledge about how to get around in this subtree encoded within it. Hopefully, this will be the only place this knowledge is coded. Here is a skeleton of the "standard" traversal proc, written mostly in C.
概念はノードに関連している縦断procにはそれの中でコード化されたこの下位木でどう動くかに関する知識のすべてがあるということです。 うまくいけば、これはこの知識がコード化される唯一の場所になるでしょう。 ここに、ほとんどCに書かれた「標準」の縦断procの骸骨があります。
When the query processor needs to execute a "GET" operation, it would
just call:
traverse(current, template, GET, 0)
質問プロセッサが、「得てください」という操作を実行する必要があると、ただ呼ぶでしょう: 横断(電流、テンプレート、GET、0)
Notes about this example:
この例に関する注:
- This traversal routine handles either query language
operations (GET, SET, etc.) or low-level filter operations.
Separate routines could be defined for the two classes of
operations, but they do much of the same work.
- この縦断ルーチンは照会言語操作(GET、SETなど)か低レベルであるフィルタ操作のどちらかを扱います。 2つのクラスの操作のために別々のルーチンを定義できましたが、それらは同じ仕事の多くのことをします。
- Dictionary nodes have a <traversal> proc defined.
- 辞書ノードには、>procが定義した<縦断があります。
- Leaf nodes have an <action> proc, which implement GET, SET,
GET-ATTRIBUTES, CREATE, and DELETE, and a <compare> proc,
which performs low-level filter comparisons.
- <動作>proc、どれがGET、SET、GET-ATTRIBUTES、CREATEを実行するか、そして、DELETE、および<は葉のノードで、>procを比較します。(procは低レベルであるフィルタ比較を実行します)。
- In the generic routine, the filter argument is unused,
because the generic routine isn't used for array
dictionaries, and only array dictionaries use filters.
- 一般的なルーチンでは、フィルタ議論は未使用です、一般的なルーチンがアレイ辞書に使用されないで、アレイ辞書だけがフィルタを使用するので。
- An ASN type contains the top level tag and a list of
sub-components.
- ASNタイプはトップ平らなタグとサブコンポーネントのリストを含んでいます。
- size(mask) takes an ASN.1 object and tells how many
sub-items are in it. Zero means that this is a simple
object.
- サイズ(マスク)は、ASN.1物を取って、いくつのサブ項目がそれにあるかを言います。 ゼロは、これが簡単な物であることを意味します。
- lookup(node, tag) looks up a tag in the given (tree)node,
returning a pointer to the node. If the tag doesn't exist
- ポインタをノードに返して、ルックアップ(ノード、タグ)は与えられた(木)ノードでタグを見上げます。 タグが存在していないなら
Trewitt & Partridge [Page 38] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[38ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
in that node, a pointer to a special node "NullItem" is
returned. NullItem looks like a leaf node and has procs
that perform the correct action for non-existent data.
そのノードでは、"NullItem"という特別なノードへのポインタを返します。 NullItemは葉のノードに似ていて、実在しないデータのための正しい動作を実行するprocsを持っています。
- This example does not do proper error handling, or ASN.1
generation, both of which would require additional code in
this routine.
- この例は適切なエラー処理、またはASNに.1世代をしません。その両方がこのルーチンにおける追加コードを必要とするでしょう。
/*
* For op = GET/SET/etc, return:
* true on error, otherwise false.
* When op is a filter operation, return:
* the result of the comparison.
*/
int std_traverse(node, mask, op, filter)
Treenode node; /* current node */
ASN mask; /* internal ASN.1 form */
enum opset op; /* what to do */
Filter filter; /* unused in this routine */
{
ASN item;
Treenode target;
boolean rv = false;
extern Treenode NullItem;
オプアートのための/**はGET/SET/などと等しく、戻ってください: * 誤りのときに本当であって、そうでなければ、誤っています。 * オプアートがフィルタ操作であることの、ときには、戻ってください: * 比較の結果。 */int std_横断(ノード、マスク、オプアート、フィルタ)Treenodeノード。 現在のノード*/ASNがマスクをかける/*。 /*内部のASN.1フォーム*/enum opsetオプアート。 /、**/をするべきことはフィルタをフィルターにかけます。 中の/*未使用のこれほど通常の*/、ASNの品目; Treenode目標; 論理演算子rvは虚偽; 通いの人Treenode NullItem;で等しいです。
if (filter != null) {
error(...);
return true;
}
(フィルタ!=ヌル)です。誤り(…); 本当に戻ってください。
target = lookup(node, mask.tag);
=ルックアップ(ノード、mask.tag)を狙ってください。
/* We are at the leaf of the template/path/value. */
if (size(mask) == 0)
switch (op)
{
case BEGIN:
/* non-existent node, or leaf node */
if (target == NullItem || target.traverse == 0) {
error(...);
return true;
}
else {
begin(node, mask.tag);
return false;
}
私たちがいるテンプレート/経路/の葉が評価する/*。 */が(サイズ(マスク)=0)であるなら(オプアート)を切り換える、(NullItem| | 目標=target.traverse=0)であるならBEGIN: /*実在しないノード、または葉のノード*/をケースに入れてください、誤り(…); 本当に戻ってください;、ほか(ノード、mask.tag)を始めてください; 虚偽で戻ってください;。
case GET: case SET: case GETA:
GETをケースに入れてください: SETをケースに入れてください: GETAをケースに入れてください:
Trewitt & Partridge [Page 39] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[39ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
case GETR: case CREATE: case DELETE:
/* A leaf in the mask specifies entire directory.
For GET, traverse the entire subtree. */
if (target.traverse)
if (op == GET) {
foreach subnode in target
/* Need to test to not GET memory. */
rv |= (*target.traverse)
(target, subnode.tag, op, 0);
return rv;
}
else if (op == SET) /* no-op */
return false;
else if (op != GETA) {
error(...);
return true;
}
/* We're at a leaf in both the mask and the tree.
Just execute the operation.
*/
else {
if (op == BEGIN) { /* Can't begin on leaf */
error(...);
return true;
else
return (*target.action)(target, mask, op);
}
} /* else */
GETRをケースに入れてください: CREATEをケースに入れてください: DELETEをケースに入れてください: マスクの/*A葉は全ディレクトリを指定します。 GETに関しては、全体の下位木を横断してください。 */、(target.traverse)である、(=が得るオプアート){ 目標/*のforeach subnodeはGETメモリでないことへのテストにそうしなければなりません。 */rv|= (*target.traverse) (目標、subnode.tag、オプアート、0)。 rvを返してください。 } ほかに、(オプアート=SET)/*オプアートがない*/であるなら虚偽で戻ってください。 ほか、(オプアート!=GETA)である、誤り(…); 本当に戻ってください;、/、*私たちはマスクと木の両方の葉にいます。 ただ操作を実行してください。 *ほかの/、*が葉の*/誤り(…)のときに始めることができない/; 本当に(オプアート=BEGIN)戻る、(ほかのリターン(*target.action)(目標、マスク、オプアート))/*ほかの*/
default: /* Comparison ops. */
return (*target.compare)(target, mask, op);
} /* switch */
デフォルト: /*比較オプアート。 */リターン(*target.compare)(目標、マスク、オプアート)。 } /*スイッチ*/
/* We only get here if mask has structure. */
私たちがマスクである場合にだけここに到着させる/*は構造を持っています。 */
/* can't have multiple targets for BEGIN */
if (op == BEGIN && size(mask) != 1) {
error(...);
return true;
}
/* or for a single filter operation. */
if (op is comparison && size(mask) != 1) {
error(...);
return false;
}
/* Iterate over the components in mask */
foreach item in mask
{
/*がBEGIN*/のためのマルチターゲットを持つことができない、(オプアート=BEGIN、サイズ(マスク)!=1)、誤り(…); 本当に戻ってください;、/*かaただ一つのフィルタ操作のために。 */、(オプアートが比較である、(マスク!) =1)誤り(…); リターン偽;/*がマスクのマスク*/foreachの品目のコンポーネントの上で繰り返すサイズ
Trewitt & Partridge [Page 40] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[40ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
if (target.traverse) /* traverse subtree. */
rv |= (*component.traverse)(component, item, op, 0);
else /* leaf node, at last. */
if (op is comparison)
return (*target.compare)(target, mask, op);
else
return (*target.action)(target, mask, op);
} /* foreach */
(target.traverse)/*であるなら、下位木を横断してください。 */rv|= (*component.traverse)(コンポーネント、項目、オプアート、0)。 ついにほかの/*葉のノード。 */、(オプアートは比較です)リターン(*target.compare)(目標、マスク、オプアート)であるなら。 ほかに、戻ってください(*target.action)(目標、マスク、オプアート)。 } /*foreach*/
return rv;
} /* std_traverse */
rvを返してください。 } /*std_横断*/
Here is a bare skeleton of an array-type dictionary's traversal proc.
ここに、配列型辞書の縦断procのむき出しの骸骨があります。
int array_traverse(node, mask, op, filter)
Treenode node; /* current node */
ASN mask; /* internal ASN.1 form */
enum opset op; /* what to do */
Filter filter; /* unused in this routine */
{
Treenode target;
boolean rv = false;
extern Treenode NullItem;
intアレイ_横断(ノード、マスク、オプアート、フィルタ)Treenodeノード。 現在のノード*/ASNがマスクをかける/*。 /*内部のASN.1フォーム*/enum opsetオプアート。 /、**/をするべきことはフィルタをフィルターにかけます。 中の/*未使用のこれほど通常の*/、Treenode目標; 論理演算子rvは虚偽; 通いの人Treenode NullItem;で等しいです。
/* Didn't find that key. */
if (mask.tag != this array's iteration tag)
return false;
/*は、それが主要であることがわかりませんでした。 */、(このmask.tag!=アレイの繰り返しタグ)であるなら、虚偽で戻ってください。
if (op == BEGIN && filter == null) {
error(...);
return 1;
}
(オプアート=BEGIN、フィルタ=ヌル)誤り(…)(リターン1)
/* The implementation of this loop is the major trick! */
/* Needs to stop after first filter success on BEGIN. */
foreach target in node {
if (filter == null || /* if no filter, or */
ExecFilter(target, filter)) /* if it succeeds */
rv |= (target.traverse*)(target, mask, op, 0);
}
} /* array_traverse */
この実現が輪にする/*は主要なトリックです! *//*は、最初に、フィルタ成功の後にBEGINに止まる必要があります。 */は(*フィルタでない、または*/ExecFilterでない(目標、フィルタ)なら=ヌル| | /をフィルターにかけます)/は*それであるなら*/rvを引き継ぎます| =(target.traverse*)(目標、マスク、オプアート、0)ならノードでforeachに狙います。 /*アレイ_横断*/
Object-oriented programming languages, such as C++, Modula, and Ada, are well suited to this style of implementation. There should be no particular difficulty with using a conventional language such as C or Pascal, however.
C++などのオブジェクト指向プログラミング言語(Modula、およびAda)は、このスタイルの実現によく合っています。 しかしながら、Cかパスカルなどの月並みな言葉を使用するどんな特定の困難もあるべきではありません。
Trewitt & Partridge [Page 41] RFC 1076 HEMS Monitoring and Control Language November 1988
Trewittとヤマウズラ[41ページ]RFC1076は1988年11月にモニターと制御言語のへりを取ります。
III. OBTAINING A COPY OF THE ASN.1 SPECIFICATION
III。 ASN.1仕様のコピーを入手します。
Copies of ISO Standard ASN.1 (Abstract Syntax Notation 1) are available from the following source. It comes in two parts; both are needed:
ISO Standard ASN.1(抽象的なSyntax Notation1)のコピーは以下のソースから利用可能です。 それは2つの部品に入ります。 両方が必要です:
IS 8824 -- Specification (meaning, notation)
IS 8825 -- Encoding Rules (representation)
仕様(意味、記法)が8825であるという8824はRulesをコード化していますか?(表現)
They are available from:
それらは以下から利用可能です。
Omnicom Inc.
115 Park St, S.E. (new address as of March, 1987)
Vienna, VA 22180
(703) 281-1135
Omnicom Inc.115Park通り、ウィーン、東南(1987年3月現在新しいアドレス)ヴァージニア22180(703)281-1135
Trewitt & Partridge [Page 42]
Trewittとヤマウズラ[42ページ]
一覧
スポンサーリンク
