Review of metalink I-D

[Mark Baker <distobj at acm.org>]

This is my review of draft-bryan-metalink-21.

- sec 3, last paragraph, it is mentioned that some kinds of white
space can produce an "invalid" document, yet no where is it defined
what that means

- sec 4.1.2.1.  not sure why "name" is a MUST.  I'm sure metalink
agents can pick a reasonable one, or ask the user, but if it was
required then they might not include this logic.

- sec 4.2.3.  If metalink:dynamic is intended to be a cue to agents to
redownload the file periodically, you probably also want to give them
an indication of how often to do so.  HTTP caching could be used to do
that.

- sec 4.2.6, the Openoffice example confused me briefly.  You need to
make sure it's seen to be an example, and also that "OpenOffice.org"
isn't the only possible value.  Perhaps change to;

   The "metalink:identity" element is a Text construct that conveys a
   human-readable name for a file.  For example, the identity of OpenOffice.org
   3.0 might be "OpenOffice.org", "Openoffice", or "OpenOffice 3.0".

- sec 4.2.10.2.  do we really need to use a special "torrent" type
when "application/x-bittorrent" could be used?  I'd prefer to stick
just to media type syntax and get rid of the reserved syntax.  You
should also call them "media types" instead of (or as well as if you
prefer) MIME types, and include a reference to BCP 13.

- in sec 6.3, it's not within the authority of a protocol
specification to tell agents that they "MUST NOT stop processing" or
"MUST NOT change their behaviour".  They might have their own
perfectly good reasons for, say, halting if some XHTML with Javascript
were included.  I agree with what you're trying to accomplish, but
that should be specified by saying, for example, that extensions can
be ignored.

Overall, a decent spec.  It's nice to see extensibility given
considerable attention for a change.

Mark.