Re: draft-bryan-metalinkhttp-18.txt

Hi,

a few thoughts regarding version 18 of http://tools.ietf.org/html/draft-bryan-metalinkhttp 

> 2.  Requirements
>    [...]
>    Metalink servers are HTTP servers with one or more Metalink
>    resources.  Mirror and cryptographic hash information provided by the
>    originating Metalink server MUST be considered authoritative.
>    Metalink servers and their associated mirror servers SHOULD all share
>    the same ETag policy (ETag Synchronization), i.e. based on the file [...]

Regarding sharing an ETag policy, I think the wording could be relaxed. Some mirror servers might serve only FTP, and wouldn't support ETags then. In addition, from current experience with mirror networks it seems not too realistic to me to get mirrors share a policy. Of course, it is still a good idea.

In the next paragraph:

>    Mirror servers are typically FTP or HTTP servers that "mirror"
>    another server.  That is, they provide identical copies of (at least
>    some) files that are also on the mirrored server.  Mirror servers MAY
>    be Metalink servers.  Mirror servers MUST support serving partial
>    content.  HTTP mirror servers SHOULD share the same ETag policy as
>    the originating Metalink server.  HTTP Mirror servers SHOULD support
>    Instance Digests in HTTP [RFC3230].

I'm not sure if the requirement to serve partial content should be obligatory. I know that some current mirrors don't "like" it, and I am in favor of ignoring them. But the crucial point is that any client that expects a server to support byteranges needs to expect the worst, which is that the server ignore the byterange header, starts to send the whole file and doesn't stop. Any client needs to be able to deal properly with this situation anyway, because in HTTP/1.1 it is legal to run a webserver with support for partial responses switched off. And I wonder about the need to require handling of partial requests also regardless of that: There are often small files that can sensibly be handled without partial responses. Of course, with very large files the situation is quite different, and it might not make sense at all to go without partial responses. So I'm not sure which is the best general recommendation here.

Next paragraph:

>    Metalink clients use the mirrors provided by a Metalink server with
>    Link header [draft-nottingham-http-link-header].  Metalink clients
>    MUST support HTTP and MAY support FTP, BitTorrent, or other download
>    methods.  Metalink clients MUST switch downloads from one mirror to
>    another if the mirror becomes unreachable.  Metalink clients SHOULD
>    support multi-source, or parallel, downloads, where portions of a
>    file are downloaded from multiple mirrors simultaneously (and
>    optionally, from Peer-to-Peer sources).  Metalink clients MUST
>    support Instance Digests in HTTP [RFC3230] by requesting and
>    verifying cryptographic hashes.  Metalink clients MAY make use of
>    digital signatures if they are offered.

The statement that "Metalink clients MUST support HTTP and MAY support FTP, ..." implies that such a client might support *only* HTTP. A Metalink server might happen to provide only links to FTP mirror servers, though. So in fact, either the Metalink client should be required to support all protocols that the Metalink server might include, or the Metalink server needs to include at least one URL of each protocol. The latter would seem most sensible to me. The former would seem more realistic to me though, especially if we assume that a Metalink client supports HTTP and FTP anyway, and a Metalink server will always use at least one of these protocols in practice. Interesting nitpick, and maybe not a real-world problem; I would think that it has not caused anyone a problem up to now.

Peter

Received on Monday, 27 September 2010 09:53:49 UTC