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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf