RFC1023 日本語訳
1023 HEMS monitoring and control language. G. Trewitt, C. Partridge. October 1987. (Format: TXT=40992 bytes) (Obsoleted by RFC1076) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Trewitt
Request for Comments: 1023 Stanford
C. Partridge
BBN/NNSC
October 1987
Trewittがコメントのために要求するワーキンググループG.をネットワークでつないでください: 1023 スタンフォードC.ヤマウズラBBN/NNSC1987年10月
HEMS Monitoring and Control Language
モニターと制御言語のへりを取ります。
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データ符号化規則を使用することで表されます。
STATUS OF THIS MEMO
このメモの状態
The purpose of this RFC is provide a specification for monitoring and control of network entities in the Internet. This is an experimental specification and is intended for use in testing the ideas presented here. No proposals in this memo are intended as standards for the Internet at this time. After sufficient experimentation and discussion, this RFC will be redrafted, perhaps as a standard. Distribution of this memo is unlimited.
このRFCの目的はネットワーク実体がインターネットでモニターして、制御されるための仕様を提供することです。 これは、実験仕様であり、ここに提示された考えをテストすることにおける使用のために意図します。 このメモにおける提案は全くこのとき、インターネットの規格として意図しません。 十分な実験と議論の後に、このRFCは恐らく規格として書き直されるでしょう。 このメモの分配は無制限です。
This language is a component of the High-Level Entity Monitoring System (HEMS) described in RFC-1021 and RFC-1022. Readers may want to consult these RFCs when reading this memo. RFC-1024 contains detailed assignments of numbers and structures used in this system. 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はこのシステムで使用される数と構造の詳細な課題を含んでいます。 ASN.1、このメモはISO zデータの符号化に関する知識が標準であると仮定します。
OVERVIEW AND SCOPE
概要AND範囲
The basic model of monitoring and control used in this proposal 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 things, or both. We will use gateway- oriented examples, but it should be understood that this query- response mechanism can be applied to other entities besides just gateways.
この提案に使用されるモニターとコントロールの基本型はモニターされた実体に質問を送って、実体が応答を返送するということです。 用語質問はデータベース意味で使用されます--情報を要求するかもしれなくて、もの、または両方を変更してください。 私たちはゲートウェイ指向の例を使用するつもりですが、まさしくゲートウェイ以外にこの質問反応機構を他の実体に適用できるのが理解されるべきです。
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]のようにありません。 質問はそれ自身のところに立って、完全な応答を引き出す完全な要求です。
Trewitt & Partridge [Page 1] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[1ページ]RFC1023は言語1987年10月にへりを取ります。
It is not necessary for a monitored entity to be able to store the complete query. It is quite possible for an implementation to process the query on the fly, producing portions of the response while the query is still being received.
モニターされた実体が完全な質問を保存できるのは必要ではありません。 実装が急いで質問を処理するのは、かなり可能です、まだ質問を受けている間、応答の部分を生産して。
Other RFCs associated with HEMS are: RFC-1021 -- Overview; RFC-1022 -- transport protocol and message encapsulation; RFC-1024 -- precise data definitions. These issues are not dealt with here. 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.
HEMSに関連している他のRFCsは以下の通りです。 RFC-1021(概要) RFC-1022--トランスポート・プロトコルとメッセージカプセル化。 RFC-1024--正確な資料定義。 これらの問題はここで対処されていません。 モニターされた実体の中で八重奏の系列を質問プロセッサに輸送するために何らかのメカニズムがあって、質問をしながら八重奏の系列を実体に返すために何らかのメカニズムがあると思われます。
ENCODING OF QUERIES AND RESPONSES
質問と応答のコード化
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 of this notation, see the ISO documents IS 8824 and IS 8825. See the end of this memo for information about ordering these documents.
質問と応答の両方が、ISO Standard ASN.1(抽象的なSyntax Notation1)で定義された表現を使用することでコード化されます。 ASN.1は<タグ、長さ、八重奏のストリームとしてコード化されるコンテンツ>三重の系列としてデータを表します。 データtuplesは、配列か記録などの構造化されたデータを表すために再帰的に入れ子にされるかもしれません。 この記法の余すところのない解説に関しては、ISOドキュメントが8824であり、8825であることを確実にしてください。 これらのドキュメントを注文することの情報のためのこのメモの端を見てください。
NOTATION USED IN THIS PROPOSAL
この提案に使用される記法
The notation used in this memo is similar to that used in ASN.1, but less formal, smaller, and (hopefully) easier to read. The most important difference is that, in this memo, we are not concerned with the length of the data items.
このメモで使用される記法は、ASN.1で使用されるそれと同様ですが、それほど正式でなくて、より小さい、そして、(希望をいだいて)より読みやすいです。 最も重要な違いは私たちがこのメモでデータ項目の長さに関係がないということです。
ASN.1 data items may be either a "simple type" such as integer or
octet string or a "structured type", a collection of data items. The
notation or a "structured type", a collection of data items. The
notation:
ID(value)
represents a simple data item whose tag is "ID" with the given value.
A structured data item is represented as:
ID { ... contents ... }
where contents is a sequence of data items. Remember that the
contents may include both simple and structured types, so the
structure is fully recursive.
ASN.1データ項目は、整数か八重奏ストリングなどの「純真なタイプ」か「構造化されたタイプ」のどちらかであるかもしれません、データ項目 記法か「構造化されたタイプ」の収集、データ項目 記法の収集: ID(値)はタグが与えられた値がある「ID」である簡単なデータ項目を表します。 構造化されたデータ項目は以下として表されます。 IDはコンテンツがデータ項目の系列であるところで…を満足させます…。構造が完全に再帰的であるようにコンテンツが簡単なものと同様に構造化されたタイプを含むかもしれないのを覚えていてください。
There are situations where it is desirable to specify a type but give no value, such as when there is no meaningful value for a particular measured parameter or when the entire contents of a structured type is being specified. In this situation, the same notation is used,
状況がタイプを指定しますが、値を全く与えないのが望ましいところにあります、いつ、特定の測定パラメタのためのどんな重要な値もないか、そして、または構造化されたタイプの全体のコンテンツがいつ指定されているのなどように。 この状況同じ記法は使用されています。
Trewitt & Partridge [Page 2] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[2ページ]RFC1023は言語1987年10月にへりを取ります。
but with the value omitted:
ID()
or
ID{}
The representation of this is obvious -- the data item has zero for
the length and no contents.
値で、省略されています: ID()かID、この表現は明白です--データ項目には、長さにもかかわらず、コンテンツでないゼロがあります。
DATA MODEL
データモデル
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:
モニターされた実体におけるデータは階層構造としてモデル化されます。 実装は階層構造として内部的に資料をまとめるのに必要ではありませんが、それらは照会言語を通してデータに関するこの意見を提供しなければなりません。 階層構造は以下の操作のために役に立つ構造を提供します:
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
"constructor" types as an envelope for an entire
subtree.
ASN.1をASN.1に写像すると、全体の下位木に封筒として「建設者」タイプを使用することによって、容易に階層構造を表すことができます。
Efficient Representation
Hierarchical structures are quite compact and can
be traversed very quickly.
効率的なRepresentation Hierarchical構造は、かなりコンパクトであり、非常にすばやく横断できます。
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 would just be an ASN.1 tag. Such names would be small integers (typically, less than 100) and so could easily be mapped by the monitored entity onto its internal representation.
階層構造の各ノードには、コンポーネントの部品への名前がなければなりません。 私たちは「入力誤り」などのASCIIストリングであるとして通常名前を考えるでしょうが、実際の名前はまさしくASN.1タグでしょう。 わずかな整数(通常100未満)でしょう、したがって、モニターされた実体で容易にそのような名前を内部の表現に写像できました。
We will use the term "dictionary" to represent an internal node in the hierarchy. Here is a possible organization of the hierarchy in an entity that has several network interfaces and multiple processes. The exact organization of data in entities is specified in RFC-1024.
私たちは、階層構造で内部のノードを表すのに「辞書」という用語を使用するつもりです。 ここに、いくつかのネットワーク・インターフェースと複数のプロセスを持っている実体における、階層構造の可能な組織があります。 実体における、データの正確な組織はRFC-1024で指定されます。
Trewitt & Partridge [Page 3] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[3ページ]RFC1023は言語1987年10月にへりを取ります。
system {
name -- host name
clock-msec -- msec since boot
interfaces -- # of interfaces
}
interfaces { -- one per interface
interface { type, ip-addr, in-pkts, out-pkts, . . . }
interface { type, ip-addr, in-pkts, out-pkts, . . . }
interface { type, ip-addr, in-pkts, out-pkts, . . . }
:
}
processes {
process { name, stack, interrupts, . . . }
process { name, stack, interrupts, . . . }
:
}
route-table {
route-entry { dest, interface, nexthop, cost, . . . }
route-entry { dest, interface, nexthop, cost, . . . }
:
}
arp-table {
arp-entry { hard-addr, ip-addr, age }
arp-entry { hard-addr, ip-addr, age }
:
}
memory { }
連結してください。名前--名前時計msecを接待します--ブーツインタフェース以来のmsec--インタフェースの#、が連結するシステム、--、1インタフェースあたり1つがタイプ、ip-addr、コネ-pkts出ているpkts、…を連結するpktsからのタイプ、pktsのip-addr… タイプ、ip-addr、コネ-pkts出ているpkts、…を連結してください:、プロセス; 処理してください。ルートエントリーは、destして、nexthopに費用、…を連結します。名前、スタック、中断、…は名前、スタック、中断、…を処理します:、ルートテーブル、ルートエントリーは、destして、nexthopに費用、…を連結します:、固いaddr、ip-addrが年をとらせる固いaddr、ip-addrが年をとらせるarp-エントリーarp-エントリー: メモリをarp見送ってください。{ }
The "name" of the clock in this entity would be:
system{ clock-msec }
and the name of a route-entry's IP address would be:
route-table{ route-entry{ ip-addr } }.
Actually, this is the name of the IP addresses of ALL of the routing
table entries. This ambiguity is a problem in any situation where
there are several instances of an item being monitored. If there was
a meaningful index for such tabular data (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. More on this later.
この実体における時計の「名前」は以下の通りでしょう。 システム時計msecとルートエントリーのIPアドレスの名前は以下の通りでしょう。 ルートテーブルルートエントリーip-addr。 実際に、これは経路指定テーブルエントリーのすべてのIPアドレスの名前です。 このあいまいさはモニターされる項目のいくつかのインスタンスがあるどんな状況で問題です。 そのような表データのための重要なインデックスがあった、(例えば、「経路指定テーブルエントリー#1インチ)、問題が全くないだろう、」 残念ながら、通常、そのようなインデックスはありません。 この問題への解決は、データが内容のいくつかに基づいてアクセスされるのを必要とします。 さらにこれほどより遅いのに関して。
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:
route-table{ route-entry{ ip-addr, cost } }.
独身のASN.1オブジェクトは1つ以上のデータを命名できます。 システム情報の全体の収集は以下によって命名されます。 システム、経路指定テーブルのIPアドレスと費用の名前は以下の通りでしょう。 ルートテーブル、ルートエントリー、ip-addr、費用
Trewitt & Partridge [Page 4] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[4ページ]RFC1023は言語1987年10月にへりを取ります。
Arrays
配列
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, processes, routing tables, and ARP tables are all arrays. In fact, we expect that most of the interesting data in an entity will be contained in arrays.
オブジェクトのテーブルの基礎として同じタイプで使用される辞書の1つのサブタイプがあります。 私たちは、これらを辞書配列と呼びます。 例では、インタフェース、プロセス、経路指定テーブル、およびARPテーブルのための辞書はすべて上では、配列です。 事実上、私たちは、実体における興味ある資料の大部分が配列に含まれると予想します。
The primary difference between arrays and plain dictionaries is that arrays may contain only one type of item, while dictionaries, in general, will contain many different types of items. Arrays are usually accessed associatively using special operators in the language.
配列と明瞭な辞書のプライマリ違いは配列が1つのタイプの項目だけを含むかもしれないということです、辞書が一般に多くの異なったタイプの項目を含むでしょうが。言語で結合しやすく特別なオペレータを使用することで通常、配列はアクセスされます。
The fact that these objects are viewed externally as arrays 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 represented as, for example, a hash table.
これらのオブジェクトが配列として外部的に見なされるという事実は、それらがオブジェクトの直線的なリストとして実装で表されることを意味しません。 同じようにタイプされたオブジェクトのどんな収集も配列として見なされます、それは例えば、ハッシュ表として表されるかもしれませんが。
REPRESENTATION OF A REPLY
回答の表現
The data returned to the monitoring entity is a sequence of ASN.1
data items. Each of these corresponds to one the top-level
dictionaries maintained by the monitored entity. The tags for these
data items will be in the "application-specific" class (e.g., if an
entity has the above structure for its data, then the only top-level
data items that will be returned will have tags corresponding to
these groups). If a query returned data from two of these, the
representation might look like:
interfaces{ . . . } route-table{ . . . }
which is just a stream of two ASN.1 objects (each of which may
consist of many sub-objects).
モニターしている実体に返されたデータはASN.1データ項目の系列です。それぞれのこれらはトップレベル辞書がモニターされた実体で維持した1つに対応しています。 「アプリケーション特有」のクラスにはこれらのデータ項目のためのタグがあるでしょう(例えば、実体にデータのための上の構造があると、返される唯一のトップレベルデータ項目で、タグはこれらのグループに対応するようになるでしょう)。 質問がこれらの2からデータを返すなら、表現に似ているでしょうに: インタフェース、… ただ2ASN.1オブジェクト(それのそれぞれが多くのサブオブジェクトから成るかもしれない)の流れである…をルートでテーブルの上に置いてください。
Data not in the root dictionary will have tags from the context- specific class. Therefore, data must always be fully qualified. For example, the name of the entity would 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 were "name" inside the "system" dictionary or "dest" inside the "interfaces" dictionary (assuming in this case that "name" and "dest" were assigned the same ASN.1 tag).
データは根の辞書に文脈の特定のクラスからのタグを持たないでしょう。 したがって、完全にデータにいつも資格がなければなりません。 例えば、いつもASN.1が「システム」のために反対させるカプセル化された内部を実体の名前に返すでしょう。 返されたオブジェクトが「システム」辞書における「名前」か「インタフェース」辞書で"dest"であり、それがないなら、言う方法が全くないでしょうに(同じASN.1タグはこの場合その「名前」と"dest"を仮定するのに割り当てられました)。
Having fully-qualified data simplifies decoding of the data at the receiving end and allows the tags to be locally chosen (e.g., definitions for tags dealing with ARP tables can't conflict with definitions for tags dealing with interfaces). Therefore, the people
データに完全に資格を与えたのは、犠牲者にデータの解読を簡素化して、タグが局所的に選ばれるのを許容します(ARPテーブルに対処するタグのための例えば定義はタグのためのインタフェースに対処する定義と闘争できません)。 したがって、人々
Trewitt & Partridge [Page 5] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[5ページ]RFC1023は言語1987年10月にへりを取ります。
doing the name assignments are less constrained. In addition, most of the identifiers will be fairly small integers.
名前をして、課題はそれほど抑制されません。 さらに、識別子の大部分はかなりわずかな整数になるでしょう。
It will often be the case that requested data may not be available, either because the request was badly formed (asked for data that couldn't exist) or because the particular data item wasn't defined in a particular situation (time since last error, when there hasn't been an error). In this situation, the returned data item will have the same tag as in the request, but will have zero-length data. Therefore, there can NEVER be an "undefined data" error.
しばしばそれが、データを得ることができないかもしれないよう要求したのは、ケースでしょう、要求がひどく形成されたか(存在できなかったデータを求めます)、または特定のデータ項目が特定の状況(最後の誤り以来の誤りがなかった時)で定義されなかったので。 この状況で、返されたデータ項目は、要求のように同じタグを持ちますが、ゼロ・レングスデータを持つでしょう。 したがって、「未定義のデータ」誤りが決してあることができません。
This allows completely generic queries to be composed without regard to whether the data is defined at all of the entities that will receive the request. All of the available data will be returned, without generating errors that might otherwise terminate the processing of the query.
これは、ジェネリック質問が関係なしでデータが要求を受け取る実体についていったい定義されるかどうかに構成されるのを完全に許容します。 そうでなければ質問の処理を終えるかもしれない誤りを生成しないで、利用可能なデータのすべてを返すでしょう。
REPRESENTATION OF A REQUEST
要求の表現
A request to a monitored entity is also a sequence of ASN.1 data items. Each item will fit into one of the following categories:
また、モニターされた実体への要求はASN.1データ項目の系列です。各個条は以下のカテゴリの1つに収まるでしょう:
Template These are objects with the same types as the
objects returned by a request. The difference
is that a template only specifies the shape of
the data -- there are no values contained in
it. Templates are used to select specific data
to be returned. No ordering of returned data
is implied by the ordering in a template. A
template may be either simple or structured,
depending upon what data it is naming. The
representations of the simple data items in a
template all have a length of zero.
テンプレートTheseは要求で返されたオブジェクトと同じタイプがあるオブジェクトです。 違いはテンプレートがデータの形を指定するだけであるということです--それに含まれた値が全くありません。 テンプレートは、特定のデータが返されるのを選択するのに使用されます。 テンプレートでの注文で返されたデータの注文を含意しません。 それが命名しているすべてのデータによって、テンプレートは、簡単であるか構造化されているかもしれません。 テンプレートの簡単なデータ項目の表現にはすべて、ゼロの長さがあります。
Tag A tag is a special case of a template that is a
simple (non-structured) type (i.e., it names
exactly one node in the dictionary tree).
タグAタグは純真な(非構造化された)タイプであるテンプレートの特別なケース(すなわち、それはまさに辞書木の1つのノードを命名する)です。
Opcodes These objects tell the query interpreter to do
something. They are described in detail later in
this report. Opcodes are represented as an
application-specific type whose value determines
the operation. These values are defined in
RFC-1024.
Opcodes Theseオブジェクトは、何かをするように質問インタプリタに言います。 それらは後でこのレポートで詳細に説明されます。 Opcodesは値が操作を決定するアプリケーション特定のタイプとして表されます。 これらの値はRFC-1024で定義されます。
Data These are the same objects that are used to
represent information returned from an entity.
It is occasionally be necessary to send data as
データTheseは実体から返された情報を表すのに使用される同じオブジェクトです。 それはデータを送るのに時折必要であることです。
Trewitt & Partridge [Page 6] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[6ページ]RFC1023は言語1987年10月にへりを取ります。
part of a request. For example, when requesting
information about the interface with IP address
"10.0.0.51", the address would be sent in the
same format in the request as it would be seen
in a reply.
要求の一部。 IPアドレスとのインタフェースの情報を要求するとき、例えば、「10.0 それが回答で見られるように何0.51インチも、アドレスが同じように送られる.0は中で要求をフォーマットします」。
Data, Tags, and Templates are usually in either the context-specific class, except for items in the root dictionary and a few special cases, which are in the application-specific class.
通常、文脈特有のクラスにはデータ、Tags、およびTemplatesがあります、根の辞書の項目といくつかの特別なケースを除いて。(アプリケーション特有のクラスにはケースがあります)。
QUERY LANGUAGE
照会言語
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.
- 唯一のフォームに関する一時記憶領域はスタックです。
In the current version of the query language:
照会言語の最新版で:
- There are no subroutines.
- サブルーチンが全くありません。
- There are no control structures defined in the language.
- 言語で定義された制御構造が全くありません。
- There are no arithmetic or conditional operators.
- どんな演算も条件演算子もありません。
These features could be added to the language if needed.
必要であるなら、これらの特徴は言語に追加されるかもしれません。
This language is designed with the goal of being expressive enough to write useful queries with, but to guarantee simplicity, both of query execution and language implementation.
表現しているという目標が簡単さにもかかわらず、質問実行と言語実装の保証の簡単さに役に立つ質問を書くことができるくらいこの言語は設計されています。
The central element of the language is the stack. It may contain templates, (and therefore tags), data, or dictionaries (and therefore arrays) from the entity being monitored. Initially, 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 things from the stack and may generate ASN.1 objects and send them to the output stream. Note that portions of the response may be generated while the query is still being received.
総合的な操作はオブジェクトを入力ストリームからASN.1に読み込むのから成ります。 それらが読まれるとすぐに、opcodesでないすべてのオブジェクトがスタックに押されます。 各opcodeはすぐに、実行されて、スタックからものを取り外して、ASN.1にオブジェクトを生成して、それらを出力ストリームに送るかもしれません。 まだ質問を受けている間応答の部分を生成するかもしれないことに注意してください。
The following opcodes are defined in the language. This is a
以下のopcodesは言語で定義されます。 これはaです。
Trewitt & Partridge [Page 7] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[7ページ]RFC1023は言語1987年10月にへりを取ります。
provisional list -- changes may need to be made to deal with additional needs.
暫定的なリスト--変化は、追加必要性が対処させられる必要があるかもしれません。
In the descriptions below, opcode names are in capital letters, preceded by the arguments used from the stack and followed by results left on the stack. For example:
以下での記述では、opcode名に大文字にはあって、スタックから使用される議論で先行されていて、スタックの上に残っている結果はあとに続いています。 例えば:
OP a b OP t
means that the OP operator takes <a> and <b> off of the
stack and leaves <t> on the stack. Many of the operators
below leave the first operand (<a> in this example) on
the stack for future use.
OP a b OP tは、OPオペレータがスタックから<a>と<b>を連れて行って、スタックの上に<tを>に残すことを意味します。 以下のオペレータの多くが今後の使用のためにスタックの上に(この例の<a>)に最初のオペランドを残します。
Here are the operators defined in the query language:
ここに、照会言語で定義されたオペレータはいます:
GET dict template GET dict
Emit an ASN.1 object with the same "shape" as the given
template. Any items in the template that are not in
<dictionary> (or its components) are represented as
objects with a length of zero. This handles requests for
data that isn't available, either because it isn't
defined or because it doesn't apply in this situation.
GET dictテンプレートGET dict Emitは与えられたテンプレートとして同じくらいで「形成します」ASN.1が、反対する。 テンプレートの<辞書>(または、コンポーネント)にないどんな項目もオブジェクトとしてゼロの長さで表されます。 これは得ることができないデータに関する要求を扱います、それが定義されないか、またはそれがこの状況で適用されないので。
or 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はテンプレートでなく、辞書で項目のすべてを手に入れてください。 これは辞書に項目のすべてを記載するテンプレートを提供するのに同等です。
BEGIN dict1 tag BEGIN dict1 dict
Pushes the value for dict{ tag } on the stack, which
should be another dictionary. At the same time, produce
the beginning octets of an ASN.1 object corresponding to
that dictionary. It is up to the implementation to
choose between using the "indefinite length"
representation or going back and filling the length in
later.
BEGIN dict1はdictのための値が別の辞書であるべきであるスタックの上でタグ付けをするBEGIN dict1 dict Pushesにタグ付けをします。 同時に、その辞書に対応するASN.1オブジェクトの始めの八重奏を起こしてください。 それは後で「無期長さ」表現を使用するか、戻って、または長さをいっぱいにするとき選ぶ実装まで達しています。
END dict END --
Pop the dictionary off of the stack and terminate the
currently open ASN.1 object. Must be paired with a
BEGIN.
END dict END--スタックから辞書を飛び出させてください、そして、現在開いているASN.1オブジェクトを終えてください。 BEGINと対にしなければなりません。
Getting Items Based on Their Values
項目をそれらの値に基づかせています。
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つ以上のエントリーを指定しますか? いくつかのインタフェースがある状況を考えてください。 データは以下として組織化されるかもしれません。
Trewitt & Partridge [Page 8] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[8ページ]RFC1023は言語1987年10月にへりを取ります。
interfaces {
interface { type, ip-addr, in-pkts, out-pkts, ...}
interface { type, ip-addr, in-pkts, out-pkts, ...}
:
:
}
インタフェース連結してください。pktsからのタイプ、pktsのip-addr… タイプ、ip-addr、コネ-pkts出ているpkts、…を連結してください:、:
If you only want information about one interface (perhaps because
there is an enormous amount of data about each), then you have to
have some way to name it. One possibility is to just number the
interfaces and refer to the desired interface as:
interfaces(3)
for the third one.
情報およそ1インタフェースが欲しいだけであるなら(恐らくおよそそれぞれデータの巨額があるので)、あなたには、それを命名する何らかの方法がなければなりません。 1つの可能性がまさしく数へのインタフェースです、そして、必要なインタフェースを以下を参照してください。 3番目のもののためのインタフェース(3)。
But this is probably not sufficient since interface numbers may change over time, perhaps from one reboot to the next. This method is not sufficient at all for arrays with many elements, such as processes, routing tables, etc. Large, changing arrays are probably the more common case, in fact.
しかし、インタフェース番号が時間がたつにつれて恐らく1つのリブートから次に変化するかもしれないので、これはたぶん十分ではありません。 このメソッドはプロセス、経路指定テーブルなどの多くの要素に全く配列に十分ではありません。 大きくて、変化している配列はたぶん事実上より一般的なケースです。
Because of the lack of utility of indexing in this context, there is no general mechanism in the language for indexing.
このような関係においては索引をつけるユーティリティの不足のために、索引をつけるための言語には一般的機構が全くありません。
A better scheme is to select objects based upon some value contained in them, such as the IP address or process name. The GET-MATCH operator provides this functionality in a fairly general way.
それらに含まれた何らかの値に基づく選択オブジェクトには、より良い体系があります、IPアドレスやプロセス名のように。 GET-MATCHオペレータはかなり一般的な方法でこの機能性を提供します。
GET-MATCH array value template GET-MATCH array
<array> should be a array (dictionary containing only
one type of item). The first tag in <value> and
<template> must match this type. For each entry in
<array>, match the <value> against the contents of
the entry. If there is a match, emit the entry based
upon <template>, just as in a GET operation.
GET-MATCH配列値のテンプレートGET-MATCH配列<配列>は配列であるべきです(1つのタイプの項目だけを含む辞書)。 <価値の>と<テンプレート>における最初のタグはこのタイプに合わなければなりません。 <配列>の各エントリーには、エントリーのコンテンツに対して<値の>を合わせてください。 マッチがあれば、ちょうどGET操作のように<テンプレート>に基づいたエントリーを放ってください。
If there are several leaf items in the value to be matched against,
as in:
route-entry{ interface(1), cost(3) }
all of them must match an array entry for it to be emitted.
合わせられる値に数個の葉の項目が以下のようにあれば ルートエントリーは(1)、費用(3)を連結します。彼らは皆、それが放たれる配列エントリーに合わなければなりません。
Here is an example of how this operator 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
Trewitt & Partridge [Page 9] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[9ページ]RFC1023は言語1987年10月にへりを取ります。
interfaces BEGIN -- get dictionary
interface{ ip-addr(10.0.0.51) } -- value to match
interface{ in-pkts out-pkts } -- data template to get
GET-MATCH
END -- finished with dict
BEGIN--辞書インタフェースを得るのを連結する、ip-addr、(10.0、.0、.51)、--pktsのインタフェースアウト-pktsを合わせる値(GET-MATCH ENDを手に入れるデータテンプレート)がdictを使い終わった
The exact meaning of a "match" is dependent upon the characteristics of the entities being compared. In almost all cases, it is a comparison for exact equality. However, it is quite reasonable to define values that allow matches to do interesting things. For example, one might define three different flavors of "ip-addr": one that has only the IP net number, one with the IP net+subnet, and the whole IP address. Another possibility is to allow for wildcards in IP addresses (e.g., if the "host" part of an IP address was all ones, then that would match against any IP address with the same net number).
「マッチ」の正確な意味は比較される実体の特性に依存しています。 ほとんどすべての場合、それは正確な平等のための比較です。 しかしながら、マッチがおもしろいことができる値を定義するのはかなり妥当です。 例えば、人は"ip-addr"の3つの異なった風味を定義するかもしれません: IPのネットの番号しか持っていないもの、IPネット+サブネットがある1、および全体のIPアドレス。 別の可能性はIPアドレスでワイルドカードを考慮する(例えば、IPアドレスの「ホスト」部分がすべてものであるなら、それは同じネットの数でどんなIPアドレスに対して合っているでしょうに)ことです。
So, for all data items defined, the behavior of the match operation must be defined if it is not simple equality.
それで、項目が定義したすべてのデータに関して、それが簡単な平等でないならマッチ操作の振舞いを定義しなければなりません。
Implementations don't have to provide the ability to use all items in an object to match against. It is expected that some data structures that provide for efficient lookup for one item may be very inefficient for matching against others. (For instance, routing tables are designed for lookup with IP addresses. It may be very difficult to search the routing table, matching against costs.)
実装はすべての項目を使用する能力を合っているオブジェクトに供給する必要はありません。 他のものに対して合っているには、1つの項目のために効率的なルックアップに備えるいくつかのデータ構造が非常に効率が悪いかもしれないと予想されます。 (例えば、経路指定テーブルはルックアップのためにIPアドレスで設計されています。 コストに対して合っていて、経路指定テーブルを捜すのは非常に難しいかもしれません。)
NOTE: It would be desirable to provide a general-purpose filtering capability, rather than just "equality" as provided by GET-MATCH. However, because of the potential complexity of such a facility, lack of a widely-accepted representation for filter expressions, and time pressure, we are not defining this mechanism now.
以下に注意してください。 能力をフィルターにかける汎用を提供するのはまさしくGET-MATCHによって提供される「平等」よりむしろ望ましいでしょう。 しかしながら、そのような施設の潜在的複雑さ、フィルタ式のための広く受け入れられた表現の不足、および時間圧力のために、私たちは現在、このメカニズムを定義していません。
However, if a generalized filtering mechanism is devised, the GET- MATCH operator will disappear.
しかしながら、一般化されたフィルタリングメカニズムが工夫されると、GET- MATCHオペレータは姿を消すでしょう。
Data Attributes
データ属性
Although ASN.1 data is self-describing as far as the structure goes, it gives no information about what the data means (e.g., By looking at the raw data, it is possible to tell that an item is of type [context 5] and 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?).
構造に関する限り、ASN.1データは自己説明ですが、それはデータが意味することの情報を全く教えません(例えば、Byが生データを見て、項目が長い間タイプ[文脈5]と4つの八重奏のものであると言うのは可能です)。 それは、どのように、データ(これは、整数、IPアドレス、または4文字列ですか?)を解釈するか、そして、またはデータが何を意味するか(何に関するIPアドレス?)を言いません。
Most of the time, this information will come from RFC-1024, which defines all of the ASN.1 tags and their precise meaning. When extensions have been made, it may not be possible to get
たいてい、この情報はRFC-1024から来るでしょう。(RFC-1024はASN.1タグとそれらの正確な意味のすべてを定義します)。 拡大をしたとき、それは得るのにおいて可能でないかもしれません。
Trewitt & Partridge [Page 10] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[10ページ]RFC1023は言語1987年10月にへりを取ります。
documentation on the extensions. (See the section about extensions, page 15.)
拡大に関するドキュメンテーション。 (拡大に関するセクション、15ページを参照してください。)
The query language provides a set of operators parallel to the GET and GET-MATCH operators that return a set of attributes describing the data. This information should be sufficient to let a human understand the meaning of the data and to let a sophisticated application treat the data appropriately. The information is sufficient to let an application format the information on a display and decide whether or not to subtract one sample from another.
照会言語はデータについて説明する1セットの属性を返すGETとGET-MATCHオペレータに平行に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 the 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 just look exactly like the data itself. The format is:
属性の形式はデータ自体の形式ほど簡単ではありません。 それはただちょうどデータ自体に似ているでしょう、したがって、データのタグを使用するのが可能ではありません。 形式は以下の通りです。
Attributes ::= [APPLICATION 2] 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,
}
属性:、:= [アプリケーション2] 暗黙の系列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
For example, the attributes for
system{ name, clock-msec }
might be:
system{
Attributes{
tagASN1(name), valueFormat(IA5String),
longDesc("The name of the host"),
shortDesc("hostname")
},
Attributes{
tagASN1(clock-msec), valueFormat(Integer),
longDesc("milliseconds since boot"),
shortDesc("uptime"), unitsDesc("ms")
precision(4294967296),
properties(1)
例えば、名前、時計msecがそうするかもしれないシステムのための属性、あります: システム、tagASN1(名前)、valueFormat(IA5String)、longDesc(「ホストの名前」)、shortDesc(「ホスト名」)を結果と考える、Attributes、tagASN1(時計msec)、valueFormat(整数)、longDesc(「ブーツ以来のミリセカンド」)、shortDesc(「動作可能時間」)、unitsDesc("ms")精度(4294967296)、特性(1)
Trewitt & Partridge [Page 11] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[11ページ]RFC1023は言語1987年10月にへりを取ります。
}
Note that in this example <name> and <clock-msec> are integer values
for the ASN.1 tags for the two data items. A complete definition of
the contents of the Attributes type is in RFC-1024.
} <名前>と<時計msec>が2つのデータ項目のためのASN.1タグのためのこの例では、整数値であることに注意してください。Attributesタイプのコンテンツの完全な定義がRFC-1024にあります。
Note that there will 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があるでしょう、そして、随意的な要素のいずれも現れないでしょう。
GET-ATTRIBUTES
dict template GET-ATTRIBUTES dict
Emit ASN.1 Attributes objects that for the objects named
in <template>. Any items in the template that are not
in <dictionary> (or its components), elicit an
Attributes object with no.
<でオブジェクトにちなんでテンプレートを>と命名したGET-ATTRIBUTES dictテンプレートGET-ATTRIBUTES dict Emit ASN.1 Attributesオブジェクト。 テンプレートのそれが<辞書>(または、コンポーネント)になくて、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オブジェクトを放ってください。 これは辞書に項目のすべてを記載するテンプレートを提供するのに同等です。 これは、辞書のコンテンツに関する全リストが得られるのを許容します。
GET-ATTRIBUTES-MATCH
dict value template GET-ATTRIBUTES-MATCH dict <array>
should be an array (dictionary containing only one
type of item). The first tag in <value> and
<template> must match this type. For each entry in
<array>, match the <value> against the contents of the
entry. If there is a match, emit the atributes based
upon <template>, just as in a GET-ATTRIBUTES operation.
GET-ATTRIBUTES-MATCH dict値のテンプレートGET-ATTRIBUTES-MATCH dict<配列>は配列であるべきです(1つのタイプの項目だけを含む辞書)。 <価値の>と<テンプレート>における最初のタグはこのタイプに合わなければなりません。 <配列>の各エントリーには、エントリーのコンテンツに対して<値の>を合わせてください。 マッチがあれば、ちょうどGET-ATTRIBUTES操作のように<テンプレート>に基づいたatributesを放ってください。
GET-ATTRIBUTES-MATCH is necessary because there will be situations where the contents of the elements of an array may differ, even though the array elements themselves are of the same type. The most obvious example of this is the situation where several network interfaces exist and are of different types, with different data collected for each type.
状況が配列の要素のコンテンツが異なるかもしれないところにあるので、GET-ATTRIBUTES-MATCHが必要です、同じタイプには配列の要素自体がありますが。 この最も明白な例はいくつかのネットワーク・インターフェースが存在していて、異なったタイプにはある状況です、異なったデータが各タイプのために集められている状態で。
NOTE: The GET-ATTRIBUTES-MATCH operator will disappear if a generalized filtering mechanism is devised.
以下に注意してください。 一般化されたフィルタリングメカニズムが工夫されると、GET-ATTRIBUTES-MATCHオペレータは姿を消すでしょう。
ADDITIONAL NOTE: 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
追加注意: はるかに清潔なメソッドはデータ項目のサブコンポーネントとしての興味がある属性を保存するだろうことです。 例えば、以下を要求すること。 通常、システム時計msec()GETはただデータの値を得るでしょう。 求め
Trewitt & Partridge [Page 12] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[12ページ]RFC1023は言語1987年10月にへりを取ります。
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 an
obvious notation to describe this type of organization. So, we're
stuck with the GET-ATTRIBUTES operator. However, if this cleaner
organization becomes possible, this decision may be re-thought.
木の下側への追加層は現在、属性を得るでしょう: GETは名前付の属性を得るでしょう。残念ながら.1が組織このタイプのそうについて説明するために明白な記法を供給しない(属性はアプリケーション特有のタグで命名されるでしょう。)ASN、私たちはGET-ATTRIBUTESオペレータと共に刺されます。システム、時計msec、shortDesc、unitsDesc、このクリーナー組織が可能になるなら、しかしながら、この決定は再考えられるかもしれません。
Examining Memory
メモリを調べます。
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 array, with an ASN.1 representation of OctetString. Because of the variety of addressing architectures in existence, the conversion between the OctetString and "memory" is very machine-dependent. The only simple case is for byte-addressed machines with 8 bits per byte.
メモリは配列としてOctetStringのASN.1表現でモデル化されます。 現存するアドレッシング体系のバラエティーのために、OctetStringと「メモリ」の間の変換はマシン非常に依存しています。 唯一の簡単なケースが1バイトあたり8ビットがあるバイトで扱われたマシンのためのものです。
Each address space in an entity is represented by one dictionary. In a one-address-space situation, this dictionary will be at the top level. If each process has its own address space, then one "memory" dictionary may exist for each process.
実体における各アドレス空間は1冊の辞書によって表されます。 1アドレス空間の状況に、この辞書がトップレベルにあるでしょう。 各プロセスにそれ自身のアドレス空間があるなら、1冊の「メモリ」辞書が各プロセスのために存在するかもしれません。
The GET-RANGE operator is provided for the primary purpose of retrieving the contents of memory, but can be used on any array. It is only useful in these other contexts if the array index is meaningful.
GET-RANGEオペレータをメモリのコンテンツを検索するプライマリ目的に提供しますが、どんな配列でも使用できます。 配列指数が重要であるなら、単にこれらの他の文脈で役に立ちます。
GET-RANGE array start length GET-RANGE dict
Get <length> elements of <array> starting at <start>.
<start> and <length> are both ASN.1 INTEGER type.
<で始動する<配列>のGET-RANGE配列スタート長さのGET-RANGE dict Get<長さの>要素は>を始動します。 <スタート>と<の長さの>はASN.1INTEGERがタイプする両方です。
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 is special in that it will not automatically be returned as
part of a request for an entire dictionary (e.g., If memory is part
of the "system" dictionary, then requesting:
system{}
will emit the entire contents of the system dictionary, but not the
memory item).
それが全体の辞書を求める要求の一部として自動的に返されないので、記憶は特別です。(例えば、Ifメモリは「システム」辞書の一部です、次に、以下を要求してシステム、メモリ項目ではなく、システム辞書の全体のコンテンツを放つ、)
NOTE: The GET-RANGE operator may disappear if a generalized filtering mechanism is devised.
以下に注意してください。 一般化されたフィルタリングメカニズムが工夫されるなら、GET-RANGEオペレータは姿を消すかもしれません。
Trewitt & Partridge [Page 13] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[13ページ]RFC1023は言語1987年10月にへりを取ります。
Controlling Things
ものを制御します。
All of the operators defined so far only allow data in an entity to be retrieved. By replacing the "template" arguments used in the GET operators with values, data in the entity can be changed.
今までのところ定義されているオペレータは皆、実体におけるデータが検索されるのを許すだけです。 GETオペレータで値で使用される「テンプレート」議論を置き換えることによって、実体におけるデータを変えることができます。
There are many control operations that do not correspond to simply changing the value of a piece of data, such as bringing an interface "down" or "up". In these cases, a special data item associated with the component being controlled (e.g., each interface), would be defined. Control operations then consist of "setting" this item to an appropriate command code.
単に1つのデータの値を変えると対応しない多くの制御機能があります、インタフェース“down"か“up"を持って来るのなどように。 これらのケース、制御されるコンポーネントに関連している特別なデータ項目(例えば各インタフェース)では、定義されるでしょう。 そして、制御機能はこの項目が適切なコマンドコードに「設定」であるのから成ります。
SET dict value SET dict
Set the value(s) of data in the entity to the value(s)
given in <value>.
SET dictはSET dict Setを評価します。<で与えられた値への実体における、データの値は>を評価します。
SET-MATCH array mvalue svalue SET-MATCH dict
<array> should be a array (dictionary containing only one
type of item). The first tag in <mvalue> and <svalue>
must match this type. For each entry in <array>, match
the <mvalue> against the contents of the entry. If there
is a match, set value(s) in the entity to the value(s) in
<svalue>, just as in SET.
SET-MATCH配列mvalue svalue SET-MATCH dict<配列>は配列であるべきです(1つのタイプの項目だけを含む辞書)。 <mvalue>と<svalue>における最初のタグはこのタイプに合わなければなりません。 <配列>の各エントリーには、エントリーのコンテンツに対して<mvalue>を合わせてください。 マッチがあれば、ちょうどSETのように<svalue>で値への実体に値をはめ込んでください。
CREATE array value SET dict
Insert a new entry into <array>. Depending upon the
context, there may be severe restrictions about what
constitutes a valid <value>.
CREATEは値のSET dict Insertのa新しいエントリーを<配列>に整列させます。 文脈によって、有効な<値の>を構成することに関する厳しい制限があるかもしれません。
DELETE array value SET dict
Delete the entry(s) in <array> that have values that
match <value>.
DELETEは値のSET dict Deleteを整列させます。<配列>の<値の>に合っている値があるエントリー。
If there are several leaf items in the matched value, as in
route-entry{ interface(1), cost(3) }
all of them must match an array entry for any values to be changed.
取り組んでいる値に数個の葉の項目があれば、コネとして、ルートエントリーは(1)、費用(3)を連結します。それらは皆、どんな値も変えられる配列エントリーに合わなければなりません。
Here is an example of how this operator would be used to shut down the interface with ip-address 10.0.0.51 changing its status to "down".
ここに、このオペレータがip-アドレスとのインタフェースを止めるのにどう使用されるだろうかに関する例があります。10.0 .0 .51 状態を“down"に変えます。
interfaces BEGIN -- get dictionary
interface{ ip-addr(10.0.0.51) } -- value to match
interface{ status(down) } -- value to set
SET-MATCH
END -- finished with dict
BEGIN--辞書インタフェースを得るのを連結する、ip-addr、(10.0、.0、.51)、--インタフェース状態(down)を合わせる値(SET-MATCH ENDを設定する値)がdictを使い終わった
Trewitt & Partridge [Page 14] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[14ページ]RFC1023は言語1987年10月にへりを取ります。
Delete the routing table entry for 36.0.0.0.
36.0のためのルーティングテーブル項目を削除してください。.0 .0。
route-table BEGIN -- get dictionary
route-entry{ ip-addr(36.0.0.0) } -- value to match
DELETE
END -- finished with dict
ルートテーブルBEGIN--辞書ルートエントリーを手に入れてください、ip-addr、(36.0、.0、.0)、dictを使い終わります(DELETE ENDを合わせる値)。
Note that this BEGIN/END pair ends up sending an empty ASN.1 item. We don't regard this as a problem, as it is likely that there will be some get operations executed in the same context. In addition, the "open" ASN.1 item provides the correct context for reporting errors. (See page 14.)
このBEGIN/END組が結局空のASN.1の品目を送ることに注意してください。 私たちは、これを問題と見なしません、それがそこでそうするのがありそうであるのが、同じ文脈で或るもので操作を実行するということであるということであるので。 さらに、「開いている」ASN.1の品目は誤りを報告するための正しい文脈を提供します。 (14ページを参照してください。)
NOTE: The SET-MATCH operator will disappear and the DELETE operator will change if a generalized filtering mechanism is devised.
以下に注意してください。 SET-MATCHオペレータは姿を消すでしょう、そして、DELETEオペレータは一般化されたフィルタリングメカニズムが工夫されるかどうかを変えるでしょう。
Atomic Operations
原子操作
Atomic operations can be provided if desired by allowing the stack to contain a fragment of a query. A new operation would take a query fragment and verify its executability and execute it, atomically.
スタックが質問の断片を含むのを許容することによって望んでいるなら、原子操作を提供できます。 新しい操作は、質問断片を取って、executabilityについて確かめて、原子論的にそれを実行するでしょう。
This is mentioned as a possibility, but it may be difficult to implement. More study is needed.
これは可能性として言及されますが、それは実装するのが難しいかもしれません。 より多くの研究が必要です。
ERRORS
誤り
If some particular information is requested but is not available for any reason (e.g., it doesn't apply to this implementation, isn't collected, etc.), it can ALWAYS be returned as "no-value" by giving the ASN.1 length as 0.
情報は、何らかの事項であるなら要求されていますが、どんな理由にも利用可能でなく(例えばそれは、この実装に適用しないで、また集められませんなど)、それは缶のALWAYSです。「値がありません」として、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 tag doesn't refer to a dictionary, an ERROR object be emitted. The contents of this object identify the exact nature of the error and are discussed in RFC-1024.
いかなる他の種類もあるときには、タグが辞書、ERRORオブジェクトについて言及しないときスタックの先端に不適当な議論を持っていようとするか、またはBEGINを実行などになろうとすることなどの誤りでは、放たれてください。 このオブジェクトの内容について、誤りの正確な本質を特定して、RFC-1024で議論します。
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 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.
数個があるかもしれないので、誤りが発生するとき、unterminated ASN.1は進行中であることで反対して、それぞれを終えなければなりません。 それぞれの「非-終え」られたオブジェクトはERRORオブジェクトのコピーで閉じられるでしょう。 このオブジェクトに使用される長さのコード化のタイプに頼っていて、これが、長さ(明確な長さのフォーム)のために値をいっぱいにすることを伴うだろうか、または放って、2は八重奏(無期長さのフォーム)のゼロに合っています。 すべてのオブジェクトが終えられた後に、ERRORオブジェクトの校正刷は放たれるでしょう。 この構造は、あらゆるレベルの解釈で受ける側になって誤りに気付くのを保証します。
Trewitt & Partridge [Page 15] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[15ページ]RFC1023は言語1987年10月にへりを取ります。
If there was an error before any ASN.1 objects were generated, then
the result would simply be:
error(details)
どんなASN.1オブジェクトも生成される前に誤りがあれば、結果は単に以下の通りでしょうに。 誤り(詳細)
If a couple of ASN.1 objects were unterminated, the result might look like:
一組のASN.1オブジェクトが「非-終え」られるなら、結果に似ているでしょうに:
interfaces{
interface { name(...) type(...) error(details) }
error(details)
}
error{details}
インタフェース名前(…)タイプ(…)誤り(詳細)誤り(詳細)誤りを連結します。詳細
EXTENDING THE SET OF VALUES
値のセットを広げています。
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 are two context-dependent tags assigned by the vendor for its non-standard data.
この場合、位置推算歴と傾きは標準的でないデータのためにベンダーによって割り当てられた2個の文脈依存するタグです。
If the vendor-specific method is chosen, the private data MUST have descriptions available through the GET-ATTRIBUTES and GET- ATTRIBUTESMATCH operators. Even with this descriptive ability, the preferred method is to get standard numbers assigned if possible.
ベンダー特有のメソッドが選ばれているなら、個人的なデータには、GET-ATTRIBUTESとGET- ATTRIBUTESMATCHオペレータを通して利用可能な記述がなければなりません。 適した方法はできれば、標準の数を割り当てさせるこの描写的である能力があっても、ことです。
IMPLEMENTATION
実装
Although it is not normally in the spirit of RFCs to define an implementation, the authors feel that some suggestions will be useful
実装を定義するために、通常、RFCsの精神にはそれがありませんが、作者は、いくつかの提案が役に立つと感じます。
Trewitt & Partridge [Page 16] RFC 1023 HEMS Language October 1987
Trewittとヤマウズラ[16ページ]RFC1023は言語1987年10月にへりを取ります。
to early 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.
照会言語の初期の作成者に。 完全であることが意味されるのではなく、このリストは、単に作者が、質問プロセッサが効率的に実装されるかもしれないとどう想像するかに関していくつかのヒントを与えるために意味されます。
- The stack is an abstraction -- it should be implemented
with pointers, not by copying dictionaries, etc.
- スタックは抽象化です--それは辞書などをコピーすることで実装されるのではなく、指針で実装されるべきです。
- An object-oriented approach should make initial
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.
- ほんのいくつかの「メッセージ」が、オブジェクトに解釈される必要があります。
- 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, MATCH,
SET, etc.
- ほとんどのおもしろいオブジェクトが辞書です。GET、MATCH、SETなどの特定の操作を実行するためにデータへの指針を使用して、手順「フック」であるとそれのそれぞれを実装することができます。
- The hardest part is actually extracting the data from an
existing TCP/IP implementions that weren't designed with
detailed monitoring in mind. This should be less of a
problem if a system is designed with easy monitoring as a
goal.
- 最大の難所は実際に詳細なモニターで設計されなかった既存のTCP/IP implementionsからのデータを念頭に抜粋しています。 システムが目標としての簡単なモニターで設計されるなら、問題ではこれは、より少ないはずです。
OBTAINING A COPY OF THE ASN.1 SPECIFICATION
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 17]
Trewittとヤマウズラ[17ページ]
一覧
スポンサーリンク
