Subject: Last-Call comments on 'The Standard Hexdump Format ' <draft-strombergson-shf-03.txt>

From: Jacob Nevins <[email-masked]>
Date: Fri, 26 Nov 2004 15:59:38 +0000

Re: <http://www.ietf.org/internet-drafts/draft-strombergson-shf-03.txt>

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 <block> 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 <block> 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 <block>s in the <dump> 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
   <block>.)

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

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf