idnits 2.17.1 draft-bryan-metalink-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1671. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1677. 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 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 (August 23, 2008) is 5724 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: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1320 (Obsoleted by RFC 6150) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Bryan, Ed. 3 Internet-Draft Metalinker Project 4 Intended status: Experimental August 23, 2008 5 Expires: February 24, 2009 7 The Metalink Download Description Format 8 draft-bryan-metalink-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 24, 2009. 35 Abstract 37 This document specifies Metalink Documents, an XML-based download 38 description format. 40 Table of Contents 42 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 43 1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 4 44 1.2. Namespace and Version . . . . . . . . . . . . . . . . . . 5 45 1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 5 46 2. Metalink Documents . . . . . . . . . . . . . . . . . . . . . . 6 47 3. Common Metalink Constructs . . . . . . . . . . . . . . . . . . 7 48 3.1. Text Constructs . . . . . . . . . . . . . . . . . . . . . 7 49 3.1.1. Text . . . . . . . . . . . . . . . . . . . . . . . . . 7 50 3.2. Date Constructs . . . . . . . . . . . . . . . . . . . . . 8 51 4. Metalink Element Definitions . . . . . . . . . . . . . . . . . 8 52 4.1. Container Elements . . . . . . . . . . . . . . . . . . . . 8 53 4.1.1. The "metalink:metalink" Element . . . . . . . . . . . 8 54 4.1.2. The "metalink:files" Element . . . . . . . . . . . . . 9 55 4.1.3. The "metalink:file" Element . . . . . . . . . . . . . 10 56 4.1.4. The "metalink:resources" Element . . . . . . . . . . . 12 57 4.1.5. The "metalink:verification" Element . . . . . . . . . 12 58 4.1.6. The "metalink:pieces" Element . . . . . . . . . . . . 13 59 4.2. Metadata Elements . . . . . . . . . . . . . . . . . . . . 14 60 4.2.1. The "metalink:copyright" Element . . . . . . . . . . . 14 61 4.2.2. The "metalink:description" Element . . . . . . . . . . 14 62 4.2.3. The "metalink:generator" Element . . . . . . . . . . . 14 63 4.2.4. The "metalink:hash" Element . . . . . . . . . . . . . 15 64 4.2.5. The "metalink:identity" Element . . . . . . . . . . . 16 65 4.2.6. The "metalink:language" Element . . . . . . . . . . . 16 66 4.2.7. The "metalink:license" Element . . . . . . . . . . . . 16 67 4.2.8. The "metalink:logo" Element . . . . . . . . . . . . . 17 68 4.2.9. The "metalink:origin" Element . . . . . . . . . . . . 17 69 4.2.10. The "metalink:os" Element . . . . . . . . . . . . . . 17 70 4.2.11. The "metalink:published" Element . . . . . . . . . . . 17 71 4.2.12. The "metalink:publisher" Element . . . . . . . . . . . 18 72 4.2.13. The "metalink:signature" Element . . . . . . . . . . . 18 73 4.2.14. The "metalink:size" Element . . . . . . . . . . . . . 18 74 4.2.15. The "metalink:type" Element . . . . . . . . . . . . . 19 75 4.2.16. The "metalink:updated" Element . . . . . . . . . . . . 19 76 4.2.17. The "metalink:url" Element . . . . . . . . . . . . . . 19 77 4.2.18. The "metalink:version" Element . . . . . . . . . . . . 21 78 5. Securing Metalink Documents . . . . . . . . . . . . . . . . . 21 79 5.1. Digital Signatures . . . . . . . . . . . . . . . . . . . . 21 80 5.2. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 22 81 5.3. Signing and Encrypting . . . . . . . . . . . . . . . . . . 22 82 6. Extending Metalink . . . . . . . . . . . . . . . . . . . . . . 23 83 6.1. Extensions from Non-Metalink Vocabularies . . . . . . . . 23 84 6.2. Extensions to the Metalink Vocabulary . . . . . . . . . . 23 85 6.3. Processing Foreign Markup . . . . . . . . . . . . . . . . 23 86 6.4. Extension Elements . . . . . . . . . . . . . . . . . . . . 23 87 6.4.1. Simple Extension Elements . . . . . . . . . . . . . . 24 88 6.4.2. Structured Extension Elements . . . . . . . . . . . . 24 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 91 8.1. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 8.2. IRIs . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 93 8.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 26 94 8.4. Encryption and Signing . . . . . . . . . . . . . . . . . . 26 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 96 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 97 9.2. Informative References . . . . . . . . . . . . . . . . . . 28 98 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 29 99 Appendix B. RELAX NG Compact Schema . . . . . . . . . . . . . . . 30 100 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 36 102 Intellectual Property and Copyright Statements . . . . . . . . . . 37 104 1. Introduction 106 Metalink is an XML-based document format that describes a file or 107 lists of files to be added to a download queue. Lists are composed 108 of a number of files, each with an extensible set of attached 109 metadata. For example, each file can have a description, checksum, 110 and list of URIs that it is available from. 112 The primary use case that Metalink addresses is the description of 113 downloadable content in a format so download agents can act 114 intelligently and recover from common errors with little or no user 115 interaction necessary. These errors can include multiple servers 116 going down and data corrupted in transmission. 118 1.1. Examples 120 A brief, single file Metalink Document: 122 123 124 125 126 127 ftp://ftp.example.com/example.ext 128 http://example.com/example.ext 129 http://example.com/example.ext.torrent 130 131 132 133 135 A more extensive, single file Metalink Document: 137 138 139 2008-05-15T12:23:23Z 140 141 142 A description of the example file for download. 143 144 145 83b1a04f18d6782cfe0407edadac377f 146 80bc95fd391772fa61c91ed68567f0980bb45fd9 147 148 149 150 ftp://ftp.example.com/example.ext 151 http://example.com/example.ext 152 http://example.com/example.ext.torrent 153 154 155 156 158 1.2. Namespace and Version 160 The XML Namespaces URI [REC-xml-names] for the XML data format 161 described in this specification is: 163 http://www.metalinker.org/ 165 For convenience, this data format may be referred to as "Metalink 166 3.0". This specification uses "Metalink" internally. 168 1.3. Notational Conventions 170 This specification describes conformance of Metalink Documents. 171 Additionally, it places some requirements on Metalink Processors. 173 This specification uses the namespace prefix "metalink:" for the 174 Namespace URI identified in Section 1.2, above. Note that the choice 175 of namespace prefix is arbitrary and not semantically significant. 177 Metalink is specified using terms from the XML Infoset 178 [REC-xml-infoset]. However, this specification uses a shorthand for 179 two common terms: the phrase "Information Item" is omitted when 180 naming Element Information Items and Attribute Information Items. 181 Therefore, when this specification uses the term "element," it is 182 referring to an Element Information Item in Infoset terms. Likewise, 183 when it uses the term "attribute," it is referring to an Attribute 184 Information Item. 186 Some sections of this specification are illustrated with fragments of 187 a non-normative RELAX NG Compact schema [RELAX-NG]. However, the 188 text of this specification provides the definition of conformance. A 189 complete schema appears in Appendix B. 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in BCP 14, [RFC2119], as 194 scoped to those conformance targets. 196 2. Metalink Documents 198 This specification describes Metalink Documents. 200 A Metalink Document describes a file or group of files, how to access 201 them, and metadata that identifies them. Its root is the metalink: 202 metalink element. 204 namespace metalink = "http://www.metalinker.org" 205 start = metalinkMetalink 207 Metalink Documents are specified in terms of the XML Information Set, 208 serialized as XML 1.0 [REC-xml] and identified with the "application/ 209 metalink+xml" media type. Metalink Documents MUST be well-formed 210 XML. This specification does not define a DTD for Metalink 211 Documents, and hence does not require them to be valid (in the sense 212 used by XML). 214 Metalink allows the use of IRIs [RFC3987]. Every URI [RFC3986] is 215 also an IRI, so a URI may be used wherever below an IRI is named. 216 There is one special consideration: when an IRI that is not also a 217 URI is given for dereferencing, it MUST be mapped to a URI using the 218 steps in Section 3.1 of [RFC3987]. 220 Any element defined by this specification MAY have an xml:base 221 attribute [REC-xmlbase]. When xml:base is used in an Metalink 222 Document, it serves the function described in Section 5.1.1 of 223 [RFC3986], establishing the base URI (or IRI) for resolving any 224 relative references found within the effective scope of the xml:base 225 attribute. 227 Any element defined by this specification MAY have an xml:lang 228 attribute, whose content indicates the natural language for the 229 element and its descendents. The language context is only 230 significant for elements and attributes declared to be "Language- 231 Sensitive" by this specification. Requirements regarding the content 232 and interpretation of xml:lang are specified in XML 1.0 [REC-xml], 233 Section 2.12. 235 metalinkCommonAttributes = 236 attribute xml:base { metalinkUri }?, 237 attribute xml:lang { metalinkLanguageTag }?, 238 undefinedAttribute* 240 Metalink is an extensible format. See Section 6 of this document for 241 a full description of how Metalink Documents can be extended. 243 3. Common Metalink Constructs 245 Many of Metalink's elements share a few common structures. This 246 section defines those structures and their requirements for 247 convenient reference by the appropriate element definitions. 249 When an element is identified as being a particular kind of 250 construct, it inherits the corresponding requirements from that 251 construct's definition in this section. 253 Note that there MUST NOT be any white space in a Date construct or in 254 any IRI. Some XML-emitting implementations erroneously insert white 255 space around values by default, and such implementations will emit 256 invalid Metalink Documents. 258 3.1. Text Constructs 260 A Text construct contains human-readable text, usually in small 261 quantities. The content of Text constructs is Language-Sensitive. 263 metalinkTextConstruct = 264 metalinkCommonAttributes, 265 text 267 3.1.1. Text 269 Example metalink:description with text content: 271 ... 272 273 A description of the example file for download. 274 275 ... 277 The content of the Text construct MUST NOT contain child elements. 278 Such text is intended to be presented to humans in a readable 279 fashion. Thus, Metalink Processors MAY collapse white space 280 (including line breaks) and display the text using typographic 281 techniques such as justification and proportional fonts. 283 3.2. Date Constructs 285 A Date construct is an element whose content MUST conform to the 286 "date-time" production in [RFC3339]. In addition, an uppercase "T" 287 character MUST be used to separate date and time, and an uppercase 288 "Z" character MUST be present in the absence of a numeric time zone 289 offset. 291 metalinkDateConstruct = 292 metalinkCommonAttributes, 293 xsd:dateTime 295 Such date values happen to be compatible with the following 296 specifications: [ISO.8601.1988], [W3C.NOTE-datetime-19980827], and 297 [W3C.REC-xmlschema-2-20041028]. 299 Example Date constructs: 301 2008-12-13T18:30:02Z 302 2008-12-13T18:30:02.25Z 303 2008-12-13T18:30:02+01:00 304 2008-12-13T18:30:02.25+01:00 306 Date values SHOULD be as accurate as possible. For example, it would 307 be generally inappropriate for a publishing system to apply the same 308 timestamp to several entries that were published during the course of 309 a single day. 311 4. Metalink Element Definitions 313 4.1. Container Elements 315 4.1.1. The "metalink:metalink" Element 317 The "metalink:metalink" element is the document (i.e., top-level) 318 element of a Metalink Document, acting as a container for metadata 319 and data associated with the listed files. It contains one 320 "metalink:files" element whose element children consist of metadata 321 elements followed by one or more metalink:file child elements. 323 metalinkMetalink = 324 element metalink:metalink { 325 metalinkCommonAttributes, 326 (metalinkPublished? 327 & metalinkOrigin? 328 & metalinkGenerator? 329 & metalinkUpdated? 330 & extensionElement*), 331 metalinkFiles 332 } 334 The following child elements are defined by this specification (note 335 that the presence of some of these elements is required): 337 o metalink:metalink elements MUST contain exactly one metalink:files 338 element. 339 o metalink:metalink elements MAY contain exactly one metalink:origin 340 element. If metalink:type is "dynamic", metalink:metalink 341 elements MUST contain exactly one metalink:origin element. 342 o metalink:metalink elements MAY contain exactly one metalink:type 343 element. 344 o metalink:metalink elements MAY contain exactly one metalink: 345 generator element. 346 o metalink:metalink elements MAY contain exactly one metalink: 347 published element. 348 o metalink:metalink elements MAY contain exactly one metalink: 349 updated element. If metalink:type is "dynamic", metalink:metalink 350 elements MUST contain exactly one metalink:updated element. 352 4.1.1.1. Providing Textual Content 354 Experience teaches that downloads providing textual content are in 355 general more useful than those that do not. Some applications (one 356 example is full-text indexers) require a minimum amount of text to 357 function reliably and predictably. Metalink publishers should be 358 aware of these issues. It is advisable that each metalink:file 359 element contain a non-empty metalink:description element, a non-empty 360 metalink:identity element when that element is present, and a non- 361 empty metalink:version element, and a non-empty metalink:publisher 362 element. However, the absence of metalink:description is not an 363 error, and Metalink Processors MUST NOT fail to function correctly as 364 a consequence of such an absence. 366 4.1.2. The "metalink:files" Element 368 The "metalink:files" element acts as a container for metadata and 369 data associated with the listed files. It contains one or more 370 metalink:file child elements. Certain elements can be listed either 371 under metalink:files or metalink:file. If under metalink:files, they 372 apply to all files listed in each metalink:file. If under metalink: 373 file, then they apply to just that specific file. 375 metalinkFiles = 376 element metalink:files { 377 metalinkCommonAttributes, 378 (metalinkIdentity? 379 & metalinkVersion? 380 & metalinkDescription? 381 & metalinkOS? 382 & metalinkLogo? 383 & metalinkLanguage? 384 & metalinkPublisher? 385 & metalinkCopyright? 386 & metalinkLicense? 387 & extensionElement*) 388 metalinkFile 389 } 391 The following child elements are defined by this specification (note 392 that the presence of some of these elements is required): 394 o metalink:files element MUST contain one or more metalink:file 395 elements. 396 o metalink:files elements SHOULD contain exactly one metalink: 397 identity element. 398 o metalink:files elements SHOULD contain exactly one metalink: 399 version element. 400 o metalink:files elements MAY contain exactly one metalink: 401 description element. 402 o metalink:files elements MAY contain exactly one metalink:os 403 element. 404 o metalink:files elements MAY contain exactly one metalink:logo 405 element. 406 o metalink:files elements MAY contain exactly one metalink:language 407 element. 408 o metalink:files elements MAY contain exactly one metalink:publisher 409 element. 410 o metalink:files elements MAY contain exactly one metalink:copyright 411 element. 412 o metalink:files elements MAY contain exactly one metalink:license 413 element. 415 4.1.3. The "metalink:file" Element 417 The "metalink:file" element represents an individual file, acting as 418 a container for metadata and data associated with the file. 420 metalinkFile = 421 element metalink:file { 422 metalinkCommonAttributes, 423 attribute name { metalinkTextConstruct }, 424 (metalinkVerification? 425 & metalinkIdentity? 426 & metalinkVersion? 427 & metalinkDescription? 428 & metalinkSize? 429 & metalinkOS? 430 & metalinkLogo? 431 & metalinkLanguage? 432 & metalinkPublisher? 433 & metalinkCopyright? 434 & metalinkLicense? 435 & extensionElement*) 436 metalinkResources 437 } 439 This specification assigns no significance to the order of metalink: 440 file elements. 442 The following child elements are defined by this specification (note 443 that it requires the presence of some of these elements): 445 o metalink:file elements MUST contain exactly one metalink:resources 446 element. 447 o metalink:file elements SHOULD contain exactly one metalink: 448 verification element. 449 o metalink:file elements SHOULD contain exactly one metalink: 450 identity element. 451 o metalink:file elements SHOULD contain exactly one metalink:version 452 element. 453 o metalink:file elements MAY contain exactly one metalink: 454 description element. 455 o metalink:file elements SHOULD contain exactly one metalink:size 456 element. 457 o metalink:file elements MAY contain exactly one metalink:os 458 element. 459 o metalink:file elements MAY contain exactly one metalink:logo 460 element. 461 o metalink:file elements MAY contain exactly one metalink:language 462 element. 463 o metalink:file elements MAY contain exactly one metalink:publisher 464 element. 465 o metalink:file elements MAY contain exactly one metalink:copyright 466 element. 468 o metalink:file elements MAY contain exactly one metalink:license 469 element. 471 4.1.3.1. The "name" Attribute 473 metalink:file elements MUST have a "name" attribute, which contains 474 the filename of the file downloaded. 476 Directory information can also be contained in a "path/file" format 477 only, as in: 479 481 In this example, a subdirectory debian-amd64/sarge/ will be created 482 and a file named Contents-amd64.gz will be created inside it. Only 483 relative paths are allowed. Metalink Processors MUST NOT allow 484 directory traversal. 486 4.1.4. The "metalink:resources" Element 488 The "metalink:resources" element acts as a container for metadata and 489 data associated with the listed files. It contains one or more 490 metalink:url child elements. 492 metalinkResources = 493 element metalink:resources { 494 metalinkCommonAttributes, 495 extensionElement* 496 metalinkURL* 497 } 499 This specification assigns no significance to the order of metalink: 500 url elements. 502 The following child elements are defined by this specification (note 503 that the presence of some of these elements is required): 505 o metalink:resources element MUST contain one and SHOULD contain 506 more than one metalink:url elements. 508 4.1.5. The "metalink:verification" Element 510 The "metalink:verification" element acts as a container for metadata 511 and data associated with verifying the listed files. This 512 information is in the form of checksums and digital signatures. 513 Checksums are used to verify the integrity of a file or portion of a 514 file to determine if the files have been transferred without any 515 errors. Digital signatures verify that a file is from the entity 516 that has signed it. 518 metalinkVerification = 519 element metalink:verification { 520 metalinkCommonAttributes, 521 (metalinkHash* 522 & metalinkPieces* 523 & metalinkSignature 524 & extensionElement*) 525 } 527 The following child elements are defined by this specification (note 528 that the presence of some of these elements is required): 530 o metalink:verification element MAY contain one or more metalink: 531 hash elements. 532 o metalink:verification element MAY contain one or more metalink: 533 pieces elements. 534 o metalink:verification element MAY contain exactly one metalink: 535 signature elements. 537 4.1.6. The "metalink:pieces" Element 539 The "metalink:pieces" element is a Text construct that conveys a 540 human-readable piece information for a file. 542 metalinkPieces = 543 element metalink:pieces { 544 attribute length { metalinkTextConstruct }, 545 attribute type { "crc32" | "md4" | "md5" | "sha1" | 546 "sha256" | "sha384" | "sha512" | "rmd160" | "tiger" }, 547 hash+ 548 }+, 550 4.1.6.1. The "type" Attribute 552 metalink:pieces elements MUST have a "type" attribute. 554 This document defines nine initial values for hash types: 555 1. The value "crc32" signifies that the information is CRC32. 556 2. The value "md4" signifies that the hash information is MD4, as 557 specified in [RFC1320]. 558 3. The value "md5" signifies that the hash information is MD5, as 559 specified in [RFC1321]. 560 4. The value "sha1" signifies that the hash information is SHA1, as 561 specified in [RFC3174]. 563 5. The value "sha256" signifies that the hash information is SHA- 564 256, as specified in [RFC4634]. 565 6. The value "sha384" signifies that the hash information is SHA- 566 384, as specified in [RFC4634]. 567 7. The value "sha512" signifies that the hash information is SHA- 568 512, as specified in [RFC4634]. 569 8. The value "rmd160" signifies that the hash information is RMD160, 570 as specified in [RIPE]. 571 9. The value "tiger" signifies that the hash information is TIGER. 573 4.1.6.2. The "length" Attribute 575 metalink:pieces elements MUST have a "length" attribute, which is an 576 integer that describes the length of the piece of the file in octets. 578 4.2. Metadata Elements 580 4.2.1. The "metalink:copyright" Element 582 The "metalink:copyright" element is a Text construct that conveys a 583 human-readable copyright for a file. 585 metalinkCopyright = 586 element metalink:copyright { 587 metalinkTextConstruct 588 } 590 4.2.2. The "metalink:description" Element 592 The "metalink:description" element is a Text construct that conveys a 593 human-readable description for a file. 595 metalinkDescription = 596 element metalink:description { 597 metalinkTextConstruct 598 } 600 4.2.3. The "metalink:generator" Element 602 The "metalink:generator" element's content identifies the agent used 603 to generate a Metalink Document, for debugging and other purposes. 605 metalinkGenerator = element metalink:generator { 606 metalinkCommonAttributes, 607 attribute uri { metalinkUri }?, 608 attribute version { text }?, 609 text 610 } 611 The content of this element, when present, MUST be a string that is a 612 human-readable name for the generating agent. Entities such as 613 "&" and "<" represent their corresponding characters ("&" and 614 "<" respectively), not markup. 616 The metalink:generator element MAY have a "uri" attribute whose value 617 MUST be an IRI reference [RFC3987]. When dereferenced, the resulting 618 URI (mapped from an IRI, if necessary) SHOULD produce a 619 representation that is relevant to that agent. 621 The metalink:generator element MAY have a "version" attribute that 622 indicates the version of the generating agent. 624 4.2.4. The "metalink:hash" Element 626 The "metalink:hash" element is a Text construct that conveys a human- 627 readable hash for a file. 629 metalinkHash = 630 element metalink:hash { 631 attribute piece { xsd:integer }?, 632 attribute type { "crc32" | "md4" | "md5" | "sha1" | 633 "sha256" | "sha384" | "sha512" | "rmd160" | "tiger" }, 634 text 635 } 637 4.2.4.1. The "type" Attribute 639 metalink:hash elements MUST have a "type" attribute or a "piece" 640 attribute. metalink:hash elements with a "type" attribute contain a 641 hash of the whole file. metalink:hash elements with a "piece" 642 attribute contain a hash for that specific piece or chunk of the 643 file. All hashes are in lowercase hexadecimal format. 645 This document defines nine initial values for hash types: 646 1. The value "crc32" signifies that the information is CRC32. 647 2. The value "md4" signifies that the hash information is MD4, as 648 specified in [RFC1320]. 649 3. The value "md5" signifies that the hash information is MD5, as 650 specified in [RFC1321]. 651 4. The value "sha1" signifies that the hash information is SHA1, as 652 specified in [RFC3174]. 653 5. The value "sha256" signifies that the hash information is SHA- 654 256, as specified in [RFC4634]. 655 6. The value "sha384" signifies that the hash information is SHA- 656 384, as specified in [RFC4634]. 658 7. The value "sha512" signifies that the hash information is SHA- 659 512, as specified in [RFC4634]. 660 8. The value "rmd160" signifies that the hash information is RMD160, 661 as specified in [RIPE]. 662 9. The value "tiger" signifies that the hash information is TIGER. 664 4.2.4.2. The "piece" Attribute 666 metalink:hash elements MAY have a "piece" attribute, only when they 667 are a sub element of metalink:pieces. The value of "piece" starts at 668 "0" and increases, depending on the "length" attribute of metalink: 669 pieces and the size of the file. 671 4.2.5. The "metalink:identity" Element 673 The "metalink:identity" element is a Text construct that conveys a 674 human-readable identity for a file. The identity of OpenOffice.org 675 3.0 would be "OpenOffice.org". 677 metalinkIdentity = 678 element metalink:identity { 679 metalinkTextConstruct 680 } 682 4.2.6. The "metalink:language" Element 684 The "metalink:language" element is a Text construct that conveys a 685 code for the language of a file, per [ISO639-2]. 687 metalinkLanguage = 688 element metalink:language { 689 metalinkTextConstruct 690 } 692 4.2.7. The "metalink:license" Element 694 The "metalink:license" element is a Text construct that conveys a 695 human-readable license name for a file. 697 metalinkLicense = 698 element metalink:license { 699 metalinkCommonAttributes, 700 attribute uri { metalinkUri }?, 701 attribute name { metalinkTextConstruct }?, 702 } 704 The metalink:license element MAY have a "uri" attribute whose value 705 MUST be an IRI reference [RFC3987]. When dereferenced, the resulting 706 URI (mapped from an IRI, if necessary) SHOULD produce a 707 representation that is relevant to that agent. 709 The metalink:license element MAY have a "name" attribute that 710 indicates the name of the license. 712 4.2.8. The "metalink:logo" Element 714 The "metalink:logo" element's content is an IRI reference [RFC3987] 715 that identifies an image that provides visual identification for a 716 file. 718 metalinkLogo = element metalink:logo { 719 metalinkCommonAttributes, 720 (metalinkUri) 721 } 723 The image SHOULD have an aspect ratio of one (horizontal) to one 724 (vertical) and SHOULD be suitable for presentation at a small size. 726 4.2.9. The "metalink:origin" Element 728 The "metalink:origin" element is an IRI where the Metalink Document 729 was originally published. If metalink:type is "dynamic", then 730 updated versions of the Metalink can be found at this IRI. 732 metalinkOrigin = element metalink:origin { 733 metalinkCommonAttributes, 734 (metalinkUri) 735 } 737 4.2.10. The "metalink:os" Element 739 The "metalink:os" element is a Text construct that conveys a human- 740 readable Operating System for a file. 742 metalinkOS = 743 element metalink:os { 744 metalinkTextConstruct 745 } 747 4.2.11. The "metalink:published" Element 749 The "metalink:published" element is a Date construct indicating an 750 instant in time associated with an event early in the life cycle of 751 the entry. 753 metalinkPublished = 754 element metalink:published { 755 metalinkDateConstruct 756 } 758 Typically, metalink:published will be associated with the initial 759 creation or first availability of the resource. 761 4.2.12. The "metalink:publisher" Element 763 The "metalink:publisher" element indicates a group or other entity 764 which has published the file. 766 metalinkPublisher = 767 element metalink:publisher { 768 metalinkCommonAttributes, 769 attribute uri { metalinkUri }?, 770 attribute name { metalinkTextConstruct }?, 771 } 773 The metalink:publisher element MAY have a "uri" attribute whose value 774 MUST be an IRI reference [RFC3987]. When dereferenced, the resulting 775 URI (mapped from an IRI, if necessary) SHOULD produce a 776 representation that is relevant to that agent. 778 The metalink:publisher element MAY have a "name" attribute that 779 indicates the name of the publisher. 781 4.2.13. The "metalink:signature" Element 783 The "metalink:signature" element is a Text construct that conveys a 784 digital signature for a file. 786 metalinkSignature = 787 element metalink:signature { 788 attribute type { "pgp" }, 789 metalinkTextConstruct 790 } 792 4.2.13.1. The "type" Attribute 794 metalink:signature elements MUST have a "type" attribute. The value 795 of "type" MUST be the string that is non-empty and matches "pgp". 797 4.2.14. The "metalink:size" Element 799 The "metalink:size" element indicates the length of the linked 800 content in octets; it is a hint about the content length of the 801 representation returned when the IRI is mapped to a URI and 802 dereferenced. Note that the "metalink:size" element MUST override 803 the actual content length of the representation as reported by the 804 underlying protocol, i.e. files with different sizes should be 805 discarded. 807 metalinkSize = 808 element metalink:size { 809 metalinkTextConstruct 810 } 812 4.2.15. The "metalink:type" Element 814 The "metalink:type" element is a Text construct that describes 815 whether the IRI from "metalink:origin" a Metalink will contain 816 dynamic updated Metalinks or static content that is not updated. 818 metalinkType = 819 element metalink:type { 820 "static" | "dynamic" 821 } 823 4.2.16. The "metalink:updated" Element 825 The "metalink:updated" element is a Date construct indicating the 826 most recent instant in time when a Metalink was modified in a way the 827 publisher considers significant. Therefore, not all modifications 828 necessarily result in a changed metalink:updated value. 830 metalinkUpdated = 831 element metalink:updated { 832 metalinkDateConstruct 833 } 835 Publishers MAY change the value of this element over time. 837 4.2.17. The "metalink:url" Element 839 The "metalink:url" element contains the IRI of a file. All IRIs 840 should lead to identical files, except in the case of type 841 "bittorrent" where the IRI should lead to a .torrent file. 843 metalinkURL = 844 element metalink:url { 845 metalinkCommonAttributes, 846 attribute location { xsd:string { 847 minLength = "2" maxLength="2"} 848 }?, 849 attribute preference { xsd:integer }?, 850 attribute type { "ftp" | "ftps" | "http" | "https" | 851 "rsync" | "bittorrent" | "magnet" | "ed2k" }?, 852 metalinkUri 853 }+ 855 4.2.17.1. The "preference" Attribute 857 metalink:url elements MAY have a preference attribute, whose value 858 MUST be a number from 1 to 100 for priority, with 100 used first and 859 1 used last. Multiple metalink:url elements can have the same 860 preference, i.e. ten mirrors could have preference="100". 862 4.2.17.2. The "type" Attribute 864 metalink:url elements MAY have a "type" attribute that indicates the 865 IRI type. 867 This document defines eight initial values for IRI types: 868 1. The value "ftp" signifies that the IRI is accessed via FTP as 869 specified in [RFC959]. 870 2. The value "ftps" signifies that the IRI is accessed via FTPS as 871 specified in [RFC4217]. 872 3. The value "http" signifies that the IRI is accessed via HTTP as 873 specified in [RFC2616]. 874 4. The value "https" signifies that the IRI is accessed via HTTPS as 875 specified in [RFC2818]. 876 5. The value "rsync" signifies that the IRI is accessed via rsync. 877 6. The value "bittorrent" signifies that the IRI is a BitTorrent 878 .torrent file as specified in [BITTORRENT]. Metalink Processors 879 that do not support BitTorrent should ignore this type and also 880 ignore metalink:url elements that end in ".torrent". 881 7. The value "magnet" signifies that the IRI is accessed via Magnet 882 Link. 883 8. The value "ed2k" signifies that the IRI is accessed via ED2K 884 network. 886 4.2.17.3. The "location" Attribute 888 metalink:url elements MAY have a "location" attribute, which is a 889 [ISO3166] alpha-2 two letter country code for the geographical 890 location of the physical server an IRI is used to access. 892 4.2.18. The "metalink:version" Element 894 The "metalink:version" element is a Text construct that conveys a 895 human-readable version for a file. The version of OpenOffice.org 3.0 896 would be "3.0". 898 metalinkVersion = 899 element metalink:version { 900 metalinkTextConstruct 901 } 903 5. Securing Metalink Documents 905 Because Metalink is an XML-based format, existing XML security 906 mechanisms can be used to secure its content. 908 Producers of Metalinks may have sound reasons for signing and/or 909 encrypting otherwise-unprotected content. For example, a merchant 910 might digitally sign a Metalink that lists a file download to verify 911 its origin. Other merchants may wish to sign and encypt Metalinks 912 that list digital songs that have been purchased. Of course, many 913 other examples exist as well. 915 The algorithm requirements in this section pertain to the Metalink 916 Processor. They require that a recipient, at a minimum, be able to 917 handle messages that use the specified cryptographic algorithms. 918 These requirements do not limit the algorithms that the sender can 919 choose. 921 5.1. Digital Signatures 923 The root of a Metalink Document (i.e., metalink:metalink MAY have an 924 Enveloped Signature, as described by XML-Signature and Syntax 925 Processing [REC-xmldsig-core]. 927 Metalink Processors MUST NOT reject an Metalink Document containing 928 such a signature because they are not capable of verifying it; they 929 MUST continue processing and MAY inform the user of their failure to 930 validate the signature. 932 In other words, the presence of an element with the namespace URI 933 "http://www.w3.org/2000/09/xmldsig#" and a local name of "Signature" 934 as a child of the document element MUST NOT cause an Metalink 935 Processor to fail merely because of its presence. 937 Other elements in an Metalink Document MUST NOT be signed unless 938 their definitions explicitly specify such a capability. 940 Section 6.5.1 of [REC-xmldsig-core] requires support for Canonical 941 XML [REC-xml-c14n]. However, many implementers do not use it because 942 signed XML documents enclosed in other XML documents have their 943 signatures broken. Thus, Metalink Processors that verify signed 944 Metalink Documents MUST be able to canonicalize with the exclusive 945 XML canonicalization method identified by the URI 946 "http://www.w3.org/2001/10/xml-exc-c14n#", as specified in Exclusive 947 XML Canonicalization [REC-xml-exc-c14n]. 949 Section 4.4.2 of [REC-xmldsig-core] requires support for DSA 950 signatures and recommends support for RSA signatures. However, 951 because of the much greater popularity in the market of RSA versus 952 DSA, Metalink Processors that verify signed Metalink Documents MUST 953 be able to verify RSA signatures, but do not need be able to verify 954 DSA signatures. Due to security issues that can arise if the keying 955 material for message authentication code (MAC) authentication is not 956 handled properly, Metalink Documents SHOULD NOT use MACs for 957 signatures. 959 5.2. Encryption 961 The root of a Metalink Document (i.e., metalink:metalink in a 962 Metalink Document MAY be encrypted, using the mechanisms described by 963 XML Encryption Syntax and Processing [REC-xmlenc-core]. 965 Section 5.1 of [REC-xmlenc-core] requires support of TripleDES, AES- 966 128, and AES-256. Metalink Processors that decrypt Metalink 967 Documents MUST be able to decrypt with AES-128 in Cipher Block 968 Chaining (CBC) mode. 970 Encryption based on [REC-xmlenc-core] does not ensure integrity of 971 the original document. There are known cryptographic attacks where 972 someone who cannot decrypt a message can still change bits in a way 973 where part or all the decrypted message makes sense but has a 974 different meaning. Thus, Metalink Processors that decrypt Metalink 975 Documents SHOULD check the integrity of the decrypted document by 976 verifying the hash in the signature (if any) in the document, or by 977 verifying a hash of the document within the document (if any). 979 5.3. Signing and Encrypting 981 When an Metalink Document is to be both signed and encrypted, it is 982 generally a good idea to first sign the document, then encrypt the 983 signed document. This provides integrity to the base document while 984 encrypting all the information, including the identity of the entity 985 that signed the document. Note that, if MACs are used for 986 authentication, the order MUST be that the document is signed and 987 then encrypted, and not the other way around. 989 6. Extending Metalink 991 6.1. Extensions from Non-Metalink Vocabularies 993 This specification describes Metalink's XML markup vocabulary. 994 Markup from other vocabularies ("foreign markup") can be used in an 995 Metalink Document. 997 6.2. Extensions to the Metalink Vocabulary 999 The Metalink namespace is reserved for future forward-compatible 1000 revisions of Metalink. Future versions of this specification could 1001 add new elements and attributes to the Metalink markup vocabulary. 1002 Software written to conform to this version of the specification will 1003 not be able to process such markup correctly and, in fact, will not 1004 be able to distinguish it from markup error. For the purposes of 1005 this discussion, unrecognized markup from the Metalink vocabulary 1006 will be considered "foreign markup". 1008 6.3. Processing Foreign Markup 1010 Metalink Processors that encounter foreign markup in a location that 1011 is legal according to this specification MUST NOT stop processing or 1012 signal an error. It might be the case that the Metalink Processor is 1013 able to process the foreign markup correctly and does so. Otherwise, 1014 such markup is termed "unknown foreign markup". 1016 When unknown foreign markup is encountered as a child of metalink: 1017 file, metalink:metalink, Metalink Processors MAY bypass the markup 1018 and any textual content and MUST NOT change their behavior as a 1019 result of the markup's presence. 1021 When unknown foreign markup is encountered in a Text Construct, 1022 software SHOULD ignore the markup and process any text content of 1023 foreign elements as though the surrounding markup were not present. 1025 6.4. Extension Elements 1027 Metalink allows foreign markup anywhere in an Metalink document, 1028 except where it is explicitly forbidden. Child elements of metalink: 1029 file and metalink:metalink are considered Metadata elements and are 1030 described below. Child elements of Person constructs are considered 1031 to apply to the construct. The role of other foreign markup is 1032 undefined by this specification. 1034 6.4.1. Simple Extension Elements 1036 A Simple Extension element MUST NOT have any attributes or child 1037 elements. The element MAY contain character data or be empty. 1038 Simple Extension elements are not Language-Sensitive. 1040 simpleExtensionElement = 1041 element * - metalink:* { 1042 text 1043 } 1045 The element can be interpreted as a simple property (or name/value 1046 pair) of the parent element that encloses it. The pair consisting of 1047 the namespace-URI of the element and the local name of the element 1048 can be interpreted as the name of the property. The character data 1049 content of the element can be interpreted as the value of the 1050 property. If the element is empty, then the property value can be 1051 interpreted as an empty string. 1053 6.4.2. Structured Extension Elements 1055 The root element of a Structured Extension element MUST have at least 1056 one attribute or child element. It MAY have attributes, it MAY 1057 contain well-formed XML content (including character data), or it MAY 1058 be empty. Structured Extension elements are Language-Sensitive. 1060 structuredExtensionElement = 1061 element * - metalink:* { 1062 (attribute * { text }+, 1063 (text|anyElement)*) 1064 | (attribute * { text }*, 1065 (text?, anyElement+, (text|anyElement)*)) 1066 } 1068 The structure of a Structured Extension element, including the order 1069 of its child elements, could be significant. 1071 This specification does not provide an interpretation of a Structured 1072 Extension element. The syntax of the XML contained in the element 1073 (and an interpretation of how the element relates to its containing 1074 element) is defined by the specification of the Metalink extension. 1076 7. IANA Considerations 1078 A Metalink Document, when serialized as XML 1.0, can be identified 1079 with the following media type: 1081 MIME media type name: application 1082 MIME subtype name: metalink+xml 1083 Mandatory parameters: None. 1084 Optional parameters: 1085 "charset": This parameter has semantics identical to the charset 1086 parameter of the "application/xml" media type as specified in 1087 [RFC3023]. 1088 Encoding considerations: Identical to those of "application/xml" as 1089 described in [RFC3023], Section 3.2. 1090 Security considerations: As defined in this specification. 1091 In addition, as this media type uses the "+xml" convention, it 1092 shares the same security considerations as described in [RFC3023], 1093 Section 10. 1094 Interoperability considerations: There are no known interoperability 1095 issues. 1096 Published specification: This specification. 1097 Applications that use this media type: No known applications 1098 currently use this media type. 1100 Additional information: 1102 Magic number(s): As specified for "application/xml" in [RFC3023], 1103 Section 3.2. 1104 File extension: .metalink 1105 Fragment identifiers: As specified for "application/xml" in 1106 [RFC3023], Section 5. 1107 Base URI: As specified in [RFC3023], Section 6. 1108 Macintosh File Type code: TEXT 1109 Person and email address to contact for further information: Anthony 1110 Bryan 1111 Intended usage: COMMON 1112 Author/Change controller: IESG 1114 8. Security Considerations 1116 Publishers are encouraged to offer Metalink documents via 1117 authenticated HTTP under TLS. Publishers are also encouraged to 1118 include digital signatures of the files within the Metalink Documents 1119 if they are available. 1121 8.1. URIs 1123 Metalink Processors handle URIs. See Section 7 of [RFC3986]. 1125 8.2. IRIs 1127 Metalink Processors handle IRIs. See Section 8 of [RFC3987]. 1129 8.3. Spoofing 1131 Metalink Processors should be aware of the potential for spoofing 1132 attacks where the attacker publishes Metalinks with false 1133 information. Malicious publishers might create Metalink Documents 1134 containing inaccurate information anywhere in the document. At best, 1135 this could deceive unaware downloaders that they are downloading a 1136 malicious or worthless file. At worst, malicious publishers could 1137 attempt a distributed denial of service attack by inserting unrelated 1138 IRIs into Metalink Documents. 1140 8.4. Encryption and Signing 1142 Metalink Documents can be encrypted and signed using 1143 [REC-xmlenc-core] and [REC-xmldsig-core], respectively, and are 1144 subject to the security considerations implied by their use. 1146 Digital signatures provide authentication, message integrity, and 1147 non-repudiation with proof of origin. Encryption provides data 1148 confidentiality. 1150 9. References 1152 9.1. Normative References 1154 [BITTORRENT] 1155 Cohen, B., "The BitTorrent Protocol Specification", 1156 BITTORRENT 11031, February 2008, 1157 . 1159 [ISO3166] International Organization for Standardization, "ISO 3166: 1160 1988 (E/F) - Codes for the representation of names of 1161 countries - The International Organization for 1162 Standardization, 3rd edition, 1988-08-15.", ISO Standard 1163 3166, 1988. 1165 [ISO639-2] 1166 International Organization for Standardization, "ISO 639- 1167 2:1998 - Codes for the representation of names of 1168 languages -- Part 2: Alpha-3 code - edition 1, 1169 1998-11-01, 66 pages, prepared by a Joint Working Group of 1170 ISO TC46/SC4 and ISO TC37/SC2.", ISO Standard 639-2, 1998. 1172 [REC-xml] Yergeau, F., Paoli, J., Bray, T., Sperberg-McQueen, C., 1173 and E. Maler, "Extensible Markup Language (XML) 1.0 1174 (Fourth Edition)", World Wide Web Consortium 1175 Recommendation REC-xml-20060816, August 2006, 1176 . 1178 [REC-xml-c14n] 1179 Boyer, J., "Canonical XML Version 1.0", W3C REC REC-xml- 1180 c14n-20010315, March 2001, 1181 . 1183 [REC-xml-exc-c14n] 1184 Eastlake, D., Boyer, J., and J. Reagle, "Exclusive XML 1185 Canonicalization Version 1.0", W3C REC REC-xml-exc-c14n- 1186 20020718, July 2002, 1187 . 1189 [REC-xml-infoset] 1190 Cowan, J. and R. Tobin, "XML Information Set (Second 1191 Edition)", World Wide Web Consortium Recommendation REC- 1192 xml-infoset-20040204, February 2004, 1193 . 1195 [REC-xml-names] 1196 Hollander, D., Bray, T., Tobin, R., and A. Layman, 1197 "Namespaces in XML 1.0 (Second Edition)", World Wide Web 1198 Consortium Recommendation REC-xml-names-20060816, 1199 August 2006, 1200 . 1202 [REC-xmlbase] 1203 Marsh, J., "XML Base", W3C REC W3C.REC-xmlbase-20010627, 1204 June 2001, 1205 . 1207 [REC-xmldsig-core] 1208 Solo, D., Reagle, J., and D. Eastlake, "XML-Signature 1209 Syntax and Processing", World Wide Web Consortium 1210 Recommendation REC-xmldsig-core-20020212, February 2002, 1211 . 1213 [REC-xmlenc-core] 1214 Eastlake, D. and J. Reagle, "XML Encryption Syntax and 1215 Processing", World Wide Web Consortium Recommendation REC- 1216 xmlenc-core-20021210, December 2002, 1217 . 1219 [RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, 1220 April 1992. 1222 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 1223 April 1992. 1225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1226 Requirement Levels", BCP 14, RFC 2119, March 1997. 1228 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1229 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1230 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1232 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1234 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1235 Types", RFC 3023, January 2001. 1237 [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 1238 (SHA1)", RFC 3174, September 2001. 1240 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1241 Timestamps", RFC 3339, July 2002. 1243 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1244 Resource Identifier (URI): Generic Syntax", STD 66, 1245 RFC 3986, January 2005. 1247 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1248 Identifiers (IRIs)", RFC 3987, January 2005. 1250 [RFC4217] Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217, 1251 October 2005. 1253 [RFC4634] Eastlake, D. and P. Jones, "US Secure Hash Algorithms (SHA 1254 and HMAC-SHA)", RFC 4634, July 2006. 1256 [RFC959] Postel, J. and J. Reynolds, "FILE TRANSFER PROTOCOL 1257 (FTP)", RFC 959, October 1985. 1259 [RIPE] Dobbertin, H., Bosselaers, A., and B. Preneel, "RIPEMD- 1260 160: A Strengthened Version of RIPEMD", RIPE RIPE, 1261 April 1996. 1263 9.2. Informative References 1265 [ISO.8601.1988] 1266 International Organization for Standardization, "Data 1267 elements and interchange formats - Information interchange 1268 - Representation of dates and times", ISO Standard 8601, 1269 June 1988. 1271 [RELAX-NG] 1272 Clark, J., "RELAX NG Compact Syntax", December 2001, . 1276 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication 1277 Format", RFC 4287, December 2005. 1279 [W3C.NOTE-datetime-19980827] 1280 Wolf, M. and C. Wicksteed, "Date and Time Formats", W3C 1281 NOTE NOTE-datetime-19980827, August 1998, 1282 . 1284 [W3C.REC-xmlschema-2-20041028] 1285 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1286 Second Edition", W3C REC REC-xmlschema-2-20041028, 1287 October 2004, 1288 . 1290 Appendix A. Contributors 1292 The layout and content of this document relies heavily on work 1293 pioneered in the Atom Syndication Format as specified in [RFC4287]. 1295 The following people contributed to preliminary versions of this 1296 document: Paul Burkhead, Kristian Weston, Darius Liktorius, Michael 1297 Burford, Giorgio Maone, Manuel Subredu, Tatsuhiro Tsujikawa, A. Bram 1298 Neijt, Max Velasques, Manolo Valdes, Urs Wolfer, Frederick Cheung, 1299 Nils Maier, Hampus Wessman, Neil McNab, Hayden Legendre, Danny Ayers, 1300 Nick Dominguez, Rene Leonhardt, Per Oyvind Karlsen, Gary Zellerbach, 1301 James Clark, Tim Bray, Dan Brickley, Daniel Stenberg, Peter Poeml, 1302 and Matt Domsch. The content and concepts within are a product of 1303 the Metalink community. 1305 The Metalink community has dozens of very active contributors who 1306 proposed ideas and wording for this document, including: 1308 Nicolas Alvarez, Patrick Ruckstuhl, Mike Wells, Sebastien Willemijns, 1309 Micah Cowan, Dan Fandrich, Francis Giannaros, Yazsoft, Lukas 1310 Appelhans, KGet developers, FDM Team, Orbit Team, Arne 1311 Babenhauserheide, Mathias Berchtold, Xienzhenyu and TheWorld Browser 1312 Team, Xi Software, Bridget and Ethan Fletcher, Ruben Kerkhof, 1313 Agostino Russo, Gervase Markham, Salvatore and Robin Musumeci, Steve 1314 and Rachel Eshelman, Lucas and Rachel Hewett, Ryan and Darren Cronin, 1315 Dave Winquist, Bob Denison, Wes Shelton, Kees Cook, Josh Colbert, 1316 Steve Kleisath, Chad Neptune, Nick Carrabba, Chris Carrabba, Erin 1317 Solari, Derick Cordoba, Ryan Alexander, John Sowder, Sandra Amisano, 1318 Tom Mainville, Janie Wargo, Jason Hansen, Markus Hofmann, Dan 1319 Connolly, Tim Berners-Lee, Harry Chen, Adrien Macneil, Louis Suarez- 1320 Potts, Ross Smith, Rahul Sundaram, Jesse Keating, Michal Bentkowski, 1321 Andrew Pantyukhin, Judd Vinet, Charles Landemaine, Pascal Bleser, 1322 Jeff@BLAG, Yuichiro Nakada, Jereme Hancock, Marcel Hauser, Jeff 1323 Covey, Doug Lang, Seth Brown, Alexander Lazic, Mayank Sharma, Robin 1324 Heggelund Hansen, Steve Langasek, Federico Parodi, Stefano Verna, 1325 Jason Green, James Linden, Matt Nederlanden, Aren Olsen, Dag 1326 Odenhall, Troy Sobotka, Corey Farwell, Ed Lee, Shawn Wilsher, Mike 1327 Connor, Anand Muttagi, Debi Goulding, the Anthony Family, the Bryan 1328 Family, Juanita Anthony and Zimmy Bryan. 1330 Appendix B. RELAX NG Compact Schema 1332 This appendix is informative. 1334 The Relax NG schema explicitly excludes elements in the Metalink 1335 namespace that are not defined in this revision of the specification. 1336 Requirements for Metalink Processors encountering such markup are 1337 given in Sections 6.2 and 6.3. 1339 # -*- rnc -*- 1340 # RELAX NG Compact Syntax Grammar for the 1341 # Metalink Format Specification Version 1 1343 namespace metalink = "http://www.metalinker.org" 1344 namespace xsd = "http://www.w3.org/2001/XMLSchema" 1346 # Common attributes 1348 metalinkCommonAttributes = 1349 attribute xml:base { metalinkUri }?, 1350 attribute xml:lang { metalinkLanguageTag }?, 1351 undefinedAttribute* 1353 # Text Constructs 1355 metalinkTextConstruct = 1356 metalinkCommonAttributes, 1357 text 1359 # Date Construct 1360 metalinkDateConstruct = 1361 metalinkCommonAttributes, 1362 xsd:dateTime 1364 start = 1365 element metalink { 1366 attribute version { "3.0" }, 1367 element generator { 1368 attribute uri { metalinkUri }?, 1369 attribute version { text }?, 1370 metalinkTextConstruct 1371 } 1372 element origin { metalinkUri }?, 1373 element type { "static" | "dynamic" }?, 1374 element published { metalinkDateConstruct }?, 1375 element updated { metalinkDateConstruct }?, 1376 element files { 1377 element file { 1378 attribute name { metalinkTextConstruct }, 1379 element identity { metalinkTextConstruct }?, 1380 element version { metalinkTextConstruct }?, 1381 element size { xsd:integer }?, 1382 element description { metalinkTextConstruct }?, 1383 element license { 1384 attribute uri { metalinkUri }?, 1385 attribute name { metalinkTextConstruct }?, 1386 }?, 1387 element logo { metalinkUri }?, 1388 element publisher { 1389 attribute uri { metalinkUri }?, 1390 attribute name { metalinkTextConstruct }?, 1391 }?, 1392 element language { metalinkTextConstruct }?, 1393 element copyright { metalinkTextConstruct }?, 1394 element license { metalinkTextConstruct }?, 1395 element os { metalinkTextConstruct }?, 1396 element verification { 1397 hash+, 1398 element pieces { 1399 attribute length { metalinkTextConstruct }, 1400 attribute type { "crc32" | "md4" | "md5" | "sha1" | 1401 "sha256" | "sha384" | "sha512" | "rmd160" | "tiger" }, 1402 hash+ 1403 }+, 1404 element signature { 1405 attribute type { "pgp" }, 1406 text 1407 } 1408 }?, 1409 element resources { 1410 element url { 1411 attribute location { xsd:string { 1412 minLength = "2" maxLength="2"} 1413 }?, 1414 attribute preference { xsd:integer }?, 1415 attribute type { "ftp" | "ftps" | "http" | "https" | 1416 "rsync" | "bittorrent" | "magnet" | "ed2k" }?, 1417 metalinkUri 1418 }+ 1419 } 1420 }+ 1421 } 1422 } 1423 hash = 1424 element hash { 1425 attribute piece { metalinkTextConstruct }?, 1426 attribute type { "crc32" | "md4" | "md5" | "sha1" | 1427 "sha256" | "sha384" | "sha512" | "rmd160" | "tiger" }, 1428 text 1429 } 1431 # As defined in RFC 3066 1432 metalinkLanguageTag = xsd:string { 1433 pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*" 1434 } 1436 # Unconstrained; it's not entirely clear how IRI fit into 1437 # xsd:anyURI so let's not try to constrain it here 1438 metalinkUri = text 1440 # Simple Extension 1442 simpleExtensionElement = 1443 element * - metalink:* { 1444 text 1445 } 1447 # Structured Extension 1449 structuredExtensionElement = 1450 element * - metalink:* { 1451 (attribute * { text }+, 1452 (text|anyElement)*) 1453 | (attribute * { text }*, 1454 (text?, anyElement+, (text|anyElement)*)) 1456 } 1458 # Other Extensibility 1460 extensionElement = 1461 simpleExtensionElement | structuredExtensionElement 1463 undefinedAttribute = 1464 attribute * - (xml:base | xml:lang | local:*) { text } 1466 undefinedContent = (text|anyForeignElement)* 1468 anyElement = 1469 element * { 1470 (attribute * { text } 1471 | text 1472 | anyElement)* 1473 } 1475 anyForeignElement = 1476 element * - metalink:* { 1477 (attribute * { text } 1478 | text 1479 | anyElement)* 1480 } 1482 # EOF 1484 Index 1486 A 1487 application/metalink+xml Media Type 24 1489 C 1490 copyright XML element 14 1492 D 1493 description XML element 14 1495 F 1496 file XML element 10 1497 files XML element 9 1499 G 1500 generator XML element 14 1501 Grammar 1502 metalinkCommonAttributes 7 1503 metalinkCopyright 14 1504 metalinkDateConstruct 8 1505 metalinkDescription 14 1506 metalinkFile 11 1507 metalinkFiles 10 1508 metalinkGenerator 14 1509 metalinkHash 15 1510 metalinkIdentity 16 1511 metalinkLanguage 16 1512 metalinkLicense 16 1513 metalinkLogo 17 1514 metalinkMetalink 9 1515 metalinkOrigin 17 1516 metalinkOS 17 1517 metalinkPieces 13 1518 metalinkPublished 18 1519 metalinkPublisher 18 1520 metalinkResources 12 1521 metalinkSignature 18 1522 metalinkSize 19 1523 metalinkTextConstruct 7 1524 metalinkType 19 1525 metalinkUpdated 19 1526 metalinkURL 20 1527 metalinkVerification 13 1528 metalinkVersion 21 1529 simpleExtensionElement 24 1530 structuredExtensionElement 24 1532 H 1533 hash XML element 15 1535 I 1536 identity XML element 16 1538 L 1539 language XML element 16 1540 license XML element 16 1541 logo XML element 17 1543 M 1544 Media Type 1545 application/metalink+xml 24 1546 metalink XML element 8 1547 metalinkCommonAttributes grammar production 7 1548 metalinkCopyright grammar production 14 1549 metalinkDateConstruct grammar production 8 1550 metalinkDescription grammar production 14 1551 metalinkFile grammar production 11 1552 metalinkFiles grammar production 10 1553 metalinkGenerator grammar production 14 1554 metalinkHash grammar production 15 1555 metalinkIdentity grammar production 16 1556 metalinkLanguage grammar production 16 1557 metalinkLicense grammar production 16 1558 metalinkLogo grammar production 17 1559 metalinkMetalink grammar production 9 1560 metalinkOrigin grammar production 17 1561 metalinkOS grammar production 17 1562 metalinkPieces grammar production 13 1563 metalinkPublished grammar production 18 1564 metalinkPublisher grammar production 18 1565 metalinkResources grammar production 12 1566 metalinkSignature grammar production 18 1567 metalinkSize grammar production 19 1568 metalinkTextConstruct grammar production 7 1569 metalinkType grammar production 19 1570 metalinkUpdated grammar production 19 1571 metalinkURL grammar production 20 1572 metalinkVerification grammar production 13 1573 metalinkVersion grammar production 21 1575 O 1576 origin XML element 17 1577 os XML element 17 1579 P 1580 pieces XML element 13 1581 published XML element 17 1582 publisher XML element 18 1584 R 1585 resources XML element 12 1587 S 1588 signature XML element 18 1589 simpleExtensionElement grammar production 24 1590 size XML element 18 1591 structuredExtensionElement grammar production 24 1593 T 1594 type XML element 19 1596 U 1597 updated XML element 19 1598 url XML element 19 1600 V 1601 verification XML element 12 1602 version XML element 21 1604 X 1605 XML Elements 1606 copyright 14 1607 description 14 1608 entry 10 1609 files 9 1610 generator 14 1611 hash 15 1612 identity 16 1613 language 16 1614 license 16 1615 logo 17 1616 metalink 8 1617 origin 17 1618 os 17 1619 pieces 13 1620 published 17 1621 publisher 18 1622 resources 12 1623 signature 18 1624 size 18 1625 type 19 1626 updated 19 1627 url 19 1628 verification 12 1629 version 21 1631 Author's Address 1633 Anthony Bryan (editor) 1634 Metalinker Project 1636 Email: anthonybryan@gmail.com 1637 URI: http://www.metalinker.org 1639 Full Copyright Statement 1641 Copyright (C) The IETF Trust (2008). 1643 This document is subject to the rights, licenses and restrictions 1644 contained in BCP 78, and except as set forth therein, the authors 1645 retain all their rights. 1647 This document and the information contained herein are provided on an 1648 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1649 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1650 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1651 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1652 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1653 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1655 Intellectual Property 1657 The IETF takes no position regarding the validity or scope of any 1658 Intellectual Property Rights or other rights that might be claimed to 1659 pertain to the implementation or use of the technology described in 1660 this document or the extent to which any license under such rights 1661 might or might not be available; nor does it represent that it has 1662 made any independent effort to identify any such rights. Information 1663 on the procedures with respect to rights in RFC documents can be 1664 found in BCP 78 and BCP 79. 1666 Copies of IPR disclosures made to the IETF Secretariat and any 1667 assurances of licenses to be made available, or the result of an 1668 attempt made to obtain a general license or permission for the use of 1669 such proprietary rights by implementers or users of this 1670 specification can be obtained from the IETF on-line IPR repository at 1671 http://www.ietf.org/ipr. 1673 The IETF invites any interested party to bring to its attention any 1674 copyrights, patents or patent applications, or other proprietary 1675 rights that may cover technology that may be required to implement 1676 this standard. Please address the information to the IETF at 1677 ietf-ipr@ietf.org.