The latest version of the Internet Draft of the Metalink Download Description is at http://tools.ietf.org/html/draft-bryan-metalinkhttp
(Incremental updates are at http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ )

Example:

   Link: <http://www2.example.com/example.ext>; rel="duplicate"
   Link: <ftp://ftp.example.com/example.ext>; rel="duplicate"
   Link: <http://example.com/example.ext.torrent>; rel="describedby";
   type="application/x-bittorrent"
   Link: <http://example.com/example.ext.metalink>; rel="describedby";
   type="application/metalink4+xml"
   Link: <http://example.com/example.ext.asc>; rel="describedby";
   type="application/pgp-signature"
   Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=

Implementations:

• metalink-checker
  
• Convert Metalink 3.0 to Apache directives for Metalink/HTTP
  

Known issues:

• Use of Link header to describe Mirrors.  Only send a few mirrors with Link header, or only send them if Want-Digest is used?  Some organizations have many mirrors.
• A way to differentiate between mirrors that have synchronized ETags and those that don't.
• Do we want a way to show that whole directories are mirrored, instead of individual files?
• Will we use Metalink/XML for partial file checksums? This is an important feature & that would add XML dependency to apps.
• Do we need an official MIME type for .torrent files or allow "application/x-bittorrent"?

This draft compared to IETF ID Metalink/XML specification:

• (+) Reuses existing HTTP standards without defining anything new besides a Link Relation Type.  It's more of a collection/  coordinated feature set.
• (?)  The existing standards don't seem to be widely implemented.
  
• (+) No XML dependency.
• (+)  Existing Metalink/XML clients can be easily converted to support this as well.
• (+) Coordination of mirror servers is preferred, but not required. Coordination may be difficult or impossible unless you are in control of all servers on the mirror network.
• (-?)  Tied to HTTP, not as generic.  FTP/P2P clients won't be using it unless they also support HTTP, unlike Metalink/XML.
  
• (-) Requires software or configuration changes to originating server.
• (-) Also, Metalink/XML files are easily mirrored on all servers. Even if usage in that case is not as transparent, it still gives access to users at all mirrors (FTP included) to all download information with no changes needed to the server.
• (-) Not portable/archivable/emailable.  Metalink/XML is used to import/export transfer queues.  Not as easy for search engines to index?
• (-) No way to show mirror geographical location (yet).
• (-) Not as rich metadata.
• (-) Not able to add multiple files to a download queue or create directory structure.