Skip to main content

The S Hexdump Format
draft-strombergson-shf-06

Revision differences

Document history

Date Rev. By Action
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Scott Hollenbeck
2005-03-30
06 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-03-25
06 Amy Vezza IESG state changed to Approved-announcement sent
2005-03-25
06 Amy Vezza IESG has approved the document
2005-03-24
06 Amy Vezza IESG state changed to Approved-announcement sent
2005-03-24
06 Amy Vezza IESG has approved the document
2005-03-24
06 Amy Vezza Closed "Approve" ballot
2005-03-24
06 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2005-03-24
06 Scott Hollenbeck State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Scott Hollenbeck
2005-03-24
06 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Discuss by Scott Hollenbeck
2005-03-23
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-03-23
06 (System) New version available: draft-strombergson-shf-06.txt
2005-03-10
06 Scott Hollenbeck State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Scott Hollenbeck
2005-02-18
06 (System) Removed from agenda for telechat - 2005-02-17
2005-02-17
06 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2005-02-17
06 Amy Vezza [Ballot Position Update] New position, No Objection, has been recorded for Sam Hartman by Amy Vezza
2005-02-17
06 Thomas Narten [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten
2005-02-17
06 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2005-02-17
06 Harald Alvestrand
[Ballot discuss]
Nope.

This is a rich XML application for doing a simple task that has no proven usefulness in the field.
It may need …
[Ballot discuss]
Nope.

This is a rich XML application for doing a simple task that has no proven usefulness in the field.
It may need doing, but the word "Standard" is totally inappropriate as its name.
I will not let this go out with the name "Standard" on my watch.

However, I'm fine with calling it the "S" Hexdump Format.
2005-02-17
06 Harald Alvestrand [Ballot Position Update] New position, Discuss, has been recorded for Harald Alvestrand by Harald Alvestrand
2005-02-17
06 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2005-02-16
06 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2005-02-16
06 Alex Zinin [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin
2005-02-16
06 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-02-16
06 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2005-02-14
06 Ted Hardie Note field has been cleared by Ted Hardie
2005-02-14
06 Michelle Cotton IANA Comments:
Needs an IANA Considerations section requesting registration of the MIME Media Type.
2005-02-07
06 Scott Hollenbeck [Ballot comment]
Section 5, fourth bullet: s/blocks of and SHF Dump/blocks of an SHF Dump/
2005-02-07
06 Scott Hollenbeck
[Ballot discuss]
The MIME type registration request identifies the change controller as "the authors of this document".  The request is to register this type in …
[Ballot discuss]
The MIME type registration request identifies the change controller as "the authors of this document".  The request is to register this type in the standards tree.  Shouldn't the IESG thus be the change controller?
2005-02-07
06 Scott Hollenbeck [Ballot Position Update] New position, Discuss, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2005-02-04
06 Ted Hardie Placed on agenda for telechat - 2005-02-17 by Ted Hardie
2005-02-04
06 Ted Hardie State Changes to IESG Evaluation from Waiting for Writeup::AD Followup by Ted Hardie
2005-02-04
06 Ted Hardie [Ballot Position Update] New position, Yes, has been recorded for Ted Hardie
2005-02-04
06 Ted Hardie Ballot has been issued by Ted Hardie
2005-02-04
06 Ted Hardie Created "Approve" ballot
2005-01-11
06 (System) Sub state has been changed to AD Follow up from New Id Needed
2005-01-11
05 (System) New version available: draft-strombergson-shf-05.txt
2004-12-29
06 Ted Hardie State Changes to Waiting for Writeup::Revised ID Needed from Waiting for Writeup by Ted Hardie
2004-12-29
06 Ted Hardie [Note]: 'Needs revision to handle last call comments' added by Ted Hardie
2004-12-22
06 (System) State has been changed to Waiting for Writeup from In Last Call by system
2004-12-21
06 Ted Hardie
Last call comments:
From Steve Hanna:

Whitepace" should be "Whitespace".

"Such uses is" should be "Such uses are"

Last check needed to ensure that all …
Last call comments:
From Steve Hanna:

Whitepace" should be "Whitespace".

"Such uses is" should be "Such uses are"

Last check needed to ensure that all 2^8 type expressions are retained (in some the ^ has disappeared)

From Ned Freed:

Some comments. First, a typo:

  "For example 28 equals the value 256." should be
  "For example 2^8 equals the value 256."

There are also any number of similar typos where "(264)" should actually be
"(2^64)".

Block labels, start addresses, and checksums should all be optional, not
mandatory. Applications exist for unordered block sequences, and many
applications have no need for checksums. (In fact I'd say most applications
don't need checksums.)

Checksums don't appear to cover start_address and other attributes. Is
this going to be a problem?

There doesn't appear to be a rule saying that the number of hex characters in a
data block has to be even, although the fact that lengths are expressed in
terms of an integral number of octets certainly seems to imply it.

The examples should probably include normal XML leadin " so they are actually valid XML, not XML fragments.

I'm not sure what the point of a charset parameter that has to be present and
must always be set to UTF-8 is.

Section 9.5 has two places where examples are supposed to be given but
appear to be missing. With the examples missing I'm not clear on what
can be omitted here, but if the intent is to allow material that
doesn't conform to XML syntax rules I'm against it. I will also point
out that if the material doesn't conform to XML syntax rules it should
have a media type name ending in "+xml".

Section 10 talks about start_address being a possible extension, but it sure
looks like it is a well defined part of the specification to me.

The DTD refers to an address attribute, not a start_address attribute.
There's also a bad wrap in the dump ATTLIST that needs to be fixed.

Not a requirement by any means, but I'd like to see a schema for this format in
addition to a DTD.

There's something wrong with the section numbers and/or content in and around
section 11. Part of this section looks like it belongs in the media type
registration section (9).

That's it!

From Jacob Nevins:


The Last-Call for this document caught my eye when it went past on the
IETF mailing list and I'm interested (having written too many Intel-HEX
and S-record parsers in the past).

I'm ignorant of whether there is a deployed base of this format, so I
shall assume there isn't. (Not that it matters much either way for my
comments.)

Firstly, some typographical detail that should be easy to fix:

* In section 2 the notation "2^n" for "two to the n'th power" is
  defined. However, it is almost never used; throughout, we have
  confusion like "larger than 232 bits" (presumably 2^32) and
  "(264)-1 bits" (2^64). This should be fixed before publication.

* section 5, 5th para: typo "receiveing"

* section 10, 1st para: typo "exending"

Now on to my main problem with the document as it stands:

In section 5 "SHF rules and limits":

| o  The words inside a Dump may be in the native endianness of the
|    consumer, since this represents raw memory.  However implementers
|    may choose to store also this data in a Big Endian format for ease
|    of reading: Big Endian values are more human-readable than Little
|    Endian ones.

This is no good for interoperability. If you're going to allow data to
be of either endianness, you should tag the  with the
endianness of the contained data (and when I say should, I mean it
should be required with MUST).

And finally, some more handwavey comments, which can probably be
ignored as you see fit.

* Why is the "name" attribute of  mandatory? (If I'm converting
  from H32/Srec, I'm not going to have anything to put here. This is
  likely to be the case in other situations too.)

* I'm not convinced that a count of s in the  tag is a
  good idea in XML, but I can't offhand say why. I'd have thought
  that if you have an XML parser to hand you're unlikely to need such
  a thing, but I'm not that familiar with the practicalities of XML,
  and don't know whether there's precedent for this.

  What should one do if the "blocks" attribute turns out to be
  untrue? (The same question applies to the "length" attribute of
  .)

* SHA-1 seems a bit heavy for a checksum, probably ruling out
  verification on many embedded systems. What are we trying to
  protect against here?

* One application of this format is for automatic conversion to/from
  Intel HEX / S-Records, by tools that know nothing about the
  intended consumer. I believe that it meets this requirement (apart
  from "name" as noted above); the endianness issue doesn't bite
  because these formats are always 1 byte wide.

__________________

From Randy Presuhn:

Hi -

Does anyone else have a problem with the word "Standard" in the
title of this document?  Even http://www.ietf.org/ietf/1id-guidelines.txt
says to avoid that word in document titles.

Randy
2004-12-09
04 (System) New version available: draft-strombergson-shf-04.txt
2004-11-24
06 Amy Vezza Last call sent
2004-11-24
06 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2004-11-23
06 Ted Hardie Last Call was requested by Ted Hardie
2004-11-23
06 (System) Ballot writeup text was added
2004-11-23
06 (System) Last call text was added
2004-11-23
06 (System) Ballot approval text was added
2004-11-23
06 Ted Hardie State Changes to Last Call Requested from Publication Requested by Ted Hardie
2004-11-18
03 (System) New version available: draft-strombergson-shf-03.txt
2004-11-15
06 Ted Hardie Draft Added by Ted Hardie in state Publication Requested
2004-10-21
02 (System) New version available: draft-strombergson-shf-02.txt
2004-07-14
01 (System) New version available: draft-strombergson-shf-01.txt
2003-10-21
00 (System) New version available: draft-strombergson-shf-00.txt