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
The S Hexdump Format
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（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に対してフォーマット（SHF）、16進数でバイナリデータを記述するための新しい、XMLベースのオープンフォーマットを指定します。 SHFは、両方の小規模および大規模、単純および複雑な16進データが開いて、モダン、transport-とベンダー中立の形式でダンプを説明する能力を提供します。
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.
コンピューティング、ネットワーク、および組み込みシステムコミュニティにおいて、進データのデータフォーマットのいくつかの種類が使用されています。より一般的な形式の一つは伝えモトローラ社で発生し、「S-記録」（およびいくつかの誘導体）、として知られています。 S hexdumpがフォーマットは、その名誉で命名されました。
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のコンフィギュレーションビットストリーム、グラフィックおよび他のアプリケーション・リソース、ルーティングテーブルなど残念ながら、フォーマットなし使用真に、オープンベンダー中立、および/または明確に定義されています。
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
さらに問題これらのフォーマットのどれもがますます一般的になっている大規模なデータサイズを表現することができないという事実です。異なるで複数のサブブロックからなるデータ・ダンプ
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.
はるかに大きい32 ^ 2よりビットデータの数バイトからどこにでも及ぶワードサイズ、およびデータサイズが処理されません。また、これらのフォーマットに含まれるチェックサムは、あまりにも単純化され、より大きなデータサイズのために、彼らは正確にエラーを検出するのに十分な能力を提供します。また、適切なエラー検出のために必要なオーバーヘッドが非常に大きいです。
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.
フォーマットに導入単純化の一つは、オクタル又は進数のような他の数のシステムを禁止するために、さらにはバイト（8ビットのグループ）のみのワードサイズを可能にすることです。これは意図的なものであると実用的な現代の用途を目的とした実装を簡素化するために行われました。難解な番号システムまたは奇数ワードサイズを目的のフォーマットが他の場所で実施されてもよいです。
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データの解析およびチェックサムは、順番に最後のステップ（例えば、前の通常のビットストリームにSHFトークンに変換ワークステーションコンピュータ、によって行うことができます）ファームウェアのアップグレードの開始。
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は、ダンプ形式であり、そのような、例えば、コア・メモリの内容を変更することが意図されているバイナリ・コンフィギュレーション・フォーマットまたはパッチ、同様のアプリケーションと混同してはなりません。そのようなアプリケーションは、マシンのメモリ内の個々のビットまたはビットのグループを変更する可能性を必要とし、本文書に記載の機構の使用目的ではありません。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[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ビットのグループとして解釈されるべきです。キーワード「オクテットは、」バイトの別の名前です。
The key word "Word" is to be interpreted as a group containing an integral number of Bytes.
キーワード「ワード」バイトの整数を含む基として解釈されるべきです。
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.
キーワード「ブロック」は下から上位アドレスに実行し、特定のアドレスで始まる、単語の順序付けられたシーケンスとして解釈されるべきです。ブロックは、典型的には、コンピュータのメモリ内の特定のアドレス範囲におけるワードのシーケンスを表します。
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.
キーワード「ダンプ」又は特定の順序であってもなくてもよいブロックのシーケンスとして解釈されるべきです。ダンプは、典型的には、例えば（これに限定されない）、全体としてダンプが特定の意味を有するように、組み込みシステムのための完全なファームウェアをコンピュータのメモリのいくつかの非連続的な、興味深い部分を表します。
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）nに上昇2値として解釈されるべきです。例えば、2 ^ 8は、値256に等しいです。
The SHF-format has the following features:
SHF-形式は、次の機能があります。
o Support for arbitrarily wide data Words
任意の幅の広いデータワードのためのOサポート
o Support for very large data Blocks
非常に大規模なデータ・ブロックのためのOサポート
o Support for an arbitrary number of independent data Blocks
独立したデータブロックの任意の数のOサポート
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
XMLベースのフォーマットO
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ビットとさらに大きなワードサイズを使用しています。
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.
SHFは、Wordのサイズを指定できるようにすることで、これらのシステムのすべてをサポートしています。ワードサイズは、整数のバイト数と少なくとも一つの（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は、大小両方のデータ・ブロックを表現することができます。データブロックは、少なくとも一つ（1）Wordを含まなければなりません。また、データブロックは、（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ダンプは、少なくとも一つ（1）のデータブロックを含まなければなりません。サポートされているブロックの最大数は2 ^ 64です。ダンプ内の各データブロックは異なるワードサイズを持ち、異なるアドレスで起動することがあります。
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.
チェックサム（またはメッセージダイジェスト）は、各ブロックの正確性やデータの整合性を検証するために使用される20バイト（160ビット）の長さです。ダイジェストは、実際にはSHFデータブロック、NOT表現、すなわち、NOT ASCIIコードで表されるデータに基づいて計算しなければなりません。 SHA-1は、（2 ^ 64）-1ビットより大きくないデータブロックのダイジェストを計算することができ、これは、（2 ^ 64）-1ビットにSHF内の各データ・ブロックのサイズを制限します。
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のフォーマットは、ダンプを表すXMLデータ構造から成ります。ダンプは、ダンプヘッダ部及び一つのデータを含む（1）以上のブロックのセクションから構成されています。データの各ブロックは他のブロックとは無関係です。
A short, symbolic example of an SHF Dump is illustrated by the following structure:
SHFダンプの短い、シンボリック例は、以下の構造によって示されます：
<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ビット値）"> <ブロック名= "（人間が読み取り可能な文字列）" start_addressの= "（64ビット値）が" word_size =」（64ビット値）」長さ= "（64ビット値）が" チェックサム= "（20バイトのダイジェスト）">（データ）</> </ダンプブロック>
The header section comprises the Dump tag, which includes the following attributes:
ヘッダ部は、次の属性を含むダンプタグを含みます。
o name: A compulsory string of arbitrary length used by any interested party to identify the specific SHF Dump.
O名：特定のSHFダンプを識別するために、あらゆる利害関係者によって使用される任意の長さの強制的な文字列。
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ダンプ内のブロックの数を表す任意の64ビットの16進値。時はいつでも利用でき、この値が供給されなければなりません。しかし、ブロックの数が予め与えることができない可能性のあるシナリオがあります。値が存在する場合、それは実装によって検証されなければなりません。値が虚偽である場合、動作は実装定義です。
After the opening Dump tag, one or more subsections of Blocks must follow. Finally, the complete SHF Dump ends with a closing Dump tag.
オープニングダンプタグの後、ブロックの一の以上のサブセクションでは、従わなければなりません。最後に、完全なSHFダンプが終了ダンプタグで終わり。
The Block subsection contains a Block tag and a number of data words. The Block tag includes the following attributes:
ブロックのサブセクションは、ブロックタグとデータワードの数が含まれています。ブロックタグは次の属性が含まれます。
o name: A compulsory string of arbitrary length used by any interested party to identify the specific Block.
O名：特定のブロックを識別するために、任意の利害関係者によって使用される任意の長さの強制的な文字列。
o start_address: A compulsory, 64-bit hexadecimal value representing the start address in Bytes for the data in the Block.
O start_addressの：ブロック内のデータのバイトで開始アドレスを表す強制、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 word_size：データの一つの単語のバイト数（幅）を表す強制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長さ：ブロック要素の内部に次の単語の数を示す符号なし64ビット整数の強制的な16進表現。この値が虚偽であることが判明した場合、ブロックは捨てなければなりません。
o checksum: A compulsory hexadecimal representation of the 20 Byte SHA-1 digest of the data in the Block.
Oチェックサム：ブロック内のデータの20バイトの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 * word_sizeの*長さ）によって与えられます。式は、（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.
開口ブロックタグの後に、ブロック内の実際のデータの16進表現が続きます。最後に、ブロックのセクションでは、クロージングブロックタグで終わります。
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進数でなければなりません。このルールから除外唯一の属性はダンプとブロックタグのname属性です。この制限は、ダンプを読みやすくするために課されている：読者は図は、16進表記で、またはしないで、常に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ブロックで表されるデータは、（2 ^ 64）-1ビットよりも大きくてはいけません。
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ワードのサイズは、（2 ^ 64）-1ビットよりも大きくてはいけません。これが最大幅に定義されたWordでブロックが複数の単語を含むことができないことを意味します。 SHFの消費者は、それがSHFダンプのブロックを解析するために開始する前に、特定のワード長を扱うことができることを保証しなければなりません。そうしないと、バッファオーバーフローを引き起こし、消費するアプリケーションを実行しているシステムの安定性とセキュリティを危険にさらすことがあります。
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、アドレス1234としない3412を示し、に属性値を交換するようなアーキテクチャ上で実行されている任意の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.
ワードサイズが1つのバイトよりも大きい場合には、O同様に、ダンプ内の言葉は、ビッグエンディアン形式で格納する必要があります。ここでは、周りのバイトをスワップするための同じ必要性は、前の段落で述べたように、発生する可能性があります。
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:
要素という名前の「ブロック」と属性「ブロック」、「住所」、「word_size」と「チェックサム」の内容は、唯一の有効なhexbyte配列である文字が含まれている必要があります。これらは：
whitespace ::= (#x20 | #x9 | #xC | #xD | #xA)
hexdigit ::= [0-9A-Fa-f]
hexbytes ::= whitespace* hexdigit (hexdigit|whitespace)*
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ファイルを読み込むパーサは静かに（誤って）これらの要素や属性のいずれかに表示され、他の文字を無視すべきです。これらの外国人の文字は、それらが存在しなかったかのように扱われるべきです。また、「空白」は何の意味論的な意味を持たないことに注意してください。それはダンプの可読性を向上させることの理由でのみ有効です。空白は完全に除去されてもよいし、所望であればhexbyte配列が連結します。ワードサイズをバイト数で指定されるという事実は、ブロック内の16進数字の数は偶数である必要があることを意味することに注意してください。不正な形式のブロックは実装によって無視されるべきです。
<!-- DTD for the S Hexdump Format, as of 2003-10-10 Linus Walleij, Joachim Strombergson, Patrik Faltstrom 2003
<！ - DTD S hexdumpがフォーマットのため、2003年10月10日ライナスWalleij、ヨアヒムStrombergson、パトリックFaltstrom 2003年
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"?>
<！ENTITY％SHF PUBLIC " - // IETF // DTD SHF // EN" "http://ietf.org/dtd/shf.dtd">％のSHF。 - ？？> <xmlのバージョン= "1.0" エンコード= "UTF-8">
<!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>
<！ELEMENTブロック（#PCDATA）> <！ATTLISTブロック名CDATA #REQUIREDアドレスCDATA #REQUIREDのword_size CDATA #REQUIRED長CDATA #REQUIREDチェックサムCDATA #REQUIRED>
This section contains three different SHF examples, illustrating the usage of SHF and the attributes in SHF.
このセクションでは、SHFおよびSHFの属性の使用法を示す、三つの異なるSHFの例を含んでいます。
The first example is a simple SHF Dump with a single Block of data:
最初の例では、データの単一のブロックを有する単純なSHFダンプです。
<?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 version = "1.0" エンコード= "UTF-8"？> <ダンプ名= "単純SHF例" ブロック= "01"> <ブロック名= "HEX形式の重要なメッセージ" アドレス= "0400" word_size = "01" 長さ= "1F" チェックサム= "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 </ブロック> < />ダンプ
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:
第二の例は、13の第フィボナッチ数を計算し0x1101-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 version = "1.0" エンコード= "UTF-8"？> <ダンプ名= "6502フィボナッチ" ブロック= "02"> <ブロック名= "コード" アドレス= "1000" word_size = "01" の長さ= "2A" チェックサム= "5cab5bf8ee299af1ad17e8093d941914eb5930c7"> 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 A9 60 </ブロック> <ブロック名= "Memの" アドレス= "1100" word_size = "01" 長さ= "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ビット幅のデータのブロックを含みます。
<?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 version = "1.0" エンコード= "UTF-8"？>「= <ブロック名= "SMILのメモリダンプ" アドレス<ブロック= "00001" 名前= "幅のデータ・ワードとSHFダンプの例を" ダンプ> 000" word_size = "5" 長さ= "1A" チェックサム= "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 </ブロック> </ダンプ>
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つが、転送管理、または変換したい進データを表すためのフォーマットです。フォーマット自体が表現されたデータが誤って、悪意のある、またはその他の危険な表現されていないことを保証するものではありません。
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ファイルのデータの整合性は、必要であれば、このようなRFC 3275によって記述ジェネリック署名機構としてSHFファイル、[3]に、外部手段によって、提供されます。
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].
このセクションでは、SHFにMIMEタイプの登録情報が含まれています。メディアタイプは、[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の0 MIMEメディアタイプ名：アプリケーションO MIMEサブタイプ名：必須パラメータO SHF + XML：文字セット
Required parameters: 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.
このメディアタイプは、バイナリコンテンツを含む可能性があります。バイナリ転送を可能にしないトランスポート上で使用される際に、適切な符号化が適用されなければなりません。
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.
それ自体が進ダンプは、他のXMLファイルに適用されるものよりも他のセキュリティの考慮事項を持っていません。しかし、含まれるバイナリデータを復号形式でターゲットプラットフォームのための任意の実行可能なコードを含んでいてもよいです。追加のセキュリティが必要な場合は、追加のトランスポート・セキュリティ・ソリューションを適用することができます。進ダンプに含まれるターゲット・コードの場合、開発者は、ターゲットプラットフォーム用hexdumpが形式で証明書、チェックサム、などを含めることができます。このような用途には、この文書の範囲と実装の問題外です。
Interoperability considerations:
相互運用性の考慮事項：
n/a
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.
このメディアタイプは、XML 1.0仕様[5]の適切なサブセットです。一つの制限は行われない：NO 5つのあらかじめ定義された一般的な実体参照以外の参照他のエンティティ（ "＆＃038;"、 "＆LT;"、 "＆GT;"、 "'は、"、及び "＆QUOT;"）と数値を実体参照が存在してもよいです。 "XML" 宣言（例えば、の<？xml version = "1.0"？>）も "DOCTYPE" 宣言でもない（例えば、<！DOCTYPE ...>）に存在することが必要です。 （XMLフラグメントが許可されている。）他のすべてのXML 1.0の命令（例えば、CDATAブロック、処理命令など）が許可されます。
Applications that use this media type: any program or individual wishing to make use of this XML 1.0 subset for hexdump exchange.
このメディアタイプを使用するアプリケーション：任意のプログラムまたは個人はhexdumpが交換のために、このXML 1.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マジックナンバー：常にファイル拡張子O SHFファイルのための存在である単一の最初のバイトシーケンスがありません：MacintoshのファイルタイプコードoをSHF：なし
Intended usage: COMMON.
意図している用法：COMMON。
Author/Change controller: this MIME transport type is controlled by the IETF.
著者/変更コントローラ：このMIMEトランスポートタイプはIETFによって制御されます。
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ダンプとして実行可能なコードを表すことになるでしょう、そして、アドレスは、任意のプロセッサのCPU部のための出発点として設定することができるように、特定のダンプ・ブロックに関連する実行開始アドレスを必要とするかもしれませんブロック内のコードの存在、すでに「アドレス」属性を経由して開始アドレスを付与された生のデータとは対照的。これは、「start_addressの」属性を持つブロックタグを拡張することによって行うことができます。
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.
ダンプが、このような二つのCPU、独立のメモリとのそれぞれとシステムなどのいくつかの独立したアドレス空間、コンピュータシステムに適用されたときに別の可能なシナリオがあります。この場合、ユーザは「ADDRESS_SPACE」属性を追加することもできます。
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.
限り、そのような新しい属性が削除または再定義されない属性と、追加されるように、得られたダンプは、有効なSHFダンプと見なされ、アプリケーション/ XML + SHFトランスポートタイプを使用して輸送しなければなりません。修飾された名前空間を知らないパーサは静かにそのような拡張属性を無視し、又はフィルタとしてSHFファイルを処理するときに、単に入力から出力へそれらを複製しなければなりません。そのような拡張属性の管理は、異なるユーザのクラスやIETFのない問題間の慣習の問題です。
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のメモリダンプが親切ルンド大学でステンHenrikssonによって提供されました。 SHFドキュメント上の校正と良いフィードバックを寛大にピーター・リンドグレン、トニー・ハンセン、ラリーMasinter、およびクライヴD.W.によって提供されましたフェザー。我々はまた、開発中の彼らの助けのためのアプリケーションエリアのワークグループに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", BCP 14, RFC 3174, September 2001.
[2]イーストレイクは、第三、D.とP.ジョーンズは、BCP 14、RFC 3174、2001年9月、 "米国は、ハッシュアルゴリズム1（SHA1）を固定します"。
[3] Eastlake, 3rd, D., Joseph, J., and D. David, "(Extensible Markup Language) XML-Signature Syntax and Processing", BCP 14, RFC 3275, March 2002.
[3]イーストレイク、第三、D.、ジョセフ、J.、およびD.デイヴィッド、 "XML（Extensible Markup Language）に-署名構文と処理"、BCP 14、RFC 3275、2002年3月。
[4] Makoto, M., Simon, S., and D. Dan, "(Extensible Markup Language) XML Media Types", RFC 3023, January 2001.
[4]誠、M.、サイモン、S.、およびD.ダン、 "XML（Extensible Markup Language）にメディアタイプ"、RFC 3023、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-マックイーン、CMとMALER、イブ、Yergeau、フランソワ、 "拡張マークアップ言語（XML）1.0（第3版）"、http://www.w3.org/TR / REC-XML。
Authors' Addresses
著者のアドレス
Joachim Strombergson InformAsic AB Hugo Grauers gata 5a Gothenburg 411 33 SE
ヨアヒムストロムベルクソンInformAsic ABヒューゴGrauers通り5Aイェーテボリ411 33ギガバイト
Phone: +46 31 68 54 90 EMail: Joachim.Strombergson@InformAsic.com URI: http://www.InformAsic.com/
電話：+46 31 68 54 90 Eメール：Joachim.Strombergson@InformAsic.com URI：http://www.InformAsic.com/
Linus Walleij Lunds Tekniska Hogskola Master Olofs Vag 24 Lund 224 66 SE
ライナスWalleijルンド音楽大学マスターオロフ・浮浪人24 224 66ルンド、SE
Phone: +46 703 193678 EMail: triad@df.lth.se
電話：+46 703 193678 Eメール：triad@df.lth.se
Patrik Faltstrom Cisco Systems Inc Ledasa 273 71 Lovestad Sweden
パトリックFaltstromシスコシステムズ社Ledasa 273 71 Lovestadスウェーデン
EMail: paf@cisco.com URI: http://www.cisco.com
電子メール：paf@cisco.com URI：http://www.cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。