idnits 2.17.1 draft-bryan-metalinkhttp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 24, 2009) is 5328 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Downref: Normative reference to an Informational RFC: RFC 3174 ** Obsolete normative reference: RFC 3230 (Obsoleted by RFC 9530) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Bryan, Ed. 3 Internet-Draft N. McNab 4 Intended status: Standards Track Metalinker Project 5 Expires: March 28, 2010 H. Nordstrom 6 September 24, 2009 8 MetaLinkHeader: Mirrors and Checksums in HTTP Headers 9 draft-bryan-metalinkhttp-06 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on March 28, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document specifies MetaLinkHeader: Mirrors and Checksums in HTTP 58 Headers, an alternative to the Metalink XML-based download 59 description format. MetaLinkHeader describes multiple download 60 locations (mirrors), Peer-to-Peer, checksums, digital signatures, and 61 other information using existing standards. Clients can 62 transparently use this information to make file transfers more robust 63 and reliable. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 5 70 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Mirrors / Multiple Download Locations . . . . . . . . . . . . 6 72 4. Peer-to-Peer Descriptions / Metainfo . . . . . . . . . . . . . 6 73 5. OpenPGP Signatures . . . . . . . . . . . . . . . . . . . . . . 7 74 6. Checksums of Whole Files . . . . . . . . . . . . . . . . . . . 7 75 7. Client / Server Multi-source Download Interaction . . . . . . 7 76 7.1. Early File Mismatch Detection with Strong ETag or 77 Instance Digest from Mirrors . . . . . . . . . . . . . . . 9 78 7.2. Error Recovery . . . . . . . . . . . . . . . . . . . . . . 10 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 8.1. Link Relation Type Registration: "duplicate" . . . . . . . 11 81 8.2. Hypertext Transfer Protocol (HTTP) Digest Algorithm 82 Values Registration . . . . . . . . . . . . . . . . . . . 11 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 9.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 12 85 9.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 9.3. Cryptographic Hashes . . . . . . . . . . . . . . . . . . . 12 87 9.4. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 12 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 90 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 91 Appendix A. Acknowledgements and Contributors . . . . . . . . . . 13 92 Appendix B. Comparisons to Similar Options (to be removed by 93 RFC Editor before publication) . . . . . . . . . . . 13 94 Appendix C. Document History (to be removed by RFC Editor 95 before publication) . . . . . . . . . . . . . . . . . 14 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 99 1. Introduction 101 MetaLinkHeader is an alternative to Metalink, usually an XML-based 102 document format [draft-bryan-metalink]. MetaLinkHeader attempts to 103 provide as much functionality as the Metalink XML format by using 104 existing standards such as Web Linking 105 [draft-nottingham-http-link-header], Instance Digests in HTTP 106 [RFC3230], and Etags. MetaLinkHeader is used to list information 107 about a file to be downloaded. This includes lists of multiple URIs 108 (mirrors), Peer-to-Peer information, checksums, and digital 109 signatures. 111 Identical copies of a file are frequently accessible in multiple 112 locations on the Internet over a variety of protocols (FTP, HTTP, and 113 Peer-to-Peer). In some cases, Users are shown a list of these 114 multiple download locations (mirrors) and must manually select a 115 single one on the basis of geographical location, priority, or 116 bandwidth. This distributes the load across multiple servers. At 117 times, individual servers can be slow, outdated, or unreachable, but 118 this can not be determined until the download has been initiated. 119 This can lead to the user canceling the download and needing to 120 restart it. During downloads, errors in transmission can corrupt the 121 file. There are no easy ways to repair these files. For large 122 downloads this can be extremely troublesome. Any of the number of 123 problems that can occur during a download lead to frustration on the 124 part of users. 126 All the information about a download, including mirrors, checksums, 127 digital signatures, and more can be transferred in coordinated HTTP 128 Headers. This Metalink transfers the knowledge of the download 129 server (and mirror database) to the client. Clients can fallback to 130 other mirrors if the current one has an issue. With this knowledge, 131 the client is enabled to work its way to a successful download even 132 under adverse circumstances. All this is done transparently to the 133 user and the download is much more reliable and efficient. In 134 contrast, a traditional HTTP redirect to a mirror conveys only 135 extremely minimal information - one link to one server, and there is 136 no provision in the HTTP protocol to handle failures. Other features 137 that some clients provide include multi-source downloads, where 138 portions of a file are downloaded from multiple mirrors (and 139 optionally, Peer-to-Peer) simultaneously, which frequently results in 140 a faster download. 142 [[ Discussion of this draft should take place on IETF HTTP WG mailing 143 list at ietf-http-wg@w3.org or the Metalink discussion mailing list 144 located at metalink-discussion@googlegroups.com. To join the list, 145 visit http://groups.google.com/group/metalink-discussion . ]] 147 1.1. Examples 149 A brief Metalink server response with checksum, mirrors, .metalink, 150 and OpenPGP signature: 152 Link: ; rel="duplicate" 153 Link: ; rel="duplicate" 154 Link: ; rel="describedby"; 155 type="application/x-bittorrent" 156 Link: ; rel="describedby"; 157 type="application/metalink4+xml" 158 Link: ; rel="describedby"; 159 type="application/pgp-signature" 160 Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5= 162 1.2. Notational Conventions 164 This specification describes conformance of MetaLinkHeader. 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in BCP 14, [RFC2119], as 169 scoped to those conformance targets. 171 2. Requirements 173 In this context, "MetaLink" refers to a MetaLinkHeader which consists 174 of mirrors and checksums in HTTP Headers as described in this 175 document. "Metalink XML" refers to the XML format described in 176 [draft-bryan-metalink]. 178 Metalink servers are HTTP servers that MUST have lists of mirrors and 179 use the Link header [draft-nottingham-http-link-header] to indicate 180 them. They also MUST provide checksums of files via Instance Digests 181 in HTTP [RFC3230], whether requested or not. Mirror and checksum 182 information provided by the originating Metalink server MUST be 183 considered authoritative. Metalink servers and their associated 184 mirror servers SHOULD all share the same ETag policy (ETag 185 Synchronization), i.e. based on the file contents (checksum) and not 186 server-unique filesystem metadata. The emitted ETag may be 187 implemented the same as the Instance Digest for simplicity. 189 Mirror servers are typically FTP or HTTP servers that "mirror" 190 another server. That is, they provide identical copies of (at least 191 some) files that are also on the mirrored server. Mirror servers MAY 192 be Metalink servers. Mirror servers MUST support serving partial 193 content. Mirror servers SHOULD support Instance Digests in HTTP 195 [RFC3230]. Optimally, mirror servers will share the same ETag policy 196 as the Metalink server and provide Instance Digests. 198 Metalink clients use the mirrors provided by a Metalink server with 199 Link header [draft-nottingham-http-link-header]. Metalink clients 200 MUST support HTTP and MAY support FTP, BitTorrent, or other download 201 methods. Metalink clients MUST switch downloads from one mirror to 202 another if the one mirror becomes unreachable. Metalink clients are 203 RECOMMENDED to support multi-source, or parallel, downloads, where 204 portions of a file are downloaded from multiple mirrors 205 simultaneously (and optionally, from Peer-to-Peer sources). Metalink 206 clients MUST support Instance Digests in HTTP [RFC3230] by requesting 207 and verifying checksums. Metalink clients MAY make use of digital 208 signatures if they are offered. 210 3. Mirrors / Multiple Download Locations 212 Mirrors are specified with the Link header 213 [draft-nottingham-http-link-header] and a relation type of 214 "duplicate" as defined in Section 8.1. 216 A brief Metalink server response with two mirrors only: 218 Link: ; rel="duplicate" 219 Link: ; rel="duplicate" 221 Mirror servers are listed in order of priority. 223 [[Some organizations have many mirrors. Only send a few mirrors, or 224 only use the Link header if Want-Digest is used?]] 226 4. Peer-to-Peer Descriptions / Metainfo 228 Ways to download a file over Peer-to-Peer networks are specified with 229 the Link header [draft-nottingham-http-link-header] and a relation 230 type of "describedby" and a type parameter hat indicates the MIME 231 type of the metadata available at the IRI. 233 A brief Metalink server response with .torrent and .metalink: 235 Link: ; rel="describedby"; 236 type="application/x-bittorrent" 237 Link: ; rel="describedby"; 238 type="application/metalink4+xml" 240 5. OpenPGP Signatures 242 OpenPGP signatures are specified with the Link header 243 [draft-nottingham-http-link-header] and a relation type of 244 "describedby" and a type parameter of "application/pgp-signature". 246 A brief Metalink server response with OpenPGP signature only: 248 Link: ; rel="describedby"; 249 type="application/pgp-signature" 251 6. Checksums of Whole Files 253 Metalink servers MUST provide Instance Digests in HTTP [RFC3230] for 254 files they describe with mirrors. Mirror servers MAY as well. 256 A brief Metalink server response with checksum: 258 Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5= 260 7. Client / Server Multi-source Download Interaction 262 Metalink clients begin a download with a standard HTTP [RFC2616] GET 263 request to the Metalink server. A Range limit is optional, not 264 required. Here the client prefers SHA-1 checksums over MD5: 266 GET /distribution/example.ext HTTP/1.1 267 Host: www.example.com 269 Alternatively, Metalink clients can use a HEAD request to discover 270 mirrors via Link headers. After that, it follows with a GET request 271 as usual. 273 The Metalink server responds with this: 275 HTTP/1.1 200 OK 276 Accept-Ranges: bytes 277 Content-Length: 14867603 278 Content-Type: application/x-cd-image 279 Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5=" 280 Link: ; rel="duplicate" 281 Link: ; rel="duplicate" 282 Link: ; rel="describedby"; 283 type="application/x-bittorrent" 284 Link: ; rel="describedby"; 285 type="application/metalink4+xml" 286 Link: ; rel="describedby"; 287 type="application/pgp-signature" 288 Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5= 290 From the Metalink server response the client learns the following 291 metadata about the requested object, in addition also starting to 292 receive the object: 293 o Mirror profile link. 294 o Instance Digest. 295 o Object size. 296 o ETag. (ETag synchronization between mirrors is OPTIONAL). 297 o Peer-to-peer information. 298 o Digital signature. 299 o Metalink XML, which can include checksums to repair a file. 301 If the object is large and gets delivered slower than expected then 302 the Metalink client starts a number of parallel ranged downloads (one 303 per selected mirror server other than the first) using mirrors 304 provided by the Link header with "duplicate" relation type, using the 305 location of the original GET request in the "Referer" header field. 306 If no Range limit was given in the original request then work from 307 the tail of the object (the first request is still running and will 308 eventually catch up), otherwise continue after the range requested in 309 the first request. 311 If ETags are coordinated between mirrors, If-Match conditions based 312 on the ETag SHOULD be used to quickly detect out-of-date mirrors by 313 using the ETag from the Metalink server response. If no indication 314 of ETag syncronisation/knowledge is given then If-Match should not be 315 used, and optimally there will be an Instance Digest in the mirror 316 response which we can use to detect a mismatch early, and if not then 317 a mismatch won't be detected until the completed object is verified. 318 One of the client requests to a mirror server: 320 GET /example.ext HTTP/1.1 321 Host: www2.example.com 322 Range: bytes=7433802- 323 If-Match: "thvDyvhfIqlvFe+A9MYgxAfm1q5=" 324 Referer: http://www.example.com/distribution/example.ext 326 The mirror servers respond with a 206 Partial Content HTTP status 327 code and appropriate "Content-Length" and "Content Range" header 328 fields. The mirror server response to the above request: 330 HTTP/1.1 206 Partial Content 331 Accept-Ranges: bytes 332 Content-Length: 7433801 333 Content-Range: bytes 7433802-14867602/14867603 334 Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5=" 335 Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5= 337 If the first request was not Range limited then abort it by closing 338 the connection when it catches up with the other parallel downloads 339 of the same object. 341 Once the download has completed, the Metalink client MUST verify the 342 checksum of the file. 344 7.1. Early File Mismatch Detection with Strong ETag or Instance Digest 345 from Mirrors 347 In HTTP terms, the requirement is that merging of ranges from 348 multiple responses must be verified with a strong validator, which in 349 this context is the same as either instance digest or a strong ETag. 350 In most cases it is sufficient that the Metalink server provides 351 mirrors and Instance Digest information, but operation will be more 352 robust and efficient if the mirror servers do implement a 353 synchronized ETag as well. In fact, the emitted ETag may be 354 implemented the same as the Instance Digest for simplicity, but there 355 is no need to specify how ETag generated, just that it needs to be 356 shared among the mirror servers. If the mirror server provides 357 neither synchronized ETag or Instance Digest, then early detection of 358 mismatches is not possible unless file length also differs. Finally, 359 the error is still detectable when the merged response is verified. 361 ETag can not be used for verifying the integrity of the received 362 content. But it is a guarantee issued by the Metalink server that 363 the content is correct for that ETag. And if the ETag given by the 364 mirror server matches the ETag given by the master server, then we 365 have a chain of trust where the master server authorizes these 366 responses as valid for that object. 368 This guarantees that a mismatch will be detected by using only the 369 synchronized ETag from a master server and mirror server, even 370 alerted by the mirror servers themselves by responding with an error, 371 preventing accidental merges of ranges from different versions of 372 files with the same name. This even includes many malicious attacks 373 where the data on the mirror has been replaced by some other file, 374 but not all. 376 Synchronized ETag can not strictly protect against malicious attacks 377 or server or network errors replacing content, but neither can 378 Instance Digest on the mirror servers as the attacker most certainly 379 can make the server seemingly respond with the expected Instance 380 Digest even if the file contents have been modified, just as he can 381 with ETag, and the same for various system failures also causing bad 382 data to be returned. The Metalink client has to rely on the Instance 383 Digest returned by the Metalink master server in the first response 384 for the verification of the downloaded object as a whole. 386 If the mirror servers do return an Instance Digest, then that is a 387 bonus, just as having them return the right set of Link headers is. 388 The set of trusted mirrors doing that can be substituted as master 389 servers accepting the initial request if one likes. 391 The benefit of having slave mirror servers (those not trusted as 392 masters) return Instance Digest is that the client then can detect 393 mismatches early even if ETag is not used. Both ETag and slave 394 mirror Instance Digest do provide value, but just one is sufficient 395 for early detection of mismatches. If none is provided then early 396 detection of mismatches is not possible unless the file length also 397 differs, but the error is still detected when the merged response is 398 verified. 400 7.2. Error Recovery 402 If the object checksum does not match the Instance Digest then fetch 403 the Metalink XML or other recovery profile link, where partial file 404 checksums can be found, allowing detection of which server returned 405 bad information. If the Instance Digest computation does not match 406 then the client needs to fetch the partial file checksums and from 407 there figure out what of the downloaded data can be recovered and 408 what needs to be fetched again, or if no partial checksums are 409 available fetch the complete object from a trusted Metalink server. 411 8. IANA Considerations 413 Accordingly, IANA has made the following registrations. 415 8.1. Link Relation Type Registration: "duplicate" 417 o Relation Name: duplicate 419 o Description: Refers to a resource whose available representations 420 are byte-for-byte identical with the corresponding representations of 421 the context IRI. 423 o Reference: This specification. 425 o Notes: This relation is for static resources. That is, an HTTP GET 426 request on any duplicate will return the same representation. It 427 does not make sense for dynamic or POSTable resources and should not 428 be used for them. 430 8.2. Hypertext Transfer Protocol (HTTP) Digest Algorithm Values 431 Registration 433 This document makes use of the IANA registry named "Hypertext 434 Transfer Protocol (HTTP) Digest Algorithm Values" specified in 435 [RFC3230]. 437 Digest Algorithm: SHA-224 438 Description: The SHA-224 algorithm [SHS]. The output of this 439 algorithm is encoded using the base64 encoding [RFC2045]. 440 Reference: [SHS] [RFC2045] 442 Digest Algorithm: SHA-256 443 Description: The SHA-256 algorithm [SHS]. The output of this 444 algorithm is encoded using the base64 encoding [RFC2045]. 445 Reference: [SHS] [RFC2045] 447 Digest Algorithm: SHA-384 448 Description: The SHA-384 algorithm [SHS]. The output of this 449 algorithm is encoded using the base64 encoding [RFC2045]. 450 Reference: [SHS] [RFC2045] 452 Digest Algorithm: SHA-512 453 Description: The SHA-512 algorithm [SHS]. The output of this 454 algorithm is encoded using the base64 encoding [RFC2045]. 455 Reference: [SHS] [RFC2045] 457 9. Security Considerations 458 9.1. URIs and IRIs 460 Metalink clients handle URIs and IRIs. See Section 7 of [RFC3986] 461 and Section 8 of [RFC3987] for security considerations related to 462 their handling and use. 464 9.2. Spoofing 466 There is potential for spoofing attacks where the attacker publishes 467 Metalinks with false information. In that case, this could deceive 468 unaware downloaders that they are downloading a malicious or 469 worthless file. Also, malicious publishers could attempt a 470 distributed denial of service attack by inserting unrelated IRIs into 471 Metalinks. 473 9.3. Cryptographic Hashes 475 Currently, some of the digest values defined in Instance Digests in 476 HTTP [RFC3230] are considered insecure. These include the whole 477 Message Digest family of algorithms which are not suitable for 478 cryptographically strong verification. Malicious people could 479 provide files that appear to be identical to another file because of 480 a collision, i.e. the weak cryptographic hashes of the intended file 481 and a substituted malicious file could match. 483 If a Metalink contains hashes as described in Section 6, it SHOULD 484 include "sha" which is SHA-1, as specified in [RFC3174]. It MAY also 485 include other hashes. 487 9.4. Signing 489 Metalinks should include digital signatures, as described in 490 Section 5. 492 Digital signatures provide authentication, message integrity, and 493 non-repudiation with proof of origin. 495 10. References 497 10.1. Normative References 499 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 500 Extensions (MIME) Part One: Format of Internet Message 501 Bodies", RFC 2045, November 1996. 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, March 1997. 506 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 507 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 508 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 510 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 511 (SHA1)", RFC 3174, September 2001. 513 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 514 RFC 3230, January 2002. 516 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 517 Resource Identifier (URI): Generic Syntax", STD 66, 518 RFC 3986, January 2005. 520 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 521 Identifiers (IRIs)", RFC 3987, January 2005. 523 [SHS] National Institute of Standards and Technology (NIST), 524 "Secure Hash Standard", FIPS PUB 180-3, October 2008, . 528 [draft-nottingham-http-link-header] 529 Nottingham, M., "Web Linking", 530 draft-nottingham-http-link-header-06 (work in progress), 531 July 2009. 533 10.2. Informative References 535 [draft-bryan-metalink] 536 Bryan, A., Ed., Tsujikawa, T., McNab, N., and P. Poeml, 537 "The Metalink Download Description Format", 538 draft-bryan-metalink-16 (work in progress), August 2009. 540 Appendix A. Acknowledgements and Contributors 542 Thanks to Mark Nottingham, Daniel Stenberg and Matt Domsch. 544 Appendix B. Comparisons to Similar Options (to be removed by RFC Editor 545 before publication) 547 This draft, compared to the Metalink XML format 548 [draft-bryan-metalink] : 550 o (+) Reuses existing HTTP standards without defining anything new 551 besides a Link Relation Type. It's more of a collection/ 552 coordinated feature set. 553 o (?) The existing standards don't seem to be widely implemented. 554 o (+) No XML dependency. 555 o (?) Existing Metalink XML clients can be easily converted to 556 support this as well. 557 o (-?) Tied to HTTP, not as generic. FTP/P2P clients won't be 558 using it unless they also support HTTP, unlike Metalink XML. 559 o (---) Requires changes to server software. 560 o (-?) Could require some coordination of all mirror servers for 561 all features, which may be difficult or impossible unless you are 562 in control of all servers on the mirror network. 563 o (-) Requires server-side support. Metalink XML can be created by 564 user (or server, but server component/changes not required). 565 o (-) Also, Metalink XML files are easily mirrored on all servers. 566 Even if usage in that case is not as transparent, it still gives 567 access to users at all mirrors (FTP included) to all download 568 information with no changes needed to the server. 569 o (-) Not portable/archivable/emailable. Metalink XML is used to 570 import/export transfer queues. Not as easy for search engines to 571 index? 572 o (-) No way to show mirror/p2p geographical location (yet). 573 o (ADDRESSED IN THIS REVISION) No checksums besides MD5/SHA-1. 574 o (-) Not as rich metadata. 575 o (-) Not able to add multiple files to a download queue or create 576 directory structure. 578 draft-ford-http-multi-server compared to this draft : 580 o (+) Plans to define mirrors for whole directories. 581 o (-?) Defines new headers. Doesn't reuse existing standards. 582 o (---) Requires changes to server software. 583 o (---) Requires coordination of all mirror servers, which may be 584 difficult or impossible unless you are in control of all servers 585 on the mirror network. 586 o (---) Doesn't tie in p2p. 587 o (-) No way to show mirror/p2p priority or geographical location 588 (yet). 590 Appendix C. Document History (to be removed by RFC Editor before 591 publication) 593 [[ to be removed by the RFC editor before publication as an RFC. ]] 595 Known issues concerning this draft: 597 o Use of Link header to describe Mirrors. Only send a few mirrors 598 with Link header, or only send them if Want-Digest is used? Some 599 organizations have many mirrors. 600 o A way to differentiate between mirrors that have synchronized 601 ETags and those that don't. 602 o Do we want a way to show that whole directories are mirrored, 603 instead of individual files? 604 o Need an official MIME type for .torrent files or allow 605 "application/x-bittorrent"? 606 o ADDRESSED:Some publishers desire stronger hashes than MD5 and 607 SHA-1. 609 -06 : September , 2009. 610 o Add Mismatch Detection, Error Recovery, and Digest Algorithm 611 values. 612 o Remove Content-MD5 and Want-Digest. 614 -05 : September 19, 2009. 615 o ETags, preferably matching the Instance Digests. 617 -04 : September 17, 2009. 618 o Temporarily remove .torrent. 620 -03 : September 16, 2009. 621 o Mention HEAD request, negotiate mirrors if Want-Digest is used. 623 -02 : September 6, 2009. 624 o Content-MD5 for partial file checksums. 626 -01 : September 1, 2009. 627 o Link Relation Type Registration: "duplicate" 629 -00 : August 24, 2009. 630 o Initial draft. 632 Authors' Addresses 634 Anthony Bryan (editor) 635 Metalinker Project 637 Email: anthonybryan@gmail.com 638 URI: http://www.metalinker.org 639 Neil McNab 640 Metalinker Project 642 Email: neil@nabber.org 643 URI: http://www.nabber.org 645 Henrik Nordstrom 647 Email: henrik@henriknordstrom.net 648 URI: http://www.henriknordstrom.net/