The S Hexdump Format
draft-strombergson-shf-06

[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.

[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?

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