Please review application/shf+xml

[ben at morrow.me.uk]

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