RFC4194 日本語訳
4194 The S Hexdump Format. J. Strombergson, L. Walleij, P. Faltstrom. October 2005. (Format: TXT=25727 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Strombergson
Request for Comments: 4194 InformAsic AB
Category: Standards Track L. Walleij
Lunds Tekniska Hogskola
P. Faltstrom
Cisco Systems Inc
October 2005
Strombergsonがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4194InformAsic ABカテゴリ: 標準化過程L.Walleij Lunds Tekniska Hogskola P.FaltstromシスコシステムズInc2005年10月
The S Hexdump Format
S Hexdump形式
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document specifies the S Hexdump Format (SHF), a new, XML-based open format for describing binary data in hexadecimal notation. SHF provides the ability to describe both small and large, simple and complex hexadecimal data dumps in an open, modern, transport- and vendor-neutral format.
このドキュメントはS Hexdump Format(SHF)、新しくて、XMLベースの開いている形式を16進法におけるバイナリ・データについて説明するのに指定します。 SHFは開いていて、現代の輸送とベンダー中立の形式で簡単なものと小さくて大きくて、同様に複雑な16進データ憂鬱について説明する能力を提供します。
1. Introduction
1. 序論
In the computing, network, and embedded systems communities, several different types of data formats for hexadecimal data are being used. One of the more common formats is known as "S-records" (and several derivatives), which reportedly originated at the Motorola company. The S Hexdump Format is named in its honour.
コンピューティング、ネットワーク、および組込み型システム共同体では、16進データのためのいくつかの異なったタイプのデータ形式は使用されています。 より一般的な形式の1つは「S-記録」(そして、いくつかの派生物)として知られています。(伝えられるところによれば、それは、モトローラ会社で起因しました)。 S Hexdump Formatは名誉で命名されます。
Typical uses of these dump formats include executable object code for embedded systems (i.e., "firmware"), on-chip flash memories and filesystems, FPGA configuration bitstreams, graphics and other application resources, routing tables, etc. Unfortunately, none of the formats used are truly open, vendor-neutral, and/or well-defined.
これらのダンプ形式の典型的な用途は組込み型システム(すなわち、「ファームウェア」)とチップの上のフラッシュメモリとファイルシステムとFPGA構成bitstreamsとグラフィックスと他のアプリケーションリソース、経路指定テーブルなどのための実行可能なオブジェクトコードを含んでいます。 残念ながら、使用される形式のいずれも、本当に、開いて、ベンダー中立である、そして/または、明確ではありません。
Even more problematic is the fact that none of these formats are able to represent the large data sizes that are getting more and more common. Data dumps comprised of multiple sub-blocks with different
さらに問題が多いのは、これらの形式のどれかがますます一般的になっている大きいデータサイズを表すことができないという事実です。 異なることで複数のサブブロックから成るデータ憂鬱
Strombergson, et al. Standards Track [Page 1] RFC 4194 The S Hexdump Format October 2005
Strombergson、他 規格はS Hexdump形式2005年10月にRFC4194を追跡します[1ページ]。
Word sizes, and data sizes spanning anywhere from a few Bytes of data to much larger than 2^32 bits are not handled. Also, the checksums included in these formats are too simplistic and for larger data sizes, they provide insufficient ability to accurately detect errors. Alternatively, the overhead needed for proper error detection is very large.
どこでもデータのいくつかのBytesから32ビットよりはるかに大きくなるまでわたるのが扱った語長、およびデータサイズ。 また、これらの形式で含まれていたチェックサムも安易過ぎます、そして、より大きいデータサイズのために、それらは正確に誤りを検出する不十分な能力を提供します。 あるいはまた、適切な誤り検出に必要であるオーバーヘッドは非常に大きいです。
Therefore, the S Hexdump format is an effort to provide a modern, XML-based format that is not too complex for simple tools and computing environments to implement, generate, parse, and use. Yet the format is able to handle large data sizes and complex data structures, and can provide high quality error detection by leveraging standardized cryptographic hash functions.
したがって、S Hexdump形式は簡単なツールとコンピューティング環境が実装して、生成して、分析して、使用できないくらいには複雑でない現代的で、XMLベースの形式を提供する取り組みです。 しかし、形式は、大きいデータサイズと複雑なデータ構造を扱うことができて、標準化された暗号のハッシュ関数を利用することによって、高品質の誤り検出を提供できます。
One of the simplifications introduced in the format is to disallow other number systems such as octal or decimal notation, and to allow for Word sizes of even bytes (8-bit groups) only. This is intentional and was done to simplify implementations aimed for practical present-day applications. Formats aimed for esoteric number systems or odd Word sizes may be implemented elsewhere.
形式で導入された簡素化の1つは、8進か10進法などの他の数体系を禁じて、バイト(8ビットのグループ)だけさえのWordサイズを考慮することです。 これを意図的であり、実用的な現代のアプリケーションのために目的とされた実装を簡素化するためにしました。 形式が難解な数体系を目指したか、または変なWordサイズはほかの場所で実装されるかもしれません。
At present, the usage of the SHF format may be mainly for Internet transport and file storage on development machinery. A parser for the XML format is presently not easily deployed in hardware devices, but the parsing and checksumming of the SHF data may be done by a workstation computer, which in turn converts the SHF tokens to an ordinary bitstream before the last step (e.g., of a firmware upgrade) commences.
現在のところ、開発機械の上に主にインターネット輸送とファイル記憶装置にはSHF形式の用法があるかもしれません。 現在、ハードウェアデバイスで容易にXML形式のためのパーサを配布しませんが、ワークステーションコンピュータはSHFデータの構文解析とchecksummingをするかもしれません。(順番に、最後のステップ(例えば、ファームウェアアップグレードの)が始まる前にそれは、SHFトークンを普通のbitstreamに変換します)。
SHF is a dump format only and shall not be confused with similar applications, such as binary configuration formats or patches, which are intended to, for example, alter contents of a core memory. Such applications require the possibility of modifying individual bits or groups of bits in the memory of a machine, and is not the intended usage of the mechanism described in the present document.
SHFはダンプ形式専用であり、同様のアプリケーションに混乱しないでしょう、2進の構成形式やパッチなどのように。(例えば、パッチはコアメモリのコンテンツを変更されるつもりです)。 そのようなアプリケーションはマシンに関するメモリでビットの個々のビットかグループを変更する可能性を必要とします、そして、メカニズムの意図している使用法は現在のドキュメントで説明されませんか?
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
The key word "Byte" is to be interpreted as a group of 8 bits. The key word "Octet" is another name for Byte.
「バイト」というキーワードは8ビットのグループとして解釈されることです。 「八重奏」というキーワードはByteのための別の名前です。
The key word "Word" is to be interpreted as a group containing an integral number of Bytes.
「Word」というキーワードはBytesの整数を含むグループとして解釈されることです。
Strombergson, et al. Standards Track [Page 2] RFC 4194 The S Hexdump Format October 2005
Strombergson、他 規格はS Hexdump形式2005年10月にRFC4194を追跡します[2ページ]。
The key word "Block" is to be interpreted as an ordered sequence of Words, beginning at a certain address, running from lower to higher addresses. A Block typically represents a sequence of Words at a certain address range in the memory of a computer.
キーワードは、より高いアドレスにより低くワーズの規則正しい系列として解釈されるためにあって、aあるアドレスで始まる実行を「妨げます」。 Blockはコンピュータに関するメモリのある一定のアドレスの範囲にワーズの系列を通常表します。
The key word "Dump" is to be interpreted as a sequence of Blocks, which may or may not be in a particular order. A Dump typically represents some non-continuous, interesting parts of the memory of a computer, such that the Dump as a whole has a certain meaning, for example (but not limited to) a complete firmware for an embedded system.
「ダンプ」というキーワードはBlocksの系列として解釈されることです。(Blocksは特定のオーダーにあるかもしれません)。 Dumpはコンピュータに関するメモリのいくつかの非連続して、おもしろい部分を通常表します、Dumpには、ある意味が全体であるように、例えば(他)、組込み型システムのための完全なファームウェア。
The expression "2^n" is to be interpreted as the value two (2) raised to the n:th power. For example, 2^8 equals the value 256.
式「2^n」は2(2)がnに上げた値として解釈されることです:、第パワー。 例えば、2^8は値256と等しいです。
3. Features and Functionality
3. 特徴と機能性
The SHF-format has the following features:
SHF-形式には、以下の特徴があります:
o Support for arbitrarily wide data Words
o 任意に広いデータワーズのサポート
o Support for very large data Blocks
o 非常に大きいデータBlocksのサポート
o Support for an arbitrary number of independent data Blocks
o 独立しているデータBlocksの特殊活字の数字のサポート
o Data integrity detection against errors provided by the RFC3174
specified (see [2]) SHA-1 cryptographic signature
o RFC3174によって提供された誤りに対するデータの保全検出が指定した、([2]) SHA-1の暗号の署名を見てください。
o An XML-based format
o XMLベースの形式
In the embedded systems domain, 8- and 16-bit processors are still used in large numbers and will continue to be used for any foreseeable future. Simultaneously, more and more systems are using 64-bit and even larger Word sizes.
組込み型システムドメインでは、8と16ビットのプロセッサは、まだ数多く使用されていて、どんな予見できる未来の間も、使用され続けるでしょう。 同時に、ますます多くのシステムが64ビットの、そして、さらに大きいWordサイズを使用します。
SHF supports all of these systems by allowing the Word size to be specified. The Word size MUST be an integer number of Bytes and at least one (1) Byte.
Wordサイズが指定されるのを許容することによって、SHFはこれらのシステムのすべてをサポートします。 Wordサイズは、Bytesの整数と少なくとも1(1)バイトでなければなりません。
SHF is able to represent both large and small data Blocks. The data Block MUST contain at least one (1) Word. Additionally, the data Block MUST NOT be larger than (2^64)-1 bits.
SHFは大きいものと同様に小さいデータBlocksを表すことができます。 データBlockは少なくとも1(1)のWordを含まなければなりません。 さらに、データBlockは(2^64)より-1ビット大きいはずがありません。
The SHF Dump MUST contain at least one (1) data Block. The maximum number of Blocks supported is 2^64. Each data Block in the Dump MAY have different Word sizes and start at different addresses.
SHF Dumpは少なくとも1(1)のデータBlockを含まなければなりません。 サポートされたBlocksの最大数は2^64です。 DumpのそれぞれのデータBlockは異なったWordサイズを持って、異なったアドレスで始まるかもしれません。
Strombergson, et al. Standards Track [Page 3] RFC 4194 The S Hexdump Format October 2005
Strombergson、他 規格はS Hexdump形式2005年10月にRFC4194を追跡します[3ページ]。
The checksum (or message digest) used to verify the correctness or data integrity of each Block is 20 Bytes (160 bits) long. The digest MUST be calculated on the data actually represented by the SHF data Block, NOT the representation, i.e., NOT the ASCII-code. SHA-1 is only able to calculate a digest for a data Block no larger than (2^64)-1 bits and this limits the size of each data Block in SHF to (2^64)-1 bits.
チェックサム(または、メッセージダイジェスト)は以前はよく正当性について確かめていたか、それぞれのBlockのデータ保全が長さ(160ビット)の20Bytesです。 実際に表現ではなく、SHFデータBlockによって表されたデータでダイジェストについて計算しなければなりません、すなわち、ASCII-コードでない。 SHA-1は、(2^64)の-1ビットとこれほど大きくないデータBlockのためのダイジェストがSHFのそれぞれのデータBlockのサイズを(2^64)に-1ビット制限すると見込むことができるだけです。
4. SHF XML Specification
4. SHF XML仕様
The SHF format consists of an XML data structure representing a Dump. The Dump consists of a Dump header section and one (1) or more Block sections containing data. Each Block of data is independent of any other Block.
SHF形式はDumpを表すXMLデータ構造から成ります。 DumpはDumpヘッダー部分とデータを含む1(1)以上のBlock部から成ります。 データのそれぞれのBlockはいかなる他のBlockからも独立しています。
A short, symbolic example of an SHF Dump is illustrated by the following structure:
SHF Dumpの短くて、シンボリックな例は以下の構造によって例証されます:
<dump name="(Human readable string)" blocks="(64-bit value)">
<block name="(Human readable string)" start_address="(64-bit
value)" word_size="(64-bit value)" length="(64-bit value)"
checksum="(20-Byte digest)">
(Data)
</block>
</dump>
「<ダンプ名=」(人間の読み込み可能なストリング)」 」 ブロック=(64ビットの値)「><ブロック名=」(人間の読み込み可能なストリング)」 」 始め_アドレス=(64ビットの値)」 」 単語_サイズ=(64ビットの値)」 」 長さ=(64ビットの値)」 」 チェックサム=(20バイトのダイジェスト)「>(データ)</ブロック></ダンプ>」
4.1. Header Section
4.1. ヘッダー部分
The header section comprises the Dump tag, which includes the following attributes:
ヘッダー部分はDumpタグを包括します:(タグは以下の属性を含んでいます)。
o name: A compulsory string of arbitrary length used by any
interested party to identify the specific SHF Dump.
o 以下を命名してください。 特定のSHF Dumpを特定するのにどんな利害関係者によっても使用された任意の長さの強制的なストリング。
o blocks: An optional 64-bit hexadecimal value representing the
number of Blocks in the specific SHF Dump. Whenever available,
this value should be supplied. However, there are potential
scenarios where the number of Blocks cannot be given beforehand.
If the value is present, it should be verified by implementers; if
the value is untrue, the behaviour is implementation-defined.
o ブロック: 特定のSHF DumpのBlocksの数を表す任意の64ビットの16進値。 利用可能であるときはいつも、この値を供給するべきです。 しかしながら、潜在的シナリオがあらかじめBlocksの数を与えることができないところにあります。 値が存在しているなら、それはimplementersによって確かめられるはずです。 値が虚偽であるなら、ふるまいは実装で定義されています。
After the opening Dump tag, one or more subsections of Blocks must follow. Finally, the complete SHF Dump ends with a closing Dump tag.
初めのDumpタグの、あとにBlocksの1つ以上の小区分について行かなければなりません。 最終的に、完全なSHF Dumpは終わりのDumpタグで終わります。
Strombergson, et al. Standards Track [Page 4] RFC 4194 The S Hexdump Format October 2005
Strombergson、他 規格はS Hexdump形式2005年10月にRFC4194を追跡します[4ページ]。
4.2. Block Subsection
4.2. ブロック小区分
The Block subsection contains a Block tag and a number of data words. The Block tag includes the following attributes:
Block小区分はBlockタグと多くのデータ・ワードを含んでいます。 Blockタグは以下の属性を含んでいます:
o name: A compulsory string of arbitrary length used by any
interested party to identify the specific Block.
o 以下を命名してください。 特定のBlockを特定するのにどんな利害関係者によっても使用された任意の長さの強制的なストリング。
o start_address: A compulsory, 64-bit hexadecimal value representing
the start address in Bytes for the data in the Block.
o _アドレスを始めてください: データのためのBlockのBytesの開始アドレスを表す強制的で、64ビットの16進値。
o word_size: A compulsory 64-bit hexadecimal value representing the
number of Bytes (the width) of one Word of the data.
o _サイズを言い表してください: データの1つのWordのBytes(幅)の数を表す強制的な64ビットの16進値。
o length: A compulsory hexadecimal representation of an unsigned
64-bit integer indicating the number of Words following inside the
Block element. If this value turns out to be untrue, the Block
MUST be discarded.
o 長さ: Block要素の中の次のワーズの数を示す未署名の64ビットの整数の強制的な16進表現。 この値が虚偽であると判明するなら、Blockを捨てなければなりません。
o checksum: A compulsory hexadecimal representation of the 20 Byte
SHA-1 digest of the data in the Block.
o チェックサム: Blockのデータの20Byte SHA-1ダイジェストの強制的な16進表現。
The total size of the data in the Block (in bits) is given by the expression (8 * word_size * length). The expression MUST NOT be larger than (2^64)-1.
式(8*単語_のサイズ*長さ)でBlock(ビットの)のデータの総サイズを与えます。 式は(2^64)-1より大きいはずがありません。
After the opening Block tag, a hexadecimal representation of the actual data in the Block follows. Finally, the Block section ends with a closing Block tag.
初めのBlockタグの、あとにBlockの実際のデータの16進表現について行っています。 最終的に、Block部は終わりのBlockタグで終わります。
5. SHF Rules and Limits
5. SHF規則と限界
There are several rules and limits in SHF:
いくつかの規則と限界がSHFにあります:
o All attribute values representing an actual value and the data
MUST be in hexadecimal notation. The only attribute excluded from
this rule is the name attribute in the Dump and Block tags. This
restriction has been imposed for ease of reading the dump: a
reader shall not be uncertain about whether a figure is in hex
notation or not, and can always assume it is hexadecimal.
o 16進法には実価とデータを表すすべての属性値があるに違いありません。 この規則から除かれた唯一の属性がDumpとBlockタグの名前属性です。 この制限はダンプを読む容易さのために課されました: 読者は、図が十六進法記法であるかに関して不確実でなく、いつもそれが16進であると仮定できます。
o All attribute values, with the exception of the checksum, MAY omit
leading zeros. Conversely, the checksum MUST NOT omit leading
zeros.
o チェックサム以外のすべての属性値が先行ゼロを省略するかもしれません。 逆に、チェックサムは先行ゼロを省略してはいけません。
o The data represented in a Block MUST NOT be larger than (2^64)-1
bits.
o Blockに表されたデータは(2^64)より-1ビット大きいはずがありません。
Strombergson, et al. Standards Track [Page 5] RFC 4194 The S Hexdump Format October 2005
Strombergson、他 規格はS Hexdump形式2005年10月にRFC4194を追跡します[5ページ]。
o The size of a Word MUST NOT be larger than (2^64)-1 bits. This
implies that a Block with a Word defined to the maximum width
cannot contain more than one Word. An SHF consumer shall assure
that it can handle a certain Word length before beginning to parse
blocks of an SHF Dump. Failure to do so may cause buffer
overflows and endanger the stability and security of the system
running the consuming application.
o Wordのサイズは(2^64)より-1ビット大きいはずがありません。 これは、Wordが全幅と定義されているBlockが1つ以上のWordを含むことができないのを含意します。 SHF消費者は、SHF Dumpのブロックを分析し始める前に、あるWordの長さを扱うことができることを保証するものとします。 そうしない場合、バッファオーバーフローを引き起こして、消費アプリケーションを実行するシステムの安定性とセキュリティを危険にさらすかもしれません。
o The attribute values representing an actual value MUST be in
big-endian format. This means that the most significant
hexadecimal digits are to be put to the left in a hexadecimal
Word, address, or similar field. For example, the address value
1234 represents the address 1234 and not 3412. While some
computing architectures may be using little-endian Words as their
native format, it is the responsibility of any SHF producer
running on such an architecture to swap the attribute values to a
big-endian format. The reverse holds for a consumer receiving the
big-endian SHF attributes: if the consumer is little-endian, the
values have to be swapped around.
o ビッグエンディアン形式には実価を表す属性値があるに違いありません。 これは、最も重要な16進数字が16進Word、アドレス、または同様の分野で左につけられることであることを意味します。 例えば、アドレス値1234は3412ではなくアドレス1234を表します。 いくつかのコンピューティングアーキテクチャがそれらのネイティブの形式としてリトルエンディアンワーズを使用しているかもしれない間、ビッグエンディアン形式と属性値を交換するのは、そのようなアーキテクチャで動いているどんなSHFプロデューサーの責任です。 逆はビッグエンディアンSHF属性を受ける消費者のために成立します: 消費者がリトルエンディアンであるなら、値では、スワップされなければなりません。
o Likewise, the words inside a Dump MUST be stored in a big-endian
format if the word size is larger than one Byte. Here, the same
need for swapping Bytes around may arise, as mentioned in the
previous paragraph.
o 同様に、語長が1Byteより大きいなら、ビッグエンディアン形式でDumpの中の単語を保存しなければなりません。 ここに、スワッピングおよそBytesの同じ必要性は前のパラグラフで言及されるように起こるかもしれません。
6. SHF DTD
6. SHF DTD
The contents of the element named "block" and the attributes "blocks", "address", "word_size" and "checksum" should only contain the characters that are valid hexbyte sequences. These are:
「ブロック」、属性「ブロック」、「アドレス」、「単語_サイズ」、および「チェックサム」という要素のコンテンツは有効なhexbyte系列であるキャラクタを含むだけであるべきです。 これらは以下の通りです。
whitespace ::= (#x20 | #x9 | #xC | #xD | #xA)
hexdigit ::= [0-9A-Fa-f]
hexbytes ::= whitespace* hexdigit (hexdigit|whitespace)*
空白:、:= (#x20| #x9| #xC| #xD| #xA) hexdigit:、:= [0-9Aファf]は以下をhexbytesします:= 空白*hexdigit(hexdigit| 空白)*
A parser reading in an SHF file should silently ignore any other characters that (by mistake) appear in any of these elements or attributes. These alien characters should be treated as if they did not exist. Also note that "whitespace" has no semantic meaning; it is only valid for the reason of improving the human readability of the Dump. Whitespace may be altogether removed and the hexbyte sequences concatenated if desired. Notice that the fact that word size is to be given in a number of bytes implies that the number of hexadecimal digits inside a block need to be even. Malformed blocks should be ignored by implementations.
SHFファイルで読むパーサは静かにこれらの要素か属性のいずれにも現れる(間違って)いかなる他のキャラクタも無視するはずです。 まるで彼らが存在しないかのようにこれらの外国のキャラクタは扱われるべきです。 また、「空白」にはどんな意味意味もないことに注意してください。 それは単にDumpの人間の読み易さを改良する理由で有効です。 空白は、全体で取り除いて望まれているなら連結されたhexbyte系列であるかもしれません。 語長がバイト数で与えることであるという事実がそれを含意するのに注意してください。同等になるブロックの必要性における16進数字の数。 奇形のブロックは実装によって無視されるべきです。
Strombergson, et al. Standards Track [Page 6] RFC 4194 The S Hexdump Format October 2005
Strombergson、他 規格はS Hexdump形式2005年10月にRFC4194を追跡します[6ページ]。
<!--
DTD for the S Hexdump Format, as of 2003-10-10
Linus Walleij, Joachim Strombergson, Patrik Faltstrom 2003
<!--2003年10月10日ライナスWalleij、ヨアヒムStrombergson、パトリクFaltstrom2003年現在S Hexdump形式のためのDTD
Refer to this DTD as:
このDTDを以下を参照してください。
<!ENTITY % SHF PUBLIC "-//IETF//DTD SHF//EN"
"http://ietf.org/dtd/shf.dtd">
%SHF;
-->
<?xml version="1.0" encoding="UTF-8"?>
<!実体%SHF公共の「-//IETF//DTD SHF//アン」、「 http://ietf.org/dtd/shf.dtd 「>%SHF」 --><?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ>。
<!ELEMENT dump (block)+>
<!ATTLIST dump
name CDATA #REQUIRED
blocks CDATA #IMPLIED>
<!ELEMENTダンプ(ブロック)+><!ATTLISTダンプ名前CDATA#REQUIREDはCDATA#IMPLIED>を妨げます。
<!ELEMENT block (#PCDATA)>
<!ATTLIST block
name CDATA #REQUIRED
address CDATA #REQUIRED
word_size CDATA #REQUIRED
length CDATA #REQUIRED
checksum CDATA #REQUIRED>
ATTLISTブロック名CDATA#REQUIREDがCDATA#REQUIRED単語_サイズCDATA#REQUIRED長さのCDATA#REQUIREDチェックサムCDATA#REQUIRED>を扱う<!ELEMENTブロック(#PCDATA)><!
7. SHF Examples
7. SHFの例
This section contains three different SHF examples, illustrating the usage of SHF and the attributes in SHF.
SHFでSHFの使用法と属性を例証して、このセクションは3つの異なったSHFの例を含みます。
The first example is a simple SHF Dump with a single Block of data:
最初の例はデータの独身のBlockと簡単なSHF Dumpです:
<?xml version="1.0" encoding="UTF-8"?>
<dump name="Simple SHF example" blocks="01">
<block name="Important message in hex format" address="0400"
word_size="01" length="1f"
checksum="5601b6acad7da5c7b92036786250b053f05852c3">
41 6c 6c 20 79 6f 75 72 20 62 61 73 65 20 61 72
65 20 62 65 6c 6f 6e 67 20 74 6f 20 75 73 0a
</block>
</dump>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ「><ダンプ名前=「簡単なSHFの例」ブロックは十六進法形式において「1インチの><ブロック名=」重要なメッセージと等しく」アドレス=「0400」が_サイズ=を言い表す、「"1f"1インチの長さ=チェックサムは「5601b6acad7da5c7b92036786250b053f05852c3">41 6c 6c20 79 6f75 72 20 62 61 73 65 20 61 72 65 20 62 65 6c 6f 6e67 20 74 6f20 75 73 0a</ブロック></ダンプ>」と等しいです。
Strombergson, et al. Standards Track [Page 7] RFC 4194 The S Hexdump Format October 2005
Strombergson、他 規格はS Hexdump形式2005年10月にRFC4194を追跡します[7ページ]。
The second example is a program in 6502 machine code residing at memory address 0x1000, which calculates the 13 first Fibonacci numbers and stores them at 0x1101-0x110d:
2番目の例は最初に、13フィボナッチの数列について計算して、0×1101 0x110dにそれらを保存するメモリアドレス0x1000に住んでいる6502年の機械コードでプログラムです:
<?xml version="1.0" encoding="UTF-8"?>
<dump name="6502 Fibonacci" blocks="02">
<block name="Code" address="1000" word_size="01" length="2a"
checksum="5cab5bf8ee299af1ad17e8093d941914eb5930c7">
a9 01 85 20 85 21 20 1e 10 20 1e 10 18 a5 21 aa
65 20 86 20 85 21 20 1e 10 c9 c8 90 ef 60 ae 00
11 a5 21 9d 00 11 ee 00 11 60
</block>
<block name="Mem" address="1100" word_size="01" length="e"
checksum="c8c2001c42b0226a5d9f7c2f24bd47393166487a">
01 00 00 00 00 00 00 00 00 00 00 00 00 00
</block>
</dump>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ「><ダンプ名=、「6502、」 「」 2インチの><ブロック名=コード」というブロック=が扱うフィボナッチ=「1000」が_サイズ=を言い表す、「"2a"1インチの長さ=チェックサムは「5cab5bf8ee299af1ad17e8093d941914eb5930c7">a9 01 85 20 85 21 20 1e10 20 1e10 18a5 21aa65 20 86 20 85 21 20 1e10c9 c8 90」と等しいです; 「ef60ae00 11a5 21 9d00 11ee00 11 60ブロック><ブロック名="Mem"アドレス=「1100」単語_サイズ=</「1インチの長さ=」e」チェックサムが等しい、「c8c2001c42b0226a5d9f7c2f24bd47393166487a「>01 00 00 00 00 00 00 00 00 00 00 00 00 00</ブロック></ダンプ>」
The final example contains a Block of 40-bit wide data:
最終的な例は40ビットの広いデータのBlockを含んでいます:
<?xml version="1.0" encoding="UTF-8"?>
<dump name="Example of an SHF dump with wide data words" blocks="00001">
<block name="SMIL memory dump" address="000" word_size="5"
length="1A" checksum="ff2033489aff0e4e4f0cd7901afc985f7a213c97">
00100 00200 00000 00090 00000 00036 00300 00400
00852 00250 00230 00858 00500 00600 014DC 00058
002A8 000B8 00700 00800 000B0 00192 00100 00000
00900 00A00 00000 0000A 40000 00000 00B00 00C00
00000 00000 00000 00001 00D00 00E00 00000 00100
0CCCC CCCCD 00F00 01000 00000 00010 80000 00000
00100 00790 00000 00234
</block>
</dump>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ「広いデータがあるSHFダンプに関する例は言い表す」><ダンプ名=が=を妨げる、「"1A"「0インチの単語_サイズ=」の5インチの1インチの><ブロック名=「SMILメモリダンプ」アドレス=長さ=チェックサムは「ff2033489aff0e4e4f0cd7901afc985f7a213c97">00100 00200 00000 00090 00000 00036 00300 00400 00852 00250」と等しいです; 00230 00858 00500 00600 014DC00058 002A8 000B8 00700 00800 000B0 00192 00100 00000 00900 00A00 00000 0000A40000 00000 00B00 00C00 00000 00000 00000 00001 00D00 00E00 00000 00100 0CCCC CCCCD 00F00 01000 00000 00010 80000 00000 00100 00790 00000 00234</ブロック></ダンプ>。
8. SHF Security Considerations
8. SHFセキュリティ問題
The SHF format is a format for representing hexadecimal data that one wants to transfer, manage, or transform. The format itself does not guarantee that the represented data is not falsely represented, malicious, or otherwise dangerous.
SHF形式は、1つが移したいか、管理したいか、または変形させたがっている16進データを表すための形式です。 形式自体は、表されたデータが間違って表されないか、悪意があるか、またはそうでなければ、危険であることを保証しません。
The data integrity of the SHF file as a whole is to be provided, if needed, by means external to the SHF file, such as the generic signing mechanism described by RFC 3275 [3].
全体でSHFファイルのデータ保全は提供することです、必要であるなら、SHFファイルへの外部の手段で、RFC3275[3]で説明されたジェネリック署名メカニズムなどのように。
Strombergson, et al. Standards Track [Page 8] RFC 4194 The S Hexdump Format October 2005
Strombergson、他 規格はS Hexdump形式2005年10月にRFC4194を追跡します[8ページ]。
9. IANA Considerations
9. IANA問題
This section contains the registration information for the MIME type to SHF. The media type has been chosen to comply with the guidelines in [4].
このセクションはMIMEの種類のためのレジスト情報をSHFに含みます。 メディアタイプは、[4]でガイドラインに従うために選ばれました。
o Registration: application/shf+xml o MIME media type name: application o MIME subtype name: shf+xml o Required parameters: charset
o 登録: アプリケーション/shf+xml o MIMEメディア型名: アプリケーションo MIME「副-タイプ」は以下を命名します。 shf+xml o Requiredパラメタ: charset
Required parameters: charset
必要なパラメタ: charset
This parameter must exist and must be set to "UTF-8". No other character sets are allowed for transporting SHF data. The character set designator MUST be uppercase.
このパラメタは存在しなければならなくて、「UTF-8インチ」に設定しなければなりません。 他の文字集合は、全くSHFデータを輸送するために許容されていません。 文字集合指示子は大文字しているに違いありません。
Encoding considerations:
問題をコード化します:
This media type may contain binary content; accordingly, when used over a transport that does not permit binary transfer, an appropriate encoding must be applied.
このメディアタイプは2進の内容を含むかもしれません。 それに従って、2進の転送を可能にしない輸送の上で使用されると、適切なコード化を適用しなければなりません。
Security considerations:
セキュリティ問題:
A hex Dump in itself has no other security considerations than what applies for any other XML file. However, the included binary data may in decoded form contain any executable code for a target platform. If additional security is desired, additional transport security solutions may be applied. For target code contained in a hex Dump, developers may want to include certificates, checksums, and the like in hexdump form for the target platform. Such uses are outside the scope of this document and a matter of implementation.
十六進法Dumpには、本来、他のセキュリティ問題が全くいかなる他のXMLファイルにも申し込むことほどありません。 しかしながら、含まれているバイナリ・データは解読されたフォームに目標プラットホームへのどんな実行コードも含むかもしれません。 追加担保が望まれているなら、追加輸送セキュリティ対策は適用されるかもしれません。 十六進法Dumpに含まれた目標コードのために、開発者は目標プラットホームへのhexdumpフォームに証明書、チェックサム、および同様のものを含みたがっているかもしれません。 このドキュメントの範囲と実装の問題の外でそのような用途があります。
Interoperability considerations:
相互運用性問題:
n/a
なし
Published specification:
広められた仕様:
This media type is a proper subset of the XML 1.0 specification [5].
One restriction is made: no entity references other than the five
predefined general entities references ("&", "<", ">",
"'", and """) and numeric entity references may be present.
Neither the "XML" declaration (e.g., <?xml version="1.0" ?>) nor the
"DOCTYPE" declaration (e.g., <!DOCTYPE ...>) need be present. (XML
fragments are allowed.) All other XML 1.0 instructions (e.g., CDATA
blocks, processing instructions, and so on) are allowed.
このメディアタイプはXML1.0仕様[5]の真部分集合です。 1つの制限をします: 「5以外のどんな実体参照も一般実体参照を事前に定義しなかった、("&"、"<"">"、」 apos;、」 """、)、数値実体参照は存在しているかもしれません。 どちらの"XML"宣言、(<?例えば、xmlバージョンが等しい、「1インチ?>、)、"DOCTYPE"宣言(例えば、<!DOCTYPE…>)が存在していなければならない、」 (XML断片は許容されています。) すべての他のXML1.0指示(例えば、CDATAブロック、処理命令など)が許されています。
Strombergson, et al. Standards Track [Page 9] RFC 4194 The S Hexdump Format October 2005
Strombergson、他 規格はS Hexdump形式2005年10月にRFC4194を追跡します[9ページ]。
Applications that use this media type: any program or individual wishing to make use of this XML 1.0 subset for hexdump exchange.
このメディアタイプを使用するアプリケーション: hexdump交換にこのXML1.0部分集合を利用するどんなプログラムか個々の願望。
Additional information:
追加情報:
o Magic number: There is no single initial Byte sequence that is
always present for SHF files
o File extension: shf
o Macintosh File Type code: none
o マジックナンバー: どんなSHFファイルo File拡張子のためにいつも存在しているただ一つの初期のByte系列もありません: shf oマッキントッシュFile Typeコード: なし
Intended usage: COMMON.
意図している用法: 一般的。
Author/Change controller: this MIME transport type is controlled by the IETF.
コントローラを書くか、または変えてください: このMIME輸送タイプはIETFによって監督されます。
10. Extensions
10. 拡大
The attributes of elements in the SHF XML format may be extended when need arises. For example, certain applications will want to represent executable code as an SHF Dump, and may then need an execution start address to be associated with certain Dump Blocks, so that the address can be configured as a starting point for the CPU part of any processor code present in the Block, as opposed to the raw data, which is already given a start address by way of the "address" attribute. This can be done by extending the Block tag with a "start_address" attribute.
必要性が起こるとき、SHF XML形式の要素の属性は広げられるかもしれません。 例えば、あるアプリケーションはSHF Dumpとして実行コードを表したくなるでしょう、そして、次に、実行開始アドレスが、あるDump Blocksに関連しているのが必要であるかもしれません、Blockの現在のどんなプロセッサコードのCPU部分のための出発点としてもアドレスを構成できるように、生データと対照的に。「アドレス」属性を通した開始アドレスは既に生データに与えられています。 「始め_アドレス」属性があるBlockタグを広げることによって、これができます。
Another possible scenario is when a dump is applied to a computer system with several independent address spaces, such as a system with two CPUs, each with independent memories. In this case, a user may want to add an "address_space" attribute.
別の可能なシナリオはダンプがいくつかの独立しているアドレス空間でコンピュータ・システムに適用される時です、2個のCPUがあるシステムのように、それぞれ独立している思い出で。 この場合、ユーザは「アドレス_スペース」属性を加えたがっているかもしれません。
As long as such new attributes are added, with no attributes being removed or redefined, the resulting Dump shall be considered a valid SHF Dump and transported using the application/xml+shf transport type. Parsers unaware of the modified namespace shall silently ignore any such extended attributes, or simply duplicate them from input to output when processing an SHF file as a filter. The management of such extended attributes is a matter of convention between different classes of users and not a matter of the IETF.
そのような新しい属性が取り除くか、または再定義する属性なしで加えられる限り、結果として起こるDumpは、アプリケーション/xml+shf輸送タイプを使用することで有効なSHF Dumpであると考えられて、輸送されるものとします。 変更された名前空間に気づかないパーサは、静かにどんなそのような拡張属性も無視するものとするか、またはフィルタとしてSHFファイルを処理するとき出力する入力からそれらを単にコピーするものとします。 そのような拡張属性の管理はIETFの問題ではなく、異なったクラスのユーザの間のコンベンションの物質です。
Strombergson, et al. Standards Track [Page 10] RFC 4194 The S Hexdump Format October 2005
Strombergson、他 規格はS Hexdump形式2005年10月にRFC4194を追跡します[10ページ]。
11. Additional Information
11. 追加情報
Contact for further information: c.f., the "Authors' Addresses" section of this memo.
詳細のために以下に連絡してください。 c. f.、このメモの「作者のアドレス」セクション。
Acknowledgements: The SMIL memory Dump was kindly provided by Sten Henriksson at Lund University. Proofreading and good feedback on the SHF document was generously provided by Peter Lindgren, Tony Hansen, Larry Masinter, and Clive D.W. Feather. We also want to thank the Applications area workgroup for their help during development.
承認: SMILメモリDumpはランド大学でステンHenrikssonによって親切に提供されました。 SHFドキュメントの校正していて良いフィードバックはピーター・リンドグレーン、トニー・ハンセン、ラリーMasinter、およびクライヴD.W.Featherによって気前よく提供されました。 また、開発の間、彼らの助けについてApplications領域ワークグループに感謝申し上げます。
12. Normative References
12. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", BCP 14, RFC 3174, September 2001.
[2] イーストレークと3番目とD.とP.ジョーンズ、「米国の安全なハッシュアルゴリズム1(SHA1)」、BCP14、RFC3174、2001年9月。
[3] Eastlake, 3rd, D., Joseph, J., and D. David, "(Extensible Markup
Language) XML-Signature Syntax and Processing", BCP 14,
RFC 3275, March 2002.
[3] イーストレーク、3番目、D.、ジョゼフ、J.、およびD.デヴィッド、「(拡張マークアップ言語)XML-署名構文と処理」(BCP14、RFC3275)は2002を行進させます。
[4] Makoto, M., Simon, S., and D. Dan, "(Extensible Markup Language)
XML Media Types", RFC 3023, January 2001.
[4] 誠、M.、サイモン、S.、およびD.ダン、「(拡張マークアップ言語)XMLメディアタイプ」、RFC3023、2001年1月。
[5] Bray, Tim, Paoli, Jean, Sperberg-McQueen, C. M. and Maler, Eve,
Yergeau, Francois, "Extensible Markup Language (XML) 1.0 (Third
Edition)", http://www.w3.org/TR/REC-xml.
[5] ロバの鳴き声とティムとパオリとジーンとSperberg-マックィーンとC.M.とMaler、イブ、Yergeau、フランソア、「拡張マークアップ言語(XML)1.0(第3版)」 http://www.w3.org/TR/REC-xml 。
Strombergson, et al. Standards Track [Page 11] RFC 4194 The S Hexdump Format October 2005
Strombergson、他 規格はS Hexdump形式2005年10月にRFC4194を追跡します[11ページ]。
Authors' Addresses
作者のアドレス
Joachim Strombergson InformAsic AB Hugo Grauers gata 5a Gothenburg 411 33 SE
ヨアヒム・Strombergson InformAsic ABユーゴー・Grauers gata 5aイェーテボリ411 33SE
Phone: +46 31 68 54 90 EMail: Joachim.Strombergson@InformAsic.com URI: http://www.InformAsic.com/
以下に電話をしてください。 +46 31 68 54 90はメールされます: Joachim.Strombergson@InformAsic.com ユリ: http://www.InformAsic.com/
Linus Walleij Lunds Tekniska Hogskola Master Olofs Vag 24 Lund 224 66 SE
ライナス・Walleij Lunds Tekniska HogskolaマスターOlofs Vag24ランド224 66SE
Phone: +46 703 193678 EMail: triad@df.lth.se
以下に電話をしてください。 +46 703 193678 メール: triad@df.lth.se
Patrik Faltstrom Cisco Systems Inc Ledasa 273 71 Lovestad Sweden
パトリク・FaltstromシスコシステムズInc Ledasa273 71Lovestadスウェーデン
EMail: paf@cisco.com URI: http://www.cisco.com
メール: paf@cisco.com ユリ: http://www.cisco.com
Strombergson, et al. Standards Track [Page 12] RFC 4194 The S Hexdump Format October 2005
Strombergson、他 規格はS Hexdump形式2005年10月にRFC4194を追跡します[12ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Strombergson, et al. Standards Track [Page 13]
Strombergson、他 標準化過程[13ページ]
一覧
スポンサーリンク
