idnits 2.17.1
draft-strombergson-shf-06.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3978, Section 5.1.a on line 19.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 549.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 526.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 533.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 539.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement.
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
This document is an Internet-Draft and is subject to all provisions of
Section 3 of RFC 3667.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
BCP 79.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** The document is more than 15 pages and seems to lack a Table of Contents.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There are 2 instances of too long lines in the document, the longest one
being 4 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (March 22, 2005) is 6973 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: '0-9A-Fa-f' on line 271
-- Looks like a reference, but probably isn't: 'WWWXML' on line 413
== Unused Reference: '4' is defined on line 485, but no explicit reference
was found in the text
** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. '2')
** Obsolete normative reference: RFC 3023 (ref. '4') (Obsoleted by RFC 7303)
Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 Standards Track J. Strombergson
2 Internet-Draft InformAsic AB
3 Expires: September 23, 2005 L. Walleij
4 Lunds Tekniska Hogskola
5 P. Faltstrom
6 Cisco Systems Inc
7 March 22, 2005
9 The S Hexdump Format
10 draft-strombergson-shf-06.txt
12 Status of this Memo
14 This document is an Internet-Draft and is subject to all provisions
15 of Section 3 of RFC 3667. By submitting this Internet-Draft, each
16 author represents that any applicable patent or other IPR claims of
17 which he or she is aware have been or will be disclosed, and any of
18 which he or she become aware will be disclosed, in accordance with
19 RFC 3668.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that
23 other groups may also distribute working documents as
24 Internet-Drafts.
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on September 23, 2005.
39 Copyright Notice
41 Copyright (C) The Internet Society (2005).
43 Abstract
45 This document specifies the S Hexdump Format (SHF), a new XML-based
46 open format for describing binary data in hexadecimal notation. SHF
47 provides the ability to describe both small and large, simple and
48 complex hexadecimal data dumps in an open, modern, transport and
49 vendor neutral format.
51 1. Introduction
53 In the computing, network and embedded systems communities several
54 different types of data formats for hexadecimal data are being used.
55 One of the more common formats is known as "S-records" (and several
56 derivatives) which reportedly originated at the Motorola company.
57 The S Hexdump Format is named in its honour.
59 Typical uses of these dump formats include executable object code for
60 embedded systems (i.e. "firmware"), on-chip flash memories and
61 filesystems, FPGA configuration bitstreams, graphics and other
62 application resources, routing tables, etc. Unfortunately, none of
63 the formats used are truly open, vendor neutral and/or well defined.
65 Even more problematic is the fact that none of these formats are able
66 to represent data sizes that are getting more and more common. Data
67 dumps comprised of multiple sub-blocks with different Word sizes,
68 data sizes spanning anywhere from a few Bytes of data to data sizes
69 much larger than 2^32 bits are not handled. Also, the checksums
70 included in these formats are too simplistic and for larger data
71 sizes provides insufficient ability to accurately detect errors.
72 Alternatively, the overhead needed for proper error detection is very
73 large.
75 The S Hexdump format therefore is an effort to provide a modern,
76 XML-based format that is not too complex for simple tools and
77 computing environments to implement, generate, parse and use. Yet
78 the format is able to handle large data sizes and complex data
79 structures and can provide high quality error detection by leveraging
80 standardized cryptographic hash functions.
82 One of the simplifications introduced in the format is to disallow
83 other number systems such as octal or decimal notation, and to allow
84 for Word sizes of even bytes (8-bit groups) only. This is
85 intentional and was done to simplify implementations aimed for
86 practical present-day applications. Formats aimed for esoteric
87 number systems or odd Word sizes may be implemented elsewhere.
89 At present, the usage of the SHF format may be mainly for Internet
90 transport and file storage on development machinery. A parser for
91 the XML format is presently not easily deployed in hardware devices,
92 but the parsing and checksumming of the SHF data may be done by a
93 workstation computer, which in turn converts the SHF tokens to an
94 ordinary bitstream before the last step (e.g., of a firmware upgrade)
95 commence.
97 SHF is a dump format only and shall not be confused with similar
98 applications, such as binary configuration formats or patches, which
99 are intended to e.g. alter contents of a core memory. Such
100 applications require the possibility to modify individual bits or
101 groups of bits in the memory of a machine, and is not the intended
102 usage of the mechanism described in the present document.
104 2. Terminology
106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
108 document are to be interpreted as described in RFC 2119 [1].
110 The key word Byte is to be interpreted as a group of 8 bits. The key
111 word Octet is another name for Byte.
113 The key word Word is to be interpreted as a group containing an
114 integral number of Bytes.
116 The key word Block is to be interpreted as an ordered sequence of
117 Words, beginning at a certain address, running from lower to higher
118 addresses. A Block typically represents a sequence of Words at a
119 certain address range in the memory of a computer.
121 The key word Dump is to be interpreted as a sequence of Blocks, which
122 may or may not be in a particular order. A Dump typically represents
123 some non-continous, interesting parts of the memory of a computer,
124 such that the Dump as a whole has a certain meaning, for example (but
125 not limited to) a complete firmware for an embedded system.
127 The expression 2^n is to be interpreted as the value two (2) raised
128 to the n:th power. For example 2^8 equals the value 256.
130 3. Features and functionality
132 The SHF-format has the following features:
133 o Support for arbitrarily wide data Words
134 o Support for very large data Blocks
135 o Support for an arbitrary number of independent data Blocks
136 o Data integrity detection against errors provided by the RFC3174
137 specified (see [2]) SHA-1 cryptographic signature
138 o An XML-based format
140 In the embedded systems domain, 8- and 16-bit processors are still
141 used in large numbers and will continue to be used for any forseeable
142 future. Simultaneously, more and more systems are using 64-bit and
143 even larger Word sizes.
145 SHF supports all of these systems by allowing the Word size to be
146 specified. The Word size MUST be an integer number of Bytes and at
147 least one (1) Byte.
149 SHF is able to represent both large and small data Blocks. The data
150 Block MUST contain at least one (1) Word. Additionally, the data
151 Block MUST NOT be larger than (2^64)-1 bits.
153 The SHF Dump MUST contain at least one (1) data Block. The maximum
154 number of Blocks supported is 2^64. Each data Block in the Dump MAY
155 have different Word sizes and start at different addresses.
157 The checksum (or message digest) used to verify the correctness or
158 data integrity of each Block is 20 Bytes (160 bits) long. The digest
159 MUST be calculated on the data actually represented by the SHF data
160 Block, NOT the representation, i.e. NOT the ASCII-code. SHA-1 is
161 only able to calculate a digest for a data Block no larger than
162 (2^64)-1 bits and this limits the size of each data Block in SHF to
163 (2^64)-1 bits.
165 4. SHF XML specification
167 The SHF format consists of an XML data structure representing a Dump.
168 The Dump consists of a Dump header section and one (1) or more Block
169 sections containing data. Each Block of data is independent of any
170 other Block.
172 A short, symbolic example of a SHF Dump is illustrated by the
173 following structure:
175
176
179 (Data)
180
181
183 4.1 Header section
185 The header section comprises the Dump tag, which includes the
186 following attributes:
188 o name: A compulsory string of arbitrary length used by any
189 interested party to identify the specific SHF Dump.
190 o blocks: An optional 64 bit hexadecimal value representing the
191 number of Blocks in the specific SHF Dump. Whenever available,
192 this value should be supplied. There are however potential
193 scenarios where the number of Blocks cannot be given beforehand.
194 If the value is present, it should be verified by implementers: if
195 the value is untrue the behaviour is implementation-defined.
197 After the opening Dump tag, one or more subsections of Blocks must
198 follow. Finally, the complete SHF Dump ends with a closing Dump tag.
200 4.2 Block subsection
202 The Block subsection contains a Block tag and a number of data words
203 The Block tag includes the following attributes:
205 o name: A compulsory string of arbitrary length used by any
206 interested party to identify the specific Block.
207 o start_address: A compulsory 64 bit hexadecimal value representing
208 the start address in Bytes for the data in the Block.
209 o word_size: A compulsory 64 bit hexadecimal value representing the
210 number of Bytes (the width) of one Word of the data.
212 o length: A compulsory hexadecimal representation of an unsigned
213 64-bit integer indicating the number of Words following inside the
214 Block element. If this value turns out to be untrue, the Block
215 MUST be discarded.
216 o checksum: A compulsory hexadecimal representation of the 20 Byte
217 SHA-1 digest of the data in the Block.
219 The total size of the data in the Block (in bits) is given by the
220 expression (8 * word_size * length). The expression MUST NOT be
221 larger than (2^64)-1.
223 After the opening Block tag, a hexadecimal representation of the
224 actual data in the Block follows. Finally, the Block section ends
225 with a closing Block tag.
227 5. SHF rules and limits
229 There are several rules and limits in SHF:
230 o All attribute values representing an actual value and the data
231 MUST be in hexadecimal notation. The only attribute excluded from
232 this rule is the name attribute in the Dump and Block tags. This
233 restriction has been imposed for ease of reading the dump: a
234 reader shall not be uncertain about whether a figure is in hex
235 notation or not, and can always assume it is hexadecimal.
236 o All attribute values with the exception for the checksum MAY omit
237 leading zeros. Conversely, the checksum MUST NOT omit leading
238 zeros.
239 o The data represented in a Block MUST NOT be larger than (2^64)-1
240 bits.
241 o The size of a Word MUST NOT be larger than (2^64)-1 bits. This
242 implies that a Block with a Word defined to the maximum width can
243 not contain more than one Word. An SHF consumer shall assure that
244 it can handle a certain Word length before beginning to parse
245 blocks of an SHF Dump. Failure to do so may cause buffer
246 overflows and endanger the stability and security of the system
247 running the consuming application.
248 o The attribute values representing an actual value MUST be in "Big
249 Endian-format". This means that the most significant hexadecimal
250 digits are to be put to the left in a hexadecimal Word, address or
251 similar field, so that e.g. the address value 1234 represents the
252 address 1234 and not 3412. While some computing architectures may
253 be using Little Endian Words as their native format, it is the
254 responsibility of any SHF producer running on such an architecture
255 to swap the attribute values to a Big Endian format. The reverse
256 holds for a consumer receiving the Big Endian SHF attributes: if
257 the consumer is Little Endian, the values have to be swapped
258 around.
259 o The words inside a Dump MUST likewise be stored in a Big Endian
260 format if the word size is larger than one Byte. Here the same
261 need for swapping Bytes around may arise as mentioned in the
262 previous paragraph.
264 6. SHF DTD
266 The contents of the element named "block" and the attributes
267 "blocks", "address", "word_size" and "checksum" should only contain
268 the characters that are valid hexbyte sequences. These are:
270 whitespace ::= (#x20 | #x9 | #xC | #xD | #xA)
271 hexdigit ::= [0-9A-Fa-f]
272 hexbytes ::= whitespace* hexdigit (hexdigit|whitespace)*
274 A parser reading in an SHF file should silently ignore any other
275 characters that (by mistake) appear in any of these elements or
276 attributes. These alien characters should be treated as if they did
277 not exist. Also note that "whitespace" has no semantic meaning; it
278 is only valid for the reason of improving the human readability of
279 the Dump. Whitespace may be altogether removed and the hexbyte
280 sequences concatenated if desired. Notice that the fact that word
281 size is to be given in a number of bytes implies that the number of
282 hexadecimal digits inside a block need to be even. Malformed blocks
283 should be ignored by implementations.
285
295
297
298
302
303
310 7. SHF examples
312 This section contains three different SHF examples, illustrating the
313 usage of SHF and the attributes in SHF.
315 The first example is a simple SHF Dump with a single Block of data:
317
318
319
322 41 6c 6c 20 79 6f 75 72 20 62 61 73 65 20 61 72
323 65 20 62 65 6c 6f 6e 67 20 74 6f 20 75 73 0a
324
325
327 The second example is a program in 6502 machine code residing at
328 memory address 0x1000, which calculates the 13 first fibonacci
329 numbers and stores them at 0x1101-0x110d:
331
332
333
335 a9 01 85 20 85 21 20 1e 10 20 1e 10 18 a5 21 aa
336 65 20 86 20 85 21 20 1e 10 c9 c8 90 ef 60 ae 00
337 11 a5 21 9d 00 11 ee 00 11 60
338
339
341 01 00 00 00 00 00 00 00 00 00 00 00 00 00
342
343
345 The final example contains a Block of 40-bit wide data:
347
348
349
351 00100 00200 00000 00090 00000 00036 00300 00400
352 00852 00250 00230 00858 00500 00600 014DC 00058
353 002A8 000B8 00700 00800 000B0 00192 00100 00000
354 00900 00A00 00000 0000A 40000 00000 00B00 00C00
355 00000 00000 00000 00001 00D00 00E00 00000 00100
356 0CCCC CCCCD 00F00 01000 00000 00010 80000 00000
357 00100 00790 00000 00234
359
360
362 8. SHF security considerations
364 The SHF format is a format for representing hexadecimal data that one
365 wants to transfer, manage or transform. The format itself does not
366 guarantee that the represented data is not falsely represented,
367 malicious or otherwise dangerous.
369 The data integrity of the SHF file as a whole is to be provided, if
370 needed, by means external to the SHF file, such as the generic
371 signing mechanism described by RFC 3275 [3].
373 9. IANA Considerations
375 This section contains the registration information for the MIME type
376 to SHF.
378 o Registration: application/shf+xml
379 o MIME media type name: application
380 o MIME subtype name: shf+xml
381 o Required parameters: charset
383 Required parameters: charset
385 This parameter must exist and must be set to "UTF-8". No other
386 character sets are allowed for transporting SHF data. The character
387 set designator MUST be uppercase.
389 Encoding considerations
391 This media type may contain binary content; accordingly, when used
392 over a transport that does not permit binary transfer, an appropriate
393 encoding must be applied.
395 Security considerations
397 A hex Dump in itself has no other security considerations than what
398 applies for any other XML file. However the included binary data may
399 in decoded form contain any executable code for a target platform.
400 If additional security is desired, additional transport security
401 solutions may be applied. For target code contained in a hex Dump,
402 developers may want to include certificates, checksums and the like
403 in hexdump form for the target platform. Such uses are outside the
404 scope of this document and a matter of implementation.
406 Interoperability considerations
408 n/a
410 Published specification
412 This media type is a proper subset of the the XML 1.0 specification
413 [WWWXML]. One restriction is made: no entity references other than
414 the five predefined general entities references ("&", "<", ">", "'",
415 and """) and numeric entity references may be present. Neither the
416 "XML" declaration (e.g., ) nor the "DOCTYPE" declaration (e.g., )
417 need be present. (XML fragments are allowed.) All other XML 1.0
418 instructions (e.g., CDATA blocks, processing instructions, and so on)
419 are allowed.
421 Applications which use this media type: any program or individual
422 wishing to make use of this XML 1.0 subset for hexdump exchange.
424 Additional information
426 o Magic number: There is no single initial Byte sequence that is
427 always present for SHF files
428 o File extension: shf
429 o Macintosh File Type code: none
431 Intended usage: COMMON.
433 Author/Change controller: this MIME transport type is controlled by
434 the IETF.
436 10. Extensions
438 The attributes of elements in the SHF XML format may be extended when
439 need arise. For example, certain applications will want to represent
440 executable code as a SHF Dump and may then need a execution start
441 address to be associated with certain Dump Blocks, so that the
442 address can be configured as a starting point for the CPU part of any
443 processor code present in the Block, as opposed to the raw data which
444 is already given a start address by way of the "address" attribute.
445 This can be done by extending the Block tag with a "start_address"
446 attribute.
448 Another possible scenario is when a dump is applied to a computer
449 system with several independent address spaces, such as a system with
450 two CPU:s with independent memories. In this case, a user may want
451 to add an "address_space" attribute.
453 As long as such new attributes are added, with no attributes being
454 removed or redefined, the resulting Dump shall be considered a valid
455 SHF Dump, transported using the application/xml+shf transport type,
456 and parsers unaware of the modified namespace shall silently ignore
457 any such extended attributes, or simply duplicate them from input to
458 output when processing an SHF file as a filter. The management of
459 such extended attributes is a matter of convention between different
460 classes of users and not a matter of the IETF.
462 11. Additional information
464 Contact for further information: c.f., the "Author's Address" section
465 of this memo.
467 Acknowledgments: The SMIL memory Dump was kindly provided by Sten
468 Henriksson at Lund University. Proofreading and good feedback on the
469 SHF draft was generously provided by Peter Lindgren, Tony Hansen,
470 Larry Masinter and Clive D.W. Feather. We also want to thank the
471 Applications area workgroup for their help during development.
473 12. References
475 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
476 Levels", BCP 14, RFC 2119, March 1997.
478 [2] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
479 (SHA1)", BCP 14, RFC 3174, September 2001.
481 [3] Eastlake, 3rd, D., Joseph, J. and D. David, "(Extensible Markup
482 Language) XML-Signature Syntax and Processing", BCP 14,
483 RFC 3275, March 2002.
485 [4] Makoto, M., Simon, S. and D. Dan, "(Extensible Markup Language)
486 XML Media Types", BCP 14, RFC 3023, January 2001.
488 Authors' Addresses
490 Joachim Strombergson
491 InformAsic AB
492 Hugo Grauers gata 5a
493 Gothenburg 411 33
494 SE
496 Phone: +46 31 68 54 90
497 Email: Joachim.Strombergson@InformAsic.com
498 URI: http://www.InformAsic.com/
500 Linus Walleij
501 Lunds Tekniska Hogskola
502 Master Olofs Vag 24
503 Lund 224 66
504 SE
506 Phone: +46 703 193678
507 Email: triad@df.lth.se
508 Patrik Faltstrom
509 Cisco Systems Inc
510 Ledasa
511 273 71 Lovestad
512 Sweden
514 Email: paf@cisco.com
515 URI: http://www.cisco.com
517 Intellectual Property Statement
519 The IETF takes no position regarding the validity or scope of any
520 Intellectual Property Rights or other rights that might be claimed to
521 pertain to the implementation or use of the technology described in
522 this document or the extent to which any license under such rights
523 might or might not be available; nor does it represent that it has
524 made any independent effort to identify any such rights. Information
525 on the procedures with respect to rights in RFC documents can be
526 found in BCP 78 and BCP 79.
528 Copies of IPR disclosures made to the IETF Secretariat and any
529 assurances of licenses to be made available, or the result of an
530 attempt made to obtain a general license or permission for the use of
531 such proprietary rights by implementers or users of this
532 specification can be obtained from the IETF on-line IPR repository at
533 http://www.ietf.org/ipr.
535 The IETF invites any interested party to bring to its attention any
536 copyrights, patents or patent applications, or other proprietary
537 rights that may cover technology that may be required to implement
538 this standard. Please address the information to the IETF at
539 ietf-ipr@ietf.org.
541 Disclaimer of Validity
543 This document and the information contained herein are provided on an
544 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
545 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
546 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
547 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
548 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
549 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
551 Copyright Statement
553 Copyright (C) The Internet Society (2005). This document is subject
554 to the rights, licenses and restrictions contained in BCP 78, and
555 except as set forth therein, the authors retain all their rights.
557 Acknowledgment
559 Funding for the RFC Editor function is currently provided by the
560 Internet Society.