[要約] RFC 4194は、S Hexdump Formatというデータ形式に関する規格であり、16進数のデータを可読性の高い形式で表示するための方法を提供しています。この規格の目的は、データの解析やトラブルシューティングを容易にすることです。
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
S hexdump形式
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).
Copyright（c）The Internet Society（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.
このドキュメントは、Sexdump形式（SHF）を指定します。これは、16進表記でバイナリデータを記述するための新しいXMLベースのオープンフォーマットです。SHFは、オープン、モダン、輸送、およびベンダーの中立形式で、大小の、シンプルで複雑な16進のデータダンプを記述する機能を提供します。
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-Records」（およびいくつかのデリバティブ）として知られています。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.
さらに問題があるのは、これらの形式のいずれも、ますます一般的になっている大きなデータサイズを表すことができないという事実です。データダンプは、異なる単語サイズの複数のサブブロックで構成され、数バイトのデータから2^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つは、Octalまたは10進表記などの他の数値システムを禁止し、バイト（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 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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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ビットのグループとして解釈されます。キーワード「Octet」は、Byteの別名です。
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」という式は、n：thパワーに上げられた値2（2）として解釈されます。たとえば、2^8は値256に等しくなります。
The SHF-format has the following features:
SHF-Formatには次の機能があります。
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
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ビットとさらに大きなワードサイズを使用しています。
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は、単語サイズを指定できるようにすることにより、これらすべてのシステムをサポートします。単語のサイズは、整数数のバイト数と少なくとも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つの単語が含まれている必要があります。さらに、データブロックは（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データブロックで実際に表されるデータで計算する必要があります。つまり、ASCIIコードではありません。SHA-1は、（2^64）-1ビット以下のデータブロックのダイジェストのみを計算でき、これによりSHFの各データブロックのサイズが（2^64）-1ビットに制限されます。
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>
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.
オープニングダンプタグの後、ブロックの1つ以上のサブセクションに従う必要があります。最後に、完全な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ビット160ビットの160ビットの160ビットの値。
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：データの1つの単語のバイト数（幅）数を表す強制64ビット160ビットの六量体値。
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ビット整数の強制的な六肢表現。この値が真実でないことが判明した場合、ブロックを破棄する必要があります。
o checksum: A compulsory hexadecimal representation of the 20 Byte SHA-1 digest of the data in the Block.
o Checksum：ブロック内のデータの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進表記でなければなりません。このルールから除外された唯一の属性は、ダンプタグとブロックタグの名前属性です。この制限は、ダンプを読みやすくするために課されています。読者は、数字が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ビットより大きくてはなりません。これは、最大幅に定義された単語を持つブロックに複数の単語を含めることができないことを意味します。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進数桁が、六分位の単語、住所、または同様のフィールドで左に置かれることを意味します。たとえば、アドレス値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 同様に、ダンプ内の単語は、単語のサイズが1バイトより大きい場合は、ビッグエンディアン形式で保存する必要があります。ここでは、前の段落に記載されているように、バイトを交換するのと同じ必要性が発生する可能性があります。
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ファイルでのパーサーの読み取りは、これらの要素または属性のいずれかに（誤って）表示される他の文字を静かに無視する必要があります。これらのエイリアンのキャラクターは、まるで存在しないかのように扱われるべきです。また、「白人」には意味的な意味がないことにも注意してください。ダンプの人間の読みやすさを改善する理由でのみ有効です。白面は完全に削除され、必要に応じてヘックスビートシーケンスが連結される場合があります。単語サイズが多くのバイトで与えられるという事実は、ブロック内の16進数の数字が均等である必要があることを意味することに注意してください。不正なブロックは、実装によって無視する必要があります。
<!-- DTD for the S Hexdump Format, as of 2003-10-10 Linus Walleij, Joachim Strombergson, Patrik Faltstrom 2003
<！ - 2003-10-10の時点で、S Hexdump形式のDTD、Linus Walleij、Joachim Strombergson、Patrik 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"?>
<!ELEMENT dump (block)+>
<!ATTLIST dump
name CDATA #REQUIRED
blocks CDATA #IMPLIED>
<!ELEMENT block (#PCDATA)>
<!ATTLIST block
name CDATA #REQUIRED
address CDATA #REQUIRED
word_size CDATA #REQUIRED
length CDATA #REQUIRED
checksum CDATA #REQUIRED>
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:
最初の例は、データの単一ブロックを備えた単純な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> 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:
<？xml version = "1.0" encoding = "utf-8"？> <dump name = "simple shf example" blocks = "01"> <block name = "hex形式の重要なメッセージ"アドレス= "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/ダンプ> 2番目の例は、メモリアドレス0x1000に存在する6502マシンコードのプログラムです。これは、13の最初のフィボナッチ数を計算し、0x1101-0x110dに保存します。
<?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>
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>
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形式は、転送、管理、または変換を望んでいる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ファイル全体のデータ整合性は、必要に応じて、RFC 3275 [3]によって記述された一般的な署名メカニズムなど、SHFファイルの外部にある手段によって提供されます。
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要求パラメーター：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.
このメディアタイプには、バイナリコンテンツが含まれている場合があります。したがって、バイナリ転送を許可しない輸送で使用する場合、適切なエンコードを適用する必要があります。
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.
HEXダンプ自体には、他の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]の適切なサブセットです。1つの制限が作成されます：5つの事前定義された一般的なエンティティリファレンス（ "＆amp;"、 "＆lt;"、 "＆gt;"、 "＆apos;"）および数値エンティティ参照以外のエンティティ参照はありません。。「XML」宣言（例：<？XMLバージョン= "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 Exchangeのためにこの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 マジック番号：SHFファイルに常に存在する初期バイトシーケンスはありませんoファイル拡張子：SHF O Macintoshファイルタイプコード：なし
Intended usage: 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.
別の可能なシナリオは、ダンプが2つの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.
謝辞：スマイルの記憶ダンプは、ランド大学のステン・ヘンリクソンから親切に提供されました。SHFドキュメントに関する校正と適切なフィードバックは、Peter Lindgren、Tony Hansen、Larry Masinter、およびClive D.W.からgeneしみなく提供されました。フェザー。また、開発中のアプリケーションエリアワークグループの助けに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", BCP 14, RFC 3174, September 2001.
[2] Eastlake、3rd、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、BCP 14、RFC 3174、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] Eastlake、3rd、D.、Joseph、J。、およびD. David、「（拡張可能なマークアップ言語）XML-Signature構文と処理」、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] Makoto、M.、Simon、S。、およびD. Dan、「（拡張可能なマークアップ言語）XMLメディアタイプ」、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] ブレイ、ティム、パオリ、ジャン、スパルバーグ・マックーン、C。M。およびマラー、イブ、イヴ、ヤエルゴー、フランソワ、「拡張可能なマークアップ言語（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
Joachim Strombergson Ab Hugo Grauers Gata 5a Gothenburg 411 33 SE
Phone: +46 31 68 54 90
EMail: Joachim.Strombergson@InformAsic.com
URI: http://www.InformAsic.com/
Linus Walleij Lunds Tekniska Hogskola Master Olofs Vag 24 Lund 224 66 SE
Linus Walleij Lunds Tekniska Hogskola Master Olofs Vag 24 Lund 224 66 SE
Phone: +46 703 193678
EMail: triad@df.lth.se
Patrik Faltstrom Cisco Systems Inc Ledasa 273 71 Lovestad Sweden
Patrik Faltstrom Cisco Systems Inc Ledasa 273 71 Lovestad Sweden
EMail: paf@cisco.com
URI: http://www.cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。