idnits 2.17.1 draft-bryan-metalink-26.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 23, 2010) is 5204 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'BITTORRENT' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'REC-xml' -- Possible downref: Non-RFC (?) normative reference: ref. 'REC-xml-c14n' -- Possible downref: Non-RFC (?) normative reference: ref. 'REC-xml-exc-c14n' -- Possible downref: Non-RFC (?) normative reference: ref. 'REC-xml-infoset' -- Possible downref: Non-RFC (?) normative reference: ref. 'REC-xml-names' -- Possible downref: Non-RFC (?) normative reference: ref. 'REC-xmlbase' -- Possible downref: Non-RFC (?) normative reference: ref. 'REC-xmldsig-core' ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Bryan 3 Internet-Draft T. Tsujikawa 4 Intended status: Standards Track N. McNab 5 Expires: July 27, 2010 6 P. Poeml 7 Novell, Inc. 8 January 23, 2010 10 The Metalink Download Description Format 11 draft-bryan-metalink-26 13 Abstract 15 This document specifies Metalink, an XML-based download description 16 format. Metalink describes download locations (mirrors), checksums, 17 and other information. Clients can transparently use this 18 information to reliably transfer files. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on July 27, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.2. Namespace and Version . . . . . . . . . . . . . . . . . . 6 63 1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 7 64 2. Metalink Documents . . . . . . . . . . . . . . . . . . . . . . 7 65 3. Common Metalink Constructs . . . . . . . . . . . . . . . . . . 9 66 3.1. Text Constructs . . . . . . . . . . . . . . . . . . . . . 9 67 3.2. Date Constructs . . . . . . . . . . . . . . . . . . . . . 9 68 4. Metalink Element Definitions . . . . . . . . . . . . . . . . . 10 69 4.1. Container Elements . . . . . . . . . . . . . . . . . . . . 10 70 4.1.1. The "metalink:metalink" Element . . . . . . . . . . . 10 71 4.1.2. The "metalink:file" Element . . . . . . . . . . . . . 11 72 4.1.3. The "metalink:pieces" Element . . . . . . . . . . . . 13 73 4.2. Metadata Elements . . . . . . . . . . . . . . . . . . . . 13 74 4.2.1. The "metalink:copyright" Element . . . . . . . . . . . 13 75 4.2.2. The "metalink:description" Element . . . . . . . . . . 14 76 4.2.3. The "metalink:generator" Element . . . . . . . . . . . 14 77 4.2.4. The "metalink:hash" Element . . . . . . . . . . . . . 15 78 4.2.5. The "metalink:identity" Element . . . . . . . . . . . 16 79 4.2.6. The "metalink:language" Element . . . . . . . . . . . 16 80 4.2.7. The "metalink:logo" Element . . . . . . . . . . . . . 16 81 4.2.8. The "metalink:metaurl" Element . . . . . . . . . . . . 17 82 4.2.9. The "metalink:origin" Element . . . . . . . . . . . . 18 83 4.2.10. The "metalink:os" Element . . . . . . . . . . . . . . 19 84 4.2.11. The "metalink:published" Element . . . . . . . . . . . 19 85 4.2.12. The "metalink:publisher" Element . . . . . . . . . . . 19 86 4.2.13. The "metalink:signature" Element . . . . . . . . . . . 20 87 4.2.14. The "metalink:size" Element . . . . . . . . . . . . . 20 88 4.2.15. The "metalink:updated" Element . . . . . . . . . . . . 21 89 4.2.16. The "metalink:url" Element . . . . . . . . . . . . . . 21 90 4.2.17. The "metalink:version" Element . . . . . . . . . . . . 22 91 5. Extending Metalink . . . . . . . . . . . . . . . . . . . . . . 22 92 5.1. Extensions from Non-Metalink Vocabularies . . . . . . . . 22 93 5.2. Extensions to the Metalink Vocabulary . . . . . . . . . . 22 94 5.3. Processing Foreign Markup . . . . . . . . . . . . . . . . 23 95 5.4. Extension Elements . . . . . . . . . . . . . . . . . . . . 23 96 5.4.1. Simple Extension Elements . . . . . . . . . . . . . . 23 97 5.4.2. Structured Extension Elements . . . . . . . . . . . . 23 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 99 6.1. XML Namespace Registration . . . . . . . . . . . . . . . . 24 100 6.2. application/metalink4+xml MIME type . . . . . . . . . . . 24 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 102 7.1. Digital Signatures . . . . . . . . . . . . . . . . . . . . 26 103 7.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 26 104 7.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 27 105 7.4. Cryptographic Hashes . . . . . . . . . . . . . . . . . . . 27 106 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 107 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 108 8.2. Informative References . . . . . . . . . . . . . . . . . . 29 109 Appendix A. Acknowledgements and Contributors . . . . . . . . . . 30 110 Appendix B. RELAX NG Compact Schema . . . . . . . . . . . . . . . 30 111 Appendix C. Document History (to be removed by RFC Editor 112 before publication) . . . . . . . . . . . . . . . . . 35 113 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 116 1. Introduction 118 Metalink is an XML-based document format that describes a file or 119 list of files to be downloaded from a server. Metalinks can list a 120 number of files, each with an extensible set of attached metadata. 121 Each listed file can have a description, checksum, and a list of URIs 122 (Uniform Resource Identifiers) that it is available from. 124 Often, identical copies of a file are accessible in multiple 125 locations on the Internet over a variety of protocols (FTP, HTTP, and 126 Peer-to-Peer). In some cases, users are shown a list of these 127 multiple download locations (mirror servers) and must manually select 128 one based on geographical location, priority, or bandwidth. This is 129 done to distribute the load across multiple servers, and to give 130 human users the opportunity to choose a download location that they 131 expect to work best for them. 133 At times, individual servers can be slow, outdated, or unreachable, 134 but this can not be determined until the download has been initiated. 135 This can lead to the user canceling the download and needing to 136 restart it. During downloads, errors in transmission can corrupt the 137 file. There are no easy ways to repair these files. For large 138 downloads this can be especially troublesome. Any of the number of 139 problems that can occur during a download lead to frustration on the 140 part of users, and bandwidth wasted with retransmission. 142 Knowledge about availability of a download on mirror servers can be 143 acquired and maintained by the operators of the origin server, or by 144 a third party. This knowledge, together with checksums, digital 145 signatures, and more can be stored in a machine-readable Metalink 146 file. The Metalink file can transfer this knowledge to the user 147 agent, which can peruse it in automatic ways or present the 148 information to a human user. User agents can fall back to alternate 149 mirrors if the current one has an issue. Thereby, clients are 150 enabled to work their way to a successful download even under adverse 151 circumstances. All this can be done transparently to the human user 152 and the download is much more reliable and efficient. In contrast, a 153 traditional HTTP redirect to one mirror conveys only comparatively 154 minimal information - a referral to a single server, and there is no 155 provision in the HTTP protocol to handle failures. 157 Other features that some clients provide include multi-source 158 downloads, where chunks of a file are downloaded from multiple 159 mirrors (and optionally, Peer-to-Peer) simultaneously, which 160 frequently results in a faster download. Metalinks can leverage 161 HTTP, FTP and Peer-to-Peer protocols together, because regardless 162 over which protocol the Metalink was obtained, it can make a resource 163 accessible through other protocols. If the Metalink was obtained 164 from a trusted source, included verification metadata can solve trust 165 issues when downloading files from replica servers operated by third 166 parties. Metalinks also provide structured information about 167 downloads that can be indexed by search engines. 169 [[ Discussion of this draft should take place on 170 apps-discuss@ietf.org. Past discussion has gone on at the Metalink 171 discussion mailing list located at 172 metalink-discussion@googlegroups.com / 173 http://groups.google.com/group/metalink-discussion . ]] 175 1.1. Examples 177 A brief, Metalink Document that describes a single file: 179 180 181 182 14471447 183 ftp://ftp.example.com/example.ext 184 http://example.com/example.ext 185 186 http://example.com/example.ext.torrent 187 188 189 A more extensive, Metalink Document that describes two files: 191 192 193 2009-05-15T12:23:23Z 194 195 14471447 196 197 Example 198 199 1.0 200 en 201 202 A description of the example file for download. 203 204 f0ad929cd259957e160ea442eb80986b5f01... 205 ftp://ftp.example.com/example.ext 207 http://example.com/example.ext 209 http://example.com/example.ext.torrent 211 212 213 14471447 214 215 Example2 216 217 1.0 218 en 219 220 Another description for a second file. 221 222 2f548ce50c459a0270e85a7d63b2383c5523... 223 ftp://ftp.example.com/example2.ext 225 http://example.com/example2.ext 227 http://example.com/example2.ext.torrent 229 230 232 1.2. Namespace and Version 234 The XML Namespaces URI [REC-xml-names] for the XML data format 235 described in this specification is: 237 urn:ietf:params:xml:ns:metalink 239 For convenience, this data format may be referred to as "Metalink", 240 which this specification uses internally. 242 1.3. Notational Conventions 244 This specification describes conformance of Metalink Documents. 245 Additionally, it places some requirements on Metalink Processors. 247 This specification uses the namespace prefix "metalink:" for the 248 Namespace URI identified in Section 1.2, above. Note that the choice 249 of namespace prefix is arbitrary and not semantically significant. 251 Metalink is specified using terms from the XML Infoset 252 [REC-xml-infoset]. However, this specification uses a shorthand for 253 two common terms: the phrase "Information Item" is omitted when 254 naming Element Information Items and Attribute Information Items. 255 Therefore, when this specification uses the term "element," it is 256 referring to an Element Information Item in Infoset terms. Likewise, 257 when it uses the term "attribute," it is referring to an Attribute 258 Information Item. 260 Some sections of this specification are illustrated with fragments of 261 a non-normative RELAX NG Compact schema [RELAX-NG]. However, the 262 text of this specification provides the definition of conformance. A 263 complete schema appears in Appendix B. 265 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 266 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 267 document are to be interpreted as described in BCP 14, [RFC2119], as 268 scoped to those conformance targets. 270 2. Metalink Documents 272 This specification describes Metalink Documents. 274 A Metalink Document describes a file or group of files, how to access 275 them, and metadata that identifies them. Its root is the metalink: 276 metalink element. 278 namespace metalink = "urn:ietf:params:xml:ns:metalink" 279 start = metalinkMetalink 281 Metalink Documents are specified in terms of the XML Information Set, 282 serialized as XML 1.0 [REC-xml] and identified with the "application/ 283 metalink4+xml" media type. 285 Metalink Documents MUST be well-formed XML. This specification does 286 not define a DTD (Document Type Definition) for Metalink Documents, 287 and hence does not require them to be valid (in the sense used by 288 XML). 290 Metalink allows the use of IRIs (Internationalized Resource 291 Identifiers), encoded according to [RFC3987]. Every URI [RFC3986] is 292 also an IRI, so a URI may be used wherever below an IRI is named. 293 There is one special consideration: when an IRI that is not also a 294 URI is given for dereferencing, it MUST be mapped to a URI using the 295 steps in Section 3.1 of [RFC3987]. 297 Any element defined by this specification MAY have an xml:base 298 attribute [REC-xmlbase]. When xml:base is used in a Metalink 299 Document, it serves the function described in Section 5.1.1 of 300 [RFC3986], establishing the base URI (or IRI) for resolving any 301 relative references found within the effective scope of the xml:base 302 attribute. 304 Any element defined by this specification MAY have an xml:lang 305 attribute, whose content indicates the natural language for the 306 element and its descendents. The language context is only 307 significant for elements and attributes declared to be "Language- 308 Sensitive" by this specification. Requirements regarding the content 309 and interpretation of xml:lang are specified in XML 1.0 [REC-xml], 310 Section 2.12. 312 metalinkCommonAttributes = 313 attribute xml:base { metalinkUri }?, 314 attribute xml:lang { metalinkLanguageTag }?, 315 undefinedAttribute* 317 All leading and trailing whitespace is part of the element content, 318 and MUST NOT be ignored. Consequently, it is disallowed for elements 319 where the defined type does not allow whitespace, such as dates, 320 integers, or IRIs. Some XML-generating implementations erroneously 321 insert white space around values by default, and such implementations 322 will generate invalid Metalink Documents. 324 Metalink Documents that do not follow this specification are invalid 325 and SHOULD NOT be used by Metalink Processors. 327 Metalink is an extensible format. See Section 5 of this document for 328 a full description of how Metalink Documents can be extended. 330 3. Common Metalink Constructs 332 Many Metalink elements share common structures. This section defines 333 those structures and their requirements for convenient reference by 334 the appropriate element definitions. 336 When an element is identified as being a particular kind of 337 construct, it inherits the corresponding requirements from that 338 construct's definition in this section. 340 3.1. Text Constructs 342 A Text construct contains human-readable text, usually short in 343 length. 345 metalinkTextConstruct = 346 metalinkCommonAttributes, 347 text 349 For example, a metalink:description with text content: 351 ... 352 353 A description of the example file for download. 354 355 ... 357 The content of the Text construct MUST NOT contain child elements. 358 Such text is intended to be presented to humans in a readable 359 fashion. Thus, white space could be collapsed (including line 360 breaks) and text could be displayed using typographic techniques such 361 as justification and proportional fonts. 363 3.2. Date Constructs 365 A Date construct is an element whose content MUST conform to the 366 "date-time" production in [RFC3339]. In addition, an uppercase "T" 367 character MUST be used to separate date and time, and an uppercase 368 "Z" character MUST be present in the absence of a numeric time zone 369 offset. 371 metalinkDateConstruct = 372 metalinkCommonAttributes, 373 xsd:dateTime 375 Such date values happen to be compatible with the following 376 specifications: [ISO.8601.1988], [NOTE-datetime-19980827], and 377 [REC-xmlschema-2-20041028]. 379 Example Date constructs: 381 ... 382 2009-05-15T18:30:02Z 383 ... 384 2009-05-15T18:30:02.25Z 385 ... 386 2009-05-15T18:30:02+01:00 387 ... 388 2009-05-15T18:30:02.25+01:00 389 ... 391 4. Metalink Element Definitions 393 4.1. Container Elements 395 4.1.1. The "metalink:metalink" Element 397 The "metalink:metalink" element is the document (i.e., top-level) 398 element of a Metalink Document, acting as a container for metadata 399 and data associated with the listed files. It contains one or more 400 metalink:file child elements which consist of metadata elements. 402 metalinkMetalink = 403 element metalink:metalink { 404 metalinkCommonAttributes, 405 (metalinkFile+ 406 & metalinkGenerator? 407 & metalinkOrigin? 408 & metalinkPublished? 409 & metalinkUpdated? 410 & extensionElement*) 411 } 413 The following child elements are defined by this specification (note 414 that the presence of some of these elements is required): 416 o metalink:metalink elements MUST contain one or more metalink:file 417 elements. 418 o metalink:metalink elements MAY contain exactly one metalink: 419 generator element and MUST NOT contain more than one such element. 420 o metalink:metalink elements SHOULD contain exactly one metalink: 421 origin element and MUST NOT contain more than one such element. 422 o metalink:metalink elements MAY contain exactly one metalink: 423 published element and MUST NOT contain more than one such element. 425 4.1.1.1. Providing Textual Content 427 Experience teaches that downloads providing textual content are in 428 general more useful than those that do not. Some applications (one 429 example is full-text indexers) require a minimum amount of text to 430 function reliably and predictably. Metalink publishers should be 431 aware of these issues. It is RECOMMENDED that each metalink:file 432 element contain a non-empty metalink:description element, a non-empty 433 metalink:identity element, a non-empty metalink:version element, and 434 a non-empty metalink:publisher element when these elements are 435 present. However, the absence of metalink:description, metalink: 436 identity, metalink:version, and metalink:publisher is not an error, 437 and Metalink Processors MUST NOT fail to function correctly as a 438 consequence of such an absence. 440 4.1.2. The "metalink:file" Element 442 The "metalink:file" element represents an individual file, acting as 443 a container for metadata and data associated with the file. Each 444 unique file described in a Metalink Document MUST have its own 445 metalink:file element. 447 All metalink:url elements contained in each metalink:file element 448 SHOULD lead to identical files. That is, each metalink:url element 449 should be an alternative location for the same file and each 450 metalink:metaurl element should provide metadata to retrieve the same 451 file in another way, such as a peer to peer network. 453 metalinkFile = 454 element metalink:file { 455 metalinkCommonAttributes, 456 attribute name { text }, 457 (metalinkCopyright? 458 & metalinkDescription? 459 & metalinkHash* 460 & metalinkIdentity? 461 & metalinkLanguage* 462 & metalinkLogo? 463 & metalinkMetaURL* 464 & metalinkURL* 465 & metalinkOS* 466 & metalinkPieces* 467 & metalinkPublisher? 468 & metalinkSignature? 469 & metalinkSize? 470 & metalinkVersion? 471 & extensionElement*) 472 } 474 This specification assigns no significance to the order of metalink: 475 file elements or to the order of metalink:url or metalink:metaurl 476 elements. Significance is determined by the value of the "priority" 477 attribute of the metalink:url or metalink:metaurl elements. 479 The following child elements are defined by this specification (note 480 that it requires the presence of some of these elements): 482 o metalink:file elements MAY contain exactly one metalink:copyright 483 element and MUST NOT contain more than one such element. 484 o metalink:file elements MAY contain exactly one metalink: 485 description element and MUST NOT contain more than one such 486 element. 487 o metalink:file elements MAY contain exactly one metalink:identity 488 element and MUST NOT contain more than one such element. 489 o metalink:file elements MAY contain one or more metalink:hash 490 elements. 491 o metalink:file elements MAY contain one or more metalink:language 492 element. 493 o metalink:file elements MAY contain exactly one metalink:logo 494 element and MUST NOT contain more than one such element. 495 o metalink:file elements MAY contain one or more metalink:os 496 element. 497 o metalink:file elements MUST contain at least one metalink:url 498 element or at least one metalink:metaurl element. Typically, 499 metalink:file elements contain more than one metalink:url element 500 to provide multiple download sources. 501 o metalink:file elements MAY contain one or more metalink:pieces 502 elements. 503 o metalink:file elements MAY contain exactly one metalink:publisher 504 element and MUST NOT contain more than one such element. 505 o metalink:file elements MAY contain one or more metalink:signature 506 elements. 507 o metalink:file elements SHOULD contain exactly one metalink:size 508 element and MUST NOT contain more than one such element. 509 o metalink:file elements MAY contain exactly one metalink:version 510 element and MUST NOT contain more than one such element. 512 4.1.2.1. The "name" Attribute 514 metalink:file elements MUST have a "name" attribute, which contains 515 the local filename that the downloaded file will be written to. 516 Hence, if a Metalink Document contains multiple metalink:file 517 elements, the value of the "name" attribute MUST be unique for each. 519 Directory information can also be contained in a "path/file" format 520 only, as in: 522 524 In this example, a subdirectory "debian-amd64/sarge/" will be created 525 and a file named "Contents-amd64.gz" will be created inside it. The 526 path MUST NOT contain any directory traversal directives or 527 information. The path MUST be relative. The path MUST NOT begin 528 with a "/", "./" or "../", contain "/../", or end with "/..". 530 4.1.3. The "metalink:pieces" Element 532 The "metalink:pieces" element acts as a container for a list of 533 checksums of non-overlapping pieces of the file. The checksums MUST 534 be listed in the same order as the corresponding pieces appear in the 535 file, starting at the beginning of the file. 537 metalinkPieces = 538 element metalink:pieces { 539 attribute length { xsd:positiveInteger }, 540 attribute type { text }, 541 metalinkHash+ 542 } 544 4.1.3.1. The "type" Attribute 546 metalink:pieces elements MUST have a "type" attribute. 548 The IANA registry named "Hash Function Textual Names" defines values 549 for hash types. See Section 7.4 for security implications. 551 4.1.3.2. The "length" Attribute 553 metalink:pieces elements MUST have a "length" attribute, which is a 554 positive integer that describes the length of the pieces of the file 555 in octets. The whole file is divided into non-overlapping pieces of 556 this length, starting from the beginning of the file. That is, every 557 piece should be the same size, apart from the last piece which is the 558 remainder. The last piece extends to the end of the file, and can 559 therefore be shorter than the other pieces. 561 4.2. Metadata Elements 563 4.2.1. The "metalink:copyright" Element 565 The "metalink:copyright" element is a Text construct that conveys a 566 human-readable copyright for a file. It is Language-Sensitive. 568 metalinkCopyright = 569 element metalink:copyright { 570 metalinkTextConstruct 571 } 573 4.2.2. The "metalink:description" Element 575 The "metalink:description" element is a Text construct that conveys a 576 human-readable file description. It is Language-Sensitive. 578 metalinkDescription = 579 element metalink:description { 580 metalinkTextConstruct 581 } 583 4.2.3. The "metalink:generator" Element 585 The "metalink:generator" element's content identifies the generating 586 agent name and versionused to generate a Metalink Document, for 587 debugging and other purposes. 589 metalinkGenerator = 590 element metalink:generator { 591 metalinkTextConstruct 592 } 594 metalink:generator element's content is defined below in ABNF 595 notation [RFC5234]. 597 token = 1* 598 separators = "(" / ")" / "<" / ">" / "@" 599 / "," / ";" / ":" / "\" / <"> 600 / "/" / "[" / "]" / "?" / "=" 601 / "{" / "}" / SP / HTAB 602 agent = token ["/" agent-version] 603 agent-version = token 605 Examples: 607 ... 608 MirrorBrain/2.11 609 ... 610 MirrorManager/1.2.11 611 ... 612 metalinktools/0.3.6 613 ... 614 MetalinkEditor/1.2.0 615 ... 617 token is of type text. Although any character allowed in text MAY 618 appear in an agent-version, this token SHOULD only be used for a 619 version identifier (i.e., successive versions of the same agent 620 SHOULD only differ in the agent-version portion of the agent value). 622 4.2.4. The "metalink:hash" Element 624 The "metalink:hash" element is a Text construct that conveys a 625 cryptographic hash for a file. All hashes are encoded in lowercase 626 hexadecimal format. Hashes are used to verify the integrity of a 627 complete file or portion of a file to determine if the file has been 628 transferred without any errors. 630 metalinkHash = 631 element metalink:hash { 632 attribute type { text }?, 633 text 634 } 636 Metalink Documents MAY contain one or multiples hashes of a complete 637 file. metalink:hash elements with a "type" attribute MUST contain a 638 hash of the complete file. In this example, both SHA-1 and SHA-256 639 hashes of the complete file are included. 641 ... 642 a97fcf6ba9358f8a6f62beee4421863d3e52b080 643 fc87941af7fd7f03e53b34af393f4c14923d74... 644 ... 646 Metalink Documents MAY also contain hashes for individual pieces of a 647 file. metalink:hash elements that are inside a metalink:pieces 648 container element have a hash for that specific piece or chunk of the 649 file, and are of the same hash type as the metalink:pieces element 650 they are contained in. 652 metalink:hash elements without a "type" attribute MUST contain a hash 653 for that specific piece or chunk of the file and MUST be listed in 654 the same order as the corresponding pieces appear in the file, 655 starting at the beginning of the file. The size of the piece is 656 equal to the value of the "length" attribute of the metalink:pieces 657 element. See Section 4.1.3.2 for more information on the size of 658 pieces. 660 In this example, SHA-1 and SHA-256 hashes of the complete file are 661 included, along with four SHA-1 piece hashes. 663 ... 664 a97fcf6ba9358f8a6f62beee4421863d3e52b080 665 fc87941af7fd7f03e53b34af393f4c14923d74... 666 667 d96b9a4b92a899c2099b7b31bddb5ca423bb9b30 668 10d68f4b1119014c123da2a0a6baf5c8a6d5ba1e 669 3e84219096435c34e092b17b70a011771c52d87a 670 67183e4c3ab892d3ebe8326b7d79eb62d077f487 671 672 ... 674 4.2.4.1. The "type" Attribute 676 metalink:hash elements MUST have a "type" attribute, if and only if 677 it contains a hash of the complete file. The IANA registry named 678 "Hash Function Textual Names" defines values for hash types. See 679 Section 7.4 for security implications. 681 4.2.5. The "metalink:identity" Element 683 The "metalink:identity" element is a Text construct that conveys a 684 human-readable identity for a file. For example, the identity of 685 Firefox 3.5 would be "Firefox". 687 metalinkIdentity = 688 element metalink:identity { 689 metalinkTextConstruct 690 } 692 4.2.6. The "metalink:language" Element 694 The "metalink:language" element is a Text construct that conveys a 695 code for the language of a file, per [RFC5646]. 697 Multiple metalink:language elements are allowed, for instance, to 698 describe a file such as an binary installation program that provides 699 multiple language options, or a movie with multiple language tracks, 700 or a document in multiple languages. 702 metalinkLanguage = 703 element metalink:language { 704 metalinkTextConstruct 705 } 707 4.2.7. The "metalink:logo" Element 709 The "metalink:logo" element's content is an IRI reference [RFC3987] 710 that identifies an image that provides visual identification for a 711 file. 713 metalinkLogo = 714 element metalink:logo { 715 metalinkCommonAttributes, 716 (metalinkUri) 717 } 719 The image SHOULD have an aspect ratio of one (horizontal) to one 720 (vertical) and SHOULD be suitable for presentation at a small size. 722 4.2.8. The "metalink:metaurl" Element 724 The "metalink:metaurl" element contains the IRI of a metadata file, 725 also known as a metainfo file, about a resource to download. For 726 example, this could be the IRI of a BitTorrent .torrent file, a 727 Metalink Document, or other type of metadata file. Note that the 728 information in the metalink:hash element does not apply to these 729 metadata files, but to the files that are described by them. 731 metalinkMetaURL = 732 element metalink:metaurl { 733 metalinkCommonAttributes, 734 attribute priority { xsd:positiveInteger { 735 maxInclusive = "999999"}}?, 736 attribute mediatype { text }, 737 attribute name { text }?, 738 (metalinkUri) 739 } 741 4.2.8.1. The "priority" Attribute 743 metalink:metaurl elements MAY have a priority attribute. Values MUST 744 be positive integers between 1 and 999999. Lower values indicate a 745 higher priority. metalink:metaurl elements without a priority 746 attribute are considered to have the lowest priority, i.e. 999999. 747 The priority values of metalink:metaurl and metalink:url elements are 748 compared and those with the lowest values, starting with 1, are used 749 first. Multiple metalink:metaurl and metalink:url elements MAY have 750 the same priority, i.e. one BitTorrent .torrent file and three FTP 751 URIs could have priority="1". See also the "priority" attribute of 752 the metalink:url element. 754 4.2.8.2. The "mediatype" Attribute 756 metalink:metaurl elements MUST have a "mediatype" attribute that 757 indicates the MIME media type [RFC4288] of the metadata available at 758 the IRI. In the case of BitTorrent as specified in [BITTORRENT], the 759 value "torrent" is REQUIRED. Types without "/" are reserved. 760 Currently, "torrent" is the only reserved value. 762 Values for this attribute are defined below in ABNF notation 763 [RFC5234]. 765 media-type = (type-name "/" subtype-name) / media-reserved 766 media-reserved = "torrent" 767 type-name = 768 subtype-name = 770 4.2.8.3. The "name" Attribute 772 metalink:metaurl elements MAY have a "name" attribute that indicates 773 a specific file in a BitTorrent .torrent file or a Metalink Document 774 that describes multiple files. 776 Directory information can also be contained in a "path/file" format 777 only, as in: 779 782 In this example, a file named "Contents-amd64.gz" is indicated, in a 783 "debian-amd64/sarge/" subdirectory. The path MUST NOT contain any 784 directory traversal directives or information. The path MUST be 785 relative. The path MUST NOT begin with a "/", "./" or "../", contain 786 "/../", or end with "/..". 788 4.2.9. The "metalink:origin" Element 790 The "metalink:origin" element is an IRI where the Metalink Document 791 was originally published. If the dynamic attribute of metalink: 792 origin is "true", then updated versions of the Metalink can be found 793 at this IRI. 795 metalinkOrigin = 796 element metalink:origin { 797 metalinkCommonAttributes, 798 attribute dynamic { xsd:boolean }?, 799 (metalinkUri) 800 } 802 4.2.9.1. The "dynamic" Attribute 804 The metalink:origin element MAY have a "dynamic" attribute, set to 805 "true" or "false", which tells if a Metalink at the origin IRI will 806 contain dynamic updated information or if it is static and not likely 807 to be updated. 809 4.2.10. The "metalink:os" Element 811 The "metalink:os" element is a Text construct that conveys an 812 Operating System for a file. The IANA registry named "Operating 813 System Names" defines values for OS types. 815 metalinkOS = 816 element metalink:os { 817 metalinkTextConstruct 818 } 820 4.2.11. The "metalink:published" Element 822 The "metalink:published" element is a Date construct indicating an 823 instant in time associated with an event early in the life cycle of 824 the entry. 826 metalinkPublished = 827 element metalink:published { 828 metalinkDateConstruct 829 } 831 Typically, metalink:published will be associated with the initial 832 creation or first availability of the resource. The metalink:updated 833 element is used when a Metalink Document has been updated after 834 initial publication. 836 4.2.12. The "metalink:publisher" Element 838 The "metalink:publisher" element contains a human-readable group or 839 other entity which has published the file described in the Metalink 840 Document and a URI for more information. 842 metalinkPublisher = 843 element metalink:publisher { 844 metalinkCommonAttributes, 845 attribute name { text }, 846 attribute url { metalinkUri }? 847 } 849 The metalink:publisher element MUST have a "name" attribute that 850 indicates the human-readable name of the publisher. 852 The metalink:publisher element MAY have a "url" attribute whose value 853 MUST be an IRI reference [RFC3987]. 855 4.2.13. The "metalink:signature" Element 857 The "metalink:signature" element is a Text construct that conveys a 858 digital signature for a file described in a Metalink Document. 859 Digital signatures verify that a file is from the entity that has 860 signed it. 862 Support for digital signatures included in this element is OPTIONAL. 864 metalinkSignature = 865 element metalink:signature { 866 attribute mediatype { text }, 867 metalinkTextConstruct 868 } 870 Example with an OpenPGP signature [RFC4880]: 872 873 -----BEGIN PGP SIGNATURE----- 874 Version: GnuPG v1.4.10 (GNU/Linux) 876 iEYEABECAAYFAkrxdXQACgkQeOEcayedXJHqFwCfd1p/HhRf/iDvYhvFbTrQPz+p 877 p3oAoO9lKHoOqOE0EMB3zmMcLoYUrNkg 878 =ggAf 879 -----END PGP SIGNATURE----- 880 882 4.2.13.1. The "mediatype" Attribute 884 metalink:signature elements MUST have a "mediatype" attribute that 885 indicates the MIME media type [RFC4288] of the included digital 886 signature. 888 Values for this attribute are defined below in ABNF notation 889 [RFC5234]. 891 media-type = type-name "/" subtype-name 892 type-name = 893 subtype-name = 895 4.2.14. The "metalink:size" Element 897 The "metalink:size" element indicates the length of the linked 898 content in octets. This is the content length of the representation 899 returned when the IRI is mapped to a URI and dereferenced. Note that 900 the "metalink:size" element MUST override the actual content length 901 of the representation as reported by the underlying protocol, and 902 those that do not match will be discarded by Metalink Processors. 904 This value MUST be a non-negative integer. 906 metalinkSize = 907 element metalink:size { 908 xsd:nonNegativeInteger 909 } 911 4.2.15. The "metalink:updated" Element 913 The "metalink:updated" element is a Date construct indicating the 914 most recent instant in time when a Metalink was modified in a way the 915 publisher considers significant. Therefore, not all modifications 916 necessarily result in a changed metalink:updated value. 918 metalinkUpdated = 919 element metalink:updated { 920 metalinkDateConstruct 921 } 923 Publishers MAY change the value of this element over time. 925 4.2.16. The "metalink:url" Element 927 The "metalink:url" element contains a file IRI. Most metalink:file 928 container elements will contain multiple metalink:url elements, and 929 each one SHOULD be a valid alternative to download the same file. 931 The metalink:url elements SHOULD be resolvable and, if resolvable, 932 SHOULD lead to identical files. 934 Metalink Processors MUST filter out invalid files obtained from 935 "metalink:url" elements by using information in the metalink:size 936 element and metalink:hash elements. 938 metalinkURL = 939 element metalink:url { 940 metalinkCommonAttributes, 941 attribute location { xsd:string { 942 minLength = "2" maxLength="2"} 943 }?, 944 attribute priority { xsd:positiveInteger { 945 maxInclusive = "999999"}}?, 946 (metalinkUri) 947 } 949 4.2.16.1. The "priority" Attribute 951 metalink:url elements MAY have a priority attribute. Values MUST be 952 positive integers between 1 and 999999. Lower values indicate a 953 higher priority. metalink:url elements without a priority attribute 954 are considered to have the lowest priority, i.e. 999999. Multiple 955 metalink:url elements can have the same priority, i.e. ten mirrors 956 could have priority="1". 958 4.2.16.2. The "location" Attribute 960 metalink:url elements MAY have a "location" attribute, which is a 961 [ISO3166-1] alpha-2 two letter country code for the geographical 962 location of the physical server an IRI is used to access. 964 4.2.17. The "metalink:version" Element 966 The "metalink:version" element is a Text construct that conveys a 967 human-readable version for a file. The version of Firefox 3.5 would 968 be "3.5". 970 metalinkVersion = 971 element metalink:version { 972 metalinkTextConstruct 973 } 975 5. Extending Metalink 977 5.1. Extensions from Non-Metalink Vocabularies 979 This specification describes Metalink's XML markup vocabulary. 980 Markup from other vocabularies ("foreign markup") can be used in a 981 Metalink Document. 983 5.2. Extensions to the Metalink Vocabulary 985 The Metalink namespace is reserved for future forward-compatible 986 revisions of Metalink. Future versions of this specification could 987 add new elements and attributes to the Metalink markup vocabulary. 988 Software written to conform to this version of the specification will 989 not be able to process such markup correctly and, in fact, will not 990 be able to distinguish it from markup error. For the purposes of 991 this discussion, unrecognized markup from the Metalink vocabulary 992 will be considered "foreign markup". 994 5.3. Processing Foreign Markup 996 Metalink Processors that encounter foreign markup in a location that 997 is legal according to this specification MUST NOT stop processing or 998 signal an error. It might be the case that the Metalink Processor is 999 able to process the foreign markup correctly and does so. Otherwise, 1000 such markup is termed "unknown foreign markup". 1002 When unknown foreign markup is encountered as a child of metalink: 1003 file, metalink:metalink, Metalink Processors MAY bypass the markup 1004 and any textual content and MUST NOT change their behavior as a 1005 result of the markup's presence. 1007 When unknown foreign markup is encountered in a Text Construct, 1008 software SHOULD ignore the markup and process any text content of 1009 foreign elements as though the surrounding markup were not present. 1011 5.4. Extension Elements 1013 Metalink allows foreign markup anywhere in a Metalink document, 1014 except where it is explicitly forbidden. Child elements of metalink: 1015 file and metalink:metalink are considered Metadata elements and are 1016 described below. The role of other foreign markup is undefined by 1017 this specification. 1019 5.4.1. Simple Extension Elements 1021 A Simple Extension element MUST NOT have any attributes or child 1022 elements. The element MAY contain character data or be empty. 1023 Simple Extension elements are not Language-Sensitive. 1025 simpleExtensionElement = 1026 element * - metalink:* { 1027 text 1028 } 1030 The element can be interpreted as a simple property (or name/value 1031 pair) of the parent element that encloses it. The pair consisting of 1032 the namespace-URI of the element and the local name of the element 1033 can be interpreted as the name of the property. The character data 1034 content of the element can be interpreted as the value of the 1035 property. If the element is empty, then the property value can be 1036 interpreted as an empty string. 1038 5.4.2. Structured Extension Elements 1040 The root element of a Structured Extension element MUST have at least 1041 one attribute or child element. It MAY have attributes, it MAY 1042 contain well-formed XML content (including character data), or it MAY 1043 be empty. Structured Extension elements are Language-Sensitive. 1045 structuredExtensionElement = 1046 element * - metalink:* { 1047 (attribute * { text }+, 1048 (text|anyElement)*) 1049 | (attribute * { text }*, 1050 (text?, anyElement+, (text|anyElement)*)) 1051 } 1053 The structure of a Structured Extension element, including the order 1054 of its child elements, could be significant. 1056 This specification does not provide an interpretation of a Structured 1057 Extension element. The syntax of the XML contained in the element 1058 (and an interpretation of how the element relates to its containing 1059 element) is defined by the specification of the Metalink extension. 1061 6. IANA Considerations 1063 6.1. XML Namespace Registration 1065 This document makes use of the XML registry specified in [RFC3688]. 1066 Accordingly, IANA has made the following registration: 1068 Registration request for the Metalink namespace: 1070 URI: urn:ietf:params:xml:ns:metalink 1072 Registrant Contact: See the "Author's Address" section of this 1073 document. 1075 XML: None. Namespace URIs do not represent an XML specification. 1077 6.2. application/metalink4+xml MIME type 1079 A Metalink Document, when serialized as XML 1.0, can be identified 1080 with the following media type: 1082 MIME media type name: application 1083 MIME subtype name: metalink4+xml 1084 Mandatory parameters: None. 1086 Optional parameters: 1087 "charset": This parameter has semantics identical to the charset 1088 parameter of the "application/xml" media type as specified in 1089 [RFC3023]. 1090 Encoding considerations: Identical to those of "application/xml" as 1091 described in [RFC3023], Section 3.2. 1092 Security considerations: As defined in this specification. 1093 In addition, as this media type uses the "+xml" convention, it 1094 shares the same security considerations as described in [RFC3023], 1095 Section 10. 1096 Interoperability considerations: There are no known interoperability 1097 issues. 1098 Published specification: This specification. 1099 Applications that use this media type: No known applications 1100 currently use this media type. 1102 Additional information: 1104 Magic number(s): As specified for "application/xml" in [RFC3023], 1105 Section 3.2. 1106 File extension: .meta4 1107 Fragment identifiers: As specified for "application/xml" in 1108 [RFC3023], Section 5. 1109 Base URI: As specified in [RFC3023], Section 6. 1110 Macintosh File Type code: TEXT 1111 Person and email address to contact for further information: Anthony 1112 Bryan 1113 Intended usage: COMMON 1114 Author/Change controller: IESG 1116 7. Security Considerations 1118 Because Metalink is an XML-based format, existing XML security 1119 mechanisms can be used to secure its content. 1121 Producers of Metalink Documents may have sound reasons for signing 1122 otherwise-unprotected content. For example, a merchant might 1123 digitally sign a Metalink that lists a file download to verify its 1124 origin. Other merchants may wish to sign and encrypt Metalink 1125 Documents that list digital songs that have been purchased. Of 1126 course, many other examples are conceivable as well. 1128 Publishers are encouraged to offer Metalink documents via 1129 authenticated HTTP under TLS (Transport Layer Security) as specified 1130 in [RFC2818]. The choice of a secure content layer is entirely 1131 possible for content providers. 1133 Publishers are also encouraged to include digital signatures of the 1134 files within the Metalink Documents, if they are available, as 1135 described in Section 4.2.13. 1137 7.1. Digital Signatures 1139 The root of a Metalink Document (i.e., metalink:metalink) or any 1140 metalink:file element MAY have an Enveloped Signature, as described 1141 by XML-Signature and Syntax Processing [REC-xmldsig-core]. 1143 Metalink Processors MUST NOT reject a Metalink Document containing 1144 such a signature because they are not capable of verifying it; they 1145 MUST continue processing and MAY inform the user of their failure to 1146 validate the signature. 1148 In other words, the presence of an element with the namespace URI 1149 "http://www.w3.org/2000/09/xmldsig#" and a local name of "Signature" 1150 as a child of the document element MUST NOT cause a Metalink 1151 Processor to fail merely because of its presence. 1153 Other elements in a Metalink Document MUST NOT be signed unless their 1154 definitions explicitly specify such a capability. 1156 Section 6.5.1 of [REC-xmldsig-core] requires support for Canonical 1157 XML [REC-xml-c14n]. However, many implementers do not use it because 1158 signed XML documents enclosed in other XML documents have their 1159 signatures broken. Thus, Metalink Processors that verify signed 1160 Metalink Documents MUST be able to canonicalize with the exclusive 1161 XML canonicalization method identified by the URI 1162 "http://www.w3.org/2001/10/xml-exc-c14n#", as specified in Exclusive 1163 XML Canonicalization [REC-xml-exc-c14n]. 1165 Section 4.4.2 of [REC-xmldsig-core] requires support for DSA 1166 signatures and recommends support for RSA signatures. However, 1167 because of the much greater popularity in the market of RSA versus 1168 DSA, Metalink Processors that verify signed Metalink Documents MUST 1169 be able to verify RSA signatures, but do not need be able to verify 1170 DSA signatures. Due to security issues that can arise if the keying 1171 material for message authentication code (MAC) authentication is not 1172 handled properly, Metalink Documents SHOULD NOT use MACs for 1173 signatures. 1175 7.2. URIs and IRIs 1177 Metalink Processors handle URIs and IRIs. See Section 7 of [RFC3986] 1178 and Section 8 of [RFC3987] for security considerations related to 1179 their handling and use. 1181 7.3. Spoofing 1183 There is potential for spoofing attacks where the attacker publishes 1184 Metalink Documents with false information. Malicious publishers 1185 might create Metalink Documents containing inaccurate information 1186 anywhere in the document. Unaware downloaders could be deceived into 1187 downloading a malicious or worthless file. Malicious publishers 1188 could attempt a distributed denial of service attack by inserting 1189 unrelated IRIs into Metalink Documents. 1191 Digital signatures address the issue of spoofing. 1193 7.4. Cryptographic Hashes 1195 Currently, some of the hash types defined in the IANA registry named 1196 "Hash Function Textual Names" are considered insecure. These include 1197 the whole Message Digest family of algorithms which are not suitable 1198 for cryptographically strong verification. Malicious people could 1199 provide files that appear to be identical to another file because of 1200 a collision, i.e. the weak cryptographic hashes of the intended file 1201 and a substituted malicious file could match. 1203 Metalink Generators and Processors MUST support "sha-256" which is 1204 SHA-256, as specified in [FIPS-180-3], and MAY support stronger 1205 hashes. 1207 If a Metalink Document contains hashes, it SHOULD include "sha-256" 1208 which is SHA-256, or stronger. It MAY also include other hashes from 1209 the IANA registry named "Hash Function Textual Names". 1211 8. References 1213 8.1. Normative References 1215 [BITTORRENT] 1216 Cohen, B., "The BitTorrent Protocol Specification", 1217 BITTORRENT 11031, February 2008, 1218 . 1220 [FIPS-180-3] 1221 National Institute of Standards and Technology (NIST), 1222 "Secure Hash Standard (SHS)", FIPS PUB 180-3, 1223 October 2008. 1225 [ISO3166-1] 1226 International Organization for Standardization, "ISO 3166- 1227 1:2006. Codes for the representation of names of 1228 countries and their subdivisions -- Part 1: Country 1229 codes", November 2006. 1231 [REC-xml] Yergeau, F., Paoli, J., Bray, T., Sperberg-McQueen, C., 1232 and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth 1233 Edition)", W3C REC-xml-20081126, November 2008, 1234 . 1236 [REC-xml-c14n] 1237 Boyer, J., "Canonical XML Version 1.0", W3C REC REC-xml- 1238 c14n-20010315, March 2001, 1239 . 1241 [REC-xml-exc-c14n] 1242 Eastlake, D., Boyer, J., and J. Reagle, "Exclusive XML 1243 Canonicalization Version 1.0", W3C REC REC-xml-exc-c14n- 1244 20020718, July 2002, 1245 . 1247 [REC-xml-infoset] 1248 Cowan, J. and R. Tobin, "XML Information Set (Second 1249 Edition)", W3C REC-xml-infoset-20040204, February 2004, 1250 . 1252 [REC-xml-names] 1253 Hollander, D., Bray, T., Tobin, R., and A. Layman, 1254 "Namespaces in XML 1.0 (Third Edition)", W3C REC-xml- 1255 names-20091208, December 2009, 1256 . 1258 [REC-xmlbase] 1259 Marsh, J. and R. Tobin, "XML Base (Second Edition)", 1260 W3C REC-xmlbase-20090128, January 2009, 1261 . 1263 [REC-xmldsig-core] 1264 Solo, D., Reagle, J., and D. Eastlake, "XML-Signature 1265 Syntax and Processing (Second Edition)", W3C REC-xmldsig- 1266 core-20080610, June 2008, 1267 . 1269 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1270 Requirement Levels", BCP 14, RFC 2119, March 1997. 1272 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1274 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1275 Types", RFC 3023, January 2001. 1277 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1278 Timestamps", RFC 3339, July 2002. 1280 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1281 Resource Identifier (URI): Generic Syntax", STD 66, 1282 RFC 3986, January 2005. 1284 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1285 Identifiers (IRIs)", RFC 3987, January 2005. 1287 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1288 Registration Procedures", BCP 13, RFC 4288, December 2005. 1290 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1291 Specifications: ABNF", STD 68, January 2008. 1293 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 1294 Languages", BCP 47, RFC 5646, September 2009. 1296 8.2. Informative References 1298 [ISO.8601.1988] 1299 International Organization for Standardization, "Data 1300 elements and interchange formats - Information interchange 1301 - Representation of dates and times", ISO Standard 8601, 1302 June 1988. 1304 [NOTE-datetime-19980827] 1305 Wolf, M. and C. Wicksteed, "Date and Time Formats", 1306 W3C NOTE-datetime-19980827, August 1998, 1307 . 1309 [REC-xmlschema-2-20041028] 1310 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1311 Second Edition", W3C REC-xmlschema-2-20041028, 1312 October 2004, 1313 . 1315 [RELAX-NG] 1316 Clark, J., "RELAX NG Compact Syntax", December 2001, . 1320 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1321 January 2004. 1323 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication 1324 Format", RFC 4287, December 2005. 1326 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1327 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1329 Appendix A. Acknowledgements and Contributors 1331 The layout and shape of this document relies heavily on work 1332 pioneered in the Atom Syndication Format as specified in [RFC4287]. 1334 The content and concepts within are a product of the Metalink 1335 community. Key contributors provided early implementations: A. Bram 1336 Neijt, Hampus Wessman, Darius Liktorius, Manuel Subredu, Michael 1337 Burford, Giorgio Maone, Nils Maier, Max Velasques, Manolo Valdes, 1338 Hayden Legendre, Frederick Cheung, Rene Leonhardt, Per Oyvind 1339 Karlsen, Matt Domsch, Yazsoft, KGet developers, Free Download Manager 1340 developers, Orbit developers, Arne Babenhauserheide, Mathias 1341 Berchtold, Xienzhenyu and TheWorld Browser developers, Xi Software, 1342 Agostino Russo, and James Antill. 1344 The Metalink community has dozens of contributors who proposed ideas 1345 and wording for this document, or contributed to the evolution of 1346 Metalink, including: 1348 Paul Burkhead, Kristian Weston, Nicolas Alvarez, Urs Wolfer, Bridget 1349 and Ethan Fletcher, Patrick Ruckstuhl, Sebastien Willemijns, Micah 1350 Cowan, Ruben Kerkhof, Danny Ayers, Nick Dominguez, Gary Zellerbach, 1351 James Clark, Daniel Stenberg, John and Sandra Sowder, Salvatore 1352 Musumeci, Steve Eshelman, Lucas Hewett, Ryan Cronin, Dave Winquist, 1353 Bob Denison, Wes Shelton, Kees Cook, Josh Colbert, Steve Kleisath, 1354 Chad Neptune, Nick Carrabba, Chris Carrabba, Erin Solari, Derick 1355 Cordoba, Ryan Alexander, Tom Mainville, Janie Wargo, Jason Hansen, 1356 Tim Bray, Dan Brickley, Markus Hofmann, Dan Connolly, Tim Berners- 1357 Lee, Louis Suarez-Potts, Ross Smith, Jeff Covey, Ed Lee, Shawn 1358 Wilsher, Mike Connor, Johan Svedberg, Dedric Carter, and Debi 1359 Goulding. We also thank the Anthony Family, the Bryan Family, 1360 Juanita Anthony and Zimmy Bryan. 1362 We also thank the following contributors for assistance and review: 1363 Eran Hammer-Lahav, Lisa Dusseault, Mark Nottingham, Peter Saint- 1364 Andre, Julian Reschke, Chris Newman, Ian Macfarlane, Dave Cridland, 1365 Barry Leiba, Uri Blumenthal, Paul Hoffman, Felix Sasaki, Matthias 1366 Fuchs, Mark Baker, Scott Cantor, Brian Carpenter, Alexey Melnikov, 1367 Lars Eggert, Pasi Eronen, Tim Polk, and Dan Romascanu. 1369 Appendix B. RELAX NG Compact Schema 1371 This appendix is informative. 1373 The Relax NG schema explicitly excludes elements in the Metalink 1374 namespace that are not defined in this revision of the specification. 1375 Requirements for Metalink Processors encountering such markup are 1376 given in Sections 5.2 and 5.3. 1378 # -*- rnc -*- 1379 # RELAX NG Compact Syntax Grammar for the 1380 # Metalink Format Specification Version 4 1381 # Based on RFC 4287 schema 1383 namespace local = "" 1384 namespace metalink = "urn:ietf:params:xml:ns:metalink" 1385 namespace xsd = "http://www.w3.org/2001/XMLSchema" 1387 # Common attributes 1389 metalinkCommonAttributes = 1390 attribute xml:base { metalinkUri }?, 1391 attribute xml:lang { metalinkLanguageTag }?, 1392 undefinedAttribute* 1394 # Text Constructs 1396 metalinkTextConstruct = 1397 metalinkCommonAttributes, 1398 text 1400 # Date Construct 1402 metalinkDateConstruct = 1403 metalinkCommonAttributes, 1404 xsd:dateTime 1406 start = metalinkMetalink 1408 metalinkMetalink = 1409 element metalink:metalink { 1410 metalinkCommonAttributes, 1411 (metalinkFile+ 1412 & metalinkGenerator? 1413 & metalinkOrigin? 1414 & metalinkPublished? 1415 & metalinkUpdated? 1416 & extensionElement*) 1417 } 1419 metalinkFile = 1420 element metalink:file { 1421 metalinkCommonAttributes, 1422 attribute name { text }, 1423 (metalinkCopyright? 1424 & metalinkDescription? 1425 & metalinkHash* 1426 & metalinkIdentity? 1427 & metalinkLanguage* 1428 & metalinkLogo? 1429 & metalinkMetaURL* 1430 & metalinkURL* 1431 & metalinkOS* 1432 & metalinkPieces* 1433 & metalinkPublisher? 1434 & metalinkSignature? 1435 & metalinkSize? 1436 & metalinkVersion? 1437 & extensionElement*) 1438 } 1440 metalinkPieces = 1441 element metalink:pieces { 1442 attribute length { xsd:positiveInteger }, 1443 attribute type { text }, 1444 metalinkHash+ 1445 } 1447 metalinkCopyright = 1448 element metalink:copyright { 1449 metalinkTextConstruct 1450 } 1452 metalinkDescription = 1453 element metalink:description { 1454 metalinkTextConstruct 1455 } 1457 metalinkGenerator = 1458 element metalink:generator { 1459 metalinkTextConstruct 1460 } 1462 metalinkHash = 1463 element metalink:hash { 1464 attribute type { text }?, 1465 text 1466 } 1468 metalinkIdentity = 1469 element metalink:identity { 1470 metalinkTextConstruct 1471 } 1473 metalinkLanguage = 1474 element metalink:language { 1475 metalinkTextConstruct 1476 } 1478 metalinkLogo = 1479 element metalink:logo { 1480 metalinkCommonAttributes, 1481 (metalinkUri) 1482 } 1484 metalinkMetaURL = 1485 element metalink:metaurl { 1486 metalinkCommonAttributes, 1487 attribute priority { xsd:positiveInteger { 1488 maxInclusive = "999999"}}?, 1489 attribute mediatype { text }, 1490 attribute name { text }?, 1491 (metalinkUri) 1492 } 1494 metalinkOrigin = 1495 element metalink:origin { 1496 metalinkCommonAttributes, 1497 attribute dynamic { xsd:boolean }?, 1498 (metalinkUri) 1499 } 1501 metalinkOS = 1502 element metalink:os { 1503 metalinkTextConstruct 1504 } 1506 metalinkPublished = 1507 element metalink:published { 1508 metalinkDateConstruct 1509 } 1511 metalinkPublisher = 1512 element metalink:publisher { 1513 metalinkCommonAttributes, 1514 attribute name { text }, 1515 attribute url { metalinkUri }? 1516 } 1518 metalinkSignature = 1519 element metalink:signature { 1520 attribute mediatype { text }, 1521 metalinkTextConstruct 1522 } 1524 metalinkSize = 1525 element metalink:size { 1526 xsd:nonNegativeInteger 1527 } 1529 metalinkUpdated = 1530 element metalink:updated { 1531 metalinkDateConstruct 1532 } 1534 metalinkURL = 1535 element metalink:url { 1536 metalinkCommonAttributes, 1537 attribute location { xsd:string { 1538 minLength = "2" maxLength="2"} 1539 }?, 1540 attribute priority { xsd:positiveInteger { 1541 maxInclusive = "999999"}}?, 1542 (metalinkUri) 1543 } 1545 metalinkVersion = 1546 element metalink:version { 1547 metalinkTextConstruct 1548 } 1550 # As defined in RFC 3066 and compatible with RFC 5646 1551 metalinkLanguageTag = xsd:string { 1552 pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*" 1553 } 1555 # Unconstrained; it's not entirely clear how IRI fit into 1556 # xsd:anyURI so let's not try to constrain it here 1557 metalinkUri = text 1559 # Simple Extension 1561 simpleExtensionElement = 1562 element * - metalink:* { 1563 text 1564 } 1566 # Structured Extension 1568 structuredExtensionElement = 1569 element * - metalink:* { 1570 (attribute * { text }+, 1571 (text|anyElement)*) 1572 | (attribute * { text }*, 1573 (text?, anyElement+, (text|anyElement)*)) 1574 } 1576 # Other Extensibility 1578 extensionElement = 1579 simpleExtensionElement | structuredExtensionElement 1581 undefinedAttribute = 1582 attribute * - (xml:base | xml:lang | local:*) { text } 1584 undefinedContent = (text|anyForeignElement)* 1586 anyElement = 1587 element * { 1588 (attribute * { text } 1589 | text 1590 | anyElement)* 1591 } 1593 anyForeignElement = 1594 element * - metalink:* { 1595 (attribute * { text } 1596 | text 1597 | anyElement)* 1598 } 1600 # EOF 1602 Appendix C. Document History (to be removed by RFC Editor before 1603 publication) 1605 [[ to be removed by the RFC editor before publication as an RFC. ]] 1607 Updated versions can be found at 1608 http://tools.ietf.org/html/draft-bryan-metalink with frequent updates 1609 in Subversion at 1610 http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ 1612 Known issues concerning this draft: 1614 o None. 1616 -26 : January xx, 2010. 1617 o Address IESG Comments and Discuss: Alexey Melnikov. 1619 -25 : January 11, 2010. 1620 o Julian Reschke XML issues. 1621 o Generator ABNF and reference. Remove license element. 1622 o Update IPR to "trust200902". 1623 o dynamic element changed to dynamic attribute of origin element. 1625 -24 : December 08, 2009. 1626 o Document Shepherd review changes. 1627 o Example XML indentation. 1628 o Baseline file hash: SHA-256. 1630 -23 : November 26, 2009. 1631 o Apps Area AD review changes, Change RFC3688 from Normative to 1632 Informative Reference. 1633 o Schema: integer changed to positiveInteger or nonNegativeInteger 1634 where fitting. 1636 -22 : November 09, 2009. 1637 o Clarifications. 1639 -21 : October 13, 2009. 1640 o Update author details. 1642 -20 : October 12, 2009. 1643 o RFC 5646 updates RFC 4646. 1645 -19 : October 5, 2009. 1646 o Remove organization for independent authors. 1648 -18 : October 4, 2009. 1649 o File extension: .meta4 1650 o Hashes clarification, modified to allow multiple metalink:os 1651 elements, add size element to example. 1653 -17 : September 28, 2009. 1654 o Typo correction. 1656 -16 : August 31, 2009. 1657 o Clarifications. 1659 -15 : August 26, 2009. 1661 o Rename "preference" attribute of metaurl and url elements to 1662 "priority", where lower values indicate higher priority. 1664 -14 : August 24, 2009. 1665 o Update abstract and introduction. 1667 -13 : August 21, 2009. 1668 o Remove files, resources, verification container elements. 1669 o MIME type: application/metalink4+xml 1671 -12 : August 18, 2009. 1672 o Remove "piece" attribute from hash elements in pieces container 1673 elements. 1674 o Rename "uri" attribute of license and publisher elements to "url". 1676 -11 : August 08, 2009. 1677 o Renamed type element (static or dynamic values) to dynamic element 1678 (true or false values). 1679 o Removed metadata inheritance and most other elements from files 1680 element. 1682 -10 : July 28, 2009. 1683 o Schema fixes. 1684 o Rename metadata element to metaurl, add name attribute to it 1685 similar to file element's name attribute. 1686 o Update REC-xmldsig-core reference to second edition. 1688 -09 : July 11, 2009. 1689 o Replace ISO639-2 references with RFC 4646. 1690 o Add ISO3166-1. 1692 -08 : July 04, 2009. 1693 o Clarifications. 1694 o Remove "uri" and "version" attributes from generator element. 1696 -07 : June 18, 2009. 1697 o This ID describes the Metalink document format/schema. 1698 o Remove "Client Implementation Considerations" section. 1699 o Expand "Known issues" section of Document History. 1701 -06 : March 3, 2009. 1702 o Add authors and this Document History section. 1704 -05 : January 13, 2009. 1705 o Clarifications. 1707 -04 : December 31, 2008. 1709 o New IPR notice as required by IETF. 1710 o Correct "metalink:pieces" Element text. 1711 o Add hash examples. 1712 o Slim down "Securing Metalink Documents" section. 1713 o Recommend at least SHA-1. 1715 -03 : September 19, 2008. 1716 o New namespace - urn:ietf:params:xml:ns:metalink 1717 o Use the IANA registry named "Operating System Names" to define 1718 values for OS types. 1719 o Add "Client Implementation Considerations" section, which includes 1720 Content Negotiation. 1722 -02 : September 4, 2008. 1723 o Use the IANA registry named "Hash Function Textual Names" for hash 1724 types. 1725 o metadata Element for listing .torrent, .metalink, etc. 1726 o Remove type attribute for url Element. 1728 -01 : August 28, 2008. 1729 o Clarify directory info in name attribute, hash types, add text for 1730 preference attribute. 1732 -00 : August 23, 2008. 1733 o Initial draft; Text largely based on RFC 4287, ideas from Metalink 1734 3.0 specification. 1736 Index 1738 A 1739 ABNF 1740 mediatype 18, 20 1741 metalinkGenerator 14 1742 application/metalink4+xml Media Type 24 1744 C 1745 copyright XML element 13 1747 D 1748 description XML element 14 1750 F 1751 file XML element 11 1753 G 1754 generator XML element 14 1755 Grammar 1756 metalinkCommonAttributes 8 1757 metalinkCopyright 14 1758 metalinkDateConstruct 9 1759 metalinkDescription 14 1760 metalinkFile 11 1761 metalinkGenerator 14 1762 metalinkHash 15 1763 metalinkIdentity 16 1764 metalinkLanguage 16 1765 metalinkLogo 17 1766 metalinkMetalink 10 1767 metalinkOrigin 18 1768 metalinkOS 19 1769 metalinkPieces 13 1770 metalinkPublished 19 1771 metalinkPublisher 19 1772 metalinkSignature 20 1773 metalinkSize 21 1774 metalinkTextConstruct 9 1775 metalinkUpdated 21 1776 metalinkURL 17, 21 1777 metalinkVersion 22 1778 simpleExtensionElement 23 1779 structuredExtensionElement 24 1781 H 1782 hash XML element 15 1784 I 1785 identity XML element 16 1787 L 1788 language XML element 16 1789 logo XML element 16 1791 M 1792 Media Type 1793 application/metalink4+xml 24 1794 mediatype ABNF 18, 20 1795 metadata XML element 17 1796 metalink XML element 10 1797 metalinkCommonAttributes grammar production 8 1798 metalinkCopyright grammar production 14 1799 metalinkDateConstruct grammar production 9 1800 metalinkDescription grammar production 14 1801 metalinkFile grammar production 11 1802 metalinkGenerator ABNF 14 1803 metalinkGenerator grammar production 14 1804 metalinkHash grammar production 15 1805 metalinkIdentity grammar production 16 1806 metalinkLanguage grammar production 16 1807 metalinkLogo grammar production 17 1808 metalinkMetalink grammar production 10 1809 metalinkOrigin grammar production 18 1810 metalinkOS grammar production 19 1811 metalinkPieces grammar production 13 1812 metalinkPublished grammar production 19 1813 metalinkPublisher grammar production 19 1814 metalinkSignature grammar production 20 1815 metalinkSize grammar production 21 1816 metalinkTextConstruct grammar production 9 1817 metalinkUpdated grammar production 21 1818 metalinkURL grammar production 17, 21 1819 metalinkVersion grammar production 22 1821 O 1822 origin XML element 18 1823 os XML element 19 1825 P 1826 pieces XML element 13 1827 published XML element 19 1828 publisher XML element 19 1830 S 1831 signature XML element 20 1832 simpleExtensionElement grammar production 23 1833 size XML element 20 1834 structuredExtensionElement grammar production 24 1836 U 1837 updated XML element 21 1838 url XML element 21 1840 V 1841 version XML element 22 1843 X 1844 XML Elements 1845 copyright 13 1846 description 14 1847 entry 11 1848 generator 14 1849 hash 15 1850 identity 16 1851 language 16 1852 logo 16 1853 metadata 17 1854 metalink 10 1855 origin 18 1856 os 19 1857 pieces 13 1858 published 19 1859 publisher 19 1860 signature 20 1861 size 20 1862 updated 21 1863 url 21 1864 version 22 1866 Authors' Addresses 1868 Anthony Bryan 1869 Pompano Beach, FL 1870 USA 1872 Email: anthonybryan@gmail.com 1873 URI: http://www.metalinker.org 1875 Tatsuhiro Tsujikawa 1877 Email: tatsuhiro.t@gmail.com 1878 URI: http://aria2.sourceforge.net 1880 Neil McNab 1882 Email: neil@nabber.org 1883 URI: http://www.nabber.org 1885 Peter Poeml 1886 Novell, Inc. 1888 Email: poeml@mirrorbrain.org 1889 URI: http://www.mirrorbrain.org/