[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 RFC 6249

Network Working Group                                      A. Bryan, Ed.
Internet-Draft                                                  N. McNab
Intended status: Standards Track                      Metalinker Project
Expires: March 28, 2010                                     H. Nordstrom
                                                      September 24, 2009


         MetaLinkHeader: Mirrors and Checksums in HTTP Headers
                      draft-bryan-metalinkhttp-06

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 28, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Bryan, et al.            Expires March 28, 2010                 [Page 1]

Internet-Draft    MetaLinkHeader: Mirrors and Checksums   September 2009


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document specifies MetaLinkHeader: Mirrors and Checksums in HTTP
   Headers, an alternative to the Metalink XML-based download
   description format.  MetaLinkHeader describes multiple download
   locations (mirrors), Peer-to-Peer, checksums, digital signatures, and
   other information using existing standards.  Clients can
   transparently use this information to make file transfers more robust
   and reliable.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2.  Notational Conventions . . . . . . . . . . . . . . . . . .  5
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Mirrors / Multiple Download Locations  . . . . . . . . . . . .  6
   4.  Peer-to-Peer Descriptions / Metainfo . . . . . . . . . . . . .  6
   5.  OpenPGP Signatures . . . . . . . . . . . . . . . . . . . . . .  7
   6.  Checksums of Whole Files . . . . . . . . . . . . . . . . . . .  7
   7.  Client / Server Multi-source Download Interaction  . . . . . .  7
     7.1.  Early File Mismatch Detection with Strong ETag or
           Instance Digest from Mirrors . . . . . . . . . . . . . . .  9
     7.2.  Error Recovery . . . . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Link Relation Type Registration: "duplicate" . . . . . . . 11
     8.2.  Hypertext Transfer Protocol (HTTP) Digest Algorithm
           Values Registration  . . . . . . . . . . . . . . . . . . . 11
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
     9.1.  URIs and IRIs  . . . . . . . . . . . . . . . . . . . . . . 12
     9.2.  Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 12
     9.3.  Cryptographic Hashes . . . . . . . . . . . . . . . . . . . 12
     9.4.  Signing  . . . . . . . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Acknowledgements and Contributors . . . . . . . . . . 13
   Appendix B.  Comparisons to Similar Options (to be removed by
                RFC Editor before publication)  . . . . . . . . . . . 13
   Appendix C.  Document History (to be removed by RFC Editor
                before publication) . . . . . . . . . . . . . . . . . 14



Bryan, et al.            Expires March 28, 2010                 [Page 2]

Internet-Draft    MetaLinkHeader: Mirrors and Checksums   September 2009


   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15


















































Bryan, et al.            Expires March 28, 2010                 [Page 3]

Internet-Draft    MetaLinkHeader: Mirrors and Checksums   September 2009


1.  Introduction

   MetaLinkHeader is an alternative to Metalink, usually an XML-based
   document format [draft-bryan-metalink].  MetaLinkHeader attempts to
   provide as much functionality as the Metalink XML format by using
   existing standards such as Web Linking
   [draft-nottingham-http-link-header], Instance Digests in HTTP
   [RFC3230], and Etags.  MetaLinkHeader is used to list information
   about a file to be downloaded.  This includes lists of multiple URIs
   (mirrors), Peer-to-Peer information, checksums, and digital
   signatures.

   Identical copies of a file are frequently 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 (mirrors) and must manually select a
   single one on the basis of geographical location, priority, or
   bandwidth.  This distributes the load across multiple servers.  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 extremely troublesome.  Any of the number of
   problems that can occur during a download lead to frustration on the
   part of users.

   All the information about a download, including mirrors, checksums,
   digital signatures, and more can be transferred in coordinated HTTP
   Headers.  This Metalink transfers the knowledge of the download
   server (and mirror database) to the client.  Clients can fallback to
   other mirrors if the current one has an issue.  With this knowledge,
   the client is enabled to work its way to a successful download even
   under adverse circumstances.  All this is done transparently to the
   user and the download is much more reliable and efficient.  In
   contrast, a traditional HTTP redirect to a mirror conveys only
   extremely minimal information - one link to one server, and there is
   no provision in the HTTP protocol to handle failures.  Other features
   that some clients provide include multi-source downloads, where
   portions of a file are downloaded from multiple mirrors (and
   optionally, Peer-to-Peer) simultaneously, which frequently results in
   a faster download.

   [[ Discussion of this draft should take place on IETF HTTP WG mailing
   list at ietf-http-wg@w3.org or the Metalink discussion mailing list
   located at metalink-discussion@googlegroups.com.  To join the list,
   visit http://groups.google.com/group/metalink-discussion . ]]




Bryan, et al.            Expires March 28, 2010                 [Page 4]

Internet-Draft    MetaLinkHeader: Mirrors and Checksums   September 2009


1.1.  Examples

   A brief Metalink server response with checksum, mirrors, .metalink,
   and OpenPGP signature:

   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=

1.2.  Notational Conventions

   This specification describes conformance of MetaLinkHeader.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, [RFC2119], as
   scoped to those conformance targets.


2.  Requirements

   In this context, "MetaLink" refers to a MetaLinkHeader which consists
   of mirrors and checksums in HTTP Headers as described in this
   document.  "Metalink XML" refers to the XML format described in
   [draft-bryan-metalink].

   Metalink servers are HTTP servers that MUST have lists of mirrors and
   use the Link header [draft-nottingham-http-link-header] to indicate
   them.  They also MUST provide checksums of files via Instance Digests
   in HTTP [RFC3230], whether requested or not.  Mirror and checksum
   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 contents (checksum) and not
   server-unique filesystem metadata.  The emitted ETag may be
   implemented the same as the Instance Digest for simplicity.

   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.  Mirror servers SHOULD support Instance Digests in HTTP



Bryan, et al.            Expires March 28, 2010                 [Page 5]

Internet-Draft    MetaLinkHeader: Mirrors and Checksums   September 2009


   [RFC3230].  Optimally, mirror servers will share the same ETag policy
   as the Metalink server and provide Instance Digests.

   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 one mirror becomes unreachable.  Metalink clients are
   RECOMMENDED to 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 checksums.  Metalink clients MAY make use of digital
   signatures if they are offered.


3.  Mirrors / Multiple Download Locations

   Mirrors are specified with the Link header
   [draft-nottingham-http-link-header] and a relation type of
   "duplicate" as defined in Section 8.1.

   A brief Metalink server response with two mirrors only:

   Link: <http://www2.example.com/example.ext>; rel="duplicate"
   Link: <ftp://ftp.example.com/example.ext>; rel="duplicate"

   Mirror servers are listed in order of priority.

   [[Some organizations have many mirrors.  Only send a few mirrors, or
   only use the Link header if Want-Digest is used?]]


4.  Peer-to-Peer Descriptions / Metainfo

   Ways to download a file over Peer-to-Peer networks are specified with
   the Link header [draft-nottingham-http-link-header] and a relation
   type of "describedby" and a type parameter hat indicates the MIME
   type of the metadata available at the IRI.

   A brief Metalink server response with .torrent and .metalink:

   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"





Bryan, et al.            Expires March 28, 2010                 [Page 6]

Internet-Draft    MetaLinkHeader: Mirrors and Checksums   September 2009


5.  OpenPGP Signatures

   OpenPGP signatures are specified with the Link header
   [draft-nottingham-http-link-header] and a relation type of
   "describedby" and a type parameter of "application/pgp-signature".

   A brief Metalink server response with OpenPGP signature only:

   Link: <http://example.com/example.ext.asc>; rel="describedby";
   type="application/pgp-signature"


6.  Checksums of Whole Files

   Metalink servers MUST provide Instance Digests in HTTP [RFC3230] for
   files they describe with mirrors.  Mirror servers MAY as well.

   A brief Metalink server response with checksum:

   Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=


7.  Client / Server Multi-source Download Interaction

   Metalink clients begin a download with a standard HTTP [RFC2616] GET
   request to the Metalink server.  A Range limit is optional, not
   required.  Here the client prefers SHA-1 checksums over MD5:


   GET /distribution/example.ext HTTP/1.1
   Host: www.example.com

   Alternatively, Metalink clients can use a HEAD request to discover
   mirrors via Link headers.  After that, it follows with a GET request
   as usual.

   The Metalink server responds with this:














Bryan, et al.            Expires March 28, 2010                 [Page 7]

Internet-Draft    MetaLinkHeader: Mirrors and Checksums   September 2009


   HTTP/1.1 200 OK
   Accept-Ranges: bytes
   Content-Length: 14867603
   Content-Type: application/x-cd-image
   Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
   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=

   From the Metalink server response the client learns the following
   metadata about the requested object, in addition also starting to
   receive the object:
   o  Mirror profile link.
   o  Instance Digest.
   o  Object size.
   o  ETag.  (ETag synchronization between mirrors is OPTIONAL).
   o  Peer-to-peer information.
   o  Digital signature.
   o  Metalink XML, which can include checksums to repair a file.

   If the object is large and gets delivered slower than expected then
   the Metalink client starts a number of parallel ranged downloads (one
   per selected mirror server other than the first) using mirrors
   provided by the Link header with "duplicate" relation type, using the
   location of the original GET request in the "Referer" header field.
   If no Range limit was given in the original request then work from
   the tail of the object (the first request is still running and will
   eventually catch up), otherwise continue after the range requested in
   the first request.

   If ETags are coordinated between mirrors, If-Match conditions based
   on the ETag SHOULD be used to quickly detect out-of-date mirrors by
   using the ETag from the Metalink server response.  If no indication
   of ETag syncronisation/knowledge is given then If-Match should not be
   used, and optimally there will be an Instance Digest in the mirror
   response which we can use to detect a mismatch early, and if not then
   a mismatch won't be detected until the completed object is verified.
   One of the client requests to a mirror server:







Bryan, et al.            Expires March 28, 2010                 [Page 8]

Internet-Draft    MetaLinkHeader: Mirrors and Checksums   September 2009


   GET /example.ext HTTP/1.1
   Host: www2.example.com
   Range: bytes=7433802-
   If-Match: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
   Referer: http://www.example.com/distribution/example.ext

   The mirror servers respond with a 206 Partial Content HTTP status
   code and appropriate "Content-Length" and "Content Range" header
   fields.  The mirror server response to the above request:

   HTTP/1.1 206 Partial Content
   Accept-Ranges: bytes
   Content-Length: 7433801
   Content-Range: bytes 7433802-14867602/14867603
   Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
   Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=

   If the first request was not Range limited then abort it by closing
   the connection when it catches up with the other parallel downloads
   of the same object.

   Once the download has completed, the Metalink client MUST verify the
   checksum of the file.

7.1.  Early File Mismatch Detection with Strong ETag or Instance Digest
      from Mirrors

   In HTTP terms, the requirement is that merging of ranges from
   multiple responses must be verified with a strong validator, which in
   this context is the same as either instance digest or a strong ETag.
   In most cases it is sufficient that the Metalink server provides
   mirrors and Instance Digest information, but operation will be more
   robust and efficient if the mirror servers do implement a
   synchronized ETag as well.  In fact, the emitted ETag may be
   implemented the same as the Instance Digest for simplicity, but there
   is no need to specify how ETag generated, just that it needs to be
   shared among the mirror servers.  If the mirror server provides
   neither synchronized ETag or Instance Digest, then early detection of
   mismatches is not possible unless file length also differs.  Finally,
   the error is still detectable when the merged response is verified.

   ETag can not be used for verifying the integrity of the received
   content.  But it is a guarantee issued by the Metalink server that
   the content is correct for that ETag.  And if the ETag given by the
   mirror server matches the ETag given by the master server, then we
   have a chain of trust where the master server authorizes these
   responses as valid for that object.




Bryan, et al.            Expires March 28, 2010                 [Page 9]

Internet-Draft    MetaLinkHeader: Mirrors and Checksums   September 2009


   This guarantees that a mismatch will be detected by using only the
   synchronized ETag from a master server and mirror server, even
   alerted by the mirror servers themselves by responding with an error,
   preventing accidental merges of ranges from different versions of
   files with the same name.  This even includes many malicious attacks
   where the data on the mirror has been replaced by some other file,
   but not all.

   Synchronized ETag can not strictly protect against malicious attacks
   or server or network errors replacing content, but neither can
   Instance Digest on the mirror servers as the attacker most certainly
   can make the server seemingly respond with the expected Instance
   Digest even if the file contents have been modified, just as he can
   with ETag, and the same for various system failures also causing bad
   data to be returned.  The Metalink client has to rely on the Instance
   Digest returned by the Metalink master server in the first response
   for the verification of the downloaded object as a whole.

   If the mirror servers do return an Instance Digest, then that is a
   bonus, just as having them return the right set of Link headers is.
   The set of trusted mirrors doing that can be substituted as master
   servers accepting the initial request if one likes.

   The benefit of having slave mirror servers (those not trusted as
   masters) return Instance Digest is that the client then can detect
   mismatches early even if ETag is not used.  Both ETag and slave
   mirror Instance Digest do provide value, but just one is sufficient
   for early detection of mismatches.  If none is provided then early
   detection of mismatches is not possible unless the file length also
   differs, but the error is still detected when the merged response is
   verified.

7.2.  Error Recovery

   If the object checksum does not match the Instance Digest then fetch
   the Metalink XML or other recovery profile link, where partial file
   checksums can be found, allowing detection of which server returned
   bad information.  If the Instance Digest computation does not match
   then the client needs to fetch the partial file checksums and from
   there figure out what of the downloaded data can be recovered and
   what needs to be fetched again, or if no partial checksums are
   available fetch the complete object from a trusted Metalink server.


8.  IANA Considerations

   Accordingly, IANA has made the following registrations.




Bryan, et al.            Expires March 28, 2010                [Page 10]

Internet-Draft    MetaLinkHeader: Mirrors and Checksums   September 2009


8.1.  Link Relation Type Registration: "duplicate"

   o Relation Name: duplicate

   o Description: Refers to a resource whose available representations
   are byte-for-byte identical with the corresponding representations of
   the context IRI.

   o Reference: This specification.

   o Notes: This relation is for static resources.  That is, an HTTP GET
   request on any duplicate will return the same representation.  It
   does not make sense for dynamic or POSTable resources and should not
   be used for them.

8.2.  Hypertext Transfer Protocol (HTTP) Digest Algorithm Values
      Registration

   This document makes use of the IANA registry named "Hypertext
   Transfer Protocol (HTTP) Digest Algorithm Values" specified in
   [RFC3230].

      Digest Algorithm: SHA-224
      Description: The SHA-224 algorithm [SHS].  The output of this
      algorithm is encoded using the base64 encoding [RFC2045].
      Reference: [SHS] [RFC2045]

      Digest Algorithm: SHA-256
      Description: The SHA-256 algorithm [SHS].  The output of this
      algorithm is encoded using the base64 encoding [RFC2045].
      Reference: [SHS] [RFC2045]

      Digest Algorithm: SHA-384
      Description: The SHA-384 algorithm [SHS].  The output of this
      algorithm is encoded using the base64 encoding [RFC2045].
      Reference: [SHS] [RFC2045]

      Digest Algorithm: SHA-512
      Description: The SHA-512 algorithm [SHS].  The output of this
      algorithm is encoded using the base64 encoding [RFC2045].
      Reference: [SHS] [RFC2045]


9.  Security Considerations







Bryan, et al.            Expires March 28, 2010                [Page 11]

Internet-Draft    MetaLinkHeader: Mirrors and Checksums   September 2009


9.1.  URIs and IRIs

   Metalink clients handle URIs and IRIs.  See Section 7 of [RFC3986]
   and Section 8 of [RFC3987] for security considerations related to
   their handling and use.

9.2.  Spoofing

   There is potential for spoofing attacks where the attacker publishes
   Metalinks with false information.  In that case, this could deceive
   unaware downloaders that they are downloading a malicious or
   worthless file.  Also, malicious publishers could attempt a
   distributed denial of service attack by inserting unrelated IRIs into
   Metalinks.

9.3.  Cryptographic Hashes

   Currently, some of the digest values defined in Instance Digests in
   HTTP [RFC3230] are considered insecure.  These include the whole
   Message Digest family of algorithms which are not suitable for
   cryptographically strong verification.  Malicious people could
   provide files that appear to be identical to another file because of
   a collision, i.e. the weak cryptographic hashes of the intended file
   and a substituted malicious file could match.

   If a Metalink contains hashes as described in Section 6, it SHOULD
   include "sha" which is SHA-1, as specified in [RFC3174].  It MAY also
   include other hashes.

9.4.  Signing

   Metalinks should include digital signatures, as described in
   Section 5.

   Digital signatures provide authentication, message integrity, and
   non-repudiation with proof of origin.


10.  References

10.1.  Normative References

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.



Bryan, et al.            Expires March 28, 2010                [Page 12]

Internet-Draft    MetaLinkHeader: Mirrors and Checksums   September 2009


   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
              (SHA1)", RFC 3174, September 2001.

   [RFC3230]  Mogul, J. and A. Van Hoff, "Instance Digests in HTTP",
              RFC 3230, January 2002.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, January 2005.

   [SHS]      National Institute of Standards and Technology (NIST),
              "Secure Hash Standard", FIPS PUB 180-3, October 2008, <htt
              p://csrc.nist.gov/publications/fips/fips180-3/
              fips180-3_final.pdf>.

   [draft-nottingham-http-link-header]
              Nottingham, M., "Web Linking",
              draft-nottingham-http-link-header-06 (work in progress),
              July 2009.

10.2.  Informative References

   [draft-bryan-metalink]
              Bryan, A., Ed., Tsujikawa, T., McNab, N., and P. Poeml,
              "The Metalink Download Description Format",
              draft-bryan-metalink-16 (work in progress), August 2009.


Appendix A.  Acknowledgements and Contributors

   Thanks to Mark Nottingham, Daniel Stenberg and Matt Domsch.


Appendix B.  Comparisons to Similar Options (to be removed by RFC Editor
             before publication)

   This draft, compared to the Metalink XML format
   [draft-bryan-metalink] :






Bryan, et al.            Expires March 28, 2010                [Page 13]

Internet-Draft    MetaLinkHeader: Mirrors and Checksums   September 2009


   o  (+) Reuses existing HTTP standards without defining anything new
      besides a Link Relation Type.  It's more of a collection/
      coordinated feature set.
   o  (?)  The existing standards don't seem to be widely implemented.
   o  (+) No XML dependency.
   o  (?)  Existing Metalink XML clients can be easily converted to
      support this as well.
   o  (-?)  Tied to HTTP, not as generic.  FTP/P2P clients won't be
      using it unless they also support HTTP, unlike Metalink XML.
   o  (---) Requires changes to server software.
   o  (-?)  Could require some coordination of all mirror servers for
      all features, which may be difficult or impossible unless you are
      in control of all servers on the mirror network.
   o  (-) Requires server-side support.  Metalink XML can be created by
      user (or server, but server component/changes not required).
   o  (-) 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.
   o  (-) Not portable/archivable/emailable.  Metalink XML is used to
      import/export transfer queues.  Not as easy for search engines to
      index?
   o  (-) No way to show mirror/p2p geographical location (yet).
   o  (ADDRESSED IN THIS REVISION) No checksums besides MD5/SHA-1.
   o  (-) Not as rich metadata.
   o  (-) Not able to add multiple files to a download queue or create
      directory structure.

   draft-ford-http-multi-server compared to this draft :

   o  (+) Plans to define mirrors for whole directories.
   o  (-?)  Defines new headers.  Doesn't reuse existing standards.
   o  (---) Requires changes to server software.
   o  (---) Requires coordination of all mirror servers, which may be
      difficult or impossible unless you are in control of all servers
      on the mirror network.
   o  (---) Doesn't tie in p2p.
   o  (-) No way to show mirror/p2p priority or geographical location
      (yet).


Appendix C.  Document History (to be removed by RFC Editor before
             publication)

   [[ to be removed by the RFC editor before publication as an RFC. ]]

   Known issues concerning this draft:




Bryan, et al.            Expires March 28, 2010                [Page 14]

Internet-Draft    MetaLinkHeader: Mirrors and Checksums   September 2009


   o  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.
   o  A way to differentiate between mirrors that have synchronized
      ETags and those that don't.
   o  Do we want a way to show that whole directories are mirrored,
      instead of individual files?
   o  Need an official MIME type for .torrent files or allow
      "application/x-bittorrent"?
   o  ADDRESSED:Some publishers desire stronger hashes than MD5 and
      SHA-1.

   -06 : September , 2009.
   o  Add Mismatch Detection, Error Recovery, and Digest Algorithm
      values.
   o  Remove Content-MD5 and Want-Digest.

   -05 : September 19, 2009.
   o  ETags, preferably matching the Instance Digests.

   -04 : September 17, 2009.
   o  Temporarily remove .torrent.

   -03 : September 16, 2009.
   o  Mention HEAD request, negotiate mirrors if Want-Digest is used.

   -02 : September 6, 2009.
   o  Content-MD5 for partial file checksums.

   -01 : September 1, 2009.
   o  Link Relation Type Registration: "duplicate"

   -00 : August 24, 2009.
   o  Initial draft.


Authors' Addresses

   Anthony Bryan (editor)
   Metalinker Project

   Email: anthonybryan@gmail.com
   URI:   http://www.metalinker.org








Bryan, et al.            Expires March 28, 2010                [Page 15]

Internet-Draft    MetaLinkHeader: Mirrors and Checksums   September 2009


   Neil McNab
   Metalinker Project

   Email: neil@nabber.org
   URI:   http://www.nabber.org


   Henrik Nordstrom

   Email: henrik@henriknordstrom.net
   URI:   http://www.henriknordstrom.net/








































Bryan, et al.            Expires March 28, 2010                [Page 16]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/