RFC971 日本語訳
0971 Survey of data representation standards. A.L. DeSchon. January 1986. (Format: TXT=22883 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group Annette L. DeSchon
Request for Comments: 971 ISI
January 1986
DeSchonがコメントのために要求するワーキンググループアネットL.をネットワークでつないでください: 971 ISI1986年1月
A SURVEY OF DATA REPRESENTATION STANDARDS
データ表現規格の調査
Status of This Memo
このメモの状態
This RFC discusses data representation conventions in the ARPA-Internet and suggests possible resolutions. No proposals in this document are intended as standards for the ARPA-Internet at this time. Rather, it is hoped that a general consensus will emerge as to the appropriate approach to these issues, leading eventually to the adoption of ARPA-Internet standards. Distribution of this memo is unlimited.
このRFCはARPA-インターネットのデータ表現コンベンションについて議論して、可能な解決を勧めます。 提案は全くこのとき、ARPA-インターネットの規格として本書では意図しません。 むしろ、全体的な合意がこれらの問題への適切なアプローチに関して現れることが望まれています、結局ARPA-インターネット標準の採用に通じて。 このメモの分配は無制限です。
1. Introduction
1. 序論
This report is a comparison of several data representation standards that are currently in use. The standards, or system type definitions, that will be discussed are the CCITT X.409 recommendation, the NBS Computer Based Message System (CBMS) standard, DARPA Multimedia Mail system, the Courier remote procedure call protocol, and the SUN Remote Procedure Call package.
このレポートはいくつかの現在使用中のデータ表現規格の比較です。 それによる議論しているのが、CCITT X.409推薦と、NBSコンピュータBased Message System(CBMS)規格と、DARPA Multimediaメールシステムと、Courier遠隔手続き呼び出しプロトコルと、SUN Remote Procedure Callパッケージであるということでしょうシステム型定義であり規格であり。
One purpose of this report is to determine how the CCITT standard, which is gaining wide acceptance internationally, compares with some of the other standards that have been developed in the areas of electronic mail, distributed interprocess communication, and remote procedure call. The CCITT X.409 recommendation, which is entitled "Presentation Transfer Syntax and Notation" is an international standard which is a part of the X.400 series Message Handling Systems (MHS) specifications [1]. It has been adopted by both the NBS and the ISO standards organizations. In addition, some commercial organizations have announced intentions to support a CCITT interface for electronic mail. The NBS Computer Based Message System (CBMS) standard was developed previously and was published as a Federal Information Processing Standard (FIPS Publication 98) in 1983 [3]. The DARPA Multimedia Mail system is an experimental electronic mail system which is in use in the DARPA Internet [2,4,5]. It is used to create and distribute messages that incorporate text, graphics, stored speech, and images and has been implemented on on several very different machines. Courier is the XEROX network systems remote procedure call protocol [7]. The SUN Remote Procedure Call package implements "network pipes" between UNIX machines [6].
このレポートの1つの目的はCCITT規格(広い承認を国際的に獲得している)がどのように電子メールの領域、分配されたプロセス間通信、および遠隔手続き呼び出しで開発された他の規格のいくつかと比較されるかを決定することです。 CCITT X.409推薦。((その推薦はことです)「プレゼンテーション転送構文と記法」と題しているのが、X.400シリーズMessage Handling Systems(MHS)仕様[1]の一部である世界規格である)。 それはNBSとISO規格組織の両方によって採用されました。 さらに、いくつかの営利団体が電子メールのためにCCITTインタフェースをサポートするという意志を示しました。 NBSコンピュータBased Message System(CBMS)規格は、以前に、開発されて、連邦情報処理基準(FIPS Publication98)として1983[3]で発行されました。 DARPA MultimediaメールシステムはDARPAインターネット[2、4、5]で使用中の実験的な電子メール・システムです。 それは、テキスト、グラフィックスを取り入れるメッセージを作成して、分配するのに使用されて、スピーチ、およびイメージを保存して、数個で非常に異なるところで実装されました。機械加工します。 急使はゼロックスネットワーク・システム遠隔手続き呼び出しプロトコル[7]です。 SUN Remote Procedure CallパッケージはUnixマシン[6]の間の「ネットワークパイプ」を実装します。
DeSchon [Page 1]
DeSchon[1ページ]
RFC 971 January 1986 A Survey of Data Representation Standards
RFC971 1986年1月 データ表現規格の調査
2. Background
2. バックグラウンド
This section presents a brief overview of the basic terminology and approach of each data representation standard.
このセクションは基本的な用語の簡潔な概要とそれぞれのデータ表現規格のアプローチを提示します。
2.1. Interprocess Communication Standards
2.1. プロセス間通信規格
The standards that are oriented towards distributed interprocess
communication or remote procedure call, between like machines,
generally favor the use of types that map easily into the types
defined in the programming language in use on the system. For
example, the types defined for the XEROX Courier system resemble
the types found in the Mesa programming language. Similarly, the
SUN Remote Procedure Call system types resemble the types found in
the C programming language. An advantage of a system implemented
using like machines is that the external data representation can
be defined in such a way that the conversion to and from the local
format is minimal.
一般に、規格が分配されたプロセス間通信か遠隔手続き呼び出しに向かって適応して、同様のマシンの間では、容易にタイプへの地図がシステムの上で使用中のプログラミング言語で定義したタイプの使用を支持してください。 例えば、ゼロックスCourierシステムのために定義されたタイプはMesaプログラミング言語で見つけられたタイプに類似しています。 同様に、SUN Remote Procedure CallシステムタイプはCプログラミング言語で見つけられたタイプに類似しています。 マシンのような使用が実装されたシステムの利点は形式と、そして、地方の形式からの変換が最小量であるように方法で外部データ表現を定義できるということです。
2.1.1. Courier
2.1.1. 急使
The Courier standard data types are used to define the data
objects which are transported bi-directionally between system
elements that are running the Courier remote procedure call
protocol. The "standard representation" of a type is the
encoding of the data which is transmitted. The "standard
notation" refers to the conventions for the interpretation of
the data by higher-level applications. The standard
representation of a data object encodes the value of the
object, but the type of the object is determined by the
software that generates or interprets the representation.
Courierの標準のデータ型は、Courier遠隔手続き呼び出しプロトコルを実行しているシステム・エレメントの間で2方向に輸送されるデータ・オブジェクトを定義するのに使用されます。 タイプの「標準の表現」は送られるデータのコード化です。 「標準の記法」は、よりハイレベルのアプリケーションによるデータの解釈についてコンベンションを示します。 データ・オブジェクトの標準の表現はオブジェクトの値をコード化しますが、オブジェクトのタイプは表現を生成するか、または解釈するソフトウェアで決定します。
2.1.2. SUN Remote Procedure Call Package
2.1.2. 太陽遠隔手続き呼び出しパッケージ
The SUN Remote Procedure Call package includes routines which
allow a process on one UNIX machine to consume data produced by
a process on another UNIX machine. This is called a "network
pipe" and is an extension of the standard UNIX pipe. The
"eXternal Data Representation (XDR)" standard defines the
routines that are used to encode or "serialize" data for
transmission, or to decode or "deserialize" data for local
interpretation. The syntax suggests that perhaps it should be
called "remote interprocess communication" rather than "remote
procedure call".
SUN Remote Procedure Callパッケージは1台のUnixマシンの上のプロセスがプロセスによって別のUnixマシンに作り出されたデータを消費できるルーチンを含んでいます。 これは、「ネットワークパイプ」と呼ばれて、標準のUNIXパイプの拡大です。 「外部データ表現(XDR)」規格はローカルの解釈のためのデータをトランスミッションのためのデータをコード化するか、「連載する」、解読するか、または「デシリアライズすること」に使用されるルーチンを定義します。 構文は、恐らく、それが「遠隔手続き呼び出し」よりむしろ「リモートプロセス間通信」と呼ばれるべきであると示唆します。
DeSchon [Page 2]
DeSchon[2ページ]
RFC 971 January 1986 A Survey of Data Representation Standards
RFC971 1986年1月 データ表現規格の調査
2.2. Message Standards
2.2. メッセージ規格
The message oriented standards, including DARPA Multimedia Mail,
NBS CBMS, and the CCITT X.409 standards, seem to favor more
general, highly extensible type definitions. This may have
something to do with the expectation that a system will include
many different machines, programmed using many different
programming languages.
メッセージは規格を適応させました、DARPA Multimediaメールを含んでいます、とNBS CBMS、およびCCITT X.409規格は、より一般的で、非常に広げることができる型定義を支持するために思えます。 これには、システムが含んでいる期待で多くの異なったプログラミング言語を使用することでプログラムされた多くの異なったマシンをすることがあるかもしれません。
2.2.1. DARPA Multimedia Mail
2.2.1. DARPAマルチメディアメール
The DARPA Multimedia Mail system was developed for use in DoD
Internet community. The set of data elements used in the
Multimedia Message Handling Facility (MMHF) is referred to as
its "presentation transfer syntax". The encoding of these data
elements varies with the data type being represented. Each
begins with a one-octet "element-code". Some data elements are
of a pre-determined length. For example, the INTEGER data
element occupies five octets, one for the element-code, and
four which contain the "value component". Other data elements,
however, may vary in length. For example, the TEXT data
element, is made up of a one-octet element-code, a three-octet
count of the characters to follow, and a variable number of
octets, each containing one right-justified seven bit ASCII
character. The element-code and the length constitute the "tag
component".
DARPA MultimediaメールシステムはDoDインターネットコミュニティにおける使用のために開発されました。 Multimedia Message Handling Facility(MMHF)で使用されるデータ要素のセットは「プレゼンテーション転送構文」と呼ばれます。 データ型が表されている状態で、これらのデータ要素のコード化は異なります。 それぞれが1八重奏の「要素コード」で始まります。 いくつかのデータ要素が予定された長さのものです。 例えば、INTEGERデータ要素は5つの八重奏、要素コードのためのものと「値のコンポーネント」を含む4を占領します。 しかしながら、他のデータ要素は長さにおいて異なるかもしれません。 例えば、1八重奏の要素コード、続くキャラクタの3八重奏のカウント、および可変数の八重奏で作られて、それぞれ7ビットのまさしく正当な1人のASCII文字を含むTEXTデータ要素。 要素コードと長さは「タグの部品」を構成します。
A "base data element" is self contained, while a "structured
data element" is formed using other data elements. The LIST
data element is used to create structures composed of other
elements. The tag component of a LIST is made up of a
one-octet element-code, a three-octet count of the number of
octets to follow, and a two-octet count of the number of
elements that follow. The PROPLIST data element is used to
create a structure that consists of a set of unordered
name-value pairs. The tag component of a PROPLIST is made up
of a one-octet element-code, a three-octet count of the number
of octets to follow, and a one-octet count of the number of
name-value pairs in the PROPLIST. Both the LIST and the
PROPLIST elements are followed by an ENDLIST data element.
「ベースデータ要素」は自給自足ですが、「構造化されたデータ要素」は、他のデータ要素を使用することで形成されます。 LISTデータ要素は、他の要素で構成された構造を作成するのに使用されます。 LISTのタグの部品は1八重奏の要素コード、続く八重奏の数の3八重奏のカウント、および従う要素の数の2八重奏のカウントで作られます。 PROPLISTデータ要素は、1セットの順不同の名前価値の組から成る構造を作成するのに使用されます。 PROPLISTのタグの部品は1八重奏の要素コード、続く八重奏の数の3八重奏のカウント、およびPROPLISTの名前価値の組の数の1八重奏のカウントで作られます。ENDLISTデータ要素はLISTとPROPLIST要素の両方を支えています。
2.2.2. NBS Computer Based Message System
2.2.2. NBSのコンピュータのベースのメッセージシステム
The NBS Computer Based Message System (CBMS) standard was
developed to specify the format of a message at the interface
between different computer-based message systems. Each data
element consists of a series of "components". The five
NBSコンピュータBased Message System(CBMS)規格は、異なったコンピュータベースのメッセージシステムの間のインタフェースでメッセージの形式を指定するために開発されました。それぞれのデータ要素は一連の「コンポーネント」から成ります。 5
DeSchon [Page 3]
DeSchon[3ページ]
RFC 971 January 1986 A Survey of Data Representation Standards
RFC971 1986年1月 データ表現規格の調査
possible types of component are the "identifier octet", the
"length code", the "qualifier", the "property-list" component,
and the "data element contents". Every data element contains
an identifier octet and a length code. The identifier octet
contains a one-bit flag that signifies whether the data element
contains a property-list, and a code identifying the data
element and signifying whether it contains a qualifier. In the
NBS standard, the property-list is associated with a data
element and contains properties such as a "printing-name" or a
"comment". The meaning of the qualifier depends on the data
element code. The length code indicates the number of octets
following, and is between one and three octets in length.
コンポーネントの可能なタイプは、「識別子八重奏」と、「長さのコード」と、「資格を与える人」と、「特性リスト」コンポーネントと、「データ要素コンテンツ」です。 あらゆるデータ要素が識別子八重奏と長さのコードを含んでいます。 識別子八重奏はデータ要素が特性リストを含んでいるか否かに関係なく、意味する1ビットの旗、およびデータ要素を特定して、それが資格を与える人を含むか否かに関係なく、意味するコードを含んでいます。 NBS規格では、特性リストは、データ要素に関連していて、「印刷名」か「コメント」などの特性を入れてあます。 資格を与える人の意味はデータ要素コードに依存します。 長さのコードは、続いて、八重奏の数を示して、長さが1〜3つの八重奏です。
Each data element is inherently a "primitive data element",
which contains a basic item of information, or a "constructor
data element", which contains one or more data elements. The
"field" data element (itself a constructor) uses a qualifier
component, which contains a "field identifier" to indicate
which specific field is being represented within a message.
(それは、情報の定番商品を含みます)。それぞれのデータ要素は、本来の「原始のデータ要素」か「建設者データ要素」です。(それは、1つ以上のデータ要素を含みます)。 「分野」データ要素(建設者自身)は資格を与える人コンポーネントを使用します。(それは、どの特定の分野がメッセージの中に表されているかを示すために「分野識別子」を含みます)。
2.2.3. CCITT Recommendation X.409
2.2.3. CCITT推薦X.409
The CCITT recommendation X.409 defines the notation and the
representational technique used to specify and to encode the
Message Handling System (MHS) protocols. The following is a
description of the CCITT approach to encoding type definitions.
A data element consists of three components, the "identifier"
(type), the "length", and the "contents". An element and its
components consist of a sequence of an integral number of
octets. An identifier consists of a "class" ("universal",
"application-wide", "context-specific", or "private-use"), a
"form" ("primitive" or "constructor"), and the "id code".
There is a convention defined for both single-octet and
multi-octet identifiers. The length specifies the length of
the contents in octets, and is itself variable in length.
There is also an "indefinite" value defined for the length;
this means that no length for the contents is specified, and
the contents is terminated with the the "end-of-contents" (EOC)
element. In X.409 it is possible to determine whether a data
element is a primitive or a constructor from the form part of
the identifier. In addition it is possible to "tag" the data
by attaching meaning to an id code within the context of a
specific application.
具象主義のテクニックは、CCITT推薦X.409が記法を定義して、指定して、以前はよくMessage Handling System(MHS)プロトコルをコード化していました。 ↓これは型定義をコード化することへのCCITTアプローチの記述です。 データ要素は3つのコンポーネント、「識別子」(タイプする)、「長さ」、および「コンテンツ」から成ります。 要素とそのコンポーネントは整数の八重奏の系列から成ります。 識別子は「クラス」(「アプリケーション全体「普遍的で」、」の「文脈特有である」か、または「私用」)、「フォーム」(「原始」か「建設者」)、および「イドコード」から成ります。 ともにただ一つの八重奏の、そして、マルチ八重奏の識別子のために定義されたコンベンションがあります。 長さは、八重奏における、コンテンツの長さを指定して、長さでそれ自体で可変です。 また、長さのために定義された「無期」の値があります。 これは、コンテンツのための長さが全く指定されないで、コンテンツが「コンテンツの終わり」(EOC)要素で終えられることを意味します。 X.409では、識別子のフォーム部分からデータ要素が基関数かそれとも建設者であるかを決定するのは可能です。 さらに、データが特定のアプリケーションの文脈の中のイドコードに意味を付けることによって「タグ付け」であることは可能です。
DeSchon [Page 4]
DeSchon[4ページ]
RFC 971 January 1986 A Survey of Data Representation Standards
RFC971 1986年1月 データ表現規格の調査
3. Implicit Versus Explicit Representation
3. 明白な表現に対して暗黙です。
In both the SUN Remote Procedure Call system and the XEROX Courier system the type definitions of external data are implicit. This means that for a given type of call, or message, the type definitions which is to be used to interpret the data, are agreed upon by the sender and the receiver in advance. In other words, parameters (or message fields) are assumed to be in a predefined order. Each parameter is assumed to be of a predefined type. This means the data cannot be reformated into the local form until it reaches a process that knows about the types of specific parameters. At this point, the conversion can be accomplished using system routines that know how to convert from the external format to the local format. If the system is homogeneous there may be very little conversion required. In addition, no extra overhead of sending the type definitions with the data is incurred.
SUN Remote Procedure CallシステムとゼロックスCourierシステムの両方では、外部のデータの型定義は暗に示されています。 これが与えられたタイプの呼び出しのためにそれを意味するか、またはメッセージ、データを解釈するのに使用されることである型定義はあらかじめ、送付者と受信機によって同意されます。 言い換えれば、パラメタ(または、メッセージ分野)が事前に定義されたオーダーにあると思われます。 事前に定義されたタイプには各パラメタがあると思われます。 これは、それが特定のパラメタのタイプに関して知っているプロセスに達するまで地方のフォームにデータをreformatedされることができないことを意味します。 ここに、外部形式から地方の形式まで変換する方法を知っているシステムルーチンを使用することで変換を実行できます。 システムが同次であるなら、変換は必要でなかったほとんどがあるかもしれません。 さらに、データがある型定義を送るどんな付加的なオーバーヘッドも被られません。
In the DARPA Multimedia Mail system, the NBS CBMS standard, and the CCITT X.409 recommendation, type definitions are explicit. In this case the type definitions are encoded into the message. There are several advantages to this approach. One advantage is that it allows a low level receiver process in the destination host to convert the data from the standard form to a form appropriate for the local host, as it received. This can increase efficiency if it allows the destination host to avoid passing around data that does not conform to the local word boundaries. Another advantage is that it provides flexibility for future expansion. Since the overall length is a part of the type definition, it allows a host to deal with or ignore data of types that it does not necessarily understand. Since the interpretation of the data is not dependent on its position, message fields (or parameters) can be reordered, or optionally omitted. The disadvantages of this approach are as follows. Assuming that no field could be omitted, the external representation of the message may be longer than it would have been if an implicit representation had been used. In addition, extra time may be consumed by the conversion between external format and local format, since the external format almost certainly will not match the local format for any of the participants.
DARPA Multimediaメールシステム、NBS CBMS規格、およびCCITT X.409推薦では、型定義は明白です。 この場合、型定義はメッセージにコード化されます。 このアプローチのいくつかの利点があります。 1つの利点はあて先ホストの低い平らな受信機プロセスがそれで標準形式からローカル・ホストにとって、適切なフォームまでデータを変換できるということです、受信したので。 あて先ホストが、それでローカルの語境界に従わないデータを回すのを避けることができるなら、これは効率を増強できます。 別の利点は今後の拡張に柔軟性を提供するということです。 全長が型定義の一部であるので、それで、ホストは、それが必ず理解しているというわけではないタイプに関するデータを対処するか、または無視します。 データの解釈が位置に依存していないので、メッセージ分野(または、パラメタ)を再命令するか、または任意に、省略できます。 このアプローチの損失は以下の通りです。 分野を全く省略できなかったと仮定する場合、メッセージの外部の表現は陰的表現が使用されたかどうかということであっただろうより長いかもしれません。 さらに、延長時間は外部形式と地方の形式の間の変換で費やされるかもしれません、外部形式がほぼ確実に関係者のどれかの地方の形式に合わないので。
DeSchon [Page 5]
DeSchon[5ページ]
RFC 971 January 1986 A Survey of Data Representation Standards
RFC971 1986年1月 データ表現規格の調査
4. Data Representation Standards Scorecard
4. データ表現規格採点表
The following table is a comparison of the data elements defined for the various standards being discussed. It is provided in order to give a general idea of the types defined for each standard, but it should be noted that the grouping of these types does not indicate one type corresponds exactly to any other. Where it is applicable, the identifier code appears in parantheses following the name of the data element. Under "NUMBER", "S" stands for signed, "U" stands for unsigned, "V" stands for variable, and the number represents the number of bits. For example, "Integer S16" means a "signed 16-bit integer".
以下のテーブルは議論する様々な規格のために定義されたデータ要素の比較です。 各規格のために定義されたタイプの概念を与えるためにそれを提供しますが、これらのタイプの組分けが、1つのタイプがちょうどいかなる他のも文通するのを示さないことに注意するべきです。 それが適切であるところに、データ要素の名前に従って、識別子コードはparanthesesに現れます。 「数」の下では、「S」は署名されるのに表します、そして、「U」は未署名に表します、そして、「V」は可変に表します、そして、数はビットの数を表します。 例えば、「整数S16"は「署名している16ビットの整数」を意味します」。
Type CCITT MMM NBS XEROX Sun
-----------------------------------------------------------------------
END | End-of- | ENDLIST | End-of- | -- | --
| Contents | (11) | Constructor| |
| (0) | | (1) | |
| | | | |
PAD | Null (5) | NOP (0) | No-Op (0) | -- | --
| | PAD (1) | Padding | |
| | | (33) | |
| | | | |
RECORD | Set (17) | PROPLIST | Set (11) | -- | --
| | (14) | | |
| Sequence | LIST (9) | Sequence | Sequence | Structure
| (16) | | (10) | |
| | | | Record |
| | | Message | |
| | | (77) | |
| -- | -- | -- | Array | Fixed Array
| | | | | Counted Array
| "Choice" | -- | -- | Choice |Discriminated-
| "Any" | | | | Union
| | | | |
| "Tagged" | "name" | Field (76) | -- | --
| | |Unique-ID(9)| |
| -- | SHARE-TAG | -- | -- | --
| | (12) | | |
| | SHARE-REF | | |
| | (13) | | |
| | | | |
| -- | -- | Compressed | -- | --
| | | (70) | |
| -- | ENCRYPT | Encrypted | -- | --
| | (14) | (71) | |
えー、CCITT NBSゼロックスSunをタイプしてください。----------------------------------------------------------------------- 終わり| 終わり、-、-| ENDLIST| 終わり、-、-| -- | -- | コンテンツ| (11) | 建設者| | | (0) | | (1) | | | | | | | パッド| ヌル(5)| NOP(0)| オプアートがない(0)| -- | -- | | パッド(1)| 詰め物| | | | | (33) | | | | | | | 記録| (17)を設定してください。| PROPLIST| (11)を設定してください。| -- | -- | | (14) | | | | 系列| リスト(9)| 系列| 系列| 構造| (16) | | (10) | | | | | | 記録| | | | メッセージ| | | | | (77) | | | -- | -- | -- | 配列| 固定配列| | | | | 数えられた配列| 「選択」| -- | -- | 選択|差別されます。| 「いくらか」| | | | 組合| | | | | | 「タグ付けをされます」。| 「名前」| 分野(76)| -- | -- | | |ユニークなID(9)| | | -- | シェアタグ| -- | -- | -- | | (12) | | | | | シェア審判| | | | | (13) | | | | | | | | | -- | -- | 圧縮されます。| -- | -- | | | (70) | | | -- | 暗号化します。| 暗号化されます。| -- | -- | | (14) | (71) | |
DeSchon [Page 6]
DeSchon[6ページ]
RFC 971 January 1986 A Survey of Data Representation Standards
RFC971 1986年1月 データ表現規格の調査
Type CCITT MMM NBS XEROX Sun
-----------------------------------------------------------------------
BOOLEAN| Boolean(1)| BOOLEAN(2)| Boolean(8) | Boolean | Boolean
| | | | |
NUMBER | Integer(2)| EPI (5) | Integer(32)| Integer | Integer
| SV | SV | SV | S16 | S32
| | INDEX (3) | | Cardinal | Unsigned Int
| | U16 | | U16 | U32
| | INTEGER(4)| |Unspecified|Enumeration
| | S32 | | 16 | 32
| | | | Long Int |Hyper Integer
| | | | S32 | S64
| | | | Long Card |Uns Hyper Int
| | | | U32 | U64
| | | | | Double Prec
| | | | | 64
| -- | FLOAT (15)| -- | -- | Float Pt
| | 64 | | | 32
| | | | |
BIT- | Bit String| BITSTR(6) | Bit-String | -- | --
STRING| (3) | | (67) | |
| Octet- | -- | -- | -- | Opaque
| String(4)| | | |
| | | | |
STRING | IA5 (22) | TEXT (8) | ASCII- | String | Counted-
| | | String (2)| | Byte String
| | NAME (7) | | |
| Numeric | | | |
| (18) | | | |
| Printable | | | |
| (19) | | | |
| T.61 (20) | | | |
| Videotex | | | |
| (21) | | | |
えー、CCITT NBSゼロックスSunをタイプしてください。----------------------------------------------------------------------- 論理演算子| 論理演算子(1)| 論理演算子(2)| 論理演算子(8)| 論理演算子| 論理演算子| | | | | 数| 整数(2)| エピ(5)| 整数(32)| 整数| 整数| SV| SV| SV| S16| S32| | インデックス(3)| | 枢機卿| 未署名のInt| | U16| | U16| U32| | 整数(4)| |不特定|列挙| | S32| | 16 | 32 | | | | 長いInt|超-整数| | | | S32| S64| | | | 最後の札|Uns超-Int| | | | U32| U64| | | | | 二重Prec| | | | | 64 | -- | (15)を浮かべてください。| -- | -- | Ptを広めてください。| | 64 | | | 32 | | | | | ビット| ビット列| BITSTR(6)| ビット列| -- | -- ストリング| (3) | | (67) | | | 八重奏| -- | -- | -- | 不透明なもの| ストリング(4)| | | | | | | | | ストリング| IA5(22)| テキスト(8)| ASCII| ストリング| 数えられます。| | | ストリング(2)| | バイトストリング| | 名前(7)| | | | 数値| | | | | (18) | | | | | 印刷可能| | | | | (19) | | | | | T.61(20)| | | | | ビデオテックス| | | | | (21) | | | |
DeSchon [Page 7]
DeSchon[7ページ]
RFC 971 January 1986 A Survey of Data Representation Standards
RFC971 1986年1月 データ表現規格の調査
Type CCITT MMM NBS XEROX Sun
-----------------------------------------------------------------------
OTHER | UTC Time | -- | Date (40) | -- | --
| (23) | | | |
| Gen Time | | | |
| (24) | | | |
| -- | -- | Property- | -- | --
| | | List (36)| |
| -- | -- |Property(69)| -- | --
| | | | |
| -- | -- | -- | Procedure | --
| | | | |
| -- | -- | Vendor- | -- | --
| | | Defined | |
| | | (127) | |
| | | Extension | |
| | | (126) | |
えー、CCITT NBSゼロックスSunをタイプしてください。----------------------------------------------------------------------- 他| UTC時間| -- | 日付(40)| -- | -- | (23) | | | | | 時間に情報を得てください。| | | | | (24) | | | | | -- | -- | 特性| -- | -- | | | リスト(36)| | | -- | -- |特性(69)| -- | -- | | | | | | -- | -- | -- | 手順| -- | | | | | | -- | -- | ベンダー| -- | -- | | | 定義されます。| | | | | (127) | | | | | 拡大| | | | | (126) | |
5. Conclusions
5. 結論
Of the standards discussed in this survey, the CCITT approach (X.409) has already gained wide acceptance. For a system that will include a number of dissimilar hosts, as might be the case for an Internet application, a standard that employs explicit representation, such as the CCITT X.409, would probably work well. Using the CCITT X.409 standard it is possible to construct most of the data elements that are specified for the other standards, with the possible exception of the "floating point" type. However, some of the flexibility that has been built into this standard, such as the "private-use class" may lead to ambiguity and a lack of coordination between implementors at different sites. If a standard such as the CCITT were to be used in an Internet experiment a fully defined (but large) subset would probably have to be selected.
この調査で議論した規格では、CCITTアプローチ(X.409)は既に広い承認を獲得しました。 インターネットアプリケーション、それが使う規格のためにそうであるかもしれないように多くの異なったホストを含んでいるシステムのために、CCITT X.409などの明白な表現はたぶんうまくいくでしょう。 CCITT X.409規格を使用して、他の規格に指定されるデータ要素の大部分を組み立てるのは可能です、「浮動小数点」タイプの可能な例外で。 しかしながら、「私用のクラス」などのこの規格を組み込んである柔軟性のいくつかが異なったサイトの作成者の間のコーディネートのあいまいさと不足につながるかもしれません。 CCITTなどの規格がインターネット実験に使用されることであるなら、完全に定義されて、(大きい)の部分集合はたぶん選択されなければなりません。
DeSchon [Page 8]
DeSchon[8ページ]
RFC 971 January 1986 A Survey of Data Representation Standards
RFC971 1986年1月 データ表現規格の調査
6. References
6. 参照
[1] "Message Handling Systems: Presentation Transfer Syntax and
Notation", Recommendation X.409, Document AP VIII-66-E,
International Telegraph and Telephone Consultative Committee
(CCITT), Malaga-Torremolinos, June, 1984.
[1]、「メッセージハンドリングシステム:」 「プレゼンテーション転送構文と記法」(推薦X.409)は1984年6月にAP VIII66E、国際電信電話諮問委員会(CCITT)、マラガ-トレモリノスを記録します。
[2] J. Garcia-Luna, A. Poggio, and D. Elliot, "Research into
Multimedia Message System Architecture", SRI International,
February, 1984.
[2] J.ガルシア-ルーナ、A.Poggio、およびD.エリオット、「マルチメディアメッセージシステム構築の研究」、SRIインターナショナル、1984年2月。
[3] "Specification for Message Format for Computer Based Message
Systems", FIPS Pub 98 (also published as RFC 841), National
Bureau of Standards, January, 1983.
[3] 「コンピュータのためのメッセージ・フォーマットのための仕様はメッセージシステムを基礎づけました」、FIPS Pub98(また、RFC841として、発行されます)、規格基準局、1983年1月。
[4] J. Postel, "Internet Multimedia Mail Transfer Protocol", USC
Information Sciences Institute, MMM-11 (RFC-759 revised), March,
1982.
[4] J.ポステル、「インターネットマルチメディアメール転送プロトコル」、USC情報Sciences Institute、MMM-11(RFC-759は復習した)、1982年3月。
[5] J. Postel, "Internet Multimedia Mail Document Format", USC
Information Sciences Institute, MMM-12 (RFC-767 revised), March,
1982.
[5] J.ポステル、「インターネットマルチメディアはドキュメント・フォーマットを郵送する」USC情報Sciences Institute、MMM-12(RFC-767は復習した)、1982年3月。
[6] "Extended Data Representation Reference Manual", SUN
Microsystems, September, 1984.
[6] 「拡張データ表現リファレンスマニュアル」、太陽マイクロシステムズ、1984年9月。
[7] "Courier: The Remote Procedure Call Protocol", XSIS-038112,
XEROX Corporation, December, 1981.
[7]、「急使:」 「遠隔手続き呼び出しプロトコル」、XSIS-038112、ゼロックス社、1981年12月。
DeSchon [Page 9]
DeSchon[9ページ]
一覧
スポンサーリンク
