1 Sep 2008 07:44
Metalink XML Download Description Format (draft-bryan-metalink-01)
Anthony Bryan <anthonybryan <at> gmail.com>
2008-09-01 05:44:23 GMT
2008-09-01 05:44:23 GMT
Greetings, 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. Metalink is currently supported by some 35 applications and used by projects such as OpenOffice.org, openSUSE, Ubuntu, cURL, and others. Metalink is an XML-based document format that describes a file or lists of files to be added to a download queue. Lists are composed of a number of files, each with an extensible set of attached metadata. For example, each file can have a description, checksum, and list of URIs that it is available from. The primary use case that Metalink addresses is the description of downloadable content in a format so download agents can act intelligently and recover from common errors with little or no user interaction necessary. These errors can include multiple servers going down and data corrupted in transmission. Thank you, -- -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads _______________________________________________________________________(Continue reading)
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.
RSS Feed