idnits 2.17.1 draft-bryan-metalinkhttp-08.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 date (October 4, 2009) is 5318 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 (~~), 1 warning (==), 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: April 7, 2010 H. Nordstrom 7 A. Ford 8 Roke Manor Research 9 October 4, 2009 11 Metalink/HTTP: Mirrors and Checksums in HTTP Headers 12 draft-bryan-metalinkhttp-08 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 7, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document specifies Metalink/HTTP: Mirrors and Checksums in HTTP 51 Headers, an alternative to the Metalink XML-based download 52 description format. Metalink/HTTP describes multiple download 53 locations (mirrors), Peer-to-Peer, checksums, digital signatures, and 54 other information using existing standards. Clients can 55 transparently use this information to make file transfers more robust 56 and reliable. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 4 63 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Mirrors / Multiple Download Locations . . . . . . . . . . . . 5 65 4. Peer-to-Peer Metainfo . . . . . . . . . . . . . . . . . . . . 6 66 5. OpenPGP Signatures . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Checksums of Whole Files . . . . . . . . . . . . . . . . . . . 6 68 7. Client / Server Multi-source Download Interaction . . . . . . 6 69 7.1. Error Prevention, Detection, and Correction . . . . . . . 8 70 7.1.1. Error Prevention (Early File Mismatch Detection) . . . 8 71 7.1.2. Error Correction . . . . . . . . . . . . . . . . . . . 10 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 8.1. Link Relation Type Registration: "duplicate" . . . . . . . 10 74 8.2. Hypertext Transfer Protocol (HTTP) Digest Algorithm 75 Values Registration . . . . . . . . . . . . . . . . . . . 10 76 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 9.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 11 78 9.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 9.3. Cryptographic Hashes . . . . . . . . . . . . . . . . . . . 11 80 9.4. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 84 Appendix A. Acknowledgements and Contributors . . . . . . . . . . 13 85 Appendix B. Comparisons to Similar Options (to be removed by 86 RFC Editor before publication) . . . . . . . . . . . 13 87 Appendix C. Document History (to be removed by RFC Editor 88 before publication) . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 Metalink/HTTP is an alternative to Metalink, usually an XML-based 94 document format [draft-bryan-metalink]. Metalink/HTTP attempts to 95 provide as much functionality as the Metalink/XML format by using 96 existing standards such as Web Linking 97 [draft-nottingham-http-link-header], Instance Digests in HTTP 98 [RFC3230], and ETags. Metalink/HTTP is used to list information 99 about a file to be downloaded. This includes lists of multiple URIs 100 (mirrors), Peer-to-Peer information, checksums, and digital 101 signatures. 103 Identical copies of a file are frequently accessible in multiple 104 locations on the Internet over a variety of protocols (FTP, HTTP, and 105 Peer-to-Peer). In some cases, Users are shown a list of these 106 multiple download locations (mirrors) and must manually select a 107 single one on the basis of geographical location, priority, or 108 bandwidth. This distributes the load across multiple servers. At 109 times, individual servers can be slow, outdated, or unreachable, but 110 this can not be determined until the download has been initiated. 111 This can lead to the user canceling the download and needing to 112 restart it. During downloads, errors in transmission can corrupt the 113 file. There are no easy ways to repair these files. For large 114 downloads this can be extremely troublesome. Any of the number of 115 problems that can occur during a download lead to frustration on the 116 part of users. 118 All the information about a download, including mirrors, checksums, 119 digital signatures, and more can be transferred in coordinated HTTP 120 Headers. This Metalink transfers the knowledge of the download 121 server (and mirror database) to the client. Clients can fallback to 122 other mirrors if the current one has an issue. With this knowledge, 123 the client is enabled to work its way to a successful download even 124 under adverse circumstances. All this is done transparently to the 125 user and the download is much more reliable and efficient. In 126 contrast, a traditional HTTP redirect to a mirror conveys only 127 extremely minimal information - one link to one server, and there is 128 no provision in the HTTP protocol to handle failures. Other features 129 that some clients provide include multi-source downloads, where 130 portions of a file are downloaded from multiple mirrors (and 131 optionally, Peer-to-Peer) simultaneously, which frequently results in 132 a faster download. 134 [[ Discussion of this draft should take place on IETF HTTP WG mailing 135 list at ietf-http-wg@w3.org or the Metalink discussion mailing list 136 located at metalink-discussion@googlegroups.com. To join the list, 137 visit http://groups.google.com/group/metalink-discussion . ]] 139 1.1. Examples 141 A brief Metalink server response with checksum, mirrors, .metalink, 142 and OpenPGP signature: 144 Link: ; rel="duplicate" 145 Link: ; rel="duplicate" 146 Link: ; rel="describedby"; 147 type="application/x-bittorrent" 148 Link: ; rel="describedby"; 149 type="application/metalink4+xml" 150 Link: ; rel="describedby"; 151 type="application/pgp-signature" 152 Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5= 154 1.2. Notational Conventions 156 This specification describes conformance of Metalink/HTTP. 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in BCP 14, [RFC2119], as 161 scoped to those conformance targets. 163 2. Requirements 165 In this context, "Metalink" refers to Metalink/HTTP which consists of 166 mirrors and checksums in HTTP Headers as described in this document. 167 "Metalink/XML" refers to the XML format described in 168 [draft-bryan-metalink]. 170 Metalink servers are HTTP servers that MUST have lists of mirrors and 171 use the Link header [draft-nottingham-http-link-header] to indicate 172 them. They also MUST provide checksums of files via Instance Digests 173 in HTTP [RFC3230], whether requested or not. Mirror and checksum 174 information provided by the originating Metalink server MUST be 175 considered authoritative. Metalink servers and their associated 176 mirror servers SHOULD all share the same ETag policy (ETag 177 Synchronization), i.e. based on the file contents (checksum) and not 178 server-unique filesystem metadata. The emitted ETag may be 179 implemented the same as the Instance Digest for simplicity. 181 Mirror servers are typically FTP or HTTP servers that "mirror" 182 another server. That is, they provide identical copies of (at least 183 some) files that are also on the mirrored server. Mirror servers MAY 184 be Metalink servers. Mirror servers MUST support serving partial 185 content. Mirror servers SHOULD support Instance Digests in HTTP 187 [RFC3230]. Optimally, HTTP mirror servers will share the same ETag 188 policy as the Metalink server, provide Instance Digests, or both. 189 Preferred mirror servers MUST share the same ETag policy or MUST 190 support Instance Digests. 192 Metalink clients use the mirrors provided by a Metalink server with 193 Link header [draft-nottingham-http-link-header]. Metalink clients 194 MUST support HTTP and MAY support FTP, BitTorrent, or other download 195 methods. Metalink clients MUST switch downloads from one mirror to 196 another if the one mirror becomes unreachable. Metalink clients are 197 RECOMMENDED to support multi-source, or parallel, downloads, where 198 portions of a file are downloaded from multiple mirrors 199 simultaneously (and optionally, from Peer-to-Peer sources). Metalink 200 clients MUST support Instance Digests in HTTP [RFC3230] by requesting 201 and verifying checksums. Metalink clients MAY make use of digital 202 signatures if they are offered. 204 3. Mirrors / Multiple Download Locations 206 Mirrors are specified with the Link header 207 [draft-nottingham-http-link-header] and a relation type of 208 "duplicate" as defined in Section 8.1. 210 A brief Metalink server response with two mirrors only: 212 Link: ; rel="duplicate"; 213 pri=1; pref=1 214 Link: ; rel="duplicate"; pri=2 216 Mirror servers are listed in order of priority or have a "pri" value, 217 where mirrors with lower values are used first. 219 There are two types of mirror servers: preferred and normal. 220 Optimally, HTTP mirror servers will share the same ETag policy as the 221 Metalink server, provide Instance Digests, or both. These mirrors 222 are preferred, and make it possible to detect early on, before data 223 is transferred, if the file requested matches the desired file. 224 Preferred mirror servers MUST share the same ETag policy or MUST 225 support Instance Digests. Preferred HTTP mirror servers have a 226 "pref" value of 1. 228 [[Some organizations have many mirrors. Only send a few mirrors, or 229 only use the Link header if Want-Digest is used?]] 231 4. Peer-to-Peer Metainfo 233 Metainfo files, which describe ways to download a file over Peer-to- 234 Peer networks or otherwise, are specified with the Link header 235 [draft-nottingham-http-link-header] and a relation type of 236 "describedby" and a type parameter that indicates the MIME type of 237 the metadata available at the IRI. 239 A brief Metalink server response with .torrent and .metalink: 241 Link: ; rel="describedby"; 242 type="application/x-bittorrent" 243 Link: ; rel="describedby"; 244 type="application/metalink4+xml" 246 5. OpenPGP Signatures 248 OpenPGP signatures are specified with the Link header 249 [draft-nottingham-http-link-header] and a relation type of 250 "describedby" and a type parameter of "application/pgp-signature". 252 A brief Metalink server response with OpenPGP signature only: 254 Link: ; rel="describedby"; 255 type="application/pgp-signature" 257 6. Checksums of Whole Files 259 Metalink servers MUST provide Instance Digests in HTTP [RFC3230] for 260 files they describe with mirrors. Mirror servers SHOULD as well. 262 A brief Metalink server response with checksum: 264 Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5= 266 7. Client / Server Multi-source Download Interaction 268 Metalink clients begin a download with a standard HTTP [RFC2616] GET 269 request to the Metalink server. A Range limit is optional, not 270 required. Alternatively, Metalink clients can begin with a HEAD 271 request to the Metalink server to discover mirrors via Link headers. 272 After that, the client follows with a GET request to the desired 273 mirrors. 275 GET /distribution/example.ext HTTP/1.1 276 Host: www.example.com 278 The Metalink server responds with the data and these headers: 280 HTTP/1.1 200 OK 281 Accept-Ranges: bytes 282 Content-Length: 14867603 283 Content-Type: application/x-cd-image 284 Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5=" 285 Link: ; rel="duplicate" 286 Link: ; rel="duplicate" 287 Link: ; rel="describedby"; 288 type="application/x-bittorrent" 289 Link: ; rel="describedby"; 290 type="application/metalink4+xml" 291 Link: ; rel="describedby"; 292 type="application/pgp-signature" 293 Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5= 295 From the Metalink server response the client learns the following 296 metadata about the requested object, in addition to also starting to 297 receive the object: 299 o Mirror profile link. 300 o Instance Digest. 301 o Object size. 302 o ETag. 303 o Peer-to-peer information. 304 o Digital signature. 305 o Metalink/XML, which can include partial file checksums to repair a 306 file. 308 If the object is large and gets delivered slower than expected then 309 the Metalink client starts a number of parallel ranged downloads (one 310 per selected mirror server other than the first) using mirrors 311 provided by the Link header with "duplicate" relation type, using the 312 location of the original GET request in the "Referer" header field. 313 If no Range limit was given in the original request then work from 314 the tail of the object (the first request is still running and will 315 eventually catch up), otherwise continue after the range requested in 316 the first request. 318 If ETags are coordinated between mirrors, If-Match conditions based 319 on the ETag SHOULD be used to quickly detect out-of-date mirrors by 320 using the ETag from the Metalink server response. If no indication 321 of ETag syncronisation/knowledge is given then If-Match should not be 322 used, and optimally there will be an Instance Digest in the mirror 323 response which we can use to detect a mismatch early, and if not then 324 a mismatch won't be detected until the completed object is verified. 325 One of the client requests to a mirror server: 327 GET /example.ext HTTP/1.1 328 Host: www2.example.com 329 Range: bytes=7433802- 330 If-Match: "thvDyvhfIqlvFe+A9MYgxAfm1q5=" 331 Referer: http://www.example.com/distribution/example.ext 333 The mirror servers respond with a 206 Partial Content HTTP status 334 code and appropriate "Content-Length" and "Content Range" header 335 fields. The mirror server response, with data, to the above request: 337 HTTP/1.1 206 Partial Content 338 Accept-Ranges: bytes 339 Content-Length: 7433801 340 Content-Range: bytes 7433802-14867602/14867603 341 Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5=" 342 Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5= 344 If the first request was not Range limited then abort it by closing 345 the connection when it catches up with the other parallel downloads 346 of the same object. 348 Downloads from mirrors that do not have the same file size as the 349 Metalink server MUST be aborted. 351 Once the download has completed, the Metalink client MUST verify the 352 checksum of the file. 354 7.1. Error Prevention, Detection, and Correction 356 Error prevention, or early file mismatch detection, is possible 357 before file transfers with the use of file sizes, ETags, and Instance 358 Digests. Error dectection requires Instance Digests, or checksums, 359 to determine after transfers if there has been an error. Error 360 correction, or download repair, is possible with partial file 361 checksums. 363 7.1.1. Error Prevention (Early File Mismatch Detection) 365 In HTTP terms, the requirement is that merging of ranges from 366 multiple responses must be verified with a strong validator, which in 367 this context is the same as either Instance Digest or a strong ETag. 368 In most cases it is sufficient that the Metalink server provides 369 mirrors and Instance Digest information, but operation will be more 370 robust and efficient if the mirror servers do implement a 371 synchronized ETag as well. In fact, the emitted ETag may be 372 implemented the same as the Instance Digest for simplicity, but there 373 is no need to specify how the ETag is generated, just that it needs 374 to be shared among the mirror servers. If the mirror server provides 375 neither synchronized ETag or Instance Digest, then early detection of 376 mismatches is not possible unless file length also differs. Finally, 377 the error is still detectable, after the download has completed, when 378 the merged response is verified. 380 ETag can not be used for verifying the integrity of the received 381 content. But it is a guarantee issued by the Metalink server that 382 the content is correct for that ETag. And if the ETag given by the 383 mirror server matches the ETag given by the master server, then we 384 have a chain of trust where the master server authorizes these 385 responses as valid for that object. 387 This guarantees that a mismatch will be detected by using only the 388 synchronized ETag from a master server and mirror server, even 389 alerted by the mirror servers themselves by responding with an error, 390 preventing accidental merges of ranges from different versions of 391 files with the same name. This even includes many malicious attacks 392 where the data on the mirror has been replaced by some other file, 393 but not all. 395 Synchronized ETag can not strictly protect against malicious attacks 396 or server or network errors replacing content, but neither can 397 Instance Digest on the mirror servers as the attacker most certainly 398 can make the server seemingly respond with the expected Instance 399 Digest even if the file contents have been modified, just as he can 400 with ETag, and the same for various system failures also causing bad 401 data to be returned. The Metalink client has to rely on the Instance 402 Digest returned by the Metalink master server in the first response 403 for the verification of the downloaded object as a whole. 405 If the mirror servers do return an Instance Digest, then that is a 406 bonus, just as having them return the right set of Link headers is. 407 The set of trusted mirrors doing that can be substituted as master 408 servers accepting the initial request if one likes. 410 The benefit of having slave mirror servers (those not trusted as 411 masters) return Instance Digest is that the client then can detect 412 mismatches early even if ETag is not used. Both ETag and slave 413 mirror Instance Digest do provide value, but just one is sufficient 414 for early detection of mismatches. If none is provided then early 415 detection of mismatches is not possible unless the file length also 416 differs, but the error is still detected when the merged response is 417 verified. 419 7.1.2. Error Correction 421 If the object checksum does not match the Instance Digest then fetch 422 the Metalink/XML or other recovery profile link, where partial file 423 checksums can be found, allowing detection of which server returned 424 bad information. If the Instance Digest computation does not match 425 then the client needs to fetch the partial file checksums and from 426 there figure out what of the downloaded data can be recovered and 427 what needs to be fetched again. If no partial checksums are 428 available, then the client MUST fetch the complete object from a 429 trusted Metalink server. 431 Partial file checksums can be used to detect errors during the 432 download. 434 8. IANA Considerations 436 Accordingly, IANA has made the following registrations. 438 8.1. Link Relation Type Registration: "duplicate" 440 o Relation Name: duplicate 442 o Description: Refers to a resource whose available representations 443 are byte-for-byte identical with the corresponding representations of 444 the context IRI. 446 o Reference: This specification. 448 o Notes: This relation is for static resources. That is, an HTTP GET 449 request on any duplicate will return the same representation. It 450 does not make sense for dynamic or POSTable resources and should not 451 be used for them. 453 8.2. Hypertext Transfer Protocol (HTTP) Digest Algorithm Values 454 Registration 456 This document makes use of the IANA registry named "Hypertext 457 Transfer Protocol (HTTP) Digest Algorithm Values" specified in 458 [RFC3230]. 460 Digest Algorithm: SHA-224 461 Description: The SHA-224 algorithm [SHS]. The output of this 462 algorithm is encoded using the base64 encoding [RFC2045]. 463 Reference: [SHS] [RFC2045] 464 Digest Algorithm: SHA-256 465 Description: The SHA-256 algorithm [SHS]. The output of this 466 algorithm is encoded using the base64 encoding [RFC2045]. 467 Reference: [SHS] [RFC2045] 469 Digest Algorithm: SHA-384 470 Description: The SHA-384 algorithm [SHS]. The output of this 471 algorithm is encoded using the base64 encoding [RFC2045]. 472 Reference: [SHS] [RFC2045] 474 Digest Algorithm: SHA-512 475 Description: The SHA-512 algorithm [SHS]. The output of this 476 algorithm is encoded using the base64 encoding [RFC2045]. 477 Reference: [SHS] [RFC2045] 479 9. Security Considerations 481 9.1. URIs and IRIs 483 Metalink clients handle URIs and IRIs. See Section 7 of [RFC3986] 484 and Section 8 of [RFC3987] for security considerations related to 485 their handling and use. 487 9.2. Spoofing 489 There is potential for spoofing attacks where the attacker publishes 490 Metalinks with false information. In that case, this could deceive 491 unaware downloaders that they are downloading a malicious or 492 worthless file. Also, malicious publishers could attempt a 493 distributed denial of service attack by inserting unrelated IRIs into 494 Metalinks. 496 9.3. Cryptographic Hashes 498 Currently, some of the digest values defined in Instance Digests in 499 HTTP [RFC3230] are considered insecure. These include the whole 500 Message Digest family of algorithms which are not suitable for 501 cryptographically strong verification. Malicious people could 502 provide files that appear to be identical to another file because of 503 a collision, i.e. the weak cryptographic hashes of the intended file 504 and a substituted malicious file could match. 506 If a Metalink contains whole file hashes as described in Section 6, 507 it SHOULD include "sha" which is SHA-1, as specified in [RFC3174], or 508 stronger. It MAY also include other hashes. 510 9.4. Signing 512 Metalinks should include digital signatures, as described in 513 Section 5. 515 Digital signatures provide authentication, message integrity, and 516 non-repudiation with proof of origin. 518 10. References 520 10.1. Normative References 522 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 523 Extensions (MIME) Part One: Format of Internet Message 524 Bodies", RFC 2045, November 1996. 526 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 527 Requirement Levels", BCP 14, RFC 2119, March 1997. 529 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 530 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 531 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 533 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 534 (SHA1)", RFC 3174, September 2001. 536 [RFC3230] Mogul, J. and A. Van Hoff, "Instance Digests in HTTP", 537 RFC 3230, January 2002. 539 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 540 Resource Identifier (URI): Generic Syntax", STD 66, 541 RFC 3986, January 2005. 543 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 544 Identifiers (IRIs)", RFC 3987, January 2005. 546 [SHS] National Institute of Standards and Technology (NIST), 547 "Secure Hash Standard", FIPS PUB 180-3, October 2008, . 551 [draft-nottingham-http-link-header] 552 Nottingham, M., "Web Linking", 553 draft-nottingham-http-link-header-06 (work in progress), 554 July 2009. 556 10.2. Informative References 558 [draft-bryan-metalink] 559 Bryan, A., Ed., Tsujikawa, T., McNab, N., and P. Poeml, 560 "The Metalink Download Description Format", 561 draft-bryan-metalink-16 (work in progress), August 2009. 563 Appendix A. Acknowledgements and Contributors 565 Thanks to the Metalink community, Mark Handley, Mark Nottingham, 566 Daniel Stenberg, Tatsuhiro Tsujikawa, Peter Poeml, and Matt Domsch. 568 Appendix B. Comparisons to Similar Options (to be removed by RFC Editor 569 before publication) 571 This draft, compared to the Metalink/XML format 572 [draft-bryan-metalink] : 574 o (+) Reuses existing HTTP standards without much new besides a Link 575 Relation Type. It's more of a collection/coordinated feature set. 576 o (?) The existing standards don't seem to be widely implemented. 577 o (+) No XML dependency, unless we use Metalink/XML for partial file 578 checksums. 579 o (+) Existing Metalink/XML clients can be easily converted to 580 support this as well. 581 o (+) Coordination of mirror servers is preferred, but not required. 582 Coordination may be difficult or impossible unless you are in 583 control of all servers on the mirror network. 584 o (---) Requires changes to server software. 585 o (-?) Tied to HTTP, not as generic. FTP/P2P clients won't be 586 using it unless they also support HTTP, unlike Metalink/XML. 587 o (-) Requires server-side support. Metalink/XML can be created by 588 user (or server, but server component/changes not required). 589 o (-) Also, Metalink/XML files are easily mirrored on all servers. 590 Even if usage in that case is not as transparent, it still gives 591 access to users at all mirrors (FTP included) to all download 592 information with no changes needed to the server. 593 o (-) Not portable/archivable/emailable. Metalink/XML is used to 594 import/export transfer queues. Not as easy for search engines to 595 index? 596 o (-) No way to show mirror geographical location (yet). 597 o (-) Not as rich metadata. 598 o (-) Not able to add multiple files to a download queue or create 599 directory structure. 601 draft-ford-http-multi-server compared to this draft : 603 o (+) Plans to define mirrors for whole directories. 604 o (---) Requires changes to server software. 605 o (---) Requires coordination of all mirror servers, which may be 606 difficult or impossible unless you are in control of all servers 607 on the mirror network. 608 o (---) Doesn't tie in p2p. 609 o (-) Defines new headers. Doesn't reuse existing standards. 610 o (-) No way to show mirror/p2p priority or geographical location 611 (yet). 613 Appendix C. Document History (to be removed by RFC Editor before 614 publication) 616 [[ to be removed by the RFC editor before publication as an RFC. ]] 618 Known issues concerning this draft: 619 o Use of Link header to describe Mirrors. Only send a few mirrors 620 with Link header, or only send them if Want-Digest is used? Some 621 organizations have many mirrors. 622 o A way to differentiate between mirrors that have synchronized 623 ETags and those that don't. 624 o Do we want a way to show that whole directories are mirrored, 625 instead of individual files? 626 o Will we use Metalink/XML for partial file checksums? That would 627 add XML dependency to apps for an important feature. 628 o Need an official MIME type for .torrent files or allow 629 "application/x-bittorrent"? 631 -08 : October , 2009. 632 o Clarifications. 634 -07 : September 29, 2009. 635 o Preferred mirror servers. 637 -06 : September 24, 2009. 638 o Add Mismatch Detection, Error Recovery, and Digest Algorithm 639 values. 640 o Remove Content-MD5 and Want-Digest. 642 -05 : September 19, 2009. 643 o ETags, preferably matching the Instance Digests. 645 -04 : September 17, 2009. 646 o Temporarily remove .torrent. 648 -03 : September 16, 2009. 650 o Mention HEAD request, negotiate mirrors if Want-Digest is used. 652 -02 : September 6, 2009. 653 o Content-MD5 for partial file checksums. 655 -01 : September 1, 2009. 656 o Link Relation Type Registration: "duplicate" 658 -00 : August 24, 2009. 659 o Initial draft. 661 Authors' Addresses 663 Anthony Bryan (editor) 664 Metalinker Project 666 Email: anthonybryan@gmail.com 667 URI: http://www.metalinker.org 669 Neil McNab 670 Metalinker Project 672 Email: neil@nabber.org 673 URI: http://www.nabber.org 675 Henrik Nordstrom 677 Email: henrik@henriknordstrom.net 678 URI: http://www.henriknordstrom.net/ 680 Alan Ford 681 Roke Manor Research 682 Old Salisbury Lane 683 Romsey, Hampshire SO51 0ZN 684 UK 686 Phone: +44 1794 833 465 687 Email: alan.ford@roke.co.uk