Re: [APPS-REVIEW] Metalink XML Download Description Format (draft-bryan-metalink-01)

On Mon Sep  1 06:44:23 2008, Anthony Bryan wrote:
> Here is the Internet Draft for Metalink, available at
> http://tools.ietf.org/html/draft-bryan-metalink-01
> with interim revisions at
> http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ 
> .
> We're looking for review and public comments.

1) I'm not mad keen on namespaces pointing to privately owned domain  
names. You have a different one in the examples as is specified in  
section 1.2, by the way.

2) The type attribute of the hash element ought to have values  
selected from the IANA registry of textual hash names;  
http://www.iana.org/assignments/hash-function-text-names/ - section  
4.1.6.1 & 4.2.4.1.

3) Awesome:

"""
   For convenience, this data format may be referred to as "Metalink
   3.0".  This specification uses "Metalink" internally.
"""

Yeah, so you use a longer, more formal name for *convenience*? And  
then in the specification itself, use a short-hand for, what,  
inconvenience? :-)

4) Notational convention defines a different convention than is used  
in the examples.

5) Section 2, "Metalink Documents MUST be well-formed
   XML." - and presumably "namespace well-formed", as specified in  
[XML-NAMES]? Or not?

6) Section 2: I'd personally kick out xml:base - I don't see it  
solving anything here.

7) Section 4.1.3.1: I'm deeply unconvinced about this "name"  
attribute actually containing a path - I don't see this being needed  
at all. A filename, sure. But otherwise, someone somewhere will  
inadvertantly allow /etc/passwd to be overwritten, or something  
equally hideous. Just ban '/'.

8) Section 4.1.4: "MUST contain one [good] and SHOULD contain more  
than one" - you mean if my download is only available from one  
location then this may provide a cause of poor interoperability? I  
don't think this is what you mean. I think you mean: "MUST contain at  
least one".

9) Section 4.2.3: I'm personally wary of doing this on two grounds.  
Firstly, people invariably use them for advertising, rather than  
debugging. Whilst not all marketing is, in fact, evil, I'm never  
truly keen on adding a bunch of octets for no good reason. Secondly,  
I'd live in perpetual fear that processors will change behaviour  
dependent on the agent's foibles.

10) Section 4.2.13: I had to read this twice to figure out it  
referred to a digital signature of the file to be downloaded. It  
might be as well to define a term for that in section 2, and use it  
throughout. I suspect the nice security people might have something  
to say about specifying PGP-only detatched signatures.

11) Section 4.2.17: Does that "type" attribute totally suck? Of  
course, you have to have it because every man, his dog, and his pet  
hampster has decided that only HTTP is allowed, these days, for  
absolutely everything, leading to a totally useless URI scheme which  
essentially fails to describe the actual resource it's supposedly a  
locator for. Okay, rant over, back to the review.

12) Section 4.2.17.1: Perhaps preference and weight? See SRV.

13) Section 4.2.17.2: Hang on, maybe this is a bit too far - I can  
see the need for type, sure, but I don't see the need to be able to  
specify "Use FTP to retrieve this HTTP URI", because that's just  
introducing a silly state.

14) Section 5 - I'd personally just ditch the entire thing, you  
effectively say all that's needed in Section 8.4.

15) I'm sure a lot of Section 6.1~6.3 could be summed up as "Ignore  
any markup you don't understand, whether from the metalink namespace  
or not." Of course, I'm not really an XML expert, so if this language  
is really needed, that's all fine and good.

Hope this helps, somewhat. Feel free to ignore the bits you disagree  
with.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Received on Tuesday, 2 September 2008 08:47:14 UTC