RFC31 日本語訳
0031 Binary Message Forms in Computer. D. Bobrow, W.R. Sutherland. February 1968. (Format: TXT=11191 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Request for Comments: 31
コメントを求めるワーキンググループ要求をネットワークでつないでください: 31
BINARY MESSAGE FORMS IN COMPUTER NETWORKS
コンピュータネットワークの2進のメッセージフォーム
Daniel Bobrow
Bolt, Beranek, and Newman
Cambridge, Massachusetts
ダニエルBobrow Bolt、Beranek、およびニューマン・ケンブリッジ(マサチューセッツ)
William R. Sutherland
MIT Lincoln Laboratory
Lexington, Massachusetts
ウィリアム・R.サザーランド・MITリンカーン・研究所レキシントン(マサチューセッツ)
February 1968
1968年2月
[Page 1]
RFC 31 Binary Message Forms February 1968
[1ページ] RFC31の2進のメッセージは1968年2月に形成されます。
MESSAGE FORMS IN COMPUTER NETWORKS
コンピュータネットワークのメッセージフォーム
INTRODUCTION
序論
Network communication between computers is becoming increasingly
important. However, the variety of installations working in the area
probably precludes standardization of the content and form of inter-
computer messages. There is some hope, however, that a standard way
of defining and describing message forms can be developed and used to
facilitate communication between computers. Just as ALGOL serves as
a standard vehicle for describing numerous algorithms, and BNF serves
as a standard for describing language syntax, a message description
language would be useful as a standard vehicle for defining message
formats.
Considerable progress has been made at the low level of message
handling protocol and one can expect the ASCII protocols to be used.
The discussion which follows assumes that the mechanics of exchanging
messages, check sums, repeat requests, etc., have been worked out.
The topic of concern is how to describe the content and intent of a
binary message body when the network header and trailer details have
been stripped off.
Most attempts at describing the content of binary messages
jump immediately into a consideration of the bit codings to be used.
Long, thin rectangles are drawn to represent the binary bit stream;
this stream is sliced up into boxes, and tables generally describe
the bit options for each box. A better approach would be to provide
a symbolic method for describing messages. The symbolism, by
avoiding immediate references to specific bit details, should help
one's understanding of the message content and the alternatives
available in the message body. When the basic form of the binary
message body is clear, the coding details of the actual bit fields
can be shown.
コンピュータのネットワークコミュニケーションはますます重要になっています。 しかしながら、その領域で働いているインストールのバラエティーはたぶん相互コンピュータメッセージの内容と形式の標準化を排除します。 何らかの望みがあって、しかしながら、コンピュータのコミュニケーションを容易にするのにメッセージを定義して、説明する標準の方法が形成されるのを開発して、使用できます。 ちょうど、ALGOLが多数のアルゴリズムを説明するための標準の乗り物として機能して、BNFが言語構文について説明する規格として機能するとき、メッセージ記述言語はメッセージ・フォーマットを定義するための標準の乗り物として役に立つでしょう。 かなりの進展は低レベルのメッセージハンドリングプロトコルで作られています、そして、人はASCIIプロトコルが使用されると予想できます。 続く議論は、メッセージ、チェックサム、反復要求などを交換する整備士が解決されたと仮定します。 関心の話題はネットワークヘッダーとトレーラの詳細が全部はぎ取られたとき、どう2進のメッセージ本体の内容と意図について説明するかということです。 2進のメッセージの内容について説明することへのほとんどの試みが、使用されるためにすぐ噛み付いているコーディングの考慮までジャンプします。 長くて、薄い長方形は2進のビットストリームを表すために描かれます。 このストリームは箱の中に薄く切られます、そして、一般に、テーブルは各箱のための噛み付いているオプションについて説明します。 より良いアプローチはメッセージについて説明するための演算子法を提供するだろうことです。 特定の噛み付いている詳細の即座の参照を避けることによって、シンボリズムは人のメッセージ本体で利用可能なメッセージ内容と代替手段の理解を助けるべきです。 2進のメッセージ本体の基本的なフォームが明確であるときに、実際のビットの細部がさばくコード化を示すことができます。
[Page 2]
RFC 31 Binary Message Forms February 1968
[2ページ] RFC31の2進のメッセージは1968年2月に形成されます。
Describing a binary message body is not much different from
describing a text body or language. Text assumes fixed bit fields
each containing one character. Standard language description methods
(BNF) then show how the characters can be concatenated and what
interpretation should be placed on character groups. Binary message
descriptions require the additional capacity of defining various size
fields in the message and the interpretation to be placed on the bits
contained in the field.
A message description is initially intended as a reference standard
to be written down on paper and made available to new users of a
computer network. From this standard, the new user can discover the
kind and form of the binary data being exchanged over the network.
Once this is known, the programs necessary for using the network
facilities can be created. Later on, in an established network, one
can envision the promulgation of standards for newly developed binary
formats via the exchange of ASCII text messages over the network
itself instead of on paper through the mail. Still farther into the
future, the text of a binary format standard could be used as input
to compiler-like programs which automatically create data translation
programs for converting one binary format to another. Right now,
though, some kind of binary data description method, however trivial,
is desperately needed.
テキスト本文か言語を説明するのと異なった状態でボディーがそれほど多くないという2進のメッセージについて説明します。 1文字を含んでいて、テキストは、固定噛み付いている分野がそれぞれであると仮定します。 そして、標準語記述メソッド(BNF)は、どうしたらキャラクタを連結できるか、そして、どんな解釈がキャラクタグループに置かれるべきであるかを示します。 2進のメッセージ記述はメッセージと解釈で様々なサイズ分野を定義するのがその分野に保管されていたビットに置かれる追加容量を必要とします。 メッセージ記述を初めは、基準ゲージとして紙上で書き留めるつもりであり、コンピュータネットワークの新しいユーザにとって利用可能にします。 この規格から、新しいユーザは、バイナリ・データの種類と用紙がネットワークの上と交換されていると発見できます。 これがいったん知られていると、ネットワーク施設を使用するのに必要なプログラムを作成できます。 の代わりにする、後で、既存のネットワークでは、人がネットワーク自体の上でASCIIテキスト・メッセージの交換で新たに開発されたバイナリフォーマットの規格の発布を思い描くことができる、紙上、メールで。 なお未来まで遠いです、自動的に1つのバイナリフォーマットを別のものに変換するためのデータ変換プログラムを作成するコンパイラのようなプログラムに入力されるようにバイナリフォーマット規格のテキストを使用できました。 もっとも、たった今、ある種のバイナリ・データ記述メソッドがどんなに些細であっても絶望的に必要です。
[Page 3]
RFC 31 Binary Message Forms February 1968
[3ページ] RFC31の2進のメッセージは1968年2月に形成されます。
A SUGGESTED BINARY FORMAT DESCRIPTION METHOD
提案されたバイナリフォーマット記述メソッド
The basic component of a binary message is a simple field
consisting of a consecutive number of bits in the message. Binary
messages consist of concatenated fields. A format description for a
binary message will consist of a title and four declarative sections.
2進のメッセージの基本的な成分はメッセージで一連番号のビットから成る簡単な分野です。 2進のメッセージは連結フィールドから成ります。 2進のメッセージのための書式の記述はタイトルと4つの宣言的なセクションから成るでしょう。
1) Symbolic names are declared for all the different kinds of
fields found in the binary format being defined.
2) Symbolic names are declared for commonly used values of
particular fields.
3) The legal ways of concatenating fields are indicated.
4) The number of bits in each field and any special considerations
of bit codings are declared.
1) 英字名は定義されるバイナリフォーマットで見つけられたすべての異種の分野に宣言されます。 2) 英字名は特定の分野の一般的に使用された値のために宣言されます。 3) 分野を連結する法的な方法は示されます。 4) 各分野のビットの数と噛み付いているコーディングのどんな特別な問題も宣言されます。
The following is a complete example of a binary message description for a trivial kind of pictorial data.
↓これは些細な種類の絵のデータのための2進のメッセージ記述の完全な例です。
Title: Illustrative graphic data format for a hierarchally
structured picture of lines and points.
Simple Fields:
OPT - Option Control Field
COORD - Numerical Coordinate Value
ID - Identnumber for group of picture parts
COUNT - Number of units in message
タイトル: 聖職者階級制のための説明に役立った図形データ形式は系列とポイントの画像を構造化しました。 純真なフィールズ: OPT--オプションControl Field COORD--数字のCoordinate Value ID--画像パートCOUNTのグループのためのIdentnumber--メッセージのユニットの数
Field Equivalents:
PHDR <- '2' OPT
LHDR <- '4' OPT
GRPHDR <- '1' OPT
GRPEND <- '3' OPT
同等物をさばいてください: '4'が選ぶ'2'が選ぶPHDR<LHDR<GRPHDR<'1''3'が選ぶGRPEND<を選んでください。
[Page 4]
RFC 31 Binary Message Forms February 1968
[4ページ] RFC31の2進のメッセージは1968年2月に形成されます。
Characterizations:
CPAIR <- COORD = 2
POINT <- PHDR + CPAIR
LINE <- LHDR + CPAIR = 2
PARTS <- POINT/LINE/PARTS + PARTS
PIXUNIT <- GRPHDR + ID + PARTS + GRPEND
PIXMSG <- '5' OPT + N: COUNT + PIXUNIT = N + '0' OPT
Simple Field Sizes:
OPT 3
COORD 14
ID 9
COUNT 6
特殊化: 2つの部品<の2<COORD=ポイントのCPAIR<PHDR+CPAIR系列<LHDR+CPAIR=ポイント/系列/部品+パートPIXUNIT<GRPEND PIXMSG GRPHDR+ID+部品+<'5'+ Nを選んでください: カウント+PIXUNIT=N+'0'は簡単な分野サイズを選びます: 3COORD14ID9カウント6を選んでください。
Declaration of Simple Fields
簡単な分野の宣言
The declaration of a simple field includes a symbolic
name, and for lack of a better way, an English description of what
the contents of the field represent. For example:
Simple Fields:
F1 - Geometric Options
EXP - STD Number - Exponent
COORD - STD Number - Geometric Coordinates
簡単な分野の宣言は、英字名を含んで、より良い方法(分野の内容が表すことに関するイギリスの記述)の不足のためにそうします。 例えば: 純真なフィールズ: F1--幾何学上オプションEXP--STD番号--解説者COORD--STD番号--幾何学上座標
Representing Field Values
A field with a specific value can be represented by a number in
single quotes followed by the field name. A number consists of
standard digits construed as binary if zeros and ones. Other numbers
must be followed by a base indicator unless no confusion is possible;
Q is octal, D is decimal.
フィールド名があとに続いたシングル・クォーテション・マークの数で特定の値でField Values A分野を表すのを表すことができます。 数はゼロとものであるならバイナリーに理解された標準のケタから成ります。 混乱がないのが可能でない場合、ベースインディケータは他の数のあとに続かなければなりません。 Qが8進である、Dは10進です。
Example:
'1001' F1
'300D' COORD
'27Q' EXP
Field values are integer numbers assigned such that the least
significant bit is sent first. Only that part of the number which
fits the field is used. Appropriate sign extension is needed for
negative numbers and for numbers whose bit representation is smaller
than the field.
例: '1001'F1'300D'COORD'27Q'EXP Field値が最初に最下位ビットを送るように割り当てられた整数です。 分野に合う数のその一部分だけが使用されています。 適切な符号拡張が負数と噛み付いている表現が分野より小さい数に必要です。
[Page 5]
RFC 31 Binary Message Forms February 1968
[5ページ] RFC31の2進のメッセージは1968年2月に形成されます。
Simple Field Equivalents
The declaration of a Simple Field Equivalent provides a symbolic
name which represents a particular field with a specific value.
Example:
Field Equivalents:
C1 <- '1001' F1
C2 <- '1010' F1
Simple Field Equivalentの宣言が特定の値で特定の分野を表す英字名を供給する簡単なField Equivalents。 例: 同等物をさばいてください: C1<'1001'F1C2<'1010'F1
Characterization Statement
A characterization statement defines a complex field (message or
message part) by indicating how other fields can be combined and is
similar to a definition statement in BNF. The left side is a complex
field name separated (by <-) from the concatenation indications on
the right. Field names or equivalent names are concatenated by plus
(+), alternatives indicated by slash (/). Slash has precedence over
plus so that A + B/C means A followed by either B or C. Alternatives
must be distinguishable in their own right.
Characterization statement parts can be grouped in the normal
manner by parentheses. (A + B)/C means either A followed by B or C.
特殊化Statement A特殊化声明は、どう他の分野を結合できるかを示すことによって複雑な分野(メッセージかメッセージ部分)を定義して、BNFでの定義声明と同様です。 左側は右における連結指摘と切り離された(<)複雑なフィールド名です。 スラッシュ(/)で代替手段は、プラス(+)によってフィールド名か同等な名前が連結されるのを示しました。 スラッシュで先行が終わるようになるので、そのA+B/Cは、BかC.Alternativesのどちらかによって続かれたAがそのものとして区別可能でなければならないことを意味します。 括弧は正常な方法で特殊化声明一部を分類できます。 (+B)/CはBがあとに続いたAかCのどちらかを意味します。
Repetition Indicators
Repeated occurrences of a field may be indicated by following the
field name with an equal sign (=) and a number. For example:
CPAIR <- (COORD = 2) i.e. exactly two COORD fields
PPAIRS <- (C1 + CPAIR = 10D) / (C2 + CPAIR = 40D)
分野の反復Indicators Repeated発生は、等号(=)と数でフィールド名に従うことで示されるかもしれません。 例えば: CPAIR<(COORD=2)すなわち、ちょうど2COORDはPPAIRS<(C1+CPAIRは10Dと等しいです)/をさばきます。(C2+CPAIR=40D)
Assignments Within a Characterization Statement
Simple fields interpretable as integers can be assigned to a
variable within the right side of a characterization statement. This
variable can then be used as a repetition indicator. Example:
整数が解明できる場合がありますが、特殊化声明の右側の中の変数に割り当てられて、Characterization Statement Simpleがさばく課題Within。 そして、反復インディケータとしてこの変数を使用できます。 例:
MS <- N1: EXP + CPAIR = N1
indicates that MS consists of field EXP interpreted as an integer and
then exactly that number of CPAIRS. All variables are global in
scope.
<N1さん: EXP+CPAIR=N1は、MSが整数が解釈されて、次にちょうどCPAIRSのその数が解釈された分野EXPから成るのを示します。 すべての変数が範囲でグローバルです。
Conditional Fields
Within a characterization statement a field may or may not
occur depending on the contents of some other previous field. This
situation is indicated by assigning a label to the determining field.
The conditional occurrence is then indicated by enclosing a condition
expression and the optional field description in brackets ([ and ]).
For example:
ある他の前の分野のコンテンツによって、条件付きのフィールズのWithin a特殊化声明a分野は起こるかもしれません。 この状況は、決定分野にラベルを割り当てることによって、示されます。 次に、条件付きの発生が状態式と括弧における任意のフィールド記述を同封することによって示される、([そして]) 例えば:
[Page 6]
RFC 31 Binary Message Forms February 1968
[6ページ] RFC31の2進のメッセージは1968年2月に形成されます。
SS <- V:F1 + CPAIR + [V = C1 > PPAIRS]
which defines a format of 2 and perhaps 3 fields.
a) Field F1 labeled V followed by
b) Field CPAIR followed by
c) Field PPAIRS if the first field (V) was C1; otherwise, this
third field is not present in the message.
SS<V: 2と恐らく3つの分野a)の書式を定義するF1+CPAIR+[VはC1>PPAIRSと等しいです] b)があとに続いたVとラベルされた分野F1 c)があとに続いた分野CPAIR 最初の分野(V)がC1であったならPPAIRSをさばいてください。 さもなければ、この3番目の分野はメッセージに存在していません。
Conditional Alternatives
Alternatives selected by the contents of some previous field rather
than by the contents of the alternative field itself are indicated by
an extension of the conditional field notation. For example:
SM := W : F1 + CPAIR + [W = C1 > CPAIR / C2 > PPAIRS /
The determining field occurs at the beginning of the conditional
alternative and each alternative then includes its value for the
determining field and the alternative field then present.
代替の分野自体のコンテンツでというよりむしろ前の何らかの分野のコンテンツによって選択された条件付きのAlternatives Alternativesは条件付きの分野記法の拡大で示されます。 例えば: Sm:=W: F1+CPAIR+、[Wは決定分野が起こる次に条件付きの代替手段とそれぞれの選択肢の始まりが含む次に決定分野への値と代替の分野が寄贈するC1>CPAIR / C2>PPAIRS/と等しいです。
Size of Simple Fields
A separate field size declaration is provided.
Simple Field Sizes:
F1 4
EXP 7
COORD 12
This size declaration should appear at the end of the
message description; thus, forcing the reader to postpone an early
consideration of bit details. xmodmap -e "add lock = Caps_Lock"
SimpleフィールズA別々の分野サイズ宣言のサイズを提供します。 簡単な分野サイズ: F1 4EXP7COORD12Thisサイズ宣言はメッセージ記述の終わりに現れるべきです。 したがって、「ロック=キャプス_Lockを加えてください」であって、読者に詳細ビットxmodmap-eの早めの考慮を延期させます。
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Dave Bachmann 1/98 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][デーヴ・バッハマン1/98によるオンラインRFCアーカイブへの]
[Page 7]
[7ページ]
一覧
スポンサーリンク
