idnits 2.17.1 draft-bryan-metalink-28.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 (February 12, 2010) is 5188 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-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 (==), 12 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: August 16, 2010 6 P. Poeml 7 Novell, Inc. 8 February 12, 2010 10 The Metalink Download Description Format 11 draft-bryan-metalink-28 13 Abstract 15 This document specifies Metalink, an XML-based download description 16 format. Metalink describes download locations (mirrors), 17 cryptographic hashes, and other information. Clients can 18 transparently use this 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 August 16, 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 . . . . . . . . . . . . . . . . . . 8 66 3.1. Text Constructs . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . 31 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 a document format based on Extensible Markup Language 119 (XML) that describes a file or list of files to be downloaded from a 120 server. Metalinks can list a number of files, each with an 121 extensible set of attached metadata. Each listed file can have a 122 description, multiple cryptographic hashes, and a list of Uniform 123 Resource Identifiers (URIs) that it is available from. 125 Often, identical copies of a file are accessible in multiple 126 locations on the Internet over a variety of protocols, such as File 127 Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), and 128 Peer-to-Peer (P2P). In some cases, users are shown a list of these 129 multiple download locations (mirror servers) and must manually select 130 one based on geographical location, priority, or bandwidth. This is 131 done to distribute the load across multiple servers, and to give 132 human users the opportunity to choose a download location that they 133 expect to work best for them. 135 At times, individual servers can be slow, outdated, or unreachable, 136 but this can not be determined until the download has been initiated. 137 This can lead to the user canceling the download and needing to 138 restart it. During downloads, errors in transmission can corrupt the 139 file. There are no easy ways to repair these files. For large 140 downloads this can be especially troublesome. Any of the number of 141 problems that can occur during a download lead to frustration on the 142 part of users, and bandwidth wasted with retransmission. 144 Knowledge about availability of a download on mirror servers can be 145 acquired and maintained by the operators of the origin server, or by 146 a third party. This knowledge, together with cryptographic hashes, 147 digital signatures, and more, can be stored in a machine-readable 148 Metalink file. The Metalink file can transfer this knowledge to the 149 user agent, which can peruse it in automatic ways or present the 150 information to a human user. User agents can fall back to alternate 151 mirrors if the current one has an issue. Thereby, clients are 152 enabled to work their way to a successful download even under adverse 153 circumstances. All this can be done transparently to the human user 154 and the download is much more reliable and efficient. In contrast, a 155 traditional HTTP redirect to one mirror conveys only comparatively 156 minimal information - a referral to a single server, and there is no 157 provision in the HTTP protocol to handle failures. 159 Other features that some clients provide include multi-source 160 downloads, where chunks of a file are downloaded from multiple 161 mirrors (and optionally, Peer-to-Peer) simultaneously, which 162 frequently results in a faster download. Metalinks can leverage 163 HTTP, FTP and Peer-to-Peer protocols together, because regardless 164 over which protocol the Metalink was obtained, it can make a resource 165 accessible through other protocols. If the Metalink was obtained 166 from a trusted source, included verification metadata can solve trust 167 issues when downloading files from replica servers operated by third 168 parties. Metalinks also provide structured information about 169 downloads that can be indexed by search engines. 171 [[ Discussion of this draft should take place on 172 apps-discuss@ietf.org. Past discussion has gone on at the Metalink 173 discussion mailing list located at 174 metalink-discussion@googlegroups.com / 175 http://groups.google.com/group/metalink-discussion . ]] 177 1.1. Examples 179 A brief, Metalink Document that describes a single file: 181 182 183 184 14471447 185 ftp://ftp.example.com/example.ext 186 http://example.com/example.ext 187 188 http://example.com/example.ext.torrent 189 190 191 A more extensive, Metalink Document that describes two files: 193 194 195 2009-05-15T12:23:23Z 196 197 14471447 198 Example 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 Example2 215 1.0 216 en 217 218 Another description for a second file. 219 220 2f548ce50c459a0270e85a7d63b2383c5523... 221 ftp://ftp.example.com/example2.ext 223 http://example.com/example2.ext 225 http://example.com/example2.ext.torrent 227 228 230 1.2. Namespace and Version 232 The XML Namespaces URI [REC-xml-names] for the XML data format 233 described in this specification is: 235 urn:ietf:params:xml:ns:metalink 237 For convenience, this data format may be referred to as "Metalink", 238 which this specification uses internally. 240 1.3. Notational Conventions 242 This specification describes conformance of Metalink Documents. 243 Additionally, it places some requirements on Metalink Processors. 245 This specification uses the namespace prefix "metalink:" for the 246 Namespace URI identified in Section 1.2, above. Note that the choice 247 of namespace prefix is arbitrary and not semantically significant. 249 Metalink is specified using terms from the XML Infoset 250 [REC-xml-infoset]. However, this specification uses a shorthand for 251 two common terms: the phrase "Information Item" is omitted when 252 naming Element Information Items and Attribute Information Items. 253 Therefore, when this specification uses the term "element," it is 254 referring to an Element Information Item in Infoset terms. Likewise, 255 when it uses the term "attribute," it is referring to an Attribute 256 Information Item. 258 Some sections of this specification are illustrated with fragments of 259 a non-normative RELAX NG Compact schema [RELAX-NG]. However, the 260 text of this specification provides the definition of conformance. A 261 complete schema appears in Appendix B. 263 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 264 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 265 document are to be interpreted as described in BCP 14, [RFC2119], as 266 scoped to those conformance targets. 268 2. Metalink Documents 270 This specification describes Metalink Documents. 272 A Metalink Document describes a file or group of files, how to access 273 them, and metadata that identifies them. Its root is the metalink: 274 metalink element. 276 namespace metalink = "urn:ietf:params:xml:ns:metalink" 277 start = metalinkMetalink 279 Metalink Documents are specified in terms of the XML Information Set, 280 serialized as XML 1.0 [REC-xml] and identified with the "application/ 281 metalink4+xml" media type. 283 Metalink Documents MUST be well-formed XML. This specification does 284 not define a Document Type Definition (DTD) for Metalink Documents, 285 and hence does not require them to be valid (in the sense used by 286 XML). 288 Metalink allows the use of Internationalized Resource Identifiers 289 (IRIs), encoded according to [RFC3987]. Every URI [RFC3986] is also 290 an IRI, so a URI may be used wherever below an IRI is named. There 291 is one special consideration: when an IRI that is not also a URI is 292 given for dereferencing, it MUST be mapped to a URI using the steps 293 in Section 3.1 of [RFC3987]. 295 Any element defined by this specification MAY have an xml:lang 296 attribute, whose content indicates the natural language for the 297 element and its descendents. The language context is only 298 significant for elements and attributes declared to be "Language- 299 Sensitive" by this specification. Requirements regarding the content 300 and interpretation of xml:lang are specified in XML 1.0 [REC-xml], 301 Section 2.12. 303 metalinkCommonAttributes = 304 attribute xml:lang { metalinkLanguageTag }?, 305 undefinedAttribute* 307 All leading and trailing whitespace is part of the element content, 308 and MUST NOT be ignored. Consequently, it is disallowed for elements 309 where the defined type does not allow whitespace, such as dates, 310 integers, or IRIs. Some XML-generating implementations erroneously 311 insert white space around values by default, and such implementations 312 will generate invalid Metalink Documents. 314 Metalink Documents that do not follow this specification are invalid 315 and SHOULD NOT be used by Metalink Processors. 317 Metalink is an extensible format. See Section 5 of this document for 318 a full description of how Metalink Documents can be extended. 320 3. Common Metalink Constructs 322 Many Metalink elements share common structures. This section defines 323 those structures and their requirements for convenient reference by 324 the appropriate element definitions. 326 When an element is identified as being a particular kind of 327 construct, it inherits the corresponding requirements from that 328 construct's definition in this section. 330 3.1. Text Constructs 332 A Text construct contains human-readable text, usually short in 333 length. 335 metalinkTextConstruct = 336 metalinkCommonAttributes, 337 text 339 For example, a metalink:description with text content: 341 ... 342 343 A description of the example file for download. 344 345 ... 347 The content of the Text construct MUST NOT contain child elements. 348 Such text is intended to be presented to humans in a readable 349 fashion. Thus, white space could be collapsed (including line 350 breaks) and text could be displayed using typographic techniques such 351 as justification and proportional fonts. 353 3.2. Date Constructs 355 A Date construct is an element whose content MUST conform to the 356 "date-time" production in [RFC3339]. In addition, an uppercase "T" 357 character MUST be used to separate date and time, and an uppercase 358 "Z" character MUST be present in the absence of a numeric time zone 359 offset. 361 metalinkDateConstruct = 362 metalinkCommonAttributes, 363 xsd:dateTime 365 Such date values happen to be compatible with the following 366 specifications: [ISO.8601.1988], [NOTE-datetime-19980827], and 367 [REC-xmlschema-2-20041028]. 369 Example Date constructs: 371 ... 372 2009-05-15T18:30:02Z 373 ... 374 2009-05-15T18:30:02.25Z 375 ... 376 2009-05-15T18:30:02+01:00 377 ... 378 2009-05-15T18:30:02.25+01:00 379 ... 381 4. Metalink Element Definitions 383 4.1. Container Elements 385 4.1.1. The "metalink:metalink" Element 387 The "metalink:metalink" element is the document (i.e., top-level) 388 element of a Metalink Document, acting as a container for metadata 389 and data associated with the listed files. It contains one or more 390 metalink:file child elements which consist of metadata elements. 392 metalinkMetalink = 393 element metalink:metalink { 394 metalinkCommonAttributes, 395 (metalinkFile+ 396 & metalinkGenerator? 397 & metalinkOrigin? 398 & metalinkPublished? 399 & metalinkUpdated? 400 & extensionElement*) 401 } 403 The following child elements are defined by this specification (note 404 that the presence of some of these elements is required): 406 o metalink:metalink elements MUST contain one or more metalink:file 407 elements. 408 o metalink:metalink elements MAY contain exactly one metalink: 409 generator element and MUST NOT contain more than one such element. 410 o metalink:metalink elements SHOULD contain exactly one metalink: 411 origin element and MUST NOT contain more than one such element. 412 o metalink:metalink elements MAY contain exactly one metalink: 413 published element and MUST NOT contain more than one such element. 414 o metalink:metalink elements MAY contain exactly one metalink: 415 updated element and MUST NOT contain more than one such element. 417 4.1.1.1. Providing Textual Content 419 Experience teaches that downloads providing textual content are in 420 general more useful than those that do not. Some applications (one 421 example is full-text indexers) require a minimum amount of text to 422 function reliably and predictably. Metalink publishers should be 423 aware of these issues. It is RECOMMENDED that each metalink:file 424 element contain a non-empty metalink:description element, a non-empty 425 metalink:identity element, a non-empty metalink:version element, and 426 a non-empty metalink:publisher element when these elements are 427 present. However, the absence of metalink:description, metalink: 428 identity, metalink:version, and metalink:publisher is not an error, 429 and Metalink Processors MUST NOT fail to function correctly as a 430 consequence of such an absence. 432 4.1.2. The "metalink:file" Element 434 The "metalink:file" element represents an individual file, acting as 435 a container for metadata and data associated with the file. Each 436 unique file described in a Metalink Document MUST have its own 437 metalink:file element. 439 All metalink:url elements contained in each metalink:file element 440 SHOULD lead to identical files. That is, each metalink:url element 441 should be an alternative location for the same file and each 442 metalink:metaurl element should provide metadata to retrieve the same 443 file in another way, such as a peer to peer network. Refer to 444 Section 4.2.16 and Section 4.2.8 for more information. 446 metalinkFile = 447 element metalink:file { 448 metalinkCommonAttributes, 449 attribute name { text }, 450 (metalinkCopyright? 451 & metalinkDescription? 452 & metalinkHash* 453 & metalinkIdentity? 454 & metalinkLanguage* 455 & metalinkLogo? 456 & metalinkMetaURL* 457 & metalinkURL* 458 & metalinkOS* 459 & metalinkPieces* 460 & metalinkPublisher? 461 & metalinkSignature? 462 & metalinkSize? 463 & metalinkVersion? 464 & extensionElement*) 465 } 467 This specification assigns no significance to the order of metalink: 468 file elements or to the order of metalink:url or metalink:metaurl 469 elements. Significance is determined by the value of the "priority" 470 attribute of the metalink:url or metalink:metaurl elements. 472 The following child elements are defined by this specification (note 473 that it requires the presence of some of these elements): 475 o metalink:file elements MAY contain exactly one metalink:copyright 476 element and MUST NOT contain more than one such element. 477 o metalink:file elements MAY contain exactly one metalink: 478 description element and MUST NOT contain more than one such 479 element. 480 o metalink:file elements MAY contain exactly one metalink:identity 481 element and MUST NOT contain more than one such element. 482 o metalink:file elements MAY contain one or more metalink:hash 483 elements. 484 o metalink:file elements MAY contain one or more metalink:language 485 elements. 486 o metalink:file elements MAY contain exactly one metalink:logo 487 element and MUST NOT contain more than one such element. 488 o metalink:file elements MAY contain one or more metalink:os 489 element. 490 o metalink:file elements MUST contain at least one metalink:url 491 element or at least one metalink:metaurl element. Typically, 492 metalink:file elements contain more than one metalink:url element 493 to provide multiple download sources. 494 o metalink:file elements MAY contain one or more metalink:pieces 495 elements. 496 o metalink:file elements MAY contain exactly one metalink:publisher 497 element and MUST NOT contain more than one such element. 498 o metalink:file elements MAY contain one or more metalink:signature 499 elements. 500 o metalink:file elements SHOULD contain exactly one metalink:size 501 element and MUST NOT contain more than one such element. 502 o metalink:file elements MAY contain exactly one metalink:version 503 element and MUST NOT contain more than one such element. 505 4.1.2.1. The "name" Attribute 507 metalink:file elements MUST have a "name" attribute, which contains 508 the local filename that the downloaded file will be written to. 509 Hence, if a Metalink Document contains multiple metalink:file 510 elements, the value of the "name" attribute MUST be unique for each. 512 Directory information can also be contained in a "path/file" format 513 only, as in: 515 517 In this example, a subdirectory "debian-amd64/sarge/" will be created 518 and a file named "Contents-amd64.gz" will be created inside it. The 519 path MUST NOT contain any directory traversal directives or 520 information. The path MUST be relative. The path MUST NOT begin 521 with a "/", "./" or "../", contain "/../", or end with "/..". 523 4.1.3. The "metalink:pieces" Element 525 The "metalink:pieces" element acts as a container for a list of 526 cryptographic hashes of non-overlapping pieces of the file. The 527 cryptographic hashes MUST be listed in the same order as the 528 corresponding pieces appear in the file, starting at the beginning of 529 the file. 531 metalinkPieces = 532 element metalink:pieces { 533 attribute length { xsd:positiveInteger }, 534 attribute type { text }, 535 metalinkHash+ 536 } 538 4.1.3.1. The "type" Attribute 540 metalink:pieces elements MUST have a "type" attribute. 542 The Internet Assigned Numbers Authority (IANA) registry named "Hash 543 Function Textual Names" defines values for hash types. See 544 Section 7.4 for security implications. 546 4.1.3.2. The "length" Attribute 548 metalink:pieces elements MUST have a "length" attribute, which is a 549 positive integer that describes the length of the pieces of the file 550 in octets. The whole file is divided into non-overlapping pieces of 551 this length, starting from the beginning of the file. That is, every 552 piece MUST be the same size, apart from the last piece which is the 553 remainder. The last piece extends to the end of the file, and 554 therefore MAY be shorter than the other pieces. 556 4.2. Metadata Elements 558 4.2.1. The "metalink:copyright" Element 560 The "metalink:copyright" element is a Text construct that conveys a 561 human-readable copyright for a file. It is Language-Sensitive. 563 metalinkCopyright = 564 element metalink:copyright { 565 metalinkTextConstruct 566 } 568 4.2.2. The "metalink:description" Element 570 The "metalink:description" element is a Text construct that conveys a 571 human-readable file description. It is Language-Sensitive. 573 metalinkDescription = 574 element metalink:description { 575 metalinkTextConstruct 576 } 578 4.2.3. The "metalink:generator" Element 580 The "metalink:generator" element's content identifies the generating 581 agent name and version used to generate a Metalink Document, for 582 debugging and other purposes. 584 metalinkGenerator = 585 element metalink:generator { 586 metalinkTextConstruct 587 } 589 The metalink:generator element's content is defined below in ABNF 590 notation [RFC5234]. 592 token = 1* 593 separators = "(" / ")" / "<" / ">" / "@" 594 / "," / ";" / ":" / "\" / <"> 595 / "/" / "[" / "]" / "?" / "=" 596 / "{" / "}" / SP / HTAB 597 agent = token ["/" agent-version] 598 agent-version = token 600 Examples: 602 ... 603 MirrorBrain/2.11 604 ... 605 MirrorManager/1.2.11 606 ... 607 metalinktools/0.3.6 608 ... 609 MetalinkEditor/1.2.0 610 ... 612 Although any token character MAY appear in an agent-version, this 613 token SHOULD only be used for a version identifier (i.e., successive 614 versions of the same agent SHOULD only differ in the agent-version 615 portion of the agent value). 617 4.2.4. The "metalink:hash" Element 619 The "metalink:hash" element is a Text construct that conveys a 620 cryptographic hash for a file. All hashes are encoded in lowercase 621 hexadecimal format. Hashes are used to verify the integrity of a 622 complete file or portion of a file to determine if the file has been 623 transferred without any errors. 625 metalinkHash = 626 element metalink:hash { 627 attribute type { text }?, 628 text 629 } 631 Metalink Documents MAY contain one or multiples hashes of a complete 632 file. metalink:hash elements with a "type" attribute MUST contain a 633 hash of the complete file. In this example, both SHA-1 and SHA-256 634 hashes of the complete file are included. 636 ... 637 a97fcf6ba9358f8a6f62beee4421863d3e52b080 638 fc87941af7fd7f03e53b34af393f4c14923d74... 639 ... 641 Metalink Documents MAY also contain hashes for individual pieces of a 642 file. metalink:hash elements that are inside a metalink:pieces 643 container element have a hash for that specific piece or chunk of the 644 file, and are of the same hash type as the metalink:pieces element 645 they are contained in. 647 metalink:hash elements without a "type" attribute MUST contain a hash 648 for that specific piece or chunk of the file and MUST be listed in 649 the same order as the corresponding pieces appear in the file, 650 starting at the beginning of the file. The size of the piece is 651 equal to the value of the "length" attribute of the metalink:pieces 652 element, apart from the last piece which is the remainder. See 653 Section 4.1.3.2 for more information on the size of pieces. 655 In this example, SHA-1 and SHA-256 hashes of the complete file are 656 included, along with four SHA-1 piece hashes. 658 ... 659 a97fcf6ba9358f8a6f62beee4421863d3e52b080 660 fc87941af7fd7f03e53b34af393f4c14923d74... 661 662 d96b9a4b92a899c2099b7b31bddb5ca423bb9b30 663 10d68f4b1119014c123da2a0a6baf5c8a6d5ba1e 664 3e84219096435c34e092b17b70a011771c52d87a 665 67183e4c3ab892d3ebe8326b7d79eb62d077f487 666 667 ... 669 4.2.4.1. The "type" Attribute 671 metalink:hash elements MUST have a "type" attribute, if and only if 672 it contains a hash of the complete file. The IANA registry named 673 "Hash Function Textual Names" defines values for hash types. See 674 Section 7.4 for security implications. 676 4.2.5. The "metalink:identity" Element 678 The "metalink:identity" element is a Text construct that conveys a 679 human-readable identity for a file. For example, the identity of 680 Firefox 3.5 would be "Firefox". 682 metalinkIdentity = 683 element metalink:identity { 684 metalinkTextConstruct 685 } 687 4.2.6. The "metalink:language" Element 689 The "metalink:language" element is a Text construct that conveys a 690 code for the language of a file, per [RFC5646]. 692 Multiple metalink:language elements are allowed, for instance, to 693 describe a file such as an binary installation program that provides 694 multiple language options, or a movie with multiple language tracks, 695 or a document in multiple languages. 697 metalinkLanguage = 698 element metalink:language { 699 metalinkTextConstruct 700 } 702 4.2.7. The "metalink:logo" Element 704 The "metalink:logo" element's content is an IRI reference [RFC3987] 705 that identifies an image that provides visual identification for a 706 file. 708 metalinkLogo = 709 element metalink:logo { 710 metalinkCommonAttributes, 711 (metalinkUri) 712 } 714 The image SHOULD have an aspect ratio of one (horizontal) to one 715 (vertical) and SHOULD be suitable for presentation at a small size. 717 4.2.8. The "metalink:metaurl" Element 719 The "metalink:metaurl" element contains the IRI of a metadata file, 720 also known as a metainfo file, about a resource to download. For 721 example, this could be the IRI of a BitTorrent .torrent file, a 722 Metalink Document, or other type of metadata file. Note that the 723 information in the metalink:hash element does not apply to these 724 metadata files, but to the files that are described by them. 726 metalinkMetaURL = 727 element metalink:metaurl { 728 metalinkCommonAttributes, 729 attribute priority { xsd:positiveInteger { 730 maxInclusive = "999999"}}?, 731 attribute mediatype { text }, 732 attribute name { text }?, 733 (metalinkUri) 734 } 736 4.2.8.1. The "priority" Attribute 738 metalink:metaurl elements MAY have a priority attribute. Values MUST 739 be positive integers between 1 and 999999. Lower values indicate a 740 higher priority. metalink:metaurl elements without a priority 741 attribute are considered to have the lowest priority, i.e. 999999. 742 The priority values of metalink:metaurl and metalink:url elements are 743 compared and those with the lowest values, starting with 1, are used 744 first. Multiple metalink:metaurl and metalink:url elements MAY have 745 the same priority, i.e. one BitTorrent .torrent file and three FTP 746 URIs could have priority="1". See also the "priority" attribute of 747 the metalink:url element. 749 4.2.8.2. The "mediatype" Attribute 751 metalink:metaurl elements MUST have a "mediatype" attribute that 752 indicates the Multipurpose Internet Mail Extensions (MIME) media type 753 [RFC4288] of the metadata available at the IRI. In the case of 754 BitTorrent as specified in [BITTORRENT], the value "torrent" is 755 REQUIRED. Types without "/" are reserved. Currently, "torrent" is 756 the only reserved value. 758 Values for this attribute are defined below in ABNF notation 759 [RFC5234]. 761 media-type = (type-name "/" subtype-name) / media-reserved 762 media-reserved = "torrent" 763 type-name = 764 subtype-name = 766 4.2.8.3. The "name" Attribute 768 metalink:metaurl elements MAY have a "name" attribute that indicates 769 a specific file in a BitTorrent .torrent file or a Metalink Document 770 that describes multiple files. 772 Directory information can also be contained in a "path/file" format 773 only, as in: 775 778 In this example, a file named "Contents-amd64.gz" is indicated, in a 779 "debian-amd64/sarge/" subdirectory. The path MUST NOT contain any 780 directory traversal directives or information. The path MUST be 781 relative. The path MUST NOT begin with a "/", "./" or "../", contain 782 "/../", or end with "/..". 784 4.2.9. The "metalink:origin" Element 786 The "metalink:origin" element is an IRI where the Metalink Document 787 was originally published. If the dynamic attribute of metalink: 788 origin is "true", then updated versions of the Metalink can be found 789 at this IRI. 791 metalinkOrigin = 792 element metalink:origin { 793 metalinkCommonAttributes, 794 attribute dynamic { xsd:boolean }?, 795 (metalinkUri) 796 } 798 4.2.9.1. The "dynamic" Attribute 800 The metalink:origin element MAY have a "dynamic" attribute, set to 801 "true" or "false", which tells if a Metalink at the origin IRI will 802 contain dynamic updated information or if it is static and not likely 803 to be updated. 805 4.2.10. The "metalink:os" Element 807 The "metalink:os" element is a Text construct that conveys an 808 Operating System for a file. The IANA registry named "Operating 809 System Names" defines values for OS types. 811 metalinkOS = 812 element metalink:os { 813 metalinkTextConstruct 814 } 816 4.2.11. The "metalink:published" Element 818 The "metalink:published" element is a Date construct indicating an 819 instant in time associated with an event early in the life cycle of 820 the entry. 822 metalinkPublished = 823 element metalink:published { 824 metalinkDateConstruct 825 } 827 Typically, metalink:published will be associated with the initial 828 creation or first availability of the resource. The metalink:updated 829 element is used when a Metalink Document has been updated after 830 initial publication. 832 4.2.12. The "metalink:publisher" Element 834 The "metalink:publisher" element contains a human-readable group or 835 other entity which has published the file described in the Metalink 836 Document and an IRI for more information. 838 metalinkPublisher = 839 element metalink:publisher { 840 metalinkCommonAttributes, 841 attribute name { text }, 842 attribute url { metalinkUri }? 843 } 845 The metalink:publisher element MUST have a "name" attribute that 846 indicates the human-readable name of the publisher. 848 The metalink:publisher element MAY have a "url" attribute whose value 849 MUST be an IRI reference [RFC3987]. 851 4.2.13. The "metalink:signature" Element 853 The "metalink:signature" element is a Text construct that conveys a 854 digital signature for a file described in a Metalink Document. 855 Digital signatures verify that a file is from the entity that has 856 signed it. 858 Support in Metalink Processors for digital signatures included in 859 this element is OPTIONAL. Note that the signing of Metalink 860 Documents, as opposed to a digital signature of a file described in a 861 Metalink Document, is covered in Section 7.1. 863 metalinkSignature = 864 element metalink:signature { 865 attribute mediatype { text }, 866 metalinkTextConstruct 867 } 869 Example with an OpenPGP signature [RFC4880]: 871 872 -----BEGIN PGP SIGNATURE----- 873 Version: GnuPG v1.4.10 (GNU/Linux) 875 iEYEABECAAYFAkrxdXQACgkQeOEcayedXJHqFwCfd1p/HhRf/iDvYhvFbTrQPz+p 876 p3oAoO9lKHoOqOE0EMB3zmMcLoYUrNkg 877 =ggAf 878 -----END PGP SIGNATURE----- 879 881 4.2.13.1. The "mediatype" Attribute 883 metalink:signature elements MUST have a "mediatype" attribute that 884 indicates the MIME media type [RFC4288] of the included digital 885 signature. 887 Values for this attribute are defined below in ABNF notation 888 [RFC5234]. 890 media-type = type-name "/" subtype-name 891 type-name = 892 subtype-name = 894 4.2.14. The "metalink:size" Element 896 The "metalink:size" element indicates the length of the linked 897 content in octets. This is the content length of the representation 898 returned when the IRI is mapped to a URI and dereferenced. Note that 899 the "metalink:size" element MUST override the actual content length 900 of the representation as reported by the underlying protocol, and 901 those that do not match will be discarded by Metalink Processors. 902 This value MUST be a non-negative integer. 904 metalinkSize = 905 element metalink:size { 906 xsd:nonNegativeInteger 907 } 909 4.2.15. The "metalink:updated" Element 911 The "metalink:updated" element is a Date construct indicating the 912 most recent instant in time when a Metalink was modified in a way the 913 publisher considers significant. Therefore, not all modifications 914 necessarily result in a changed metalink:updated value. 916 metalinkUpdated = 917 element metalink:updated { 918 metalinkDateConstruct 919 } 921 Publishers MAY change the value of this element over time. 923 4.2.16. The "metalink:url" Element 925 The "metalink:url" element contains a file IRI. Most metalink:file 926 container elements will contain multiple metalink:url elements, and 927 each one SHOULD be a valid alternative to download the same file. 929 The metalink:url elements SHOULD be resolvable and, if resolvable, 930 SHOULD lead to identical files. 932 Metalink Processors MUST filter out invalid files obtained from 933 "metalink:url" elements by using information in the metalink:size 934 element and metalink:hash elements. 936 metalinkURL = 937 element metalink:url { 938 metalinkCommonAttributes, 939 attribute location { xsd:string { 940 minLength = "2" maxLength="2"} 941 }?, 942 attribute priority { xsd:positiveInteger { 943 maxInclusive = "999999"}}?, 944 (metalinkUri) 945 } 947 4.2.16.1. The "priority" Attribute 949 metalink:url elements MAY have a priority attribute. Values MUST be 950 positive integers between 1 and 999999. Lower values indicate a 951 higher priority. metalink:url elements without a priority attribute 952 are considered to have the lowest priority, i.e. 999999. Multiple 953 metalink:url elements can have the same priority, i.e. ten different 954 mirrors could have priority="1". 956 4.2.16.2. The "location" Attribute 958 metalink:url elements MAY have a "location" attribute, which is a 959 [ISO3166-1] alpha-2 two letter country code for the geographical 960 location of the physical server an IRI is used to access. 962 4.2.17. The "metalink:version" Element 964 The "metalink:version" element is a Text construct that conveys a 965 human-readable version for a file. The version of Firefox 3.5 would 966 be "3.5". 968 metalinkVersion = 969 element metalink:version { 970 metalinkTextConstruct 971 } 973 5. Extending Metalink 975 5.1. Extensions from Non-Metalink Vocabularies 977 This specification describes Metalink's XML markup vocabulary. 978 Markup from other vocabularies ("foreign markup") can be used in a 979 Metalink Document. 981 5.2. Extensions to the Metalink Vocabulary 983 The Metalink namespace is reserved for future forward-compatible 984 revisions of Metalink. Future versions of this specification could 985 add new elements and attributes to the Metalink markup vocabulary. 986 Software written to conform to this version of the specification will 987 not be able to process such markup correctly and, in fact, will not 988 be able to distinguish it from markup error. For the purposes of 989 this discussion, unrecognized markup from the Metalink vocabulary 990 will be considered "foreign markup". 992 5.3. Processing Foreign Markup 994 Metalink Processors that encounter foreign markup in a location that 995 is legal according to this specification MUST ignore such foreign 996 markup, in particular they MUST NOT stop processing or signal an 997 error. It might be the case that the Metalink Processor is able to 998 process the foreign markup correctly and does so. Otherwise, such 999 markup is termed "unknown foreign markup". 1001 When unknown foreign markup is encountered as a child of metalink: 1002 file, metalink:metalink, Metalink Processors MAY bypass the markup 1003 and any textual content and MUST NOT change their behavior as a 1004 result of the markup's presence. 1006 5.4. Extension Elements 1008 Metalink allows foreign markup anywhere in a Metalink document, 1009 except where it is explicitly forbidden. Child elements of metalink: 1010 file and metalink:metalink are considered Metadata elements and are 1011 described below. The role of other foreign markup is undefined by 1012 this specification. 1014 5.4.1. Simple Extension Elements 1016 A Simple Extension element MUST NOT have any attributes or child 1017 elements. The element MAY contain character data or be empty. 1018 Simple Extension elements are not Language-Sensitive. 1020 simpleExtensionElement = 1021 element * - metalink:* { 1022 text 1023 } 1025 The element can be interpreted as a simple property (or name/value 1026 pair) of the parent element that encloses it. The pair consisting of 1027 the namespace-URI of the element and the local name of the element 1028 can be interpreted as the name of the property. The character data 1029 content of the element can be interpreted as the value of the 1030 property. If the element is empty, then the property value can be 1031 interpreted as an empty string. 1033 5.4.2. Structured Extension Elements 1035 The root element of a Structured Extension element MUST have at least 1036 one attribute or child element. It MAY have attributes, it MAY 1037 contain well-formed XML content (including character data), or it MAY 1038 be empty. Structured Extension elements are Language-Sensitive. 1040 structuredExtensionElement = 1041 element * - metalink:* { 1042 (attribute * { text }+, 1043 (text|anyElement)*) 1044 | (attribute * { text }*, 1045 (text?, anyElement+, (text|anyElement)*)) 1046 } 1048 The structure of a Structured Extension element, including the order 1049 of its child elements, could be significant. 1051 This specification does not provide an interpretation of a Structured 1052 Extension element. The syntax of the XML contained in the element 1053 (and an interpretation of how the element relates to its containing 1054 element) is defined by the specification of the Metalink extension. 1056 6. IANA Considerations 1058 6.1. XML Namespace Registration 1060 This document makes use of the XML registry specified in [RFC3688]. 1061 Accordingly, IANA has made the following registration: 1063 Registration request for the Metalink namespace: 1065 URI: urn:ietf:params:xml:ns:metalink 1067 Registrant Contact: See the "Author's Address" section of this 1068 document. 1070 XML: None. Namespace URIs do not represent an XML specification. 1072 6.2. application/metalink4+xml MIME type 1074 A Metalink Document, when serialized as XML 1.0, can be identified 1075 with the following media type: 1077 MIME media type name: application 1078 MIME subtype name: metalink4+xml 1079 Mandatory parameters: None. 1080 Optional parameters: 1081 "charset": This parameter has semantics identical to the charset 1082 parameter of the "application/xml" media type as specified in 1083 [RFC3023]. 1085 Encoding considerations: Identical to those of "application/xml" as 1086 described in [RFC3023], Section 3.2. 1087 Security considerations: As defined in this specification. 1088 In addition, as this media type uses the "+xml" convention, it 1089 shares the same security considerations as described in [RFC3023], 1090 Section 10. 1091 Interoperability considerations: There are no known interoperability 1092 issues. 1093 Published specification: This specification. 1094 Applications that use this media type: No known applications 1095 currently use this media type. 1097 Additional information: 1099 Magic number(s): As specified for "application/xml" in [RFC3023], 1100 Section 3.2. 1101 File extension: .meta4 1102 Fragment identifiers: As specified for "application/xml" in 1103 [RFC3023], Section 5. 1104 Base URI: As specified in [RFC3023], Section 6. 1105 Macintosh File Type code: TEXT 1106 Person and email address to contact for further information: Anthony 1107 Bryan 1108 Intended usage: COMMON 1109 Author/Change controller: IESG 1111 7. Security Considerations 1113 Because Metalink is an XML-based format, existing XML security 1114 mechanisms can be used to secure its content. 1116 Publishers of Metalink Documents may have sound reasons for signing 1117 otherwise-unprotected content. For example, a merchant might 1118 digitally sign a Metalink that lists a file download to verify its 1119 origin. Other merchants may wish to sign and encrypt Metalink 1120 Documents that list digital songs that have been purchased. Of 1121 course, many other examples are conceivable as well. 1123 Publishers are encouraged to offer Metalink documents via 1124 authenticated HTTP under TLS (Transport Layer Security) as specified 1125 in [RFC2818]. The choice of a secure content layer is entirely 1126 possible for content providers. 1128 Publishers are also encouraged to include digital signatures of the 1129 files within the Metalink Documents, if they are available, as 1130 described in Section 4.2.13. 1132 Normally, a publisher is in the best position to know how strong the 1133 protective signing ought to be on their content. Thus, a publisher 1134 can choose weak or strong cryptography, and a Metalink Processor 1135 would normally accept that. There MAY be applications where the 1136 Metalink Processor chooses to reject weak cryptography, but that is 1137 not envisioned as the common use case. 1139 7.1. Digital Signatures 1141 The root of a Metalink Document (i.e., metalink:metalink) or any 1142 metalink:file element MAY have an Enveloped Signature, as described 1143 by XML-Signature and Syntax Processing [REC-xmldsig-core]. 1145 Although signing and verifying signatures are both OPTIONAL, an 1146 implementation that supports either feature SHOULD implement RSA with 1147 a minimum key size of 2048 with SHA-256. 1149 Metalink Processors that support verifying signatures MUST reject 1150 Metalink Documents with invalid signatures. 1152 Metalink Processors MUST NOT reject a Metalink Document containing 1153 such a signature because they are not capable of verifying it; they 1154 MUST continue processing and MAY inform the user of their failure to 1155 validate the signature. 1157 In other words, the presence of an element with the namespace URI 1158 "http://www.w3.org/2000/09/xmldsig#" and a local name of "Signature" 1159 as a child of the document element MUST NOT cause a Metalink 1160 Processor to fail merely because of its presence. 1162 Other elements in a Metalink Document MUST NOT be signed unless their 1163 definitions explicitly specify such a capability. 1165 Section 6.5.1 of [REC-xmldsig-core] requires support for Canonical 1166 XML [REC-xml-c14n]. However, many implementers do not use it because 1167 signed XML documents enclosed in other XML documents have their 1168 signatures broken. Thus, Metalink Processors that verify signed 1169 Metalink Documents MUST be able to canonicalize with the exclusive 1170 XML canonicalization method identified by the URI 1171 "http://www.w3.org/2001/10/xml-exc-c14n#", as specified in Exclusive 1172 XML Canonicalization [REC-xml-exc-c14n]. 1174 Section 4.4.2 of [REC-xmldsig-core] requires support for DSA 1175 signatures and recommends support for RSA signatures. However, 1176 because of the much greater popularity in the market of RSA versus 1177 DSA, Metalink Processors that verify signed Metalink Documents MUST 1178 be able to verify RSA signatures, but do not need be able to verify 1179 DSA signatures. Due to security issues that can arise if the keying 1180 material for message authentication code (MAC) authentication is not 1181 handled properly, Metalink Documents SHOULD NOT use MACs for 1182 signatures. 1184 7.2. URIs and IRIs 1186 Metalink Processors handle URIs and IRIs. See Section 7 of [RFC3986] 1187 and Section 8 of [RFC3987] for security considerations related to 1188 their handling and use. 1190 7.3. Spoofing 1192 There is potential for spoofing attacks where the attacker publishes 1193 Metalink Documents with false information. Malicious publishers 1194 might create Metalink Documents containing inaccurate information 1195 anywhere in the document. Unaware downloaders could be deceived into 1196 downloading a malicious or worthless file. Malicious publishers 1197 could attempt a distributed denial of service attack by inserting 1198 unrelated IRIs into Metalink Documents. 1200 Digital signatures address the issue of spoofing. 1202 7.4. Cryptographic Hashes 1204 Currently, some of the hash types defined in the IANA registry named 1205 "Hash Function Textual Names" are considered insecure. These include 1206 the whole Message Digest family of algorithms which are not suitable 1207 for cryptographically strong verification. Malicious people could 1208 provide files that appear to be identical to another file because of 1209 a collision, i.e. the weak cryptographic hashes of the intended file 1210 and a substituted malicious file could match. 1212 Metalink Generators and Processors MUST support "sha-256" which is 1213 SHA-256, as specified in [FIPS-180-3], and MAY support stronger 1214 hashes. 1216 If a Metalink Document contains hashes, it SHOULD include "sha-256" 1217 which is SHA-256, or stronger. It MAY also include other hashes from 1218 the IANA registry named "Hash Function Textual Names". 1220 8. References 1222 8.1. Normative References 1224 [BITTORRENT] 1225 Cohen, B., "The BitTorrent Protocol Specification", 1226 BITTORRENT 11031, February 2008, 1227 . 1229 [FIPS-180-3] 1230 National Institute of Standards and Technology (NIST), 1231 "Secure Hash Standard (SHS)", FIPS PUB 180-3, 1232 October 2008. 1234 [ISO3166-1] 1235 International Organization for Standardization, "ISO 3166- 1236 1:2006. Codes for the representation of names of 1237 countries and their subdivisions -- Part 1: Country 1238 codes", November 2006. 1240 [REC-xml] Yergeau, F., Paoli, J., Bray, T., Sperberg-McQueen, C., 1241 and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth 1242 Edition)", W3C REC-xml-20081126, November 2008, 1243 . 1245 [REC-xml-c14n] 1246 Boyer, J., "Canonical XML Version 1.0", W3C REC REC-xml- 1247 c14n-20010315, March 2001, 1248 . 1250 [REC-xml-exc-c14n] 1251 Eastlake, D., Boyer, J., and J. Reagle, "Exclusive XML 1252 Canonicalization Version 1.0", W3C REC REC-xml-exc-c14n- 1253 20020718, July 2002, 1254 . 1256 [REC-xml-infoset] 1257 Cowan, J. and R. Tobin, "XML Information Set (Second 1258 Edition)", W3C REC-xml-infoset-20040204, February 2004, 1259 . 1261 [REC-xml-names] 1262 Hollander, D., Bray, T., Tobin, R., and A. Layman, 1263 "Namespaces in XML 1.0 (Third Edition)", W3C REC-xml- 1264 names-20091208, December 2009, 1265 . 1267 [REC-xmldsig-core] 1268 Solo, D., Reagle, J., and D. Eastlake, "XML-Signature 1269 Syntax and Processing (Second Edition)", W3C REC-xmldsig- 1270 core-20080610, June 2008, 1271 . 1273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1274 Requirement Levels", BCP 14, RFC 2119, March 1997. 1276 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1278 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1279 Types", RFC 3023, January 2001. 1281 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1282 Timestamps", RFC 3339, July 2002. 1284 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1285 Resource Identifier (URI): Generic Syntax", STD 66, 1286 RFC 3986, January 2005. 1288 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1289 Identifiers (IRIs)", RFC 3987, January 2005. 1291 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 1292 Registration Procedures", BCP 13, RFC 4288, December 2005. 1294 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1295 Specifications: ABNF", STD 68, January 2008. 1297 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 1298 Languages", BCP 47, RFC 5646, September 2009. 1300 8.2. Informative References 1302 [ISO.8601.1988] 1303 International Organization for Standardization, "Data 1304 elements and interchange formats - Information interchange 1305 - Representation of dates and times", ISO Standard 8601, 1306 June 1988. 1308 [NOTE-datetime-19980827] 1309 Wolf, M. and C. Wicksteed, "Date and Time Formats", 1310 W3C NOTE-datetime-19980827, August 1998, 1311 . 1313 [REC-xmlschema-2-20041028] 1314 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1315 Second Edition", W3C REC-xmlschema-2-20041028, 1316 October 2004, 1317 . 1319 [RELAX-NG] 1320 Clark, J., "RELAX NG Compact Syntax", December 2001, . 1324 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1325 January 2004. 1327 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication 1328 Format", RFC 4287, December 2005. 1330 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 1331 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 1333 Appendix A. Acknowledgements and Contributors 1335 The layout and shape of this document relies heavily on work 1336 pioneered in the Atom Syndication Format as specified in [RFC4287]. 1338 The content and concepts within are a product of the Metalink 1339 community. Key contributors provided early implementations: A. Bram 1340 Neijt, Hampus Wessman, Darius Liktorius, Manuel Subredu, Michael 1341 Burford, Giorgio Maone, Nils Maier, Max Velasques, Manolo Valdes, 1342 Hayden Legendre, Frederick Cheung, Rene Leonhardt, Per Oyvind 1343 Karlsen, Matt Domsch, Yazsoft, KGet developers, Free Download Manager 1344 developers, Orbit developers, Arne Babenhauserheide, Mathias 1345 Berchtold, Xienzhenyu and TheWorld Browser developers, Xi Software, 1346 Agostino Russo, and James Antill. 1348 The Metalink community has dozens of contributors who contributed to 1349 the evolution of Metalink or proposed ideas and wording for this 1350 document, including: 1352 Paul Burkhead, Kristian Weston, Nicolas Alvarez, Urs Wolfer, Bridget 1353 and Ethan Fletcher, Patrick Ruckstuhl, Sebastien Willemijns, Micah 1354 Cowan, Ruben Kerkhof, Danny Ayers, Nick Dominguez, Gary Zellerbach, 1355 James Clark, Daniel Stenberg, John and Sandra Sowder, Salvatore 1356 Musumeci, Steve Eshelman, Lucas Hewett, Ryan Cronin, Dave Winquist, 1357 Bob Denison, Wes Shelton, Kees Cook, Josh Colbert, Steve Kleisath, 1358 Chad Neptune, Nick Carrabba, Chris Carrabba, Erin Solari, Derick 1359 Cordoba, Ryan Alexander, Tom Mainville, Janie Wargo, Jason Hansen, 1360 Tim Bray, Dan Brickley, Markus Hofmann, Dan Connolly, Tim Berners- 1361 Lee, Louis Suarez-Potts, Ross Smith, Jeff Covey, Ed Lee, Shawn 1362 Wilsher, Mike Connor, Johan Svedberg, Dedric Carter, and Debi 1363 Goulding. We also thank the Anthony Family, the Bryan Family, 1364 Juanita Anthony and Zimmy Bryan. 1366 We also thank the following contributors for assistance and review: 1367 Eran Hammer-Lahav, Lisa Dusseault, Mark Nottingham, Peter Saint- 1368 Andre, Julian Reschke, Chris Newman, Ian Macfarlane, Dave Cridland, 1369 Barry Leiba, Uri Blumenthal, Paul Hoffman, Felix Sasaki, Matthias 1370 Fuchs, Mark Baker, Scott Cantor, Brian Carpenter, Alexey Melnikov, 1371 Lars Eggert, Pasi Eronen, Tim Polk, and Dan Romascanu. 1373 Appendix B. RELAX NG Compact Schema 1375 This appendix is informative. 1377 The Relax NG schema explicitly excludes elements in the Metalink 1378 namespace that are not defined in this revision of the specification. 1379 Requirements for Metalink Processors encountering such markup are 1380 given in Sections 5.2 and 5.3. 1382 # -*- rnc -*- 1383 # RELAX NG Compact Syntax Grammar for the 1384 # Metalink Format Specification Version 4 1385 # Based on RFC 4287 schema 1387 namespace local = "" 1388 namespace metalink = "urn:ietf:params:xml:ns:metalink" 1389 namespace xsd = "http://www.w3.org/2001/XMLSchema" 1391 # Common attributes 1393 metalinkCommonAttributes = 1394 attribute xml:lang { metalinkLanguageTag }?, 1395 undefinedAttribute* 1397 # Text Constructs 1399 metalinkTextConstruct = 1400 metalinkCommonAttributes, 1401 text 1403 # Date Construct 1405 metalinkDateConstruct = 1406 metalinkCommonAttributes, 1407 xsd:dateTime 1409 start = metalinkMetalink 1411 metalinkMetalink = 1412 element metalink:metalink { 1413 metalinkCommonAttributes, 1414 (metalinkFile+ 1415 & metalinkGenerator? 1416 & metalinkOrigin? 1417 & metalinkPublished? 1418 & metalinkUpdated? 1419 & extensionElement*) 1420 } 1422 metalinkFile = 1423 element metalink:file { 1424 metalinkCommonAttributes, 1425 attribute name { text }, 1426 (metalinkCopyright? 1427 & metalinkDescription? 1428 & metalinkHash* 1429 & metalinkIdentity? 1430 & metalinkLanguage* 1431 & metalinkLogo? 1432 & metalinkMetaURL* 1433 & metalinkURL* 1434 & metalinkOS* 1435 & metalinkPieces* 1436 & metalinkPublisher? 1437 & metalinkSignature? 1438 & metalinkSize? 1439 & metalinkVersion? 1440 & extensionElement*) 1441 } 1443 metalinkPieces = 1444 element metalink:pieces { 1445 attribute length { xsd:positiveInteger }, 1446 attribute type { text }, 1447 metalinkHash+ 1448 } 1450 metalinkCopyright = 1451 element metalink:copyright { 1452 metalinkTextConstruct 1453 } 1455 metalinkDescription = 1456 element metalink:description { 1457 metalinkTextConstruct 1458 } 1460 metalinkGenerator = 1461 element metalink:generator { 1462 metalinkTextConstruct 1463 } 1465 metalinkHash = 1466 element metalink:hash { 1467 attribute type { text }?, 1468 text 1469 } 1471 metalinkIdentity = 1472 element metalink:identity { 1473 metalinkTextConstruct 1474 } 1476 metalinkLanguage = 1477 element metalink:language { 1478 metalinkTextConstruct 1479 } 1481 metalinkLogo = 1482 element metalink:logo { 1483 metalinkCommonAttributes, 1484 (metalinkUri) 1485 } 1487 metalinkMetaURL = 1488 element metalink:metaurl { 1489 metalinkCommonAttributes, 1490 attribute priority { xsd:positiveInteger { 1491 maxInclusive = "999999"}}?, 1492 attribute mediatype { text }, 1493 attribute name { text }?, 1494 (metalinkUri) 1495 } 1497 metalinkOrigin = 1498 element metalink:origin { 1499 metalinkCommonAttributes, 1500 attribute dynamic { xsd:boolean }?, 1501 (metalinkUri) 1502 } 1504 metalinkOS = 1505 element metalink:os { 1506 metalinkTextConstruct 1507 } 1509 metalinkPublished = 1510 element metalink:published { 1511 metalinkDateConstruct 1512 } 1514 metalinkPublisher = 1515 element metalink:publisher { 1516 metalinkCommonAttributes, 1517 attribute name { text }, 1518 attribute url { metalinkUri }? 1519 } 1521 metalinkSignature = 1522 element metalink:signature { 1523 attribute mediatype { text }, 1524 metalinkTextConstruct 1525 } 1527 metalinkSize = 1528 element metalink:size { 1529 xsd:nonNegativeInteger 1530 } 1532 metalinkUpdated = 1533 element metalink:updated { 1534 metalinkDateConstruct 1535 } 1537 metalinkURL = 1538 element metalink:url { 1539 metalinkCommonAttributes, 1540 attribute location { xsd:string { 1541 minLength = "2" maxLength="2"} 1542 }?, 1543 attribute priority { xsd:positiveInteger { 1544 maxInclusive = "999999"}}?, 1545 (metalinkUri) 1546 } 1548 metalinkVersion = 1549 element metalink:version { 1550 metalinkTextConstruct 1551 } 1553 # As defined in RFC 3066 and compatible with RFC 5646 1554 metalinkLanguageTag = xsd:string { 1555 pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*" 1556 } 1558 # Unconstrained; it's not entirely clear how IRI fit into 1559 # xsd:anyURI so let's not try to constrain it here 1560 metalinkUri = text 1561 # Simple Extension 1563 simpleExtensionElement = 1564 element * - metalink:* { 1565 text 1566 } 1568 # Structured Extension 1570 structuredExtensionElement = 1571 element * - metalink:* { 1572 (attribute * { text }+, 1573 (text|anyElement)*) 1574 | (attribute * { text }*, 1575 (text?, anyElement+, (text|anyElement)*)) 1576 } 1578 # Other Extensibility 1580 extensionElement = 1581 simpleExtensionElement | structuredExtensionElement 1583 undefinedAttribute = 1584 attribute * - (xml:lang | local:*) { text } 1586 undefinedContent = (text|anyForeignElement)* 1588 anyElement = 1589 element * { 1590 (attribute * { text } 1591 | text 1592 | anyElement)* 1593 } 1595 anyForeignElement = 1596 element * - metalink:* { 1597 (attribute * { text } 1598 | text 1599 | anyElement)* 1600 } 1602 # EOF 1604 Appendix C. Document History (to be removed by RFC Editor before 1605 publication) 1607 [[ to be removed by the RFC editor before publication as an RFC. ]] 1608 Updated versions can be found at 1609 http://tools.ietf.org/html/draft-bryan-metalink with frequent updates 1610 in Subversion at 1611 http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ 1613 Known issues concerning this draft: 1614 o Waiting on: MIME type review. 1616 -28 : February xx, 2010. 1617 o Address IESG Comments and Discuss: Tim Polk. 1619 -27 : January 28, 2010. 1620 o Address IESG Comments and Discuss: Pasi Eronen and Dan Romascanu. 1621 o Remove xml:base. 1623 -26 : January 23, 2010. 1624 o Address IESG Comments and Discuss: Alexey Melnikov, Lars Eggert. 1626 -25 : January 11, 2010. 1627 o Julian Reschke XML issues. 1628 o Generator ABNF and reference. Remove license element. 1629 o Update IPR to "trust200902". 1630 o dynamic element changed to dynamic attribute of origin element. 1632 -24 : December 08, 2009. 1633 o Eran Hammer-Lahav, Document Shepherd review changes. 1634 o Example XML indentation. 1635 o Baseline file hash: SHA-256. 1637 -23 : November 26, 2009. 1638 o Lisa Dusseault, Apps Area AD review changes, Change RFC3688 from 1639 Normative to Informative Reference. 1640 o Schema: integer changed to positiveInteger or nonNegativeInteger 1641 where fitting. 1643 -22 : November 09, 2009. 1644 o Clarifications. 1646 -21 : October 13, 2009. 1647 o Update author details. 1649 -20 : October 12, 2009. 1650 o RFC 5646 updates RFC 4646. 1652 -19 : October 5, 2009. 1653 o Remove organization for independent authors. 1655 -18 : October 4, 2009. 1657 o File extension: .meta4 1658 o Hashes clarification, modified to allow multiple metalink:os 1659 elements, add size element to example. 1661 -17 : September 28, 2009. 1662 o Typo correction. 1664 -16 : August 31, 2009. 1665 o Clarifications. 1667 -15 : August 26, 2009. 1668 o Rename "preference" attribute of metaurl and url elements to 1669 "priority", where lower values indicate higher priority. 1671 -14 : August 24, 2009. 1672 o Update abstract and introduction. 1674 -13 : August 21, 2009. 1675 o Remove files, resources, verification container elements. 1676 o MIME type: application/metalink4+xml 1678 -12 : August 18, 2009. 1679 o Remove "piece" attribute from hash elements in pieces container 1680 elements. 1681 o Rename "uri" attribute of license and publisher elements to "url". 1683 -11 : August 08, 2009. 1684 o Renamed type element (static or dynamic values) to dynamic element 1685 (true or false values). 1686 o Removed metadata inheritance and most other elements from files 1687 element. 1689 -10 : July 28, 2009. 1690 o Schema fixes. 1691 o Rename metadata element to metaurl, add name attribute to it 1692 similar to file element's name attribute. 1693 o Update REC-xmldsig-core reference to second edition. 1695 -09 : July 11, 2009. 1696 o Replace ISO639-2 references with RFC 4646. 1697 o Add ISO3166-1. 1699 -08 : July 04, 2009. 1700 o Clarifications. 1701 o Remove "uri" and "version" attributes from generator element. 1703 -07 : June 18, 2009. 1705 o This ID describes the Metalink document format/schema. 1706 o Remove "Client Implementation Considerations" section. 1707 o Expand "Known issues" section of Document History. 1709 -06 : March 3, 2009. 1710 o Add authors and this Document History section. 1712 -05 : January 13, 2009. 1713 o Clarifications. 1715 -04 : December 31, 2008. 1716 o New IPR notice as required by IETF. 1717 o Correct "metalink:pieces" Element text. 1718 o Add hash examples. 1719 o Slim down "Securing Metalink Documents" section. 1720 o Recommend at least SHA-1. 1722 -03 : September 19, 2008. 1723 o New namespace - urn:ietf:params:xml:ns:metalink 1724 o Use the IANA registry named "Operating System Names" to define 1725 values for OS types. 1726 o Add "Client Implementation Considerations" section, which includes 1727 Content Negotiation. 1729 -02 : September 4, 2008. 1730 o Use the IANA registry named "Hash Function Textual Names" for hash 1731 types. 1732 o metadata Element for listing .torrent, .metalink, etc. 1733 o Remove type attribute for url Element. 1735 -01 : August 28, 2008. 1736 o Clarify directory info in name attribute, hash types, add text for 1737 preference attribute. 1739 -00 : August 23, 2008. 1740 o Initial draft; Text largely based on RFC 4287, ideas from Metalink 1741 3.0 specification. 1743 Index 1745 A 1746 ABNF 1747 metalinkGenerator 14 1748 metaurl mediatype 18 1749 signature mediatype 20 1750 application/metalink4+xml Media Type 24 1752 C 1753 copyright XML element 13 1755 D 1756 description XML element 14 1758 F 1759 file XML element 11 1761 G 1762 generator XML element 14 1763 Grammar 1764 metalinkCommonAttributes 8 1765 metalinkCopyright 13 1766 metalinkDateConstruct 9 1767 metalinkDescription 14 1768 metalinkFile 11 1769 metalinkGenerator 14 1770 metalinkHash 15 1771 metalinkIdentity 16 1772 metalinkLanguage 16 1773 metalinkLogo 17 1774 metalinkMetalink 10 1775 metalinkMetaURL 17 1776 metalinkOrigin 18 1777 metalinkOS 19 1778 metalinkPieces 13 1779 metalinkPublished 19 1780 metalinkPublisher 19 1781 metalinkSignature 20 1782 metalinkSize 21 1783 metalinkTextConstruct 9 1784 metalinkUpdated 21 1785 metalinkURL 21 1786 metalinkVersion 22 1787 simpleExtensionElement 23 1788 structuredExtensionElement 24 1790 H 1791 hash XML element 15 1793 I 1794 identity XML element 16 1796 L 1797 language XML element 16 1798 logo XML element 16 1800 M 1801 Media Type 1802 application/metalink4+xml 24 1803 metalink XML element 10 1804 metalinkCommonAttributes grammar production 8 1805 metalinkCopyright grammar production 13 1806 metalinkDateConstruct grammar production 9 1807 metalinkDescription grammar production 14 1808 metalinkFile grammar production 11 1809 metalinkGenerator ABNF 14 1810 metalinkGenerator grammar production 14 1811 metalinkHash grammar production 15 1812 metalinkIdentity grammar production 16 1813 metalinkLanguage grammar production 16 1814 metalinkLogo grammar production 17 1815 metalinkMetalink grammar production 10 1816 metalinkMetaURL grammar production 17 1817 metalinkOrigin grammar production 18 1818 metalinkOS grammar production 19 1819 metalinkPieces grammar production 13 1820 metalinkPublished grammar production 19 1821 metalinkPublisher grammar production 19 1822 metalinkSignature grammar production 20 1823 metalinkSize grammar production 21 1824 metalinkTextConstruct grammar production 9 1825 metalinkUpdated grammar production 21 1826 metalinkURL grammar production 21 1827 metalinkVersion grammar production 22 1828 metaurl mediatype ABNF 18 1829 metaurl XML element 17 1831 O 1832 origin XML element 18 1833 os XML element 19 1835 P 1836 pieces XML element 13 1837 published XML element 19 1838 publisher XML element 19 1840 S 1841 signature mediatype ABNF 20 1842 signature XML element 20 1843 simpleExtensionElement grammar production 23 1844 size XML element 20 1845 structuredExtensionElement grammar production 24 1847 U 1848 updated XML element 21 1849 url XML element 21 1851 V 1852 version XML element 22 1854 X 1855 XML Elements 1856 copyright 13 1857 description 14 1858 file 11 1859 generator 14 1860 hash 15 1861 identity 16 1862 language 16 1863 logo 16 1864 metalink 10 1865 metaurl 17 1866 origin 18 1867 os 19 1868 pieces 13 1869 published 19 1870 publisher 19 1871 signature 20 1872 size 20 1873 updated 21 1874 url 21 1875 version 22 1877 Authors' Addresses 1879 Anthony Bryan 1880 Pompano Beach, FL 1881 USA 1883 Email: anthonybryan@gmail.com 1884 URI: http://www.metalinker.org 1886 Tatsuhiro Tsujikawa 1888 Email: tatsuhiro.t@gmail.com 1889 URI: http://aria2.sourceforge.net 1890 Neil McNab 1892 Email: neil@nabber.org 1893 URI: http://www.nabber.org 1895 Peter Poeml 1896 Novell, Inc. 1898 Email: poeml@mirrorbrain.org 1899 URI: http://www.mirrorbrain.org/