Re: Multi-server HTTP

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

Anthony Bryan wrote:
> Revision 10 includes Alan Ford's merge of draft-ford-http-multi-server
> and Henrik's additions.
> 
> http://tools.ietf.org/html/draft-bryan-metalinkhttp

I took some time to look at the current draft, and have some comments below.

>    o  Use of Link header to describe Mirrors.  Only send a few mirrors
> with Link header?  Some organizations have many mirrors.

My thought is that an incomplete set of mirrors should be sent, along
with a link that is understood to refer to a more comprehensive list.

(other thoughts:)

sec 4:

sec 2, para 2:

   Metalink servers are HTTP servers that use the Link header
   [draft-nottingham-http-link-header] to present a list of mirrors of a
   resource to a client.  They MUST provide checksums of files via
   Instance Digests in HTTP [RFC3230], whether requested or not."

To me, this implies that a server either is, or is not, a "Metalink
server", and behaves as required for Metalink servers for any and all
resources that it provides. I expect that in practice, a given server
will usually be a "Metalink server" with respect to certain specific
resources, and will fail to meet the requirements of a Metalink server
with respect to other resources that are served.

sec 3.2:

I'm wondering whether a two-letter country code isn't quite granular
enough to be completely practical; for instance, a client in the US may
be closer to a mirror server in Canada or Mexico, than any available in
the US; similarly, someone in France or Germany many be closer to a
mirror in Belgium than any available in their own country.

OTOH, maybe it's "good enough"; I can't speak to any system that might
be better, apart from IP address and route analysis techniques, which
won't be helped by anything you could put in this draft RFC.

sec 3.4:

It's not clear to me how "mirror depth" should work for URIs ending in a
trailing slash.

sec 4:

It strikes me that the Link header with a "rel" param value of
"described-by" (and in fact the concept of a "Metainfo file" as a whole)
covers far too many roles, without distinguishing them sufficiently.
- From the examples, this facility can be used to provide torrent
locations, metalink description files, and cryptographic files, with
probably additional possible roles to be provided as they are invented. ;)

It would be great if a mechanism were used to explicitly describe the
role that a "metainfo file" plays, be it mirroring, torrent tracking,
providing cryptographic signatures for the resource identified; and not
rely on assumptions based on the resource's content type (which should
then be optional). Other values for the "rel" param might meet this need.

various:

I recommend that references to the term IRI be replaced by URI
throughout the document, except perhaps section 10.1, "URIs and IRIs"
itself (though I also object, if much more mildly, to the requirement
that clients handle IRIs, as this may not make sense in all cases. A
SHOULD use, perhaps? Really, it's a user interface issue, so I'm not
sure it belongs in this RFC). I don't believe IRIs have a place in HTTP
headers, where they ought to be converted to their unambiguous
corresponding URI form first. AFAICT, IRIs are best constrained to user
interfaces (entry and presentation), and their use to identify resources
between non-human mechanisms should generally be avoided.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer.
Maintainer of GNU Wget and GNU Teseq
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkrk1ywACgkQ7M8hyUobTrEe2wCeL59mim+IjDORwOZH6dfmHFmX
pFUAnRf0VrR7UVgYTzJxm2CBNXRbONCM
=EVCg
-----END PGP SIGNATURE-----

Received on Sunday, 25 October 2009 22:55:09 UTC