RFC713 日本語訳

0713 MSDTP-Message Services Data Transmission Protocol. J. Haverty. April 1976. (Format: TXT=41175 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Request for Comments: 713                           Jack Haverty  (JFH@MIT-DMS)
NIC #34739                                                             Apr 1976

コメントのために以下を要求してください。 713 ジャックHaverty( JFH@MIT-DMS )NIC#34739 1976年4月

I. ABSTRACT

I. 要約

A mechanism is defined for use by message servers in
transferring data between hosts.  The mechanism, called the
MSDTP, is defined in terms of a model of the process as a
translation between two sets of items, the abstract entities
such as 'strings' and 'integers', and the formats used to
represent such data as a byte stream.

メカニズムは使用のためにメッセージサーバによってホストの間にデータを移す際に定義されます。 MSDTPと呼ばれるメカニズムはプロセスのモデルで2セットの項目の間の翻訳、'ストリング'や'整数'などの抽象的実体、およびバイト・ストリームのようなデータを表すのに使用される形式と定義されます。

A proposed organization of a general data transfer
mechanism is described, and the manner in which the MSDTP
would be used in that environment is presented.

一般データトランスファ・メカニズムの提案された組織は説明されます、そして、MSDTPがその環境で使用される方法は提示されます。

                                -1-

-1-

II. REFERENCES

II。 参照

Black, Edward H., "The DMS Message Composer", MIT Project
MAC, Programming Technology Division Document
SYS.16.02.

技術事業部ドキュメントSYSをプログラムして、黒、エドワードH.、MITの「DMSメッセージ作曲家」がMACを映し出す、.16、.02

Burchfiel, Jerry D., Leavitt, Elsie M., Shapiro, Sonya and
Strollo, Theodore R., compilers, "Tenex Users' Guide",
Bolt Beranek and Newman, Cambridge, Mass., May 1971,
revised January 1975, Descriptive sections on the TENEX
subsystems: MAlLER, p. 116-11; MAlLSTAT, p. 118-119;
READMAIL, p. 137; and SNDMSG, p. 165-170.

Burchfiel(ジェリーD.とレービットとエルシーM.とシャピロとソーニャとStrolloとセオドアR.とコンパイラと「Tenexユーザのガイド」とBolt Beranekとニューマン、ケンブリッジ、マサチューセッツ州1971年5月)は1975年1月に復習しました、TENEXサブシステムのDescriptive部: MAlLER、p。 116-11; MAlLSTAT、p。 118-119; READMAIL、p。 137; SNDMSG、p。 165-170.

Haverty, Jack, "Communications System Overview", MIT Project
MAC, Programming Technology Division Document
SYS.16.00.

Haverty、ジャック、「通信網概要」、MITプロジェクトMAC、プログラミング技術事業部ドキュメントSYS、.16、.00

Haverty, Jack, "Communications System Daemon Manual", MIT
Project MAC, Programming Technology Division Document
SYS.16.01.

Haverty、ジャック、「通信網デーモンマニュアル」、MITプロジェクトMAC、プログラミング技術事業部ドキュメントSYS、.16、.01

ISI Information Automation Project, "Military Message
Processing System Design," Internal Project
Documentation (Out of Print), Jan. 1975

ISI情報オートメーションプロジェクト、「軍事のメッセージ処理システムデザイン」、内部のプロジェクト文書(絶版の)、1975年1月

Message Services Committee, "Interim Report", Jan. 28, 1975

1975年1月28日のメッセージサービス委員会、「中間報告」

Mooers, Charlotte D., "Mailsys Message System: Manual For
Users", Bolt Beranek and Newman, Cambridge, Mass., June
1975 (draft).

Mooers、シャーロットD.、「Mailsysはシステムを通信します」。 「ユーザにとって、手動であり」、1975(作成する)年6月にBeranekとニューマン、ケンブリッジ、マサチューセッツ州をボルトで締めてください。

Myer, Theodore H., "Notes On The BBN Mail System", Bolt
Beranek and Newman, November 8, 1974.

マイヤーとセオドアH.と「BBNメールシステムに関する注」とボルトBeranekとニューマン、1974年11月8日。

Myer, Theodore H., and Henderson, D. Austin, "Message
Transmission Protocol", Network Working Group RFC 680,
NIC 32116, April 30, 1975.

マイヤー、セオドアH.、およびヘンダーソン、D.オースチン、「メッセージトランスミッションプロトコル」は1975年4月30日にワーキンググループRFC680、NIC32116をネットワークでつなぎます。

Postel, Jon, "The PCPB8 Format", NSW Proposal, June 5, 1975

ポステル、ジョン、「PCPB8形式」、NSW提案、1975年6月5日

Tugender, R., and D. R. Oestreicher, "Basic Functional
Capabilities for a Military Message Processing
Service," ISI?RR-74-23., May 1975

Tugender、R.、およびD.R.Oestreicher、「軍事のメッセージ整理業務のための基本的な機能的な能力」、ISI--RR-74-23、1975年5月

Vezza, Al, "Message Services Committee Minority Report",
Jan. 1975

Vezza、アル、「メッセージサービス委員会のマイノリティ・リポート」、1975年1月

                                   -2-

-2-

III. OVERVIEW

III。 概要

This document describes a mechanism developed for use
by message servers communicating over an eight-bit
byte-oriented network connection to move data structures and
associated data-typing information.  It is presented here in
the hope that it may be of use to other projects which need
to transfer data structures between dissimilar hosts.

このドキュメントは使用のためにデータ構造を動かすために8ビットのバイト指向のネットワーク接続の上で交信するメッセージサーバと関連データ型定義情報によって開発されたメカニズムについて説明します。 それはここ、それが異なったホストの間にデータ構造を移す必要がある他のプロジェクトの役に立つかもしれないという望みで提示されます。

A set of abstract entities called PRIMITIVE ITEMS is
enumerated.  These are intended to include traditional data
types of general utility, such as integers, strings, and
arrays.

PRIMITIVE ITEMSと呼ばれる1セットの抽象的実体は列挙されます。 これらが一般的なユーティリティの整数や、ストリングや、配列などの伝統的なデータ型を含んでいることを意図します。

A mechanism is defined for augmenting the set of
abstract data entities handled, to allow the introduction of
application-specific data, whose format and semantics are
understood by the application programs involved, but which
can be transmitted using common coding facilities.  An
example might be a data structure called a 'file
specification', or a 'date'.  Abstract data entities defined
using this mechanism will be termed SEMANTIC ITEMS, since
they are typically used to carry data having semantic
content in the application involved.

メカニズムは、形式と意味論がかかわったアプリケーション・プログラムに解釈されますが、一般的なコード化施設を使用することで送ることができるアプリケーション特有のデータの導入を許すために扱われた抽象的なデータ実体のセットを増大させるために定義されます。 例は、'ファイル仕様'と呼ばれるデータ構造、または'日付'であるかもしれません。 このメカニズムを使用することで定義された抽象的なデータ実体はSEMANTIC ITEMSと呼ばれるでしょう、彼らがアプリケーションにおける意味内容がかかわるデータを運ぶのに通常使用されるので。

Semantic and primitive items are collectively referred
to simply as ITEMS.

意味的で原始の項目は単にITEMSとまとめて呼ばれます。

The protocol next involves the definition of the format
of the byte stream used to convey items from machine to
machine.  These encodings are described in terms of OBJECTS,
which are the physical byte streams transmitted.

次のプロトコルは機械加工するマシンから商品を伝えるのにおいて中古のバイト・ストリームの形式の定義にかかわります。 これらのencodingsはOBJECTSに関して説明されて、どれが物理的なバイト・ストリームであるかは伝わりました。

To complete the protocol, the rules for translating
between objects and items are presented as each object is
defined.

プロトコルを完成するために、各オブジェクトが定義されるとき、オブジェクトと項目の間で翻訳するための規則は提示されます。

An item is transmitted by being translated into an
object which is transmitted over the connection as a stream
of bytes to the receiver, and reconstructed there as an
item.  The protocol mechanism may thus be viewed as a simple
translator.  It enumerates a set of abstract entities, the
items, which are known to programmers, a set of entities in
byte-stream format, the objects, and the translation rules
for conversion between the sets.  A site implementing the
MSDTP would typically provide a facility to convert between
objects and the local representation of the various items
handled.  Applications using the MSDTP define their
interactions using items, without regard to the actual
formats in which such items are represented at various
machines.  This permits programs to handle higher-level
concepts such as a character string, without concern for its
numerous representational formats.  Such detail is handled
by the MSDTP.

項目は、受信機へのバイトのストリームとして接続の上に伝えられて、項目としてそこに再建されるオブジェクトに翻訳されることによって、伝えられます。 その結果、プロトコルメカニズムは純真な翻訳者として見なされるかもしれません。 それはセットの間の変換のための抽象的実体、プログラマにとって知られている項目の1セット、バイト・ストリーム形式における、1セットの実体、オブジェクト、および翻訳規則を数え上げます。 MSDTPを実装するサイトは、オブジェクトと扱われた様々な項目のローカルの表現の間で変換するために施設を通常提供するでしょう。 MSDTPを使用するアプリケーションが項目を使用することでそれらの相互作用を定義します、そのような項目が様々なマシンに表される実際の形式への尊敬なしで。 これは、プログラムが多数の具象主義の形式に関する心配のない文字列などの、よりハイレベルの概念を処理することを許可します。 そのような詳細はMSDTPによって扱われます。

                                -3-

-3-

Finally, a discussion of a general data transfer
mechanism for communication between programs is presented,
and the manner in which the particular byte-oriented
protocol defined herein would be used in that environment is
discussed.

最終的に、プログラムのコミュニケーションのための一般データトランスファ・メカニズムの議論は提示されます、そして、ここに定義された特定のバイト指向プロトコルがその環境で使用される方法について議論します。

Terminology, as introduced, is defined and highlighted
by capitalizing.

紹介される用語は、大文字で書くことによって、定義されて、強調されます。

IV. PRIMITIVE DATA ITEMS

IV。 原始のデータ項目

The primitive data items include a variety of
traditional, well-understood types, such as integers and
strings.  Primitive data items will be presented using
mnemonic names preceded by the character pair "p-", to serve
as a reminder that the named object is primitive.

原始のデータ項目は整数やストリングなどのさまざまな伝統的で、よく理解されているタイプを含んでいます。 原始のデータ項目は、命名されたオブジェクトが原始的であるということを思い出させるものとして機能するように形質対「p」によって先行された簡略名を使用することで提示されるでしょう。

These items may be represented in various computer
systems in whatever fashion their programmers desire.

これらの項目は彼らのプログラマが望んでいるどんなファッションでも様々なコンピュータ・システムで表されるかもしれません。

IV.1 -- Set Of Primitive Items

IV.1--原始の項目のセット

The set of primitive items defined includes p-INT,
p-STRING, p-STRUC, p-BITS, p-CHAR, p-BOOL, p-EMPTY, and
p-XTRA.

定義された原始の項目のセットはp-INT、p-STRING、p-STRUC、p-BITS、p-CHAR、p-ブール、p-EMPTY、およびp-XTRAを含んでいます。

Since the protocol was developed primarily for use in
message services, items such as p-FLOAT are not included
since they were unnecessary.  Additional items may be easily
added as necessary.

プロトコルが主として使用のために開発されたので、メッセージサービス、項目では、p-FLOATが含まれていないそれらは不要でした。 追加項目は必要に応じて容易に加えられるかもしれません。

A p-INT performs the traditional role of representing
integer numbers.  A p-BITS (BIT Stream) item represents a
bit stream.  The two possible p-BOOL (BOOLean) items are
used to represent the logical values of *TRUE* and *FALSE*.
The single p-EMPTY item is used to, for example, indicate
that a given field of a message is empty.  It is provided to
act as a place-holder, representing 'no data', and appears
as *EMPTY*.

p-INTは表す整数の伝統的な役割を実行します。 p-BITS(BIT Stream)の品目はストリームを少し表します。 2つの可能なp-ブール(BOOLean)項目が、*TRUE*と*FALSE*の論理的な値を表すのに使用されます。ただ一つのp-EMPTYの品目は、例えば、メッセージの与えられた分野が人影がないのを示すのに使用されます。 それは、'データがありません'を表して、プレースホルダとして機能するように提供されて、*EMPTY*として現れます。

The p-STRUC (STRUCture) item is used to group together
a collection of items as a single value, maintaining the
ordering of the elements, such as a p-STRUC of p-INTs.

p-STRUC(STRUCture)の品目はただ一つの値として項目の収集を一緒に分類するのに使用されます、要素の注文を維持して、p-INTsのp-STRUCのように。

A p-CHAR is a single character.  The most common
occurrence of character data, however, will be as p-STRINGs.
A p-STRING should be considered to be a synonym for a
p-STRUC containing only p-CHARs.  This concept is important
for generality and consistency, especially when considering
definitions of permissible operations on structures, such as
extracting subsequences of elements, etc.

p-CHARは単独のキャラクタです。 しかしながら、p-STRINGsとしてキャラクタデータの最も一般的な発生があるでしょう。 p-STRINGはp-CHARsだけを含むp-STRUCのための同義語であると考えられるべきです。 特に構造における許されている操作の定義を考えるとき、一般性と一貫性に、この概念は重要です、要素などの続きを抽出するのなどように

                                   -4-

-4-

Four p-XTRA items, which can be transmitted in a single
byte, are made available for higher level protocols to use
when a frequently used datum is handled which can be
represented just by its name.  An example would be an
acknowledgment between two servers.  Using p-XTRAs to
represent such data permits them to be handled in a single
byte.  There are four possible p-XTRA items, termed *XTRA0*,
*XTRA1*, *XTRA2*, and *XTRA3*.  These may be assigned
meanings by user protocols as desired.

4つのp-XTRAの品目(1バイトで伝えることができる)を頻繁に使用されたデータが扱われるとき使用するまさしく名前で表すことができるより高い平らなプロトコルに利用可能にします。 例は2つのサーバの間の承認でしょう。 そのようなデータを表すのにp-XTRAsを使用するのは、それらが1バイトで扱われることを許可します。 *XTRA0*、*XTRA1*、*XTRA2*、および*XTRA3*は、4つの可能なp-XTRAの品目があると呼びました。意味は望まれているようにユーザプロトコルによってこれらに割り当てられるかもしれません。

IV.2 -- Printing Conventions

IV.2--印刷コンベンション

The following printing conventions are introduced to
facilitate discussion of the primitive items.

原始の項目の議論を容易にするために以下の印刷コンベンションを導入します。

When a specific instance of a primitive data item is
presented, it will be shown in a traditional representation
for that kind of data.  For example, p-INTs are shown as
sequences of digits, e.g. 100, p-STRINGs, as sequences of
characters enclosed in double-quote characters, for example
"ABCDEF".

原始のデータ項目の特定のインスタンスが提示されるとき、それはその種類に関するデータの伝統的な表現で示されるでしょう。 例えば、p-INTsはケタ、例えば、100の系列として見せられます、p-STRINGs、二重引用文字、例えば、"ABCDEF"に同封されたキャラクタの系列として。

As shown above, the two possible p-BOOL items are shown
as *TRUE* or *FALSE*.  The object p-EMPTY appears as
*EMPTY*.  A bit stream, i.e. p-BITS, appears as a stream of
1s and 0s enclosed in asterisks, for example *100101001*.  A
p-CHAR will be presented as the character enclosed in single
quote characters, e.g., 'A'.

上に示されるように、**1と0のストリームが中にアスタリスクを同封したのでEMPTY*しばらく小川(すなわち、p-BITS)が現れるのに従ってTRUE*か*FALSE*オブジェクトp-EMPTYが現れるように2つの可能なp-ブール項目が見せられます、例えば、*100101001*。キャラクタが中に単独の引用文字、例えば、'A'を同封したので、p-CHARを寄贈するでしょう。

P-STRUCs are printed as the representations of their
elements, enclosed in parentheses, for example (1 2 3 4) or
("XYZ" "ABC" 1 2) or ((1 2 3) "A" "B"). Note that because
p-STRINGs are simply a class of p-STRUCs assigned a special
name and printing format for brevity and convenience, the
items "ABC" and ('A' 'B' 'C') are identical, and the latter
format should not be used.

例えば、それらの要素の表現として印刷されて、括弧に同封されたP-STRUCs、(1 2 3 4)、("XYZ""ABC"1 2)または((1 2 3) 「A」「B」) p-STRINGsが単に特別な名前が割り当てられて、簡潔さと便宜のために形式を印刷するp-STRUCsのクラスであるので項目"ABC"と('''B''C')が同じであり、後者の形式が使用されるべきでないことに注意してください。

To present a generic p-STRUC, as in specifying formats
of the contents of something, the items are presented as a
mnemonic name, optionally followed by a colon and the
permissible types of values for that datum.  When one of
several items may appear as the value for some component,
the permissible ones appear separated by vertical-bar
characters.  For example, p-INT|p-STRING represents a single
item, which may be either a p-INT or a p-STRING.

何かのコンテンツの形式を指定する際に、項目が簡略名として提示されるので、そのデータのためのコロンと許されているタイプの値でジェネリックp-STRUCを寄贈すると任意にいうことになりました。 数個の項目の1つが何らかのコンポーネントのための値として現れるとき、許されている人は、縦棒キャラクタで切り離されるように見えます。 例えば、p-INT|p-STRINGは1つの項目を表します。(それは、p-INTかp-STRINGのどちらかであるかもしれません)。

To represent a succession of items, the Kleene star
convention is used.  The specification p-INT[*] represents
any number of p-INTs.  Similarly, p-INT[3,5] represents from
3 to 5 p-INTs, while p-INT[*,5] specifies up to 5 and
p-iNT[5,*] specifies at least 5 p-INTs.

項目の流れを表すために、Kleene星のコンベンションは使用されています。 仕様p-INT[*]はいろいろなp-INTsを表します。 同様に、p-INT[3、5]は3〜5までp-INTsを表します、p-INT[*、5]は最大5を指定します、そして、p-iNT[5、*]は少なくとも5p-INTsを指定しますが。

                                   -5-

-5-

For example, a p-STRUC which is used to carry names and
numbers might be specified as follows.

例えば、名前と数を運ぶのに使用されるp-STRUCは以下の通り指定されるかもしれません。

(name:p-STRING number:p-INT)

(名前: p-ストリング番号: p-INT)

In discussing items in general, when a specific data
value is not intended, the name and types representation may
be used, e.g., offset:p-INT to discuss an 'offset' which has
a numeric value.

一般に、項目、特定のデータ値がいつ意図しないか、そして、名前、およびタイプについて議論するのにおいて、表現は、中古であって、例えば、オフセットであるかもしれません: 数値を持っている'オフセット'について議論するp-INT。

V. SEMANTIC ITEM MECHANISM

V。 意味項目メカニズム

The semantic item mechanism provides a means for
program designers to use a variety of application-specific
data items.

意味項目メカニズムはプログラムデザイナーがさまざまなアプリケーション特有のデータ項目を使用する手段を提供します。

This mechanism is implemented using a special tagged
structure to carry the data type information as well as the
actual components of the particular semantic item.  For
discussion purposes.  Such a special p-STRUC will be termed a
p-EDT (Extended Data Type).

このメカニズムは、特定の意味項目の実際の部品と同様にデータ型情報を運ぶのに特別なタグ付けをされた構造を使用することで実装されます。 議論目的のために。 そのような特別なp-STRUCは東部夏時間のp(拡張Data Type)と呼ばれるでしょう。

When p-EDTs are transferred, their identity as a p-EDT
is maintained.  So that an applications program receives the
corresponding semantic item instead of a simple p-STRUC.  A
p-EDT is identical to a p-STRUC in all other respects.

p-EDTsがわたっているとき、東部夏時間のpとしての彼らのアイデンティティは維持されます。 アプリケーションプログラムが簡単なp-STRUCの代わりに対応する意味項目を受けるように。 東部夏時間のpは他のすべての点がp-STRUCと同じです。

V.1 -- Format of p-EDTs

V.1--p-EDTsの形式

A prototypical p-EDT follows.  It is printed as if it
were a normal p-STRUC.  Since p-EDTs are converted to
semantic items for presentation to the user, a p-EDT will
never be used except in this protocol definition.

東部夏時間のprototypical pは続きます。 それは正常なp-STRUCであるかのように印刷されます。 p-EDTsがユーザへのプレゼンテーションのために意味項目に変換されるので、このプロトコル定義以外に、東部夏時間のpは決して使用されないでしょう。

(type:p-INT|p-STRING version:p-INT com1:any
com2:any ...)

(タイプ:p-INT|p-STRINGバージョン: p-INT com1: どんなcom2も: いくらか…)

The first element, the 'type' is generally a p-INT, and
is used to identify the particular type of semantic item.
Types are assigned numeric codes in a controlled fashion.
The type may alternatively be specified by a p-STRING, to
permit development of new data types for possible later
assignment of codes.  Each type has an equivalent p-STRING
name.  These may be used interchangeably as 'type' elements,
primarily to maintain upward compatibility.

最初の要素、'タイプ'は、一般にp-INTであり、特定のタイプの意味項目を特定するのに使用されます。 数字コードは管理された方法でタイプに割り当てられます。 あるいはまた、タイプは、コードの可能な後の課題のための新しいデータ型の開発を可能にするためにp-STRINGによって指定されるかもしれません。 各タイプには、同等なp-STRING名があります。 これらは、主として上位互換性を維持するのに'タイプ'要素として互換性を持って使用されるかもしれません。

The second element of a p-EDT is always an p-INT, the
'version', and specifies the exact format of the particular
datum.  A semantic item may undergo several revisions of its
internal structure.  Which would be evident through assigning
different versions to each revision.

東部夏時間のpの2番目の要素は、いつもp-INT、'バージョン'であり、特定のデータの正確な形式を指定します。 意味項目は内部の構造のいくつかの改正を受けるかもしれません。 各改正に異なった見解を割り当てることで、明白です。

                                   -6-

-6-

Successive components.  The 'com' elements, if any.
carry the actual data of the semantic item.  As each
semantic item is defined, conventions on permissible values
and interpretation of these components are presented.  Such
definitions may use any types of items to specify the format
of the semantic item.  Use of lower level concepts, such as
objects, in these definitions is prohibited.

連続したコンポーネント。 もしあれば、運んでください。'com'要素、意味項目の実際のデータ。 それぞれの意味項目が定義されるとき、これらのコンポーネントの許容値と解釈でのコンベンションは提示されます。 そのような定義は、意味項目の形式を指定するのにどんなタイプの項目も使用するかもしれません。 これらの定義におけるオブジェクトなどの下のレベル概念の使用は禁止されています。

Semantic items will be printed as the mnemonic for the
type involved, preceded by the character pair "s-", to
signify that the data item is handled by this mechanism.

意味項目は、データ項目がこのメカニズムによって扱われるのを意味するように形質対「s」によって先行されたかかわったタイプのためのニーモニックとして印刷されるでしょう。

V.2 -- Printing Conventions

V.2--印刷コンベンション

A semantic item is represented as if it were a p-STRUC
containing only the components, if any, but preceded by the
semantic type name and a # character.  The version number is
assumed to be 1 if unspecified.  For later versions, the
version number is attached to the type name, as in, for
example, FILE-2 to represent version 2 of the FILE data
type.

意味項目は、まるでそれがもしあればコンポーネントだけを含むp-STRUCであるかのように表されますが、意味型名と#キャラクタによって先行されています。 不特定であるなら、バージョン番号は1であると思われます。 後のバージョンにおいて、バージョン番号は型名に付けられています、例えば、FILEデータ型のバージョン2を表すFILE-2のように。

For example, a semantic item called a 'file
specification' might be defined, containing two components,
a host number and pathname.  A specific instance of such an
item might appear as #FILE(69 "DIRECTORY.NAME-OF-FILE"),
while a generic s-FILE might be presented as the following.

例えば、2つのコンポーネント、ホスト番号、およびパス名を含んでいて、'ファイル仕様'と呼ばれる意味項目は定義されるかもしれません。 そのような項目の特定のインスタンスは#FILE(69「ファイルのDIRECTORY.NAME」)として現れるかもしれません、ジェネリックs-ファイルが以下として提示されるかもしれませんが。

#FILE(host:p-INT|p-STRING pathname:p-STRING)

#ファイル(パス名: p-ストリングをホスト:p-INT|pで結びます)

the item, which may be either a p-INT or p-STRING, and
'pathname' is the second component, which must be a
p-STRING.  The full definition would present interpretation
rules for these components.

項目、どれがp-INTかそれともp-STRINGのどちらかであるかもしれないか、そして、および'パス名'は2番目のコンポーネントです。(そのコンポーネントはp-STRINGであるに違いありません)。 完全な定義はこれらのコンポーネントのために解釈規則を提示するでしょう。

VI.  ENCODING OBJECTS

VI。 オブジェクトをコード化します。

This section presents the set of objects which are used
to represent items as byte streams for inter-server
transmission.  Objects will be presented using mnemonic
type-names preceded by the character pair "b-", indicating
their existence only as byte streams.

このセクションは相互サーバ送信のためのバイト・ストリームとして項目を表すのに使用されるオブジェクトのセットを寄贈します。 単にバイト・ストリームとしてそれらの存在を示して、形質対「b」によって先行された簡略記憶型名を使用することでオブジェクトを贈るでしょう。

All servers are required to be capable of decoding the
entire set of objects.  Servers are not required to transmit
certain objects which are available to improve channel
efficiency.

すべてのサーバが、全体のセットのオブジェクトを解読できるように必要です。 サーバは、経路効率を改良するために利用可能なあるオブジェクトを伝えるのに必要ではありません。

                               -7-

-7-

The encodings are designed to facilitate programming
and efficiency of the receiving decoder.  In all cases, the
type and length in bytes of objects is supplied as the first
information sent.  This characteristic is important for ease
of implementation.  The type information permits a decoder to
be constructed in a modular fashion.  The most important
advantage of including size information is that the receiver
always knows how many bytes it must read to discover what to
do next, and knows when each object terminates.  This
requirement avoids many potential problems with timing and
synchronization of processes.

encodingsは、受信デコーダのプログラミングと効率を容易にするように設計されています。 すべての場合では、最初の情報が発信したので、バイトのオブジェクトのタイプと長さを供給します。 実装の容易さに、この特性は重要です。 タイプ情報は、デコーダがモジュール方式で組み立てられることを許可します。 サイズ情報を含む最も重要な利点は受信機が、いつもそれが読んで聞かせなければならないいくつのバイトが、次に何をしたらよいかを発見するかを知っていて、各オブジェクトがいつ終わるかを知っているということです。 この要件はプロセスのタイミングと同期の多くの潜在的な問題を避けます。

Two varieties of objects are defined.  The first will
be called ATOMIC, and includes objects used to efficiently
encode the most common data.  The second variety is termed
NON-ATOMIC, and is used to encode larger or less common
items.

2つのバラエティーのオブジェクトは定義されます。 1番目は、ATOMICと呼ばれて、効率的に最も一般的なデータをコード化するのに使用されるオブジェクトを含んでいます。 2番目のバラエティーは、NON-ATOMICと呼ばれて、より大きいかそれほど一般的でない項目をコード化するのに使用されます。

In all cases, a data object begins with a single byte,
which will be termed the TYPE-BYTE, a field of which
contains the type code of the object.  The following bytes,
if any, are interpreted according to the type involved.

すべての場合では、データ・オブジェクトは1バイトで始まります。(それは、TYPE-BYTEと呼ばれるでしょう)。その分野はオブジェクトのタイプコードを含みます。 かかわったタイプに従って、もしあれば以下のバイトは解釈されます。

VI.1 -- Presentation Conventations

VI.1--プレゼンテーションConventations

In discussing formats of bytes, the following
conventions will be employed.  The individual bits of a byte
will be referenced by using capital letters from A to H,
where A signifies the highest order bit, and H the lowest.
The entire eight bit value, for example, could be referred
to as ABCDEFGH.  Similarly, subfields of the byte will be
identified by such sequences.  The CDEF field specifies the
middle four bits of a byte.

バイトの形式について議論する際に、以下のコンベンションは使われるでしょう。 Aが意味する中でオーダービット最も高いH、およびAからHまで最も低く大文字を使用することによって、1バイトの個々のビットは参照をつけられるでしょう。 例えば8ビットの全体の値をABCDEFGHと呼ぶことができました。 同様に、バイトの部分体はそのような系列によって特定されるでしょう。 CDEF分野は1バイトのミドルフォアビットを指定します。

In referring to values of fields, binary format will be
used, and small letters near the end of the alphabet will be
used to identify particular bits for discussion.  For
example, we might say that the BCD field of a byte contains
a specifier for some type, and define its value to be
BCD=11z.  In discussions of the specifier usage, we could
refer to the cases where z=l and where z=0, as shorthand
notation to identify BCD=111 and BCD=110, respectively.

分野の値について言及する際に、バイナリフォーマットは使用されるでしょう、そして、アルファベットの終わり頃の小文字は、議論のために特定のビットを特定するのに使用されるでしょう。 例えば、私たちは、1バイトのBCD分野がタイプのための特許説明書の作成書を含むと言って、BCD=11zになるように値を定義するかもしれません。 特許説明書の作成書用法の議論では、私たちはzがそれぞれBCD=111とBCD=110を特定するために簡単な表記法としてlとどこz=0と等しいケースを示すことができました。

V1.2 -- Type-Byte Bit Assignment

V1.2--タイプバイトビット課題

To assist in understanding the assignment of the
various type-byte values, the table and graph below are
included, showing representations of the eight bits.

以下の様々なタイプバイト値、テーブル、およびグラフの課題を理解しているのを助けるのは含まれています、8ビットの表現を示して。

                               -8-

-8-

OXXXXXXX -- CHAR7 (CHARacter, 7 bit)
10XXXXXX -- SINTEGER (Small INTEGER)
l10XXXXX -- NON-ATOM (NON-ATOMic objects)
11100XXX -- LINTEGER (Large INTEGER)
11101XXX -- reserved
11110XXX -- SBITSTR (Short BIT STReam)
111110XX -- XTRA (eXTRA single-byte objects)
1111110X -- BOOL (BOOLean)
11111110 -- EMPTY (EMPTY data item)
11111111 -- PADDING (unused byte)

OXXXXXXX--CHAR7(CHARacter、7は噛み付いた)10XXXXXX--SINTEGER(小さいINTEGER)l10XXXXX--NON-ATOM(NON-ATOMicオブジェクト)11100XXX--LINTEGER(大きいINTEGER)11101XXX--予約された11110XXX--SBITSTR(短いBIT STReam)111110XX--XTRA(eXTRA単一のバイトオブジェクト)1111110X--ブール(BOOLean)11111110--EMPTY(EMPTYデータ項目)11111111--PADDING(未使用のバイト)

In each case, the bits identified by X's are used to
contain information specific to the type involved.  These
are explained when each type is defined.

その都度、Xのものによって特定されたビットは、かかわったタイプに、特定の情報を含むのに使用されます。 各タイプが定義されるとき、これらは説明されます。

An equivalent tree representation follows, for those
who prefer it.
start with high order bit
 |
 |
 |
 0-----0-----0-----0-----0-----0-----0-----0-----X
 |     |     |     |     |     |     |     |   PADDING
0|    0|    0|    0|    0|    0|    0|    0|
 |     |     |     |     |     |     |     |
 X     |     X     |     X     |     X     X
CHAR7  | NON-ATOM  |    BITS   |   BOOL   EMPTY
 (7)   |   (5)     |    (3)    |   (1)
       |        0| |           |
   SINTEGER        |          XTRA
      (6)          |           (2)
               LINTEGER
                  (3)

それを好む人のために同等な木の表現に続きます。高位のビットから始まってください。| | | 0-----0-----0-----0-----0-----0-----0-----0-----X| | | | | | | | 詰め物0| 0| 0| 0| 0| 0| 0| 0| | | | | | | | | X| X| X| X X CHAR7| 非原子| ビット| ブールEMPTYの(7)| (5) | (3) | (1) | 0| | | SINTEGER| XTRA(6)| (2) LINTEGER(3)

        Type-Byte Bit Assignment Scheme

タイプバイトビット課題体系

This picture is interpreted by entering at the top, and
taking the appropriate branch at each node to correspond to
the next bit of the type-byte, as it is scanned from left to
right.  When a type is assigned, the branch terminates with
an "X' and the name of the type of the object, with the
number of remaining bits in parentheses.  The individual
object definitions specify how these bits are used for that
particular type.

この画像はタイプバイトの次のビットに相当するのに先端で入って、各ノードで適切なブランチを要することによって、解釈されます、それが左から右までスキャンされるとき。 'タイプが選任されるとき、ブランチは「X'とオブジェクトのタイプの名前で終わります、残っているビットの数が括弧にある状態で」。 個々のオブジェクト定義はこれらのビットがその特定のタイプにどう使用されるかを指定します。

V1.3 -- Atomic Objects

V1.3--原子オブジェクト

Atomic objects are identified by specific patterns in a
type-byte.  Receiving servers must be capable of recognizing

原子オブジェクトはタイプバイトにおける特定のパターンによって特定されます。 サーバが認識できなければならない受信

                               -9-

-9-

and handling all atomic types, since the size of the object
is not explicitly present in a uniform fashion.

そして、オブジェクトのサイズが一定のファッションで明らかに存在していないので、すべての原子タイプを扱うこと。

================================
| Atomic Object: B-CHAR7       |
================================

================================ | 原子オブジェクト: B-CHAR7| ================================

The b-CHAR7 (CHARacter 7 bit) object is introduced to
handle transmission of characters, in 7-bit ASCII format.
Since the vast majority of message-related data involves
such objects, they are designed to be very efficient in
transmission.  Other formats, such as eight bit values, can
be introduced as non-atomic objects.  The format of a b-CHAR7
follows:

7ビットのASCII書式における、キャラクタの遺伝を扱うためにb-CHAR7(CHARacter7は噛み付いた)オブジェクトを導入します。 かなりの大多数のメッセージ関連のデータがそのようなオブジェクトにかかわるので、それらはトランスミッションで非常に効率的になるように設計されています。 非原子のオブジェクトとして8ビットの値などの他の形式を導入できます。 b-CHAR7の形式は続きます:

A=0 identifying the b-CHAR7 data type
BCDEFGH=tuvwxyz containing the character
code

キャラクタコードを含むb-CHAR7データ型BCDEFGH=tuvwxyzを特定するA=0

The tuvwxyz objects contain the ASCII code of the
character.  For example, transmission of a "space' (ASCII
code 32, 40 octal) would be accomplished by the following
byte.

tuvwxyzオブジェクトはキャラクタのASCIIコードを含んでいます。 '例えば、「スペース'(ASCIIコード32、40 8進)のトランスミッションは以下のバイトによって実行されるでしょう」。

00100000
ABCDEFGH

00100000 ABCDEFGH

A=0 to identify this byte as a b-CHAR7.  The remaining
bits contain the 7 bit code, octal 40, for space.

このバイトがb-CHAR7であると認識するA=0。 残っているビットは7ビット・コード、スペースへの8進40を含んでいます。

A b-CHAR7 standing alone is presented as a p-CHAR.
Such occurrences will probably be rare if they are used at
all.  The most common use of b-CHAR7's is as elements of
b-USTRUCs used to transmit p-STRINGS, as explained later.

p-CHARとして単独で立つb-CHAR7を寄贈します。 それらが少しでも使用されるなら、そのような発生はたぶんまれになるでしょう。 p-STRINGSを伝えるのに後で説明されるように使用されるb-USTRUCsの要素としてb-CHAR7のものの最も一般の使用があります。

=============================
| Atomic Object: B-SINTEGER |
=============================

============================= | 原子オブジェクト: B-SINTEGER| =============================

The b-SINTEGER (Small INTEGER) object is used to
transmit very small positive integers, of values up to 64.
It always translates to an p-INT, and any p-INT between 0
and 63 may be encoded as a b-SINTEGER for transmission.  The
format of an b-SINTEGER follows.

b-SINTEGER(小さいINTEGER)オブジェクトは、値の非常にわずかな正の整数を64まで伝えるのに使用されます。 それはいつもp-INTに翻訳されます、そして、0と63の間のどんなp-INTもトランスミッションのためのb-SINTEGERとしてコード化されるかもしれません。 b-SINTEGERの形式は続きます。

AB=10 identifying the object as a b-SINTEGER
CDEFGH=uvwxyz containing the actual number

オブジェクトが実数を含むb-SINTEGER CDEFGH=uvwxyzであると認識するAB=10

For example, to transmit the integer 10 (12 octal), the
following byte would be transmitted:

例えば、整数10(12 8進)を伝えるために、以下のバイトは伝えられるでしょう:

10001010
ABCDEFGH

10001010 ABCDEFGH

                               -10-

-10-

AB=10 to specify a b-SINTEGER.  The remaining six bits
contain the number 10 expressed in binary.

b-SINTEGERを指定するAB=10。 残っている6ビットはバイナリーで表されたNo.10を含んでいます。

=============================
| Atomic Object: B-SINTEGER |
=============================

============================= | 原子オブジェクト: B-SINTEGER| =============================

The b-SINTEGER (Large INTEGER) object is used to
transmit p-INTs to any precision up to 64 bits.  It is
always translated as a p-INT.  Sending servers are permitted
to choose either b-SINTEGER or b-SINTEGER format for
transmission of numbers, as appropriate.  When possible,
b-SINTEGERs can be used for better channel efficiency.  The
format of a b-SINTEGER follows:

b-SINTEGER(大きいINTEGER)オブジェクトは、どんな精度にもp-INTsを64ビットまで伝えるのに使用されます。 それはp-INTとしていつも翻訳されます。 送付サーバが適宜数の送信のためのb-SINTEGERかb-SINTEGER形式のどちらかを選ぶことが許可されています。 可能であるときに、より良い経路効率にb-SINTEGERsを使用できます。 b-SINTEGERの形式は続きます:

ABCDE=11100 specifying that this is a b-SINTEGER.
FGH=xyz containing a count of number of bytes to follow.

これがb-SINTEGERであると指定するABCDE=11100。 続くバイト数のカウントを含むFGH=xyz。

The xyz bits are interpreted as a number of bytes to
follow which contain the actual binary code of the the
integer in 2's complement format.  Since a zero-byte integer
is disallowed, the pattern xyz=000 is interpreted as 1000,
specifying that 8 bytes follow.  The number is transmitted
with high-order bits first.  This format permits
transmission of integers as large as 64 bits in magnitude.

2における整数の実際の2進コードを含む続く多くのバイトが形式の補足となるとき、xyzビットは解釈されます。 無バイト整数が禁じられるので、8バイトが続くと指定して、パターンxyz=000は1000として解釈されます。 数は最初に、高位のビットで伝えられます。 この形式は大きさ64ビットと同じくらい大きい整数の送信を可能にします。

For example, if the number 4096 (10000 octal) is to be
transmitted, the following sequence of bytes would be sent:

例えば、No.4096(10000 8進)が伝えることであるなら、バイトの以下の系列を送るでしょう:

11100010 00010000 00000000
ABCDEFGH ---actual data---

11100010 00010000 00000000ABCDEFGH---実際のデータ---

ABCDE=11100, identifying this as a b-LINTEGER, E=0,
specifying a positive number, and FGH=010, specifying that 2
bytes follow, containing the actual binary number.

これがb-LINTEGERであると認識して、Eは0、正の数を指定して、およびFGH=010と等しいです、2バイトが続くと指定して、ABCDE=11100、実際の2進の数を含んでいて。

============================
| Atomic Object: B-SBITSTR |
============================

============================ | 原子オブジェクト: B-SBITSTR| ============================

The b-SBITSTR (Short BIT STReam) object is used to
transmit a p-BITS of length 63 or less.  For longer bit
streams, the non-atomic object b-LBITSTR may be used.  The
format of a b-SBITSTR follows.

b-SBITSTR(短いBIT STReam)オブジェクトは、長さの63以下のp-BITSを伝えるのに使用されます。 より長いビットストリームのために、非原子のオブジェクトb-LBITSTRは使用されるかもしれません。 b-SBITSTRの形式は続きます。

ABCDE=11110 specifying the type as b-SBITSTR
FGH=xyz specifying the number of bytes
following.

続いて、バイト数を指定するb-SBITSTR FGH=xyzとしてタイプを指定するABCDE=11110。

                               -11-
The xyz value specifies the number of additional bytes
to be read to obtain the bit stream values.  As in the case
of b-SINTEGER, the value xyz=000 is interpreted as 1000,
specifying that 8 bytes follow.

-11 -xyz値は、ビットストリーム値を得るために読まれるために追加バイトの数を指定します。 b-SINTEGERに関するケースのように、8バイトが続くと指定して、値のxyz=000は1000として解釈されます。

To avoid requiring specification of exactly the number
of bits contained, the following convention is used.  The
first data byte is scanned from left to right until the
first 1 bit is encountered.  The bit stream is defined to
begin with the immediately following bit, and run through
the last bit of the last byte read.  In other words, the bit
stream is 'right-adjusted' in the collected bytes, with its
left end delimited by the first "on' bit.

ちょうど含まれたビット、以下のコンベンションの数の仕様を必要とするのを避けるのは使用されています。 最初の1ビットが遭遇するとき、最初のデータ・バイトは左から右までスキャンされます。 ビットストリームは初めに定義されて、すぐに次のが噛み付いて、最後のバイトの最後のビットを通した走行が読んだということです。 '言い換えれば、ビットストリームは集まっているバイトで'まさしく調整されています'、左の終わりが1日までに「'ビット」に区切られている状態で。

For example, to send the bit stream *001010011* (9
bits), the following bytes are transmitted.

*例えば、ビットストリーム*001010011を送るために、(9ビット)以下のバイトは伝えられます。

11110010 00000010 01010011
ABCDEhij klmnopqr stuvwxyz

11110010 00000010 01010011ABCDEhij klmnopqr stuvwxyz

The hij=010 value specifies that two bytes follow.  The
q bit, which is the first 1 bit encountered, identifies the
start of the bit stream as being the r bit.  The rstuvwxyz
bits are the bit stream being handled.

hij=010値は、2バイトが続くと指定します。 qビット(遭遇する最初の1ビットである)はrビットであるとしてビットストリームの始まりを特定します。 rstuvwxyzビットは扱われるビットストリームです。

=========================
| Atomic Object: b-BOOL |
=========================

========================= | 原子オブジェクト: b-ブール| =========================

The b-BOOL (BOOLean) object is used to transmit
p-BOOLs.  The format of b-BOOL objects follows.

b-ブール(BOOLean)オブジェクトは、p-BOOLsを伝えるのに使用されます。 b-ブールオブジェクトの形式は続きます。

ABCDEFG=1111110 specifying the type as
b-BOOL
H=z specifying the value

値を指定するb-ブールH=zとしてタイプを指定するABCDEFG=1111110

The two possible translations of a b-BOOL are *FALSE*
and *TRUE*.

b-ブールの2つの可能な翻訳が、*FALSE*と*TRUE*です。

11111100 represents *FALSE*
11111101 represents *TRUE*
ABCDEFGz

11111100が表す、*FALSE*11111101は*TRUE*ABCDEFGzを表します。

if z=0, the value is FALSE, otherwise TRUE.

そうでなければ、z=0であるなら、値はFALSE、TRUEです。

========================================
| Atomic Object: B-EMPTY |
========================================

======================================== | 原子オブジェクト: B空です。| ========================================

The b-EMPTY object type is used to transmit a 'null'
object, i.e. an *EMPTY*.  The format of an b-EMPTY follows.

b-EMPTYオブジェクト・タイプは、すなわち、'ヌル'のオブジェクト、*EMPTY*を伝えるのに使用されます。b-EMPTYの形式は続きます。

ABCDEFGH=11111110 specifying *EMPTY*

ABCDEFGH=11111110指定*EMPTY*

                                -12-
=========================
| Atomic Object: B-XTRA |
=========================

-12- ========================= | 原子オブジェクト: B-XTRA| =========================

The b-XTRA objects are used to carry the four possible
p-XTRA items, i.e., *XTRA0*, *XTRA1*, *XTRA2*, and *XTRA3*.
These four items correspond to the binary coding of the
remaining two bits after the b-XTRA type code bits.  The
format of a b-XTRA follows.

b-XTRAオブジェクトは、すなわち、4つの可能なp-XTRAの品目、*XTRA0*、*XTRA1*、*XTRA2*、および*XTRA3*を運ぶのに使用されます。b-XTRAがコードビットをタイプした後にこれらの4つの項目が残っている2ビットの2進のコード化に対応しています。 b-XTRAの形式は続きます。

ABCDEF=111110 to specify the type b-XTRA
GH=yz to identify the particular p-XTRA item
carried

特定のp-XTRAの品目を特定するためにタイプb-XTRA GH=yzを指定するABCDEF=111110は運びました。

The GH bits of the byte are decoded to produce a
particular p-XTRA item, as follows.

バイトのGHビットは、以下の特定のp-XTRAの品目を生産するために解読されます。

GH=00 -- *XTRA0*
GH=01 -- *XTRA1*
GH=10 -- *XTRA2*
GH=11 -- *XTRA3*

ギガヘルツ=00--*XTRA0*ギガヘルツ=01--*XTRA1*ギガヘルツ=10--*XTRA2*ギガヘルツ=11--*XTRA3*

The b-XTRA object is included to provide the use of
several single-byte data items to higher levels.  These
items may be assigned by individual applications to improve
the efficiency of transmission of several very frequent data
items.  For example, the message services protocols will use
these items to convey positive and negative acknowledgments,
two very common items in every interaction.

b-XTRAオブジェクトは、いくつかの単一のバイトデータ項目の使用をより高いレベルに提供するために含まれています。 これらの項目は、いくつかの非常に頻繁なデータ項目の送信の効率を高めるために個々のアプリケーションで割り当てられるかもしれません。例えば、メッセージサービスプロトコルは、あらゆる相互作用で肯定的・否定的な承認、2個の非常に一般的な商品を伝えるのにこれらの項目を使用するでしょう。

========================================
| Atomic Object: B-PADDING
========================================

======================================== | 原子オブジェクト: B-詰め物========================================

This object is anomalous, since it represents really no
data at all.  Whenever it is encountered in a byte stream in
a position where a type-byte is expected, it is completely
ignored, and the succeeding byte examined instead.  Its
purpose is to serve as a filler in byte streams, providing
servers with an aid in handling internal problems related to
their specific word lengths, etc.  The encoders may freely
use this object to serve as padding when necessary.

本当にデータを全く表さないので、このオブジェクトは変則的です。 タイプバイトが予想されて、それが完全に無視される位置でのバイト・ストリーム、および代わりに調べられた続くバイトで遭遇するときはいつも。 目的はフィラーとしてバイト・ストリームで機能することです、それらの特定の語長などに関連する内部の問題を取り扱いにおける援助があるサーバに提供して エンコーダは、必要であるときにそっと歩くとして機能するのに自由にこのオブジェクトを使用するかもしれません。

All b-PADDING data objects exist only within an encoded
byte stream.  They never cause any data item whatsoever to
be presented externally to the coder module.  The format of a
b-PADDING follows.

すべてのb-PADDINGデータ・オブジェクトがコード化されたバイト・ストリームだけの中に存在しています。 彼らは全くどんなデータ項目も符号化器モジュールに決して外部的に提示させません。 b-PADDINGの形式は続きます。

ABCDEFGH=11111111

ABCDEFGH=11111111

Note that this does not imply that all such 'null'
bytes in a stream are to be ignored, since they could be
encountered as a byte within some other type, such as
b-LINTEGER.  Only bytes of this format which, by their
position in the stream, appear as a 'type' byte are to be
ignored.

これが、ストリームにおけるそのようなすべての'ヌル'のバイトがそうであることを含意しないことに注意して、1バイトとして遭遇できたので、b-LINTEGERなどのある他のタイプの中で無視されてください。 'タイプ'バイトとしてストリームにおけるそれらの位置に現れるこの形式の唯一のバイトは無視されることです。

                                -13-
VI.4 -- Non-Atomic Objects

-13VI.4--非原子のオブジェクト

Non-atomic objects are are always transmitted preceded
by both a single type byte and some small number of size
byte(s).  The type byte identifies that the data object
concerned is of a non-atomic type, as well as uniquely
specifying the particular type involved.  All non-atomic
objects have type byte values of the following form.

非原子の目的はそうです。1タイプバイトと何らかの少ない数のサイズバイトの両方が先行して、いつも伝えられます。 タイプバイトは、データ当該目的物が非原子のタイプ、および唯一特定のタイプがかかわった指定のものであることを特定します。 すべての非原子のオブジェクトで、以下のタイプバイト値は形成されます。

ABC=110 specifying that the object is
non-atomic
DEFGH=vwxyz specifying the particular type
of object

オブジェクトが特定のタイプのオブジェクトを指定する非原子のDEFGH=vwxyzであると指定するABC=110

The vwxyz value is used to specify one of 31 possible
non-atomic types.  The value vwxyz=00000 is reserved for use
in future expansion.

vwxyz値は、31の可能な非原子のタイプのひとりを指定するのに使用されます。 値のvwxyz=00000は今後の拡張における使用のために予約されます。

In all non-atomic data objects, the byte(s) following
the type-byte specify the number of bytes to follow which
contain the data object.  In all cases, if the number of
bytes specified are processed, the next byte to be seen
should be another type-byte, the beginning of the next
object in the stream.

すべての非原子のデータ・オブジェクトでは、タイプバイトに続くバイトはデータ・オブジェクトを含む続くバイト数を指定します。 すべての場合では、指定されたバイト数が処理されるなら、探して、次のバイトはもう1タイプバイトであるべきです、ストリームにおける次のオブジェクトの始まり。

The number of bytes containing the object size
information is variable.  These bytes will be termed the
SIZE-BYTES.  The first byte encountered has the following
format.

オブジェクトサイズ情報を含むバイト数は可変です。 これらのバイトはSIZE-BYTESと呼ばれるでしょう。 遭遇する最初のバイトは以下の形式を持っています。

A=s specifying the manner in which the size
information is encoded
BCDEFGH=tuvwxyz specifying the size, or
number of bytes containing the size

サイズ情報がサイズを指定するコード化されたBCDEFGH=tuvwxyz、またはサイズを含むバイト数である方法を指定するA=s

The tuvwxyz values supply a positive binary number.  If
the s value is a one, the tuvwxyz value specifies the number
of bytes to follow which should be read and concatenated as
a binary number, which will then specify the size of the
object.  These bytes will appear with high order bits first.
Thus, if s=1, up to 128 bytes may follow, containing the
count of the succeeding data bytes, which should certainly
be sufficient.

tuvwxyz値は正の2進の数を供給します。 s値が1つであるなら、tuvwxyz値は続く2進の数として読まれて、連結されるべきであるバイト数を指定します。次に、数はオブジェクトのサイズを指定するでしょう。 これらのバイトは最初に、高位のビットと共に現れるでしょう。 したがって、最大128バイトはs=1であるなら、続くかもしれません、続く確かに、十分であるべきデータ・バイトのカウントを含んでいて。

Since many non-atomic objects will be fairly short, the
s=0 condition is used to indicate that the 7 bits contained
in tuvwxyz specify the actual data byte count.  This permits

多くの非原子のオブジェクトがかなり脆くなるので、s=0状態はtuvwxyzに含まれた7ビットが実際のデータバイト・カウントを指定するのを示すのに使用されます。 これは可能にします。

objects of sizes up to 128 bytes to be specified using one
size-information byte.  The case tuvwxyz=0000000 is
interpreted as specifying 128 bytes.

最大128バイトの1サイズ情報バイトを使用することで指定されるべきサイズのオブジェクト。 ケースtuvwxyz=0000000は、128バイトを指定しながら、解釈されます。

For example, a data object of some non-atomic type
which requires 100 (144 octal) bytes to be transmitted would
be sent as follows.

例えば、以下の通り100(144 8進)バイトが伝えられるのを必要とする非原子のタイプのデータ・オブジェクトを送るでしょう。

                                -14-

-14-

110XXXXX -- identifying a specific
non-atomic object
01100100 -- specifying that 100 bytes follow
.
.
data -- the 100 data bytes
.
.

110XXXXX--特定の非原子のオブジェクト01100100--尾行データをその100バイト指定します--100データ・バイトを特定します。

Note that the size count does not include the
size-specifier byte(s) themselves, but does include all
succeeding bytes in the stream used to encode the object.

サイズカウントがサイズ特許説明書の作成書バイト自体を含んでいませんが、オブジェクトをコード化するのに使用されるストリームに続くすべてのバイトを含んでいることに注意してください。

A data object requiring 20000 (47040 octal) bytes would
appear in the stream as follows.

20000(47040 8進)バイトを必要とするデータ・オブジェクトは以下のストリームに現れるでしょう。

110XXXXX -- identifying a specific
non-atomic object
10000010 -- specifying that the next 2 bytes
contain the stream length
01001110 -- first byte of number 20000
00100000 -- second byte
.
.
data -- 20,000 bytes
.
.

特定の非原子のオブジェクト10000010を特定するというそれを次の2バイト指定する110XXXXXがストリーム長さ01001110--数2番目のバイトデータの最初のバイト--2万バイトを含んでいます。

Interpretation of the contents of the 20000 bytes in
the stream can be performed by a module which knows the
specific format of the non-atomic type specified by DEFGH in
the type-byte.

タイプバイトでDEFGHによって指定された非原子のタイプの特定の書式を知っているモジュールでストリームにおける、20000バイトのコンテンツの解釈を実行できます。

The remainder of this section defines an initial set of
non-atomic types, the format of their encoding, and the
semantics of their interpretation.

このセクションの残りは1人の始発の非原子のタイプ、彼らのコード化の形式、および彼らの解釈の意味論を定義します。

================================
| Non-atomic Object: B-LBITSTR |
================================

================================ | 非原子のオブジェクト: B-LBITSTR| ================================

The b-LBITSTR (Long BIT Stream) data type is introduced
to transmit p-BITS which cannot be handled by a b-SBITSTR.
A b-LBITSTR may be used to transmit short p-BITS as well.
Its format follows.

b-LBITSTR(長いBIT Stream)データ型は、b-SBITSTRが扱うことができないp-BITSを伝えるために紹介されます。 b-LBITSTRは、また、短いp-BITSを伝えるのに使用されるかもしれません。 形式は続きます。

                                -15-

-15-

11000001 size-bytes data-bytes
ABCDEFGH

11000001 サイズ-バイトデータ・バイトABCDEFGH

ABC=110 identifies this as a non-atomic object.
DEFGH=00001 specifies that it is a b-LBITSTR.  The standard
sizing information specifies the number of succeeding bytes.
Within the data-bytes, the first object encountered must
decode to a p-INT.  This number conveys the length of the
bit stream to follow.  The actual bit stream begins with the
next byte, and is left-adjusted in the byte stream.  For
example to encode *101010101010*, the following b-LBITSTR
could be used, although a b-SBITSTR would be more compact.

ABC=110は、これが非原子のオブジェクトであると認識します。 DEFGH=00001は、それがb-LBITSTRであると指定します。 情報を大きさで分ける規格は続くバイトの数を指定します。 データ・バイトの中では、遭遇する最初のオブジェクトはp-INTに解読しなければなりません。 この数は、続くようにビットストリームの長さを伝えます。 実際のビットストリームは、次のバイトで始まって、左でバイト・ストリームで調整されています。 *例えば*101010101010をコード化するために、b-SBITSTRは、よりコンパクトでしょうが、以下のb-LBITSTRを使用できました。

11000001 -- identifies a b-LBITSTR
00000010 -- b-SINTEGER, to specify length
10001100 -- size = 2
10101010 -- first 8 data bits
10100000 -- last 4 data bits

11000001--b-LBITSTR00000010は特定します--、b-SINTEGER、長さ10001100を指定するために--サイズが等しい、2、10101010、--最初の8データ・ビット10100000--ベスト4データ・ビット

==============================
| Non-atomic Object: B-STRUC |
==============================

============================== | 非原子のオブジェクト: B-STRUC| ==============================

The b-STRUC (STRUCture) data type is used to transmit
any p-STRUC.  The translation rules for converting a b-STRUC
into a primitive item are presented following the discussion
of b-REPEATs.  The b-STRUC format appears as follows.

b-STRUC(STRUCture)データ型は、どんなp-STRUCも伝えるのに使用されます。 b-REPEATsの議論に続いて、原始の項目にb-STRUCを変換するための翻訳規則は提示されます。 b-STRUC形式は以下の通りに見えます。

11000010 size-bytes data-bytes
ABCDEFGH

11000010 サイズ-バイトデータ・バイトABCDEFGH

ABC=110 identifies this as a non-atomic type.
DEFGH=00010 specifies that the object is a b-STRUC.  Within
the data-bytes stream, objects simply follow in order.  This
implies that the b-STRUC encoder and decoder modules can
simply make use of recursive calls to a standard
encoder/decoder for processing each element of the b-STRUC.

ABC=110は非原子のタイプとしてこれを特定します。 DEFGH=00010は、物がb-STRUCであると指定します。 データ・バイトの流れの中では、物は単に整然とした状態で従います。 これは、b-STRUCエンコーダとデコーダモジュールが単にb-STRUCの各要素を処理するための標準のエンコーダ/デコーダに再帰的呼び出しを利用できるのを含意します。

Note that any type of object is permitted as an element of a
b-STRUC, but the size information of the b-STRUC must
include all bytes used to represent the elements.

どんなタイプの物もb-STRUCの要素として受入れられますが、b-STRUCの情報がすべてのバイト含まなければならないサイズが以前はよく要素を表していたことに注意してください。

Containment of b-STRUCs within other b-STRUCs is
permitted to any reasonable level.  That is, a b-STRUC may
contain as an element another b-STRUC, which contains
another b-STRUC, and so on.  All servers are requires to
handle such containment to at least a minimum depth of
three.

他のb-STRUCsの中のb-STRUCsの封じ込めはどんな妥当な水準にも受入れられます。 すなわち、b-STRUCは要素として別のb-STRUCなどを含むかもしれません。(b-STRUCは別のb-STRUCを含みます)。 すべてのサーバがそうです。少なくとも3の最小の深さにそのような封じ込めを扱うのが必要です。

Examples of encoded structures appear in a later
section.

コード化された構造に関する例は後のセクションに現れます。

                                -16-
============================
| Non-atomic Object: B-EDT |
============================

-16- ============================ | 非原子の物: 東部夏時間のB| ============================

A b-EDT is the object used as the carrier for p-EDTs in
transmission of semantic items.  It is functionally
identical to a b-STRUC, but has a different type code to
permit it to be identified and converted to a semantic item
instead of a p-STRUC.  The format of a b-EDT follows.

東部夏時間のbは意味項目のトランスミッションでp-EDTsにキャリヤーとして使用される物です。それには、b-STRUCと機能上同じですが、それがp-STRUCの代わりに意味項目に特定されて、変換されることを許可する異なったタイプコードがあります。 東部夏時間のbの形式は続きます。

11000011 size-bytes data-bytes
ABCDEFGH

11000011 サイズ-バイトデータ・バイトABCDEFGH

As with all non-atomic types, ABC=110 to identify this
as such, and DEFGH=00011 to specify a b-EDT.  The objects in
the data-bytes are decoded as for b-STRUCs.  However, the
first object must decode to a p-iNT or p-STRING and the
second to a p-INT, to conform to the format of p-EDTs.

すべての非原子のタイプ、そういうものとしてこれを特定するABC=110、および東部夏時間のbを指定するDEFGH=00011のように。 データ・バイトにおける物はb-STRUCsのように解読されます。 しかしながら、最初の物は、p-EDTsの形式に従うためにp-INTへのp-iNTかp-STRINGと2番目に解読しなければなりません。

===============================
| Non-atomic Object: b-REPEAT |
===============================

=============================== | 非原子の物: b-反復| ===============================

The b-REPEAT object is never translated directly into
an item.  It is legal only as an component of an enclosing
b-STRUC, b-USTRUC, b-EDT, or b-REPEAT.  A b-REPEAT is used to
concisely specify a set of elements to be treated as if they
appeared in the enclosing structure in place of the
b-REPEAT.  This provides a mechanism for encoding a sequence
of identical data items or patterns efficiently for
transmission.

b-REPEAT物は直接項目に決して翻訳されません。 それは単に同封b-STRUC、b-USTRUC、東部夏時間のb、またはb-REPEATの部品として法的です。 b-REPEATは、まるで同封構造にb-REPEATに代わって現れるかのように扱われるために1セットの要素を簡潔に指定するのに使用されます。 これはトランスミッションのために効率的に同じデータ項目かパターンの系列をコード化するのにメカニズムを提供します。

A common example of this would be in transmission of
text, where line images containing long sequences of spaces,
or pages containing multiple carriage-return, line-feed
pairs, are often encountered.  Such sequences could be
encoded as an appropriate b-REPEAT to compact the data for
transmission.  The format of a b-REPEAT is as follows.

この一般的な例はテキストの送信中でしょう。(そこでは、空間の長いひと続きの出来事、または複数の復帰を含むページを含む線イメージ(改行組)がしばしば遭遇します)。 トランスミッションのためのデータを圧縮するために適切なb-REPEATとしてそのような系列をコード化できました。 b-REPEATの形式は以下の通りです。

11000100   -- identifyIng the object as a
                b-REPEAT
size-bytes -- the standard non-atomic object
                size information
countspec  -- an object which translates to a p-INT
.
.
data -- the objects which define the pattern
.
.

11000100 --identifyIng、b-REPEATサイズ-バイトとしての物--標準の非原子の物のサイズ情報countspec--p-INTデータに翻訳される物--パターンを定義する物。

The 'countspec' object must translate to an p-INT to
specify the number of times that the following data pattern
should be repeated in the object enclosing the b-REPEAT.

'countspec'物は、以下のデータパターンがb-REPEATを同封しながら物で繰り返されるべきであるという回の数を指定するためにp-INTに翻訳されなければなりません。

                                -17-

-17-

The remaining objects in the b-REPEAT constitute the
data pattern which is to be repeated.  The decoding of the
enclosing structure will be continued as if the data pattern
objects appeared 'countspec' times in place of the b-REPEAT.
Zero repeat counts are permitted, for generality.  They
cause no objects to be simulated in the enclosing structure.

b-REPEATの残っている物は繰り返されることであるデータパターンを構成します。 まるでデータパターン物がb-REPEATに代わって'countspec'倍現れるかのように同封構造の解読は続けられるでしょう。 繰返し回数は全く一般性のために受入れられません。 彼らは同封構造で物を全くシミュレートさせません。

An encoder does not have to use b-REPEATs at all, if
simplicity of coding outweighs the benefits of data
compression.  In message services, for example, an encoder
might limIt itself to only compressing long text strings.  It
is important for compatibility, however, to have the ability
in the decoders to handle b-REPEATs.

コード化の簡単さがデータ圧縮の利益より重いなら、エンコーダは全くb-REPEATsを使用する必要はありません。 メッセージサービスでは、例えば、エンコーダは長いテキスト文字列を圧縮するだけのlimIt自身がそうするかもしれません。 しかしながら、互換性に、b-REPEATsを扱うデコーダの能力を持っているのは重要です。

===============================
| Non-atomic Object: B-USTRUC |
===============================

=============================== | 非原子の物: B-USTRUC| ===============================

The b-USTRUC (Uniform Structure) object type is
provided to enable servers to convey the fact that a p-STRUC
being transferred contains items of only a single type.  The
most common example would involve a b-USTRUC which
translates to a p-STRUC of only p-CHARs, and hence may be
considered to be a p-STRING.  Servers may use this
information to assist them in decoding objects efficiently.
No server is required to generate b-USTRUCs.

サーバが移されるp-STRUCが単独のタイプだけの項目を含んでいるという事実を伝えるのを可能にするためにb-USTRUC(一定のStructure)オブジェクト・タイプを提供します。 最も一般的な例は、p-CHARsだけのp-STRUCに翻訳するb-USTRUCを伴って、したがって、p-STRINGであると考えられるかもしれません。 サーバは、効率的に解読物にそれらを助けるのにこの情報を使用するかもしれません。 サーバは、全くb-USTRUCsを発生させるのに必要ではありません。

The internal construction of a b-USTRUC is identical to
that of a b-STRUC, except for the type-byte.  The format of a
b-USTRUC follows.

b-USTRUCの内部の構造はタイプバイト以外のb-STRUCのものと同じです。 b-USTRUCの形式は続きます。

11000101 size-bytes data-bytes
ABCDEFGH

11000101 サイズ-バイトデータ・バイトABCDEFGH

ABC=110 to identify a non-atomic object.  DEFGH=00101
specifies the object as a b-USTRUC.

非原子の物を特定するABC=110。 DEFGH=00101はb-USTRUCとして物を指定します。

===============================
| Non-atomic Object: B-STRING |
===============================

=============================== | 非原子の物: B-ストリング| ===============================

The b-STRING object is included to permit explicit
specification of a structure as a p-STRING.  This
information will permit receiving servers to process the
incoming structure more efficiently.  A b-STRING is
formatted similarity to a b-USTRUC, except that its type-byte
identifies the object as a b-STRI/NG.  The normal sizing
information is followed by a stream of bytes which are
interpreted as b-CHAR7s, Ignoring the high-order bit.  The
format of a b-STRING follows.

b-STRING物は、p-STRINGとして構造の明白な仕様を可能にするために含まれています。 この情報は、より効率的に入って来る構造を処理するためにサーバを受け取ることを許可するでしょう。 タイプバイトが、物がb-STRI/NGであると認識するのを除いて、b-STRINGはb-USTRUCへのフォーマットされた類似性です。 b-CHAR7sとして解釈されるバイトの流れは情報を大きさで分ける標準のあとに続いていて、Ignoringは高位のビットです。 b-STRINGの形式は続きます。

11000110 size-bytes data-bytes
ABCDEFGH

11000110 サイズ-バイトデータ・バイトABCDEFGH

ABC=110 to identify a non-atomic object.  DEFGH=00110
specifies the object as a b-STRING.

非原子の物を特定するABC=110。 DEFGH=00110はb-STRINGとして物を指定します。

                                -18-

-18-

VI.5 -- Structure Translation Rules

VI.5--構造翻訳規則

A b-STRUC is translated into a p-STRUC.  This is
performed by translating each object of the b-STRUC Into its
corresponding item, and saving it for inclusion In the
p-STRUC being generated.  A b-USTRUC is handled similarly,
but the coding programs may utilize the information that the
resultant p-STRUC will contain items of uniform type.  The
preferred method of coding p-STRINGS is to use b-USTRUCs.

b-STRUCはp-STRUCに翻訳されます。 これは実行されます。b-STRUC Intoの各物を翻訳するのによる対応する項目と、発生する包含In p-STRUCのためにそれを貯蓄すること。 b-USTRUCは同様に扱われますが、コード化プログラムは結果のp-STRUCが一定のタイプの項目を含むという情報を利用するかもしれません。 p-STRINGSをコード化する適した方法はb-USTRUCsを使用することです。

If all of the elements of the resultant p-STRUC are
p-CHARs, it is presented to the user of the decoder as a
p-STRING.  A p-STRING should be considered to be a synonym
for a p-STRUC containing only characters.  It need not
necessarily exist at particular sites which would present
p-STRUCs of p-CHARs to their application programs

結果のp-STRUCの要素のすべてがp-CHARsであるなら、それはp-STRINGとしてデコーダのユーザに提示されます。 p-STRINGはキャラクタだけを含むp-STRUCのための同義語であると考えられるべきです。 それは必ずp-CHARsのp-STRUCsを彼らのアプリケーション・プログラムに寄贈する特定のサイトに存在しなければならないというわけではありません。

The object b-REPEAT is handled in a special fashion
when encountered as an element.  When this occurs, the data
pattern of the b-REPEAT is translated into a sequence of
items, and that sequence is repeated in the next higher
level as many times as specified in the b-REPEAT.
Therefore, b-REPEATS are legal only as elements of a
surrounding b-STRUC, b-USTRUC, b-EDT, or b-REPEAT.

要素として遭遇すると、物のb-REPEATは特別なファッションで扱われます。 これが起こるとき、b-REPEATのデータパターンは項目の系列に翻訳されます、そして、その系列はb-REPEATで指定される何回も次の、より高いレベルで繰り返されます。 したがって、b-REPEATSは単に周囲のb-STRUC、b-USTRUC、東部夏時間のb、またはb-REPEATの要素として法的です。

In encoding a p-STRUC or p-STRING for transmission, a
translator may use b-REPEATs as desired to effect data
compression, but their use is not mandatory.  Similarly,
b-STRINGS may be used, but are not mandatory.

トランスミッションのためにp-STRUCかp-STRINGをコード化するのにおいて、データ圧縮に作用することが望まれていて、翻訳者はb-REPEATsを使用するかもしれませんが、彼らの使用は義務的ではありません。 同様に、b-STRINGSは使用されるかもしれませんが、義務的ではありません。

A b-EDT is translated into a p-EDT to identify it as a
carrier for a semantic item.  Otherwise, it is treated
identically to a b-STRUC.

東部夏時間のbは、意味項目のためのキャリヤーとしてそれを特定するために東部夏時間のpに翻訳されます。 さもなければ、それは同様にb-STRUCに扱われます。

VI.6 -- Translation Summary

VI.6--翻訳概要

The following table summarizes the possible
translations between primitive items and objects.

以下のテーブルは原始の項目と物の間の可能な翻訳をまとめます。

p-INT    <--> b-LINTEGER, b-SINTEGER
p-STRING <--> b-STRING, b-STRUC, b-USTRUC
p-STRUC  <--> b-STRING, b-STRUC, b-USTRUC
p-BITS   <--> b=SBITSTR, b-LBITSTR
p-CHAR   <--> b-CHAR7
p-BOOL   <--> b-BOOL
p-EMPTY  <--> b=EMPTY
p-XTRA   <--> b-XTRA
p-EDT    <--> b-EDT (all semantic items)
-none-   <--> b-PADDING
-none-   <--> b-REPEAT (only within structure)

p-INT<--b-STRUC、b-USTRUC p-BITS<-->b=SBITSTR、b-LBITSTR p-CHAR<-->b-LINTEGER、b-SINTEGER p-STRING<-->b-STRING、b-STRUC、b-USTRUC p-STRUC<-->b-STRING、>b-CHAR7 p-ブール<-->b-ブールp-EMPTY<-->b=EMPTY p-XTRA<-->東部夏時間のb-XTRA p<--なにもの東部夏時間の>b(すべての意味項目)<--なにもの>b-PADDING<-->b-REPEAT(構造だけの中の)

Note that all semantic items are represented as p-EDTs
which always exist as b-EDTs in byte-stream format.

すべての意味項目がb-EDTsとしてバイト・ストリーム形式でいつも存在するp-EDTsとして表されることに注意してください。

                                -19-
V1.7 -- Structure Coding Examples

-19V1.7--構造コード化の例

The following stream transmits a b-STRUC containing 3
b-SINTEGERs, with values 1, 2, and 3, representing a p-STRUC
containing three p-INTs, i.e. (1 2 3).

以下の流れは3b-SINTEGERsを含むb-STRUCを伝えます、値1、2、および3で、3p-INTs(すなわち、(1 2 3))を含むp-STRUCを表して

11000010 -- b-STRUC
00000011 -- size=3
10000001 -- b-SINTEGER=1
10000010 -- b-SINTEGER=2
10000011 -- b-SINTEGER=3

11000010--b-STRUC00000011--サイズ=3 10000001--b-SINTEGER=1 10000010--b-SINTEGER=2 10000011--b-SINTEGER=3

The next example represents a b-STRUC containing the
characters X and Y, followed by the b-LINTEGER 10,
representing a p-STRUC of 2 p-CHARs and a p-INT, i.e., ('X'
'Y' 10).  Note that the p-INT prevents considering this a
p-STRING.

次の例はすなわち、2p-CHARsとp-INTのp-STRUCを表しながらb-LINTEGER10によって続かれたキャラクタXとYを含むb-STRUC('X''Y'10)を表します。 p-INTが、これがp-STRINGであると考えるのを防ぐことに注意してください。

11000010 -- b-STRUC
00000100 -- size=4
01011000 -- b-CHAR7 'X'
01011001 -- b-CHAR7 'Y'
11100001 -- b-LINTEGER
00001010 -- 10

11000010--b-STRUC00000100--サイズが等しい、4、01011000、--b-CHAR7'X'01011001--b-CHAR7'Y'11100001--b-LINTEGER00001010 -- 10

Note that a better way to send this p-STRUC would be to
represent the integer as a b-SINTEGER, as shown below.

このp-STRUCを送るより良い方法がb-SINTEGERとして整数を表すことであることに注意してください、以下に示すように。

11000010 -- b-STRUC
00000011 -- size=3
01011000 -- b-CHAR7 'X'
01011001 -- b-CHAR7 'Y'
10001010 -- b-SINTEGER=10

11000010--b-STRUC00000011--サイズが等しい、3、01011000、--b-CHAR7'X'01011001--b-CHAR7'Y'10001010--b-SINTEGER=10

The next example shows a b-STRUC of b-CHAR7s.  It is
the translation of the b-STRING "HELLO".

次の例はb-CHAR7sのb-STRUCを示しています。 それは「こんにちは」というb-STRINGに関する翻訳です。

11000010 -- b-STRUC
00000101 -- size=5
01001000 -- b-CHAR7 'H'
01000101 -- b-CHAR7 'E'
01001100 -- b-CHAR7 'L'
01001100 -- b-CHAR7 'L'
01001111 -- b-CHAR7 'O'

11000010--b-STRUC00000101--サイズが等しい、5、01001000、--b-CHAR7'H'01000101--b-CHAR7 01001100'E'(b-CHAR7'L'01001100)b-CHAR7'L'01001111--b-CHAR7'O'

This datum could also be transmitted as a b-STRING.
Note that the character bytes are not necessarily b-CHAR7s,
since the high-order bit is ignored.

また、b-STRINGとしてこのデータを伝えることができました。 高位のビットが無視されるので、キャラクタバイトが必ずb-CHAR7sであるというわけではないことに注意してください。

11000110 -- b-STRING
00000101 -- size=5
01001000 -- 'H'
01000101 -- 'E'
01001100 -- 'L'
01001100 -- 'L'
01001111 -- 'O'

11000110--b-STRING00000101--サイズが等しい、5、01001000、--'H'01000101--01001100'E'--'L'01001100--'L'01001111--'O'

                                -20-
To encode a p-STRING containing 20 carriage-return
line-feed pairs, the following b-STRUC containing a b-REPEAT
could be used.

-20 -20復帰改行組を含むp-STRINGをコード化するために、b-REPEATを含む以下のb-STRUCは使用できました。

11000010 -- b-STRUC
00000101 -- size=5
11000100 -- b-REPEAT
00000011 -- size=3
10010100 -- count, b-SINTEGER=20
00001101 -- b-CHAR7, "CR'
00001010 -- b-CHAR7, 'IF'

'11000010--b-STRUC00000101--サイズが等しい、5、11000100、--b-REPEAT00000011--サイズが等しい、3、10010100、--、b-SINTEGER=20 00001101(b-CHAR7、「CR'00001010)b-CHAR7、'IF'、数えてください」

To encode a p-STRUC of p-INTs, where the sequence
contains a sequence of thirty 0's preceded by a single 1,
the following b-STRUC could be used.

系列がシングルが先行した30 0の系列を含むp-INTsのp-STRUCをコード化するために、1、以下のb-STRUCを使用できました。

11000010 -- b-STRUC
00000110 -- size=6
10000001 -- b-SINTEGER=1
11000100 -- b-REPEAT
00000010 -- size=2
10011110 -- count, b-SINTEGER=30
10000000 -- b-SINTEGER=0

11000010--b-STRUC00000110--サイズが等しい、6、10000001、--、b-SINTEGER=1 11000100--b-REPEAT00000010--サイズが等しい、2、10011110、--カウント、b-SINTEGER=30 10000000--b-SINTEGER=0

VII. A GENERAL DATA TRANSFER SCHEME

VII。 一般データ転送計画

This section considers a possible scheme for extending
the concept of a data translator into an multi-purpose data
transfer mechanism.

このセクションは多目的のデータ転送メカニズムにデータ翻訳者の概念について敷衍することの可能な計画を考えます。

The proposed environment would provide a set of
primitive items, including those enumerated herein but
extended as necessary to accommodate a variety of
applications.  Communication between processes would be
defined solely in terms of these items, and would
specifically avoid any consideration of the actual formats
in which the data is transferred.

提案された環境は1セットの原始の商品を提供するでしょう、さまざまなアプリケーションを収容するためにここに列挙されますが、必要に応じて広げられたものを含んでいて。 過程のコミュニケーションは、唯一これらの項目で定義されて、明確にデータがわたっている実際の形式のどんな考慮も避けるでしょう。

A repertoire of translators would be provided, one of
which is the MSDTP machinery, for use in converting items to
any of a number of transmission formats.  Borrowing a
concept from radio terminology, each translator would be
analogous to a different type of modulation scheme, to be
used to transfer data through some communications medium.
Such media could be an eight-bit byte-oriented connection,
36-bit connection, etc.  and conceivably have other
distinguishing features, such as bandwidth, cost, and delay.
For each media which a site supports, it would provide its
programmers with a module for performing the translations
required.

翻訳者のレパートリーを提供するでしょう、MSDTP機械であるものの1つ、多くのトランスミッション形式のどれかに項目を変換することにおける使用のために。 ラジオ用語から概念を借りて、それぞれの翻訳者は、コミュニケーション媒体を通してデータを移すのに使用されるために異なったタイプの変調計画に類似しているでしょう。 そのようなメディアは、8ビットのバイト指向の接続、36ビットの接続であるなど、多分特徴が帯域幅などのようにかかる他の区別、および遅れを持つことができました。 それぞれに関しては、サイトが支持するメディアであり、それは必要である翻訳を実行するためのモジュールをプログラマに提供するでしょう。

                                -21-

-21-

Certain media or translators might not handle various
items.  For example, the MSDTP does not handle items which
might be termed p-FLOATs, p-COMPLEXs, p-ARRAY, and so on.  In
addition, the efficiency of various media for transfer of
specific items may differ drastically.  MSDTP, for example,
transfers data frequently used in message handling very
efficiently, but is relatively poor at transfer of very
large or deep tree structures.

あるメディアか翻訳者が様々な項目を処理しないかもしれません。例えば、MSDTPはp-FLOATs、p-COMPLEXs、p-ARRAYなどと呼ばれるかもしれない項目を扱いません。 さらに、特定の項目の転送のための様々なメディアの効率は抜本的に異なるかもしれません。 MSDTPは例えば、非常に効率的に頻繁にメッセージハンドリングに使用されるデータを移しますが、非常に大きいか深い木構造の転送で比較的貧しいです。

Available at each site as a process or subroutine
package wouLd be a module responsible for interfacing with
its counterpart at the other end of the media.  These
modules would use a protocol, not yet defined, to match
their capabilities, and choose a particular media and
translator, when more than one exists, for transfer of data
items.

過程かサブルーチンパッケージwouLdとして各サイトで利用可能であるのは、メディアのもう一方の端の対応者に連結するのに原因となるモジュールです。 これらのモジュールはまだ定義されているのではなく、彼らの能力を合わせて、特定のメディアと翻訳者を選ぶのにプロトコルを使用するでしょう、1つ以上が存在していると、データ転送項目のために。

Such a facility could totally insulate applications
from need to consider encoding formats, machine differences,
and so on, as well as eliminate duplication of effort in
producing such facilities for every new project which
requires them.  In addition, as new translators or media are
introduced, they would become immediately available to
existing users without reprogramming.

そのような施設はコード化形式、マシン差などを考えて、それらを必要とするあらゆる新しいプロジェクトのためにそのような施設を生産することにおける、努力の複製を排除する必要性からアプリケーションを完全に隔離するかもしれません。 さらに、新しい翻訳者かメディアを導入するのに従って、それらはすぐにプログラムを変えるのなしで既存のユーザにとって利用可能になるでしょう。

Implementation of such a protocol should not be very
difficult or time-consuming, since it need not be very
sophisticated in choosing the most appropriate transfer
mechanism in initial implementations.  The system is
inherently upward-compatible and easily expandable.

そのようなプロトコルの実現は、非常に難しいか、または手間がかかっているべきではありません、それが初期の実現で最も適切なトランスファ・メカニズムを選ぶ際にそれほど洗練されている必要はないので。 システムは、本来互換性があって上向きの容易に拡張可能です。

                                -22-

-22-

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

fontFamily

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る