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