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 blocks 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 PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
