Subject: Review of metalink I-D

From: Mark Baker <[email-masked]>
Date: Thu, 29 Oct 2009 21:46:23 -0300

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.

---

From: Anthony Bryan <[email-masked]>
Date: Fri, 30 Oct 2009 12:56:09 -0400

Mark, thanks so much for your time and comments!

> space can produce an "invalid" document, yet no where is it defined

This text was borrowed from RFC 4287 yet I don't see more text to
borrow to define invalid. :)

How about adding this to sec 2, "Metalink Documents".

"Metalink Documents that do not follow this specification are invalid,
and partially or wholly unusable to Metalink Processors."

> required then they might not include this logic.

This ends up being the being the filename that the downloaded file is
written to most of the time. Agents are free to pick one, or ask the
user. (Some use "filename(2).ext" if "filename.ext" is already taken,
etc). The agent could use the filename at the end of a URI, but the
filename from each URI can be different, the contents just have to
match. We are also trying to define the document format in this draft,
with as little client behavior as possible. So this seems like the
simplest thing to require.

> an indication of how often to do so.  HTTP caching could be used to do

Yes, that is planned.
We are trying to define the document format in this draft, with as
little client behavior as possible.

>   3.0 might be "OpenOffice.org", "Openoffice", or "OpenOffice 3.0".

Let's change this because it's confusing. I believe "OpenOffice.org"
is specifically named that because "OpenOffice" is a different
product. "3.0" would go in the version element (sec 4.2.19) - should I
mention that in the draft if it's unclear?

Is this sufficient?
The "metalink:identity (The "metalink:identity" Element)" element is a
Text construct that conveys a human-readable identity for a file. For
example, the identity of Firefox 3.5 would be "Firefox".

> prefer) MIME types, and include a reference to BCP 13.

This has come up a few times in the past. :)

http://www.ietf.org/mail-archive/web/apps-review/current/msg00162.html

I prefer your approach, but I'd like others to weigh in.

An alternative would be to drop any mention of torrents, but this is
how people use metalink so I'd like it to be clear what they can do.

I've made it "MIME media type", as used in RFC 4287, and referenced
BCP 13/RFC 4288/

> that should be specified by saying, for example, that extensions can

That section is stolen outright from RFC 4287 sec 6.3

http://tools.ietf.org/html/rfc4287#section-6.3

You see the intent of what we want. Can you suggest replacement text?

> considerable attention for a change.

Thanks, Mark! There are already a handful of metalink extensions and
we want to ensure that continues.
As you can see, we're relying on the text from Atom. Without it as a
starting point, I think this draft would've been impossible.

We keep interim revisions at
http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/
-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads