Subject: Update regarding draft-bryan-metalink (intro section)

From: Peter Pöml <[email-masked]>
Date: Fri, 27 Nov 2009 23:11:00 +0100

[re-send with correct list address]

Hi!

I'm sending an update to the introductory section of the draft-bryan- 
metalink I-D. The changes are:

- mention the multi-protocol (HTTP, FTP, P2P) nature of Metalinks.
- describe how verification in Metalinks can solve issues trusting  
content replicas on mirror servers
- distinguish more clearly between human users and user agents
- various minor improvements.

I hope the changes are acceptable and not too disruptive the review  
process. Hopefully they make the whole text clearer.

I am attaching a text version of the introductory section, as well as  
a "diff" to the previous version for your convenience.

Thanks,
Peter

---

From: Anthony Bryan <[email-masked]>
Date: Mon, 30 Nov 2009 16:44:13 -0500

On Fri, Nov 27, 2009 at 5:11 PM, Peter Pöml <[email-masked]> wrote:
>
> I'm sending an update to the introductory section of the
> draft-bryan-metalink I-D. The changes are:
>
> - describe how verification in Metalinks can solve issues trusting content
> replicas on mirror servers

This last week we received some healthy review from Lisa and Eran,
document shepherd.

We addressed most issues in an interim version that can be found at
http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/
but await clarifications on a few others.

The other remaining issues:

1) Can we use Creative Commons for machine readable alternative to our
license element (Sec 4.2.8)?

2) Do we need to use ABNF for the generator element (4.2.4)?

We talked about using this from HTTP

      product         = token ["/" product-version]
      product-version = token

3) metaurl element's type attribute value (4.2.10.2). It uses MIME
type, but "torrent" is defined.

4) signature element's type attribute value (4.2.15.1). pgp is defined.

5) We allow one or more OS elements. Should we allow one or more
license and language elements?

And here is the intro with only a few small changes:

   Metalink is an XML-based document format that describes a file or
   list of files to be downloaded from a server.  Metalinks can list a
   number of files, each with an extensible set of attached metadata.
   Each listed file can have a description, checksum, and a list of URIs
   that it is available from.

   Often, identical copies of a file are accessible in multiple
   locations on the Internet over a variety of protocols (FTP, HTTP, and
   Peer-to-Peer).  In some cases, users are shown a list of these
   multiple download locations (mirror servers) and must manually select
   one based on geographical location, priority, or bandwidth.  This is
   done to distribute the load across multiple servers, and to give
   human users the opportunity to choose a download location that they
   expect to work best for them.

   At times, individual servers can be slow, outdated, or unreachable,
   but this can not be determined until the download has been initiated.
   This can lead to the user canceling the download and needing to
   restart it.  During downloads, errors in transmission can corrupt the
   file.  There are no easy ways to repair these files.  For large
   downloads this can be especially troublesome.  Any of the number of
   problems that can occur during a download lead to frustration on the
   part of users, and bandwith wasted with retransmission.

   Knowledge about availability of a download on mirror servers can be
   acquired and maintained by the operators of the origin server, or by
   third a party.  This knowledge, together with checksums, digital
   signatures, and more can be stored in a machine-readable Metalink
   file.  The Metalink file can transfer this knowledge to the user
   agent, which can peruse it in automatic ways or present the
   information to a human user.  User agents can fall back to alternate
   mirrors if the current one has an issue.  Thereby, clients are
   enabled to work their way to a successful download even under adverse
   circumstances.  All this can be done transparently to the human user
   and the download is much more reliable and efficient.  In contrast, a
   traditional HTTP redirect to one mirror conveys only comparatively
   minimal information - a referral to a single server, and there is no
   provision in the HTTP protocol to handle failures.

   Other features that some clients provide include multi-source
   downloads, where chunks of a file are downloaded from multiple
   mirrors (and optionally, Peer-to-Peer) simultaneously, which
   frequently results in a faster download.  Metalinks can leverage
   HTTP, FTP and Peer-to-Peer protocols together, because regardless
   over which protocol the Metalink was obtained, it can make a resource
   accessible through other protocols.  If the Metalink was obtained

   from a trusted source, included verification metadata can solve trust
   issues when downloading files from replica servers operated by third
   parties.  Metalinks also provide structured information about
   downloads that can be indexed by search engines.

Feedback is very welcome!
-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads