At 11pm on 21/10/03 you (Linus Walleij) wrote:
We have just published an I-D for the Standard Hex Format, and this announcement is to ask the types-list to review it from a transport type perspective.
http://www.ietf.org/internet-drafts/draft-strombergson-shf-00.txt
In section 6 the draft states | Refer to this DTD as: | | <!ENTITY % SHF PUBLIC "-//IETF//DTD SHF//EN" | "http://www.foo.org/shf.dtd"> | %SHF; and in section 9.1 | There is no charset parameter. ; however in section 9.5 we have | Second, neither the "XML" declaration (e.g., ) nor the "DOCTYPE" | declaration (e.g., ) may be present. (Accordingly, if another | character set other than UTF-8 is desired, then the "charset" | parameter must be present.) . These are inconsistent. I would suggest removing both restrictions listed in 9.5: their purpose is unclear. If it is to simplify the processing, then there are many aspects of XML parsing (CDATA sections, properly parsed comments, random charsets, substituting entity references) that are harder to deal with than simply ignoring an XML declaration and doctype. Two additional points: would it not be worth declaring an XML namespace for this format in addition to the DTD? and would it not be worth adding support for using hashes other than SHA-1, both for when the time surely comes that SHA-1 is insufficient security, and to allow simpler checksums in secure environments with limited processing power (such as embedded systems)? More generally, although this may be out of the remit of this list, is an XML-based format not a little complex for a hex dump? The draft mentions 8- and 16-bit embedded systems: are these likely to have the necessary processing power and XML-parsing tools available to make use of a dump in this format? If it is necessary to transform the dump into a simpler form on a more powerful machine this rather defeats the object of a general-purpose platform-neutral format. Ben