RFC3072 日本語訳
3072 Structured Data Exchange Format (SDXF). M. Wildgrube. March 2001. (Format: TXT=48481 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Wildgrube Request for Comments: 3072 March 2001 Category: Informational
Wildgrubeがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3072 2001年3月のカテゴリ: 情報
Structured Data Exchange Format (SDXF)
構造化されたデータ交換形式(SDXF)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
IESG Note
IESG注意
This document specifies a data exchange format and, partially, an API that can be used for creating and parsing such a format. The IESG notes that the same problem space can be addressed using formats that the IETF normally uses including ASN.1 and XML. The document reader is strongly encouraged to carefully read section 13 before choosing SDXF over ASN.1 or XML. Further, when storing text in SDXF, the user is encourage to use the datatype for UTF-8, specified in section 2.5.
このドキュメントはそのような形式を作成して、分析するのに使用できるデータ交換形式と部分的にAPIを指定します。 IESGは、ASN.1とXMLを含んでいて、通常、IETFが使用する形式を使用することで同じ問題スペースを扱うことができることに注意します。 ASN.1かXMLの上でSDXFを選ぶ前にドキュメント読者がセクション13を注意して読むよう強く奨励されます。 さらに、SDXF、ユーザにテキストを保存するのが、いつかがセクション2.5で指定されたUTF-8にデータ型式を使用するよう奨励します。
Abstract
要約
This specification describes an all-purpose interchange format for use as a file format or for net-working. Data is organized in chunks which can be ordered in hierarchical structures. This format is self-describing and CPU-independent.
この仕様はファイル形式としての使用か情報交換グループの仕事のための万能の置き換え形式について説明します。 データは階層構造で注文できる塊で組織化されます。 この形式は、自己について説明していてCPUから独立しています。
Table of Contents
目次
1. Introduction ................................................. 2 2. Description of the SDXF data format .......................... 3 3. Introduction to the SDXF functions ........................... 5 3.1 General remarks .............................................. 5 3.2 Writing a SDXF buffer ........................................ 5 3.3 Reading a SDXF buffer ........................................ 6 3.4 Example ...................................................... 6 4. Platform independence ........................................ 8 5. Compression .................................................. 9 6. Encryption ...................................................11 7. Arrays........................................................11 8. Description of the SDXF functions ............................12
1. 序論… 2 2. SDXFデータの形式の記述… 3 3. SDXFへの紹介は機能します… 5 3.1 一般所見… 5 3.2 SDXFバッファを書きます… 5 3.3 SDXFバッファを読みます… 6 3.4の例… 6 4. プラットホーム独立… 8 5. 圧縮… 9 6. 暗号化…11 7. 配列…11 8. SDXFの記述は機能します…12
Wildgrube Informational [Page 1] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[1ページ]のRFC3072
8.1 Introduction .................................................12 8.2 Basic definitions ............................................13 8.3 Definitions for C++ ..........................................15 8.4 Common Definitions ...........................................16 8.5 Special functions ............................................17 9. 'Support' of UTF-8 ...........................................19 10. Security Considerations .....................................19 11. Some general hints ..........................................20 12. IANA Considerations .........................................20 13. Discussion ..................................................21 13.1 SDXF vs. ASN.1 ..............................................21 13.2 SDXF vs. XML ................................................22 14. Author's Address ............................................24 15. Acknowledgements ............................................24 16. References ..................................................24 17. Full Copyright Statement ....................................26
8.1序論…12 8.2 基本的な定義…13 C++のための8.3の定義…15 8.4 一般的な定義…16 8.5スペシャルは機能します…17 9. UTF-8の'サポート'…19 10. セキュリティ問題…19 11. 一般は暗示します…20 12. IANA問題…20 13. 議論…21 13.1SDXF対ASN.1…21 13.2SDXF対XML…22 14. 作者のアドレス…24 15. 承認…24 16. 参照…24 17. 完全な著作権宣言文…26
1. Introduction
1. 序論
The purpose of the Structured Data eXchange Format (SDXF) is to permit the interchange of an arbitrary structured data block with different kinds of data (numerical, text, bitstrings). Because data is normalized to an abstract computer architecture independent "network format", SDXF is usable as a network interchange data format.
Structured Data eXchange Format(SDXF)の目的が異種に関するデータがある任意の構造化されたデータ・ブロックの置き換えを可能にすることである、(数字である、テキスト、bitstrings) データが抽象的なコンピュータ・アーキテクチャ独立している「ネットワーク形式」に正常にされるので、SDXFはネットワーク置き換えデータの形式として使用可能です。
This data format is not limited to any application, the demand for this format is that it is usable as a text format for word- processing, as a picture format, a sound format, for remote procedure calls with complex parameters, suitable for document formats, for interchanging business data, etc.
このデータの形式はどんなアプリケーションにも制限されないで、この形式の要求はそれが単語処理のためのテキスト形式として使用可能であるということです、画像形式として、音の形式、複雑なパラメタがある遠隔手続き呼び出しのために、ドキュメント・フォーマットに適しています、業務データなどを交換するために
SDXF is self-describing, every program can unpack every SDXF-data without knowing the meaning of the individual data elements.
個々のデータ要素の意味を知らないで、SDXFは自己に説明していて、あらゆるプログラムがあらゆるSDXF-データをアンパックできます。
Together with the description of the data format a set of functions will be introduced. With the help of these functions one can create and access the data elements of SDXF. The idea is that a programmer should only use these functions instead of maintaining the structure by himself on the level of bits and bytes. (In the speech of object-oriented programming these functions are methods of an object which works as a handle for a given SDXF data block.)
データの形式の記述と共に、関数群を導入するでしょう。 これらの機能の助けで、人は、SDXFのデータ要素を作成して、アクセスできます。 考えはプログラマがビットとバイトのレベルで自分で構造を維持することの代わりにこれらの機能を使用するだけであるべきであるということです。 (オブジェクト指向プログラミングのスピーチで、これらの機能は与えられたSDXFデータ・ブロックハンドルとして働いているオブジェクトのメソッドです。)
SDXF is not limited to a specific platform, along with a correct preparation of the SDXF functions the SDXF data can be interchanged (via network or data carrier) across the boundaries of different architectures (specified by the character code like ASCII, ANSI or EBCDIC and the byte order for binary data).
SDXFを特定のプラットホームに制限しないで、SDXF機能の正しい準備と共に、異なったアーキテクチャ(キャラクタコードで、ASCIIやANSIやEBCDICとバイトオーダーのように、バイナリ・データに指定される)の限界の向こう側にSDXFデータを交換できます(ネットワークかデータ記憶媒体を通して)。
Wildgrube Informational [Page 2] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[2ページ]のRFC3072
SDXF is also prepared to compress and encrypt parts or the whole block of SDXF data.
また、SDXFは部分か全体のブロックのSDXFデータを圧縮して、暗号化するように準備されます。
2. Description of SDXF data format.
2. SDXFデータの形式の記述。
2.1 First we introduce the term "chunk". A chunk is a data structure
with a fixed set of components. A chunk may be "elementary" or
"structured". The latter one contains itself one or more other
chunks.
2.1/1、私たちは「塊」という用語を紹介します。 塊は固定セットの部品があるデータ構造です。 塊は、「基本である」か「構造化されているかもしれません」。 後者のもの自体は他の1つ以上の塊を含んでいます。
A chunk consists of a header and the data body (content):
塊はヘッダーとデータ本体(内容)から成ります:
+----------+-----+-------+-----------------------------------+ | Name | Pos.| Length| Description | +----------+-----+-------+-----------------------------------+ | chunk-ID | 1 | 2 | ID of the chunk (unsigned short) | | flags | 3 | 1 | type and properties of this chunk | | length | 4 | 3 | length of the following data | | content | 7 | *) | net data or a list of of chunks | +----------+-----+-------+-----------------------------------+
+----------+-----+-------+-----------------------------------+ | 名前| Pos| 長さ| 記述| +----------+-----+-------+-----------------------------------+ | 塊ID| 1 | 2 | 塊(未署名のショート)のID| | 旗| 3 | 1 | この塊のタイプと特性| | 長さ| 4 | 3 | 以下のデータの長さ| | 内容| 7 | *) | データかaが記載する塊のネット| +----------+-----+-------+-----------------------------------+
(* as stated in "length". total length of chunk is length+6. The chunk ID is a non-zero positive number.
「長さ」 塊の全長における述べられるとしての*は長さ+6です。(塊IDは非ゼロ正の数です。
or more visually:
または、 より目視により:
+----+----+----+----+----+----+----+----+----+-... | chunkID | fl | length | content +----+----+----+----+----+----+----+----+----+-...
+----+----+----+----+----+----+----+----+----+-... | chunkID| fl| 長さ| 内容+----+----+----+----+----+----+----+----+----+-...
or in ASN.1 syntax:
または、ASN.1構文で:
chunk ::= SEQUENCE
{
chunkID INTEGER (1..65535),
flags BIT STRING,
length OCTET STRING SIZE 3, -- or: INTEGER (0..16777215)
content OCTET STRING
}
塊:、:= 系列旗の長さのchunkID INTEGER(1 .65535)、BIT STRING、OCTET STRING SIZE3、または: INTEGER(0 .16777215)内容OCTET STRING
2.2 Structured chunk.
2.2は塊を構造化しました。
A structured chunk is marked as such by the flag byte (see 2.5). Opposed to an elementary chunk its content consists of a list of chunks (elementary or structured):
構造化された塊はフラグバイトによってそういうものとしてマークされます(2.5を見てください)。 基本の塊に反対されて、内容は塊(基本の、または、構造化された)のリストから成ります:
Wildgrube Informational [Page 3] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[3ページ]のRFC3072
+----+-+---+-------+-------+-------+-----+-------+ | id |f|len| chunk | chunk | chunk | ... | chunk | +----+-+---+-------+-------+-------+-----+-------+
+----+-+---+-------+-------+-------+-----+-------+ | イド|f|len| 塊| 塊| 塊| ... | 塊| +----+-+---+-------+-------+-------+-----+-------+
With the help of this concept you can reproduce every hierarchically structured data into a SDXF chunk.
この概念の助けで、あなたはあらゆる階層的で構造化されたデータをSDXF塊に再生させることができます。
2.3 Some Remarks about the internal representation of the chunk's
elements:
2.3 塊の要素の内部の表現の周りのいくつかのRemarks:
Binary values are always in high-order-first (big endian) format, like the binary values in the IP header (network format). A length of 300 (=256 + 32 + 12) is stored as
2進の値はいつも高値が最初に注文された(ビッグエンディアン)形式でIPヘッダー(ネットワーク形式)の2進の値に似ています。 (=256+32+12)が保存される300の長さ
+----+----+----+----+----+----+----+----+----+-- | | | 00 01 2C | content +----+----+----+----+----+----+----+----+----+--
+----+----+----+----+----+----+----+----+----+-- | | | 00 01、2C| 内容+----+----+----+----+----+----+----+----+----+--
in hexadecimal notation.
16進法で。
This is also valid for the chunk-ID.
また、塊IDに、これも有効です。
2.4 Character values in the content portion are also an object of
adaptation: see chapter 4.
また、満足している部分の2.4の文字値が適合の目的です: 第4章を見てください。
2.5 Meaning of the flag-bits: Let us represent the flag byte in this
manner:
2.5 フラグビットの意味: この様にフラグバイトを表しましょう:
+-+-+-+-+-+-+-+-+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
| | | | | | | |
| | | | | | | +-- reserved
| | | | | | +---- array
| | | | | +------ short chunk
| | | | +-------- encrypted chunk
| | | +---------- compressed chunk
| | |
+-+-+------------ data type (0..7)
+-+-+-+-+-+-+-+-+ |0|1|2|3|4|5|6|7| +-+-+-+-+-+-+-+-+ | | | | | | | | | | | | | | | +--予約されます。| | | | | | +---- 配列| | | | | +------ 短い塊| | | | +-------- 暗号化された塊| | | +---------- 圧縮された塊| | | +-+-+------------ データ型(0..7)
data types are:
データ型は以下の通りです。
0 -- pending structure (chunk is inconsistent, see also 11.1) 1 -- structure 2 -- bit string 3 -- numeric 4 -- character 5 -- float (ANSI/IEEE 754-1985)
0--未定の構造(塊は矛盾しています、と11.1も見る)1--構造2--ビット列3--数値4(キャラクタ5)は浮きます。(ANSI/IEEE754-1985)
Wildgrube Informational [Page 4] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[4ページ]のRFC3072
6 -- UTF-8 7 -- reserved
予約された6(UTF-8 7)
2.6 A short chunk has no data body. The 3 byte Length field is used as data bytes instead. This is used in order to save space when there are many small chunks.
2.6 短い塊には、データ本体が全くありません。 3バイトのLength分野は代わりにデータ・バイトとして使用されます。 これは、多くの小さい塊があるとき、記憶空間を節約するのに使用されています。
2.7 Compressed and encrypted chunks are explained in chapter 5 and 6.
2.7 圧縮されて暗号化された塊は第5章と第6章で説明されます。
2.8 Arrays are explained in chapter 7.
2.8の配列が第7章で説明されます。
2.9 Handling of UTF-8 is explained in chapter 9.
2.9 UTF-8の取り扱いは第9章で説明されます。
2.10 Not all combinations of bits are allowed or reasonable:
2.10 ビットのすべての組み合わせが、どんな許容されているか、または合理的であるというわけではありません:
- the flags 'array' and 'short' are mutually exclusive. - 'short' is not applicable for data type 'structure' and 'float'. - 'array' is not applicable for data type 'structure'.
- 旗'配列'で'短い'は互いに排他的です。 - '構造'と'浮遊物'というデータ型には、'短いこと'は適切ではありません。 - '構造'というデータ型には、'配列'は適切ではありません。
3. Introduction to the SDXF functions
3. SDXF機能への序論
3.1 General remarks
3.1 一般所見
The functionality of the SDXF concept is not bounded to any programming language, but of course the functions themselves must be coded in a particular language. I discuss these functions in C and C++, because in the meanwhile these languages are available on almost all platforms.
SDXF概念の機能性はどんなプログラミング言語にも境界がありませんが、もちろん、特定の言語で機能自体をコード化しなければなりません。 これらの言語がその間ほとんどすべてのプラットホームで利用可能であるので、私はCとC++におけるこれらの機能について議論します。
All these functions for reading and writing SDXF chunks uses only one parameter, a parameter structure. In C++ this parameter structure is part of the "SDXF class" and the SDXF functions are methods of this class.
1つのパラメタだけ、パラメタ構造をSDXF塊用途に読み込んで、書くためのこれらのすべての機能。 C++では、このパラメタ構造は「SDXFのクラス」の一部です、そして、SDXF機能はこのクラスのメソッドです。
An exact description of the interface is given in chapter 8.
第8章でインタフェースの正確な記述を与えます。
3.2 Writing a SDXF buffer
3.2 SDXFバッファを書くこと。
For to write SDXF chunks, there are following functions:
SDXFに塊を書くために次の機能があるので:
init -- initialize the parameter structure create -- create a new chunk leave -- "close" a structured chunk
イニット--構造が作成するパラメタを初期化してください--新しい塊休暇--構造化された塊を「閉じること」を作成してください。
Wildgrube Informational [Page 5] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[5ページ]のRFC3072
3.3 Reading a SDXF buffer
3.3 SDXFバッファを読むこと。
For to read SDXF chunks, there are following functions:
塊をSDXFに読み込むために次の機能があるので:
init -- initialize the parameter structure
enter -- "go into" a structured chunk
next -- "go to" the next chunk inside a structured chunk
extract -- extract the content of an elementary chunk into
user's data area
leave -- "go out" off a structured chunk
イニット--パラメタ構造を初期化するのに入る、--次のaが構造化した「入ってください」塊--「許可」構造化された塊抽出(ユーザのデータ領域への基本の塊の内容が残す抽出)における次の塊が構造化された塊から「出かける」
3.4 Example:
3.4の例:
3.4.1 Writing:
3.4.1 書くこと:
For demonstration we use a reduced (outlined) C++ Form of these functions with polymorph definitions:
デモンストレーションのために、私たちは多形結晶定義と共にこれらの機能の減少している(概説されている)C++Formを使用します:
void create (short chunkID); // opens a new structure,
void create (short chunkID, char *string);
// creates a new chunk with dataType character, etc.)
空間は(短いchunkID)を作成します。 //は新しい構造を開けて、空間は(短いchunkID、炭*ストリング)を作成します。 //がdataTypeキャラクタなどで新しい塊を作成する、)
The sequence:
系列:
SDXF x(new); // create the SDXF object "x" for a new chunk
// includes the "init"
x.create (3301); // opens a new structure
x.create (3302, "first chunk");
x.create (3303, "second chunk");
x.create (3304); // opens a new structure
x.create (3305, "chunk in a structure");
x.create (3306, "next chunk in a structure");
x.leave (); // closes the inner structure
x.create (3307, "third chunk");
x.leave (); // closes the outer structure
SDXF x(新しい)。 新しい塊//がx.が作成する「イニット」(3301)を含んでいるので、//はSDXFオブジェクト「x」を作成します。 //はx.が作成する新しい構造(3302、「最初に、塊」)を開けます。 x. (3303、「2番目の塊」)を作成してください。 x. (3304)を作成してください。 //はx.が作成する新しい構造(3305、「構造の塊」)を開けます。 x. (3306、「構造の次の塊」)を作成してください。 x. 休暇()。 内側の構造x.が作成する//閉鎖(3307、「3番目の塊」)。 x. 休暇()。 //は表面構造を閉じます。
Wildgrube Informational [Page 6] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[6ページ]のRFC3072
creates a chunk which we can show graphically like:
私たちが図解できる塊を作成します:
3301
|
+--- 3302 = "first chunk"
|
+--- 3303 = "second chunk"
|
+--- 3304
| |
| +--- 3305 = "chunk in a structure"
| |
| +--- 3306 = "next chunk in a structure"
|
+--- 3307 = "last chunk"
3301 | +--- 3302は「最初の塊」と等しいです。| +--- 3303は「2番目の塊」と等しいです。| +--- 3304 | | | +--- 3305は「構造の塊」と等しいです。| | | +--- 3306は「構造の次の塊」と等しいです。| +--- 3307は「最後の塊」と等しいです。
3.4.2 Reading
3.4.2 読書
A typically access to a structured SDXF chunk is a selection inside a loop:
Aは構造化されたSDXFにaに通常アクセスします。塊は輪で選択です:
SDXF x(old); // defines a SDXF object "x" for an old chunk x.enter (); // enters the structure
SDXF x(古い)。 古い塊x.が()に入るので、//はSDXFオブジェクト「x」を定義します。 //は構造に入ります。
while (x.rc == 0) // 0 == ok, rc will set by the SDXF functions
{
switch (x.chunkID)
{
case 3302:
x.extract (data1, maxLength1);
// extr. 1st chunk into data1
break;
=がSDXF機能でOKに、rcに設定する//0をゆったり過ごしてください、(x.rc=0)(x.chunkID)を切り換えてください、(data1、maxLength1)を抽出してください; //extr3302をケースに入れてください: x.、最初のdata1中断までの塊
case 3303:
x.extract (data2, maxLength2);
// extr. 2nd chunk into data2
break;
ケース3303: x. 抽出(data2、maxLength2)。 //extr。 2番目のdata2中断までの塊。
case 3304: // we know this is a structure
x.enter (); // enters the inner structure
ケース3304: //、私たちは、これによるa構造x.が()に入るということであることを知っています。 //は構造を記録します。
while (x.rc == 0) // inner loop
{
switch (x.chunkID)
{
case 3305:
x.extract (data3, maxLength3);
// extr. the chunk inside struct.
//内側の輪をゆったり過ごしてください、(x.rc=0)(x.chunkID)を切り換えてください、(data3、maxLength3)を抽出してください; //extr3305をケースに入れてください: x.、structの中の塊。
Wildgrube Informational [Page 7] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[7ページ]のRFC3072
break;
case 3306:
x.extract (data4, maxLength4);
// extr. 2nd chunk inside struct.
break;
}
x.next (); // returns x.rc == 1 at end of structure
} // end-while
break;
壊れてください。 ケース3306: x. 抽出(data4、maxLength4)。 //extr。 struct休み中の2番目の塊。 x. 次の()。 //リターンx.は構造の端で=1をrcします。 //は中断を終わりでゆったり過ごします。
case 3307:
x.extract (data5, maxLength5);
// extract last chunk into data
break;
// default: none - ignore unknown chunks !!!
ケース3307: x. 抽出(data5、maxLength5)。 データへの最後の塊が壊す//抽出。 //デフォルト: なにも--未知の塊を無視してください!
} // end-switch
x.next (); // returns x.rc = 1 at end of structure
} // end-while
} //はx. 次の()を終わりで切り換えます。 //リターンx.は構造の端で=1をrcします。 /が終わりでゆったり過ごす/
4. Platform independence
4. プラットホーム独立
The very most of the computer platforms today have a 8-Bits-in-a-Byte architecture, which enables data exchange between these platforms. But there are two significant points in which platforms may be different:
コンピュータの大部分が今日載せるまさしくそのは1バイトにおける8ビットのアーキテクチャを持っています。(それは、これらのプラットホームの間のデータ交換を可能にします)。しかし、プラットホームが異なるかもしれない2つの特異点があります:
a) The representation of binary numerical (the short and long int and
floats).
a) バイナリーの表現、数字です(脆くて長いintと浮遊物)。
b) The representation of characters (ASCII/ANSI vs. EBCDIC)
b) キャラクタの表現(ASCII/ANSI対EBCDIC)
Point (a) is the phenomenon of "byte swapping": How is a short int value 259 = 0x0103 = X'0103' be stored at address 4402?
ポイント(a)は「バイトスワッピング」の現象です: 短いint値259=0×0103=X'0103'がいかがである、アドレス4402では、保存されますか?
The two flavours are:
2つの風味は以下の通りです。
4402 4403 01 03 the big-endian, and 03 01 the little-endian.
4402 4403 01 03、ビッグエンディアン、03 01はリトルエンディアンをそうします。
Point (b) is represented by a table of the assignment of the 256 possible values of a Byte to printable or control characters. (In ASCII the letter "A" is assigned to value (or position) 0x41 = 65, in EBCDIC it is 0xC1 = 193.)
ポイント(b)は印刷可能へのByteか制御文字の256の可能な値の課題のテーブルによって表されます。 (ASCIIでは、文字「A」は値(または、位置)の0×41=65に割り当てられて、それはEBCDICでは、0xC1=193です。)
Wildgrube Informational [Page 8] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[8ページ]のRFC3072
The solution of these problems is to normalize the data:
これらの問題の解決はデータを正常にすることです:
We fix:
私たちは修理します:
(a) The internal representation of binary numerals are 2-complements
in big-endian order.
(a) 2進の数字の内部の表現はビッグエンディアンオーダーで2補数です。
(b) The internal representation of characters is ISO 8859-1 (also
known as Latin 1).
(b) キャラクタの内部の表現はISO8859-1です(また、ラテン語1として、知られています)。
The fixing of point (b) should be regarded as a first strike. In some environment 8859-1 seems not to be the best choice, in a greek or russian environment 8859-5 or 8859-7 are appropriate.
ポイント(b)の修理は先制攻撃と見なされるべきです。 いくつかでは、環境8859-1がgreekで最も良い選択でないように思えるか、またはrussian環境は8859-5か8859-7に適切です。
Nevertheless, in a specific group (or world) of applications, that is to say all the applications which wants to interchange data with a defined protocol (via networking or diskette or something else), this internal character table must be unique.
それにもかかわらず、すなわち、アプリケーション、定義されたプロトコル(ネットワーク、ディスケットまたは他の何かを通した)、この内部の指標表でデータを交換する必需品がそうしなければならないすべてのアプリケーションの特定のグループ(世界的である)では、ユニークであってください。
So a possibility to define a translation table (and his inversion) should be given.
それで、変換テーブル(そして、彼の逆)を定義する可能性を与えるべきです。
Important: You construct a SDXF chunk not for a specific addressee, but you adapt your data into a normalized format (or network format).
重要: どんな特定の受け取り人にもSDXF塊を構成しませんが、あなたは正常にされた形式(または、ネットワーク形式)にデータを適合させます。
This adaption is not done by the programmer, it will be done by the create and extract function. An administrator has take care of defining the correct translation tables.
プログラマがこの適応を完了していなくて、それでする、機能を作成して、抽出してください。 管理者には、正しい訳を定義する注意が見送る撮影があります。
5. Compression
5. 圧縮
As stated in 2.5 there is a flag bit which declares that the following data (elementary or structured) are compressed. This data is not further interpretable until it is decompressed. Compression is transparently done by the SDXF functions: "create" does the compression for elementary chunks, "leave" for structured chunks, "extract" does the decompression for elementary chunks, "enter" for structured chunks.
2.5で述べられているように、以下のデータ(基本の、または、構造化された)が圧縮されると宣言するフラグビットがあります。 それが減圧されるまで、このデータはさらに解明できません。 透明に、SDXF機能で、圧縮します: 「作成」は基本の塊、構造化された塊のための「休暇」のために圧縮して、「抽出」は基本の塊のための減圧、構造化された塊のための「入ってください」をします。
Transparently means that the programmer has only to tell the SDXF functions that he want compress the following chunk(s).
透明に、プログラマが彼が欲しいとSDXF機能に言うためだけに持っている手段は以下の塊を圧縮します。
For choosing between different compression methods and for controlling the decompressed (original) length, there is an additional definition:
異なった圧縮方法を選んで、減圧された(オリジナルの)長さを制御するために、追加定義があります:
Wildgrube Informational [Page 9] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[9ページ]のRFC3072
After the chunk header for a compressed chunk, a compression header is following:
圧縮ヘッダーは圧縮された塊のための塊ヘッダーの、あとについて行っています:
+-----------------------+---------------+----------------> | chunk header | compr. header | compressed data +---+---+---+---+---+---+---+---+---+---+----------------> |chunkID|flg| length |md | orglength | +---+---+---+---+---+---+---+---+---+---+---------------->
+-----------------------+---------------+---------------->| 塊ヘッダー| comprヘッダー| 圧縮されたデータ+---+---+---+---+---+---+---+---+---+---+---------------->| chunkID|flg| 長さ|Md| orglength| +---+---+---+---+---+---+---+---+---+---+---------------->。
- 'orglength' is the original (decompressed) length of the data.
- 'orglength'はデータの元(減圧される)の長さです。
- 'md' is the "compression method": Two methods are described here:
- 'Md'は「圧縮方法」です: 2つの方法がここで説明されます:
# method 01 for a simple (fast but not very effective)
"Run Length 1" or "Byte Run 1" algorithm. (More then two
consecutive identical characters are replaced by the number of
these characters and the character itself.)
# 方法01、aにおける簡単(速い、しかし、非常に効果的でない)である、「ランレングス1インチか「バイトの走行の1インチのアルゴリズム。」 (さらに次に、2つの連続した同じキャラクタをこれらのキャラクタとキャラクタ自体の数に取り替えます。)
more precisely:
より正確:
The compressed data consists of several sections of various
length. Every section starts with a "counter" byte, a signed
"tiny" (8 bit) integer, which contains a length information.
圧縮されたデータは数人のセクションの様々な長さから成ります。 あらゆるセクションが「カウンタ」バイト、長さの情報を含む(8ビット)のサインされた「小さい」整数から始まります。
If this byte contains the value "n",
with n >= 0 (and n <128), the next n+1 bytes will be taken
unchanged;
with n < 0 (and n > -128), the next byte will be replicated
-n+1 times;
n = -128 will be ignored.
このバイトが値「n」を含んでいると、n>=0(そして、n<128)で、変わりがない状態で次のn+1バイトを取るでしょう。 n<0(そして、n>-128)で、次のバイトは+1回模写されたnになるでしょう。 n=-128は無視されるでしょう。
Appending blanks will be cutted in general. If these are
necessary, they can be reconstructed while "extract"ing with
the parameter field "filler" (see 8.2.1) set to space
character.
一般に、空白を追加するのはcuttedされるでしょう。 これらが必要であるなら、分野「フィラー」というパラメタがある「抽出」ingである間、それらを再建できる、(見る、8.2、.1、)、間隔文字にセットしてください。
# method 02 for the wonderful "deflate" algorithm which comes
from the "zip"-people.
The authors are:
Jean-loup Gailly (deflate routine),
Mark Adler (inflate routine), and others.
# 素晴らしさのための方法02は「ファスナ」人々から来るアルゴリズムに「空気を抜かせます」。 作者は以下の通りです。 ジャンルー・ゲイル(ルーチンに空気を抜かせる)、マーク・アドラー(ルーチンをふくらませる)、および他のもの。
The deflate format is described in [DEFLATE].
形式に空気を抜かせてください。[DEFLATE]では、説明されます。
The values for the compression method number are maintained by
IANA, see chap. 12.1.
数がIANAによって主張されて、ひびが切れるのを見る圧縮方法のための値。 12.1.
Wildgrube Informational [Page 10] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[10ページ]のRFC3072
6. Encryption
6. 暗号化
As stated in 2.5 there is a flag bit which declares that the following data (elementary or structured) is encrypted. This data is not interpretable until it is decrypted. En/Decryption is transparently done by the SDXF functions, "create" does the encryption for elementary chunks, "leave" for structured chunks, "extract" does the decryption for elementary chunks, "enter" for structured chunks. (Yes it sounds very similar to chapter 5.) More then one encryption method for a given range of applications is not very reasonable. Some encryption algorithms work with block ciphering algorithms. That means that the length of the data to encrypt must be rounded up to the next multiple of this block length. This blocksize (zero means non-blocking) is reported by the encryption interface routine (addressed by the option field *encryptProc, see chapter 8.5) with mode=3. If blocking is used, at least one byte is added, the last byte of the lengthening data contains the number of added bytes minus one. With this the decryption interface routine can calculate the real data length.
2.5で述べられているように、以下のデータ(基本の、または、構造化された)がコード化されていると宣言するフラグビットがあります。 それが解読されるまで、このデータは解明できません。 SDXF機能で透明にアン/復号化をして、「作成」は基本の塊、構造化された塊のための「休暇」のための暗号化をして、「抽出」は基本の塊のための復号化、構造化された塊のための「入ってください」をします。 (はい、それは第5)章と非常に同様に聞こえます。 与えられた範囲のアプリケーションのための、より多くの次に、1つの暗号化の方法はそれほど合理的ではありません。 ブロックがアルゴリズムを解いていて、いくつかの暗号化アルゴリズムが利きます。それは、コード化するデータの長さをこのブロック長の次の倍数まで一周させなければならないことを意味します。 これはblocksizeされます(ゼロは非ブロッキングであることを意味します)。暗号化インタフェースルーチン(オプション・フィールド*encryptProcによって記述されています、第8.5章を見る)で、モード=3で報告されます。 ブロッキングが使用されているなら、少なくとも1バイトは加えられて、伸すデータの最後のバイトは1を引いて加えられたバイトの数を含んでいます。 これによる復号化インタフェースルーチンは本当のデータの長さについて計算できます。
If an application (or network connect handshaking protocol) needs to negotiate an encryption method it should be used a method number maintained by IANA, see chap. 12.2.
アプリケーション(ネットワークはハンドシェイクプロトコルを接続する)が、それが暗号化方法であるべきであることを交渉する必要があるなら、使用されて、方法番号は、IANAでやつを見るように主張しました。 12.2.
Even the en/decryption is done transparently, an encryption key
(password) must be given to the SDXF functions. Encryption is done
after translating character data into, decryption is done before
translation from the internal ("network-") format.
アン/復号化さえ透明に完了していて、暗号化キー(パスワード)をSDXF機能に与えなければなりません。 キャラクタデータを翻訳した後に暗号化をする、内部の(「ネットワーク」)形式からの翻訳の前に復号化をします。
If both, encryption and compression are applied on the same chunk, compression is done first - compression on good encrypted data (same strings appears as different after encryption) tends to zero compression rates.
同じ塊で両方、暗号化、および圧縮を適用するなら、最初に、圧縮します--良いコード化されたデータ(同じストリングは暗号化の後異なるとして現れる)における圧縮は、圧縮率のゼロを合わせる傾向があります。
7. Arrays
7. アレイ
An array is a sequence of chunks with identical chunk-ID, length and data type.
アレイは同じ塊ID、長さ、およびデータ型がある塊の系列です。
At first a hint: in principle a special definition in SDXF for such an array is not really necessary:
最初に、ヒントのときに: 原則として、そのようなアレイへのSDXFとの特別な定義は本当に必要ではありません:
It is not forbidden that there are more than one chunk with equal chunk-ID within the same structured chunk.
それはそこで同じ構造化された塊の中に等しい塊IDがある1つ以上の塊がそうであることが禁じられません。
Therefore with a sequence of SDX_next / SDX_extract calls one can fill the destination array step by step.
したがって、SDX_の系列が次である場合、/SDX_抽出呼び出し1は一歩一歩目的地アレイをいっぱいにすることができます。
Wildgrube Informational [Page 11] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[11ページ]のRFC3072
If there are many occurrences of chunks with the same chunk-ID (and a comparative small length), the overhead of the chunk-packages may be significant.
同じ塊ID(比較わずかな長さ)との塊の多くの発生があれば、塊パッケージのオーバーヘッドは重要であるかもしれません。
Therefore the array flag is introduced. An array chunk has only one chunk header for the complete sequence of elementary chunks. After the chunk header for an array chunk, an array header is following:
したがって、アレイ旗を導入します。 アレイ塊には、基本の塊の完全な配列のための1個の塊ヘッダーしかありません。 アレイヘッダーはアレイ塊のための塊ヘッダーの、あとについて行っています:
This is a short integer (big endian!) which contains the number of the array elements (CT). Every element has a fixed length (EL), so the chunklength (CL) is CL = EL * CT + 2.
これは配列の要素(コネチカット)の数を含む短い整数(ビッグエンディアン!)です。 あらゆる要素には固定長(EL)があるので、chunklength(CL)はCL=EL*コネチカット+2です。
The data elements follows immediately after the array header.
データ要素はアレイヘッダー直後従います。
The complete array will be constructed by SDX_create, the complete array will be read by SDX_extract.
完全なアレイはSDXによって構成されるでしょう。_が作成する、完全なアレイはSDX_抽出で読まれるでしょう。
The parameter fields (see 8.2.1) 'dataLength' and 'count' are used for the SDXF functions 'extract' and 'create':
パラメタがさばく、(見る、8.2、.1、)、'dataLength'と'カウント'は機能が'抽出し'て、'作成する'SDXFに使用されます:
Field 'dataLength' is the common length of the array elements, 'count' is the actual dimension of the array for 'create' (input).
分野'dataLength'が配列の要素の一般的な長さである、'カウント'は'作成(入力)'のためのアレイの実サイズです。
For the 'extract' function 'count' acts both as an input and output parameter:
'抽出'のために、機能'カウント'は入力と出力パラメタとして機能します:
Input : the maximum dimension output: the actual array dimension.
以下を入力してください。 最大の寸法出力: 実際のアレイの重要性。
(If output count is greater than input count, the 'data cutted' warning will be responded and the destination array is filled up to the maximum dimension.)
(出力カウントが入力カウントより大きいなら、'データはcuttedした'という警告が反応して、目的地アレイは最大の寸法までいっぱいにされます。)
8. Description of the SDXF functions
8. SDXF機能の記述
8.1 Introduction
8.1 序論
Following the principles of Object Oriented Programming, not only the description of the data is necessary, but also the functions which manipulate data - the "methods".
Object Oriented Programmingでは、データの記述だけは必要でないという原則に従うしかし、データを操作する機能も--「方法。」
For the programmer knowing the methods is more important than knowing the data structure, the methods has to know the exact specifications of the data and guarantees the consistence of the data while creating them.
プログラマに関しては、方法を知っているのは、データの正確な仕様を知るためにデータ構造、方法を知っているのがそうしたより重要であり、それらを作成している間、データの一貫性を保証します。
Wildgrube Informational [Page 12] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[12ページ]のRFC3072
A SDXF object is an instance of a parameter structure which acts as a programming interface. Especially it points to an actual SDXF data chunk, and, while processing on this data, there is a pointer to the actual inner chunk which will be the focus for the next operation.
SDXF物はプログラミングインターフェースとして作用するパラメタ構造の例です。 実際のSDXFデータ塊を示します、そして、このデータで処理している間、次の操作のために焦点になる実際の内側の塊へのポインタがあります。
The benefit of an exact interface description is the same as using for example the standard C library functions: By using standard interfaces your code remains platform independent.
正確なインタフェース記述の恩恵は例えば標準のCライブラリ関数を使用するのと同じです: 標準インターフェースを使用することによって、あなたのコードはプラットホーム独立者のままで残っています。
8.2 Basic definitions
8.2 基本的な定義
8.2.1 The SDXF Parameter structure
8.2.1 SDXF Parameter構造
All SDXF access functions need only one parameter, a pointer to the SDXF parameter structure:
すべてのSDXFアクセス関数がSDXFパラメタ構造に1つのパラメタだけ、ポインタを必要とします:
First 3 prerequisite definitions:
最初の3つの必須の定義:
typedef short int ChunkID; typedef unsigned char Byte;
typedefの短いint ChunkID。 typedefの無記名の炭のByte。
typedef struct Chunk
{
ChunkID chunkID;
Byte flags;
char length [3];
Byte data;
} Chunk;
typedef struct Chunk ChunkID chunkID; バイト旗; 炭の長さ[3]; バイトデータ;塊。
And now the parameter structure:
現在のパラメタ構造:
typedef struct
{
ChunkID chunkID; // name (ID) of Chunk
Byte *container; // pointer to the whole Chunk
long bufferSize; // size of container
Chunk *currChunk; // pointer to actual Chunk
long dataLength; // length of data in Chunk
long maxLength; // max. length of Chunk for SDX_extract
long remainingSize; // rem. size in cont. after SDX_create
long value; // for data type numeric
double fvalue; // for data type float
char *function; // name of the executed SDXF function
Byte *data; // pointer to Data
Byte *cryptkey; // pointer to Crypt Key
short count; // (max.) number of elements in an array
short dataType; // Chunk data type / init open type
short ec; // extended return-code
typedef struct、ChunkID chunkID; Chunk Byte*容器の//名前(ID); 全体のChunk長いbufferSizeへの//ポインタ; 容器Chunk*currChunkの//サイズ; 実際のChunk長いdataLengthへの//ポインタ; Chunkの長いmaxLengthのデータの//長さ; //最大SDX_抽出の長いremainingSizeのためのChunkの長さ; //レムcont後SDXの_のサイズは長い値を作成します; データ型の数値二重fvalueのための//; データ型浮遊物の炭*機能のための//; 実行されたSDXF機能Byte*データの//名前; Data Byte*cryptkeyへの//ポインタ; Crypt Keyの短いカウントへの//ポインタ; アレイ短いdataType; //塊データ型/イニット開放型の短いec;//拡張している復帰コードの要素の//(最大)番号
Wildgrube Informational [Page 13] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[13ページ]のRFC3072
short rc; // return-code
short level; // level of hierarchy
char filler; // filler char for SDX_extract
Byte encrypt; // Indication if data to encrypt (0 / 1)
Byte compression; // compression method
// (00=none, 01=RL1, 02=zip/deflate)
} SDX_obj, *SDX_handle;
短いrc。 //復帰コードの短いレベル。 階層構造炭のフィラーの//レベル。 Byteがコード化するSDX_抽出のための//フィラー炭。 //指示、(0/1)バイトの圧縮をコード化するデータであるなら。 //圧縮方法//(01=RL1、02=は、00がなにもと等しくなく、ファスナーで閉めるか、または空気を抜きます) SDX_obj、*SDX_ハンドル。
Only the "public" fields of the parameter structure which acts as input and output for the SDXF functions is described here. A given implementation may add some "private" fields to this structure.
SDXF機能のために入出力されるように作用するパラメタ構造の「公共」の分野だけがここで説明されます。 与えられた実現はいくつかの「個人的な」分野をこの構造に追加するかもしれません。
8.2.2 Basic Functions
8.2.2 基本機能
All these functions works with a SDX_handle as the only formal parameter. Every function returns as output ec and rc as a report of success. For the values for ec, rc and dataType see chap. 8.4.
SDX_がある作品が唯一の仮パラメタとして扱うこれらのすべての機能。 成功のレポートとしてecとrcを出力するとき、あらゆる機能が戻ります。 ecのための値に関しては、rcとdataTypeはやつを見ます。 8.4.
1. SDX_init : Initialize the parameter structure.
1. SDX_イニット: パラメタ構造を初期化してください。
input : container, dataType, bufferSize (for dataType =
SDX_NEW only)
output: currChunk, dataLength (for dataType = SDX_OLD only),
ec, rc,
the other fields of the parameter structure will be
initialized.
以下を入力してください。 容器、dataType、bufferSize(dataType=SDX_NEWだけのための)出力: currChunk(dataLength(dataType=SDX_OLDだけのための)、ec、パラメタの他の分野が構造化するrc)は初期化されるでしょう。
2. SDX_enter : Enter a structured chunk.
You can access the first chunk inside this structured chunk.
input : none
output: currChunk, chunkID, dataLength, level, dataType,
ec, rc
2. SDX_に入ります: 構造化された塊に入ってください。 この構造化された塊で最初の塊にアクセスできます。以下を入力してください。 なにも以下を出力しません。 currChunk、chunkID、dataLength、レベル、dataType、ec、rc
3. SDX_leave : Leave the actual entered structured chunk.
input : none
output: currChunk, chunkID, dataLength, level, dataType,
ec, rc
3. SDX_休暇: 実際の入られた構造化された塊を残してください。以下を入力してください。 なにも以下を出力しません。 currChunk、chunkID、dataLength、レベル、dataType、ec、rc
4. SDX_next : Go to the next chunk inside a structured chunk.
input : none
output: currChunk, chunkID, dataLength, dataType, count, ec, rc
4. 次のSDX_: 構造化された塊で次の塊に行ってください。以下を入力してください。 なにも以下を出力しません。 currChunk、chunkID、dataLength、dataType、カウント、ec、rc
At the end of a structured chunk SDX_next returns rc =
SDX_RC_failed and ec = SDX_EC_eoc (end of chunk)
The actual structured chunk is SDX_leave'd automatically.
SDX_EC_次のSDX_がSDX_RC_が失敗したrc=とecを返す構造化された塊の終わり=eoc(塊の終わり)では、実際の構造化された塊は休暇が自動的にそうするSDX_です。
Wildgrube Informational [Page 14] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[14ページ]のRFC3072
5. SDX_extract : Extract data of the actual chunk.
(If actual chunk is structured, only a copy is done, elsewhere
the data is converted to host format.)
input / output depends on the dataType:
5. SDX_抽出: 実際の塊に関するデータを抜粋してください。 (実際の塊を構造化する場合にだけ、データがホスト形式に変換されるほかの場所では、コピーします。) 入力/出力はdataTypeによります:
if dataType is structured, binary or char:
input : data, maxLength, count, filler
output: dataLength, count, ec, rc
dataTypeは構造化されるか、そして、バイナリーか炭: 以下を入力してください。 データ(maxLength)は重要であり、フィラーは出力です: dataLength、カウント、ec、rc
if dataType is numeric (float resp.):
input : none
output: value (fvalue resp.), ec, rc
dataTypeが数値であるなら(respを浮かべてください。): 以下を入力してください。 なにも以下を出力しません。 値(fvalue resp)、ec、rc
6. SDX_select : Go to the (next) chunk with a given chunkID.
input : chunkID
output: currChunk, dataLength, dataType, ec, rc
6. SDX_選ぶ: 与えられたchunkIDを(次)の塊に伴ってください。以下を入力してください。 chunkID出力: currChunk、dataLength、dataType、ec、rc
7. SDX_create : Creating a new chunk (at the end of the actual
structured chunk).
input : chunkID, dataLength, data, (f)value, dataType,
compression, encrypt, count
update: remainingSize, level
output: currChunk, dataLength, ec, rc
7. SDX_は以下を作成します。 作成a新しい塊(実際の構造化された塊の終わりの)以下を入力してください。 chunkID(dataLength、データ、dataType(圧縮)がコード化する(f)値)はアップデートを数えます: remainingSizeする、レベルは以下を出力します。 currChunk、dataLength、ec、rc
8. SDX_append : Append a complete chunk at the end of the actual
structured chunk).
input : data, maxLength, currChunk
update: remainingSize, level
output: chunkID, chunkLength, maxLength, dataType, ec, rc
8. SDX_は以下を追加します。 実際の構造化された塊) . 入力の終わりに完全な塊を追加してください: データ、currChunkがアップデートするmaxLength: remainingSizeする、レベルは以下を出力します。 chunkID、chunkLength、maxLength、dataType、ec、rc
8.3 Definitions for C++
8.3 C++のための定義
This is the specification of the SDXF class in C++: (The type 'Byte' is defined as "unsigned char" for bitstrings, opposed to "signed char" for character strings)
これはC++におけるSDXFのクラスの仕様です: (タイプ'バイト'は文字列のために「サインされた炭」に反対されたbitstringsのための「無記名の炭」と定義されます)
class C_SDXF
{
public:
_クラスC SDXF、公衆:
// constructors and destructor:
C_SDXF (); // dummy
C_SDXF (Byte *cont); // old container
C_SDXF (Byte *cont, long size); // new container
C_SDXF (long size); // new container
~C_SDXF ();
// methods:
//建設者と塵芥焼却炉: C_SDXF()。 _//ダミーC SDXF(バイト*cont)。 _//古い容器C SDXF(バイト*cont、長いサイズ)。 _//新しい容器C SDXF(長いサイズ)。 //新しい容器~C_SDXF()。 //方法:
Wildgrube Informational [Page 15] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[15ページ]のRFC3072
void init (void); // old container
void init (Byte *cont); // old container
void init (Byte *cont, long size); // new container
void init (long size); // new container
イニット(空間)を欠如させてください。 容器の//古い空間イニット(バイト*cont)。 容器の//古い空間イニット(バイト*cont、長いサイズ)。 容器の//新しい空間イニット(長いサイズ)。 //新しい容器
void enter (void);
void leave (void);
void next (void);
long extract (Byte *data, long length); // chars, bits
long extract (void); // numeric data
void create (ChunkID); // structured
void create (ChunkID, long value); // numeric
void create (ChunkID, double fvalue); // float
void create (ChunkID, Byte *data, long length);// binary
void create (ChunkID, char *data); // chars
void set_compression (Byte compression_method);
void set_encryption (Byte *encryption_key);
void enter (void); void leave (void); void next (void); long extract (Byte *data, long length); // chars, bits long extract (void); // numeric data void create (ChunkID); // structured void create (ChunkID, long value); // numeric void create (ChunkID, double fvalue); // float void create (ChunkID, Byte *data, long length);// binary void create (ChunkID, char *data); // chars void set_compression (Byte compression_method); void set_encryption (Byte *encryption_key);
// interface:
// interface:
ChunkID id; // see 8.4.1
short dataType; // see 8.4.2
long length; // length of data or chunk
ChunkID id; // see 8.4.1 short dataType; // see 8.4.2 long length; // length of data or chunk
long value;
double fvalue;
short rc; // the raw return code see 8.4.3
short ec; // the extended return code see 8.4.4
long value; double fvalue; short rc; // the raw return code see 8.4.3 short ec; // the extended return code see 8.4.4
protected:
// implementation dependent ...
protected: // implementation dependent ...
};
};
8.4 Common Definitions:
8.4 Common Definitions:
8.4.1 Definition of ChunkID:
8.4.1 Definition of ChunkID:
typedef short ChunkID;
typedef short ChunkID;
8.4.2 Values for dataType:
8.4.2 Values for dataType:
SDX_DT_inconsistent = 0 SDX_DT_structured = 1 SDX_DT_binary = 2 SDX_DT_numeric = 3 SDX_DT_char = 4 SDX_DT_float = 5
SDX_DT_inconsistent = 0 SDX_DT_structured = 1 SDX_DT_binary = 2 SDX_DT_numeric = 3 SDX_DT_char = 4 SDX_DT_float = 5
Wildgrube Informational [Page 16] RFC 3072 Structured Data Exchange Format March 2001
Wildgrube Informational [Page 16] RFC 3072 Structured Data Exchange Format March 2001
SDX_DT_UTF8 = 6
SDX_DT_UTF8 = 6
data types for SDX_init:
SDX_OLD = 1
SDX_NEW = 2
data types for SDX_init: SDX_OLD = 1 SDX_NEW = 2
8.4.3 Values for rc:
8.4.3 Values for rc:
SDX_RC_ok = 0 SDX_RC_failed = 1 SDX_RC_warning = 1 SDX_RC_illegalOperation = 2 SDX_RC_dataError = 3 SDX_RC_parameterError = 4 SDX_RC_programError = 5 SDX_RC_noMemory = 6
SDX_RC_ok = 0 SDX_RC_failed = 1 SDX_RC_warning = 1 SDX_RC_illegalOperation = 2 SDX_RC_dataError = 3 SDX_RC_parameterError = 4 SDX_RC_programError = 5 SDX_RC_noMemory = 6
8.4.4 Values for ec:
8.4.4 Values for ec:
SDX_EC_ok = 0 SDX_EC_eoc = 1 // end of chunk SDX_EC_notFound = 2 SDX_EC_dataCutted = 3 SDX_EC_overflow = 4 SDX_EC_wrongInitType = 5 SDX_EC_comprerr = 6 // compression error SDX_EC_forbidden = 7 SDX_EC_unknown = 8 SDX_EC_levelOvflw = 9 SDX_EC_paramMissing = 10 SDX_EC_magicError = 11 SDX_EC_not_consistent = 12 SDX_EC_wrongDataType = 13 SDX_EC_noMemory = 14 SDX_EC_error = 99 // rc is sufficiently
SDX_EC_ok = 0 SDX_EC_eoc = 1 // end of chunk SDX_EC_notFound = 2 SDX_EC_dataCutted = 3 SDX_EC_overflow = 4 SDX_EC_wrongInitType = 5 SDX_EC_comprerr = 6 // compression error SDX_EC_forbidden = 7 SDX_EC_unknown = 8 SDX_EC_levelOvflw = 9 SDX_EC_paramMissing = 10 SDX_EC_magicError = 11 SDX_EC_not_consistent = 12 SDX_EC_wrongDataType = 13 SDX_EC_noMemory = 14 SDX_EC_error = 99 // rc is sufficiently
8.5 Special functions
8.5 Special functions
Besides the basic definitions there is a global function (SDX_getOptions) which returns a pointer to a global table of options.
Besides the basic definitions there is a global function (SDX_getOptions) which returns a pointer to a global table of options.
With the help of these options you can adapt the behaviour of SDXF. Especially you can define an alternative pair of translation tables or an alternative function which reads these tables from an external resource (p.e. from disk).
With the help of these options you can adapt the behaviour of SDXF. Especially you can define an alternative pair of translation tables or an alternative function which reads these tables from an external resource (p.e. from disk).
Wildgrube Informational [Page 17] RFC 3072 Structured Data Exchange Format March 2001
Wildgrube Informational [Page 17] RFC 3072 Structured Data Exchange Format March 2001
Within this table of options there is also a pointer to the function which is used for encryption / decryption: You can install your own encryption algorithm by setting this pointer.
Within this table of options there is also a pointer to the function which is used for encryption / decryption: You can install your own encryption algorithm by setting this pointer.
The options pointer is received by:
The options pointer is received by:
SDX_TOptions *opt = SDX_getOptions ();
SDX_TOptions *opt = SDX_getOptions ();
With:
With:
typedef struct
{
Byte *toHost; // Trans tab net -> host
Byte *toNet; // Trans tab host -> net
int maxlevel; // highest possible level
int translation; // translation net <-> host
// is in effect=1 or not=0
TEncryptProc *encryptProc; // alternate encryption routine
TGetTablesProc *getTablesProc; // alternate routine defining
// translation Tables
TcvtUTF8Proc *convertUTF8; // routine to convert to/from UTF-8
} SDX_TOptions;
typedef struct { Byte *toHost; // Trans tab net -> host Byte *toNet; // Trans tab host -> net int maxlevel; // highest possible level int translation; // translation net <-> host // is in effect=1 or not=0 TEncryptProc *encryptProc; // alternate encryption routine TGetTablesProc *getTablesProc; // alternate routine defining // translation Tables TcvtUTF8Proc *convertUTF8; // routine to convert to/from UTF-8 } SDX_TOptions;
typedef long TencryptProc (
int mode, // 1= to encrypt, 2= to decrypt, 3= encrypted length
Byte *buffer, // data to en/decrypt
long len, // len: length of buffer
char *passw); // Password
typedef long TencryptProc ( int mode, // 1= to encrypt, 2= to decrypt, 3= encrypted length Byte *buffer, // data to en/decrypt long len, // len: length of buffer char *passw); // Password
// returns length of en/de-crypted data
// (parameter buffer and passw are ignored for mode=3)
// returns blocksize for mode=3 and len=0.
// blocksize is zero for non-blocking algorithms
// returns length of en/de-crypted data // (parameter buffer and passw are ignored for mode=3) // returns blocksize for mode=3 and len=0. // blocksize is zero for non-blocking algorithms
typedef int TGetTablesProc (Byte **toNet, Byte **toHost);
// toNet, toHost: pointer to output params. Both params
// points to translation tables of 256 Bytes.
// returns success: 1 = ok, 0 = error.
typedef int TGetTablesProc (Byte **toNet, Byte **toHost); // toNet, toHost: pointer to output params. Both params // points to translation tables of 256 Bytes. // returns success: 1 = ok, 0 = error.
typedef int TcvtUTF8Proc
( int mode, // 1 = to UTF-8, 2 = from UTF-8
Byte *target, int *targetlength, // output
Byte *source, int sourcelength); // input
// targetlength contains maximal size as input param.
// returns success: 1 = ok, 0 = no conversion
typedef int TcvtUTF8Proc ( int mode, // 1 = to UTF-8, 2 = from UTF-8 Byte *target, int *targetlength, // output Byte *source, int sourcelength); // input // targetlength contains maximal size as input param. // returns success: 1 = ok, 0 = no conversion
Wildgrube Informational [Page 18] RFC 3072 Structured Data Exchange Format March 2001
Wildgrube Informational [Page 18] RFC 3072 Structured Data Exchange Format March 2001
9. 'Support' of UTF-8.
9. 'Support' of UTF-8.
Many systems supports [UTF-8] as a character format for transferred data. The benefit is that no fixing of a specific character set for an application is needed because the set of 'all' characters is used, represented by the 'Universal Character Set' UCS-2 [UCS], a double byte coding for characters.
Many systems supports [UTF-8] as a character format for transferred data. The benefit is that no fixing of a specific character set for an application is needed because the set of 'all' characters is used, represented by the 'Universal Character Set' UCS-2 [UCS], a double byte coding for characters.
SDXF does not really deal with UTF-8 by itself, there are many possibilities to interprete an UTF-8 sequence: The application may:
SDXF does not really deal with UTF-8 by itself, there are many possibilities to interprete an UTF-8 sequence: The application may:
- reconstruct the UCS-2 sequence,
- accepts only the pure ASCII character and maps non-ASCII to a
special 'non-printable' character.
- target is pure ASCII, non-ASCII is replaced in a senseful manner
(French accented vowels replaced by vowels without accents, etc.).
- target is a specific ANSI character set, the non-ASCII chars are
mapped as possible, other replaced to a 'non-printable'.
- etc.
- reconstruct the UCS-2 sequence, - accepts only the pure ASCII character and maps non-ASCII to a special 'non-printable' character. - target is pure ASCII, non-ASCII is replaced in a senseful manner (French accented vowels replaced by vowels without accents, etc.). - target is a specific ANSI character set, the non-ASCII chars are mapped as possible, other replaced to a 'non-printable'. - etc.
But SDXF offers an interface for the 'extract' and 'create' functions:
But SDXF offers an interface for the 'extract' and 'create' functions:
A function pointer may be specified in the options table to maintain this possibility (see 8.5). Default for this pointer is NULL: No further conversions are done by SDXF, the data are copied 'as is', it is treated as a bit string as for data type 'binary'.
A function pointer may be specified in the options table to maintain this possibility (see 8.5). Default for this pointer is NULL: No further conversions are done by SDXF, the data are copied 'as is', it is treated as a bit string as for data type 'binary'.
If this function is specified, it is used by the 'create' function with the 'toUTF8' mode, and by the 'extract' function with the ' fromUTF8' mode. The invoking of these functions is done by SDXF transparently.
If this function is specified, it is used by the 'create' function with the 'toUTF8' mode, and by the 'extract' function with the ' fromUTF8' mode. The invoking of these functions is done by SDXF transparently.
If the function returns zero (no conversion) SDXF copies the data without conversion.
If the function returns zero (no conversion) SDXF copies the data without conversion.
10. Security Considerations
10. Security Considerations
Any corruption of data in the chunk headers denounce the complete SDXF structure.
Any corruption of data in the chunk headers denounce the complete SDXF structure.
Any corruption of data in a encrypted or compressed SDXF structure makes this chunk unusable. An integrity check after decryption or decompression should be done by the "enter" function.
Any corruption of data in a encrypted or compressed SDXF structure makes this chunk unusable. An integrity check after decryption or decompression should be done by the "enter" function.
While using TCP/IP (more precisely: IP) as a transmission medium we can trust on his CRC check on the transport layer.
While using TCP/IP (more precisely: IP) as a transmission medium we can trust on his CRC check on the transport layer.
Wildgrube Informational [Page 19] RFC 3072 Structured Data Exchange Format March 2001
Wildgrube Informational [Page 19] RFC 3072 Structured Data Exchange Format March 2001
11. Some general hints
11. Some general hints
1. A consistent construction of a SDXF structure is done if every
"create" to a structured chunk is closed by a paired "leave".
While a structured chunk is under construction, his data type is
set to zero - that means: this chunk is inconsistent. The
SDX_leave function sets the datatype to "structured".
1. A consistent construction of a SDXF structure is done if every "create" to a structured chunk is closed by a paired "leave". While a structured chunk is under construction, his data type is set to zero - that means: this chunk is inconsistent. The SDX_leave function sets the datatype to "structured".
2. While creating an elementary chunk a platform dependent
transformation to a platform independent format of the data is
performed - at the end of construction the content of the buffer
is ready to transport to another site, without any further
translation.
2. While creating an elementary chunk a platform dependent transformation to a platform independent format of the data is performed - at the end of construction the content of the buffer is ready to transport to another site, without any further translation.
3. As you see no data definition in your programming language is
needed for to construct a specific SDXF structure. The data is
created dynamically by function calls.
3. As you see no data definition in your programming language is needed for to construct a specific SDXF structure. The data is created dynamically by function calls.
4. With SDXF as a base you can define protocols for client / server
applications. These protocols may be extended in downward
compatibility manner by following two rules:
4. With SDXF as a base you can define protocols for client / server applications. These protocols may be extended in downward compatibility manner by following two rules:
Rule 1: Ignore unknown chunkIDs.
Rule 1: Ignore unknown chunkIDs.
Rule 2: The sequence of chunks should not be significant.
Rule 2: The sequence of chunks should not be significant.
12. IANA Considerations
12. IANA Considerations
The compression and encryption algorithms for SDXF is not fixed, SDXF is open for various algorithms. Therefore an agreement is necessary to interprete the compression and encryption algorithm method numbers. (Encryption methods are not a semantic part of SDXF, but may be used for a connection protocol to negotiate the encryption method to use.)
The compression and encryption algorithms for SDXF is not fixed, SDXF is open for various algorithms. Therefore an agreement is necessary to interprete the compression and encryption algorithm method numbers. (Encryption methods are not a semantic part of SDXF, but may be used for a connection protocol to negotiate the encryption method to use.)
Following two items are registered by IANA:
Following two items are registered by IANA:
12.1 COMPRESSION METHODS FOR SDXF
12.1 COMPRESSION METHODS FOR SDXF
The compressed SDXF chunk starts with a "compression header". This header contains the compression method as an unsigned 1-Byte integer (1-255). These numbers are assigned by IANA and listed here:
The compressed SDXF chunk starts with a "compression header". This header contains the compression method as an unsigned 1-Byte integer (1-255). These numbers are assigned by IANA and listed here:
Wildgrube Informational [Page 20] RFC 3072 Structured Data Exchange Format March 2001
Wildgrube Informational [Page 20] RFC 3072 Structured Data Exchange Format March 2001
compression
method Description Hints
--------- ------------------------------- -------------
01 RUN-LENGTH algorithm see chap. 5
02 DEFLATE (ZIP) see [DEFLATE]
03-239 IANA to assign
240-255 private or application specific
compression method Description Hints --------- ------------------------------- ------------- 01 RUN-LENGTH algorithm see chap. 5 02 DEFLATE (ZIP) see [DEFLATE] 03-239 IANA to assign 240-255 private or application specific
12.2 ENCRYPTION METHODS FOR SDXF
12.2 ENCRYPTION METHODS FOR SDXF
An unique encryption method is fixed or negotiated by handshaking. For the latter one a number for each encryption method is necessary. These numbers are unsigned 1-Byte integers (1-255). These numbers are assigned by IANA and listed here:
An unique encryption method is fixed or negotiated by handshaking. For the latter one a number for each encryption method is necessary. These numbers are unsigned 1-Byte integers (1-255). These numbers are assigned by IANA and listed here:
encryption
method Description
--------- ------------------------------
01-239 IANA to assign
240-255 private or application specific
encryption method Description --------- ------------------------------ 01-239 IANA to assign 240-255 private or application specific
12.3 Hints for assigning a number:
12.3 Hints for assigning a number:
Developers which want to register a compression or encrypt method for SDXF should contact IANA for a method number. The ASSIGNED NUMBERS document should be referred to for a current list of METHOD numbers and their corresponding protocols, see [IANA]. The new method SHOULD be a standard published as a RFC or by a established standardization organization (as OSI).
Developers which want to register a compression or encrypt method for SDXF should contact IANA for a method number. The ASSIGNED NUMBERS document should be referred to for a current list of METHOD numbers and their corresponding protocols, see [IANA]. The new method SHOULD be a standard published as a RFC or by a established standardization organization (as OSI).
13. Discussion
13. Discussion
There are already some standards for Internet data exchanging, IETF prefers ASN.1 and XML therefore. So the reasons for establish a new data format should be discussed.
There are already some standards for Internet data exchanging, IETF prefers ASN.1 and XML therefore. So the reasons for establish a new data format should be discussed.
13.1 SDXF vs. ASN.1
13.1 SDXF vs. ASN.1
The demand of ASN.1 (see [ASN.1]) is to serve program language independent means to define data structures. The real data format which is used to send the data is not defined by ASN.1 but usually BER or PER (or some derivates of them like CER and DER) are used in this context, see [BER] and [PER].
The demand of ASN.1 (see [ASN.1]) is to serve program language independent means to define data structures. The real data format which is used to send the data is not defined by ASN.1 but usually BER or PER (or some derivates of them like CER and DER) are used in this context, see [BER] and [PER].
Wildgrube Informational [Page 21] RFC 3072 Structured Data Exchange Format March 2001
Wildgrube Informational [Page 21] RFC 3072 Structured Data Exchange Format March 2001
The idea behind ASN.1 is: On every platform on which a given application is to develop descriptions of the used data structures are available in ASN.1 notation. Out off these notations the real language dependent definitions are generated with the help of an ASN.1-compiler.
The idea behind ASN.1 is: On every platform on which a given application is to develop descriptions of the used data structures are available in ASN.1 notation. Out off these notations the real language dependent definitions are generated with the help of an ASN.1-compiler.
This compiler generates also transform functions for these data structures for to pack and unpack to and from the BER (or other) format.
This compiler generates also transform functions for these data structures for to pack and unpack to and from the BER (or other) format.
A direct comparison between ASN.1 and SDXF is somehow inappropriate: The data format of SDXF is related rather to BER (and relatives). The use of ASN.1 to define data structures is no contradiction to SDXF, but: SDXF does not require a complete data structure to build the message to send, nor a complete data structure will be generated out off the received message.
A direct comparison between ASN.1 and SDXF is somehow inappropriate: The data format of SDXF is related rather to BER (and relatives). The use of ASN.1 to define data structures is no contradiction to SDXF, but: SDXF does not require a complete data structure to build the message to send, nor a complete data structure will be generated out off the received message.
The main difference lies in the concept of building and interpretation of the message, I want to name it the "static" and "dynamic" concept:
The main difference lies in the concept of building and interpretation of the message, I want to name it the "static" and "dynamic" concept:
o ASN.1 uses a "static" approach: The whole data structure must
exists before the message can be created.
o ASN.1 uses a "static" approach: The whole data structure must exists before the message can be created.
o SDXF constructs and interpretes the message in a "dynamic" way,
the message will be packed and unpacked step by step by SDXF
functions.
o SDXF constructs and interpretes the message in a "dynamic" way, the message will be packed and unpacked step by step by SDXF functions.
The use of static structures may be appropriate for a series of applications, but for complex tasks it is often impossible to define the message as a whole. As an example try to define an ASN.1 description for a complex structured text document which is presented in XML: There are sections and paragraphs and text elements which may recursively consist of sections with specific text attributes.
The use of static structures may be appropriate for a series of applications, but for complex tasks it is often impossible to define the message as a whole. As an example try to define an ASN.1 description for a complex structured text document which is presented in XML: There are sections and paragraphs and text elements which may recursively consist of sections with specific text attributes.
13.2 SDXF vs. XML
13.2 SDXF vs. XML
On the one hand SDXF and XML are similar as they can handle any recursive complex data stream. The main difference is the kind of data which are to be maintained:
On the one hand SDXF and XML are similar as they can handle any recursive complex data stream. The main difference is the kind of data which are to be maintained:
o XML works with pure text data (though it should be noted that the
character representation is not standardized by XML). And: a XML
document with all his tags is readable by human. Binary data as
graphic is not included directly but may be referenced by an
external link as in HTML.
o XML works with pure text data (though it should be noted that the character representation is not standardized by XML). And: a XML document with all his tags is readable by human. Binary data as graphic is not included directly but may be referenced by an external link as in HTML.
Wildgrube Informational [Page 22] RFC 3072 Structured Data Exchange Format March 2001
Wildgrube Informational [Page 22] RFC 3072 Structured Data Exchange Format March 2001
In XML there is no strong separation between informational and
control data, escape characters (like "<" and "&") and the
<![CDATA[...]]> construction are used to distinguish between these
two types of data.
In XML there is no strong separation between informational and control data, escape characters (like "<" and "&") and the <![CDATA[...]]> construction are used to distinguish between these two types of data.
o SDXF maintains machine-readable data, it is not designed to be
readable by human nor to edit SDXF data with a text editor (even
more if compression and encryption is used). With the help of the
SDXF functions you have a quick and easy access to every data
element. The standard parser for a SDXF data structure follows
always a simple template, the "while - switch -case ID -
enter/extract" pattern as outlined in chap. 3.4.2.
o SDXF maintains machine-readable data, it is not designed to be readable by human nor to edit SDXF data with a text editor (even more if compression and encryption is used). With the help of the SDXF functions you have a quick and easy access to every data element. The standard parser for a SDXF data structure follows always a simple template, the "while - switch -case ID - enter/extract" pattern as outlined in chap. 3.4.2.
Because of the complete different philosophy behind XML and SDXF (and even ASN.1) a direct comparison may not be very senseful, as XML has its own right to exist next to ASN.1 (and even SDXF).
Because of the complete different philosophy behind XML and SDXF (and even ASN.1) a direct comparison may not be very senseful, as XML has its own right to exist next to ASN.1 (and even SDXF).
Nevertheless there is a chance to convert a XML data stream into a SDXF structure: As a first strike, every XML tag becomes a SDXF chunk ID. An elementary sequence <tag>pure text</tag> can be transformed into an elementary (non-structured) chunk with data type "character". Tags with attributes and sequences with nested tags are transformed into structured chunks. Because XML allows a tag sequence everywhere in a text stream, an artificially "elementary text" tag must be introduced: If <t> is the tag for text elements, the sequence:
Nevertheless there is a chance to convert a XML data stream into a SDXF structure: As a first strike, every XML tag becomes a SDXF chunk ID. An elementary sequence <tag>pure text</tag> can be transformed into an elementary (non-structured) chunk with data type "character". Tags with attributes and sequences with nested tags are transformed into structured chunks. Because XML allows a tag sequence everywhere in a text stream, an artificially "elementary text" tag must be introduced: If <t> is the tag for text elements, the sequence:
<t>this is a text <attr value='bold'>with</attr> attributes</t>
<t>は'大胆な'</attr>属性</t>と>'と等しいですテキスト<attrが、評価する。
is to be "in thought" replaced by:
以下に取り替えて、「考え」にはあるように、あります。
<t><et>this is a text </et><attr value='bold'><et>with</et></attr> <et> attributes</et></t>
<t><et>は'大胆な'</et></attr><et>属性</et></t>と><et>'と等しいですテキスト</et><attrが、評価する。
(With "et" as the "elementary text" tag)
(「基本のテキスト」タグとしての"et"がある)
Wildgrube Informational [Page 23] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[23ページ]のRFC3072
This results in following SDXF structure:
これは次のSDXF構造をもたらします:
ID_t | +-- ID_et = " this is a text " | +-- ID_attr | | | +-- ID_value = "bold" | | | +-- ID_et = "with" | +-- ID_et = " attributes"
ID_t| +--ID_etは「これはテキストです」と等しいです。| +--ID_attr| | | +--ID_値は「大胆さ」と等しいです。| | | +--ID_etは“with"と等しいです。| +--ID_etは「属性」と等しいです。
ID_t and ID_et may be represented by the same chunk ID, only
distinguished by the data type ("structured" for <t> and "character"
for <et>)
ID_tとID_etはデータ型によって区別されただけである同じ塊IDによって表されるかもしれません。(<et>のための<t>と「キャラクタ」のために「構造化されます」)
Binary data as pictures can be directly imbedded into a SDXF structure instead referencing them as an external link like in HTML.
直接代わりにHTMLなどのような外部のリンクとしてそれらに参照をつけるSDXF構造に絵としての2進のデータを埋め込むことができます。
14. Author's Address
14. 作者のアドレス
Max Wildgrube Schlossstrasse 120 60486 Frankfurt Germany
マックスWildgrube Schlossstrasse120 60486・フランクフルトドイツ
EMail: max@wildgrube.com
メール: max@wildgrube.com
15. Acknowledgements
15. 承認
I would like to thank Michael J. Slifcak (mslifcak@iss.net) for the supporting discussions.
サポート議論についてマイケルJ.Slifcak( mslifcak@iss.net )に感謝申し上げます。
16. References
16. 参照
[ASN.1] Information processing systems - Open Systems
Interconnection, "Specification of Abstract Syntax Notation
One (ASN.1)", International Organization for
Standardization, International Standard 8824, December
1987.
[ASN.1] 情報処理システム--オープン・システム・インターコネクション、「抽象構文記法1(ASN.1)の仕様」、国際標準化機構、国際規格8824(1987年12月)。
[BER] Information Processing Systems - Open Systems
Interconnection - "Specification of Basic Encoding Rules
for Abstract Notation One (ASN.1)", International
Organization for Standardization, International Standard
8825-1, December 1987.
[BER]情報処理システム--オープン・システム・インターコネクション--「基本的なコード化の仕様は抽象的な記法1(ASN.1)のために統治されます」、国際標準化機構、国際規格8825-1、1987年12月。
Wildgrube Informational [Page 24] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[24ページ]のRFC3072
[DEFLATE] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996.
ドイツ語、[DEFLATE]P.、「DEFLATE Compressed Data Format Specification、バージョン1.3インチ、RFC1951、1996インチ年5月。
[IANA] Internet Assigned Numbers Authority,
http://www.iana.org/numbers.htm
[IANA]インターネット規定番号権威、 http://www.iana.org/numbers.htm
[PER] Information Processing Systems - Open Systems
Interconnection -"Specification of Packed Encoding Rules
for Abstract Syntax Notation One (ASN.1)", International
Organization for Standardization, International Standard
8825-2.
[PER]情報処理システム--オープン・システム・インターコネクション--「詰まっているコード化の仕様は抽象構文記法1(ASN.1)のために統治されます」、国際標準化機構、国際規格8825-2。
[UCS] ISO/IEC 10646-1:1993. International Standard -- Information
technology -- Universal Multiple-Octet Coded Character Set
(UCS)
[UCS]ISO/IEC10646-1:1993。 国際規格--情報技術--普遍的なMultiple-八重奏Coded文字コード(UCS)
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[UTF8]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変化形式」RFC2279。
Wildgrube Informational [Page 25] RFC 3072 Structured Data Exchange Format March 2001
2001年のデータ交換形式行進のときに構造化されたWildgrubeの情報[25ページ]のRFC3072
17. Full Copyright Statement
17. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Wildgrube Informational [Page 26]
Wildgrube情報です。[26ページ]
一覧
スポンサーリンク
