[APPS-REVIEW] [Fwd: Review of metalink I-D]

[Peter Saint-Andre <stpeter at stpeter.im>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks, Mark!

I notice that you sent this to apps-discuss. Indeed, that might be a
better place to send reviews than apps-review, because apps-discuss has
broader distribution and anyone can subscribe (although it is always
best to cc the authors).

Are there any objections to making that team policy? We would retain
apps-review for team discussions (requesting reviews, complaints about
the team leads, etc.).

/psa

- -------- Original Message --------
Subject: Review of metalink I-D
Date: Thu, 29 Oct 2009 21:46:23 -0300
From: Mark Baker <distobj at acm.org>
To: apps-discuss at ietf.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.
_______________________________________________
Apps-Discuss mailing list
Apps-Discuss at ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

- --
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrrFBwACgkQNL8k5A2w/vyRgACg728vNORAhAoUuJcBfxt2Pav6
PBkAn3SS28yiMtCNpxde9wMEH2wFhtWw
=mU+/
-----END PGP SIGNATURE-----