idnits 2.17.1 draft-bryan-metalink-03.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 1675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1686. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1693. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1699. 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 (September 19, 2008) is 5697 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 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) Summary: 3 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 September 19, 2008 5 Expires: March 23, 2009 7 The Metalink Download Description Format 8 draft-bryan-metalink-03 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 March 23, 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 . . . . . . . . . . . 9 54 4.1.2. The "metalink:files" Element . . . . . . . . . . . . . 10 55 4.1.3. The "metalink:file" Element . . . . . . . . . . . . . 11 56 4.1.4. The "metalink:resources" Element . . . . . . . . . . . 12 57 4.1.5. The "metalink:verification" Element . . . . . . . . . 13 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:metadata" Element . . . . . . . . . . . 17 69 4.2.10. The "metalink:origin" Element . . . . . . . . . . . . 18 70 4.2.11. The "metalink:os" Element . . . . . . . . . . . . . . 18 71 4.2.12. The "metalink:published" Element . . . . . . . . . . . 18 72 4.2.13. The "metalink:publisher" Element . . . . . . . . . . . 18 73 4.2.14. The "metalink:signature" Element . . . . . . . . . . . 19 74 4.2.15. The "metalink:size" Element . . . . . . . . . . . . . 19 75 4.2.16. The "metalink:type" Element . . . . . . . . . . . . . 19 76 4.2.17. The "metalink:updated" Element . . . . . . . . . . . . 20 77 4.2.18. The "metalink:url" Element . . . . . . . . . . . . . . 20 78 4.2.19. The "metalink:version" Element . . . . . . . . . . . . 21 79 5. Client Implementation Considerations . . . . . . . . . . . . . 21 80 6. Securing Metalink Documents . . . . . . . . . . . . . . . . . 21 81 6.1. Digital Signatures . . . . . . . . . . . . . . . . . . . . 22 82 6.2. Encryption . . . . . . . . . . . . . . . . . . . . . . . . 23 83 6.3. Signing and Encrypting . . . . . . . . . . . . . . . . . . 23 84 7. Extending Metalink . . . . . . . . . . . . . . . . . . . . . . 23 85 7.1. Extensions from Non-Metalink Vocabularies . . . . . . . . 23 86 7.2. Extensions to the Metalink Vocabulary . . . . . . . . . . 23 87 7.3. Processing Foreign Markup . . . . . . . . . . . . . . . . 24 88 7.4. Extension Elements . . . . . . . . . . . . . . . . . . . . 24 89 7.4.1. Simple Extension Elements . . . . . . . . . . . . . . 24 90 7.4.2. Structured Extension Elements . . . . . . . . . . . . 25 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 92 8.1. XML Namespace Registration . . . . . . . . . . . . . . . . 25 93 8.2. application/metalink+xml MIME type . . . . . . . . . . . . 25 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 95 9.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 26 96 9.2. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 27 97 9.3. Encryption and Signing . . . . . . . . . . . . . . . . . . 27 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 100 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 101 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 30 102 Appendix B. RELAX NG Compact Schema . . . . . . . . . . . . . . . 30 103 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 104 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37 105 Intellectual Property and Copyright Statements . . . . . . . . . . 38 107 1. Introduction 109 Metalink is an XML-based document format that describes a file or 110 lists of files to be added to a download queue. Lists are composed 111 of a number of files, each with an extensible set of attached 112 metadata. For example, each file can have a description, checksum, 113 and list of URIs that it is available from. 115 The primary use case that Metalink addresses is the description of 116 downloadable content in a format so download agents can act 117 intelligently and recover from common errors with little or no user 118 interaction necessary. These errors can include multiple servers 119 going down and data corrupted in transmission. 121 1.1. Examples 123 A brief, single file Metalink Document: 125 126 127 128 129 130 ftp://ftp.example.com/example.ext 131 http://example.com/example.ext 132 133 http://example.com/example.ext.torrent 134 135 136 137 138 139 A more extensive, single file Metalink Document: 141 142 143 2008-05-15T12:23:23Z 144 145 146 Example 147 1.0 148 A description of the example file for 149 download. 150 151 83b1a04f18d6782cfe0407edadac377f 152 80bc95fd391772fa61c91ed68567f0980bb45fd9 153 154 155 156 ftp://ftp.example.com/example.ext 157 http://example.com/example.ext 158 159 http://example.com/example.ext.torrent 160 161 162 163 164 166 1.2. Namespace and Version 168 The XML Namespaces URI [REC-xml-names] for the XML data format 169 described in this specification is: 171 urn:ietf:params:xml:ns:metalink 173 For convenience, this data format may be referred to as "Metalink", 174 which this specification uses internally. 176 1.3. Notational Conventions 178 This specification describes conformance of Metalink Documents. 179 Additionally, it places some requirements on Metalink Processors. 181 This specification uses the namespace prefix "metalink:" for the 182 Namespace URI identified in Section 1.2, above. Note that the choice 183 of namespace prefix is arbitrary and not semantically significant. 185 Metalink is specified using terms from the XML Infoset 186 [REC-xml-infoset]. However, this specification uses a shorthand for 187 two common terms: the phrase "Information Item" is omitted when 188 naming Element Information Items and Attribute Information Items. 189 Therefore, when this specification uses the term "element," it is 190 referring to an Element Information Item in Infoset terms. Likewise, 191 when it uses the term "attribute," it is referring to an Attribute 192 Information Item. 194 Some sections of this specification are illustrated with fragments of 195 a non-normative RELAX NG Compact schema [RELAX-NG]. However, the 196 text of this specification provides the definition of conformance. A 197 complete schema appears in Appendix B. 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 200 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 201 document are to be interpreted as described in BCP 14, [RFC2119], as 202 scoped to those conformance targets. 204 2. Metalink Documents 206 This specification describes Metalink Documents. 208 A Metalink Document describes a file or group of files, how to access 209 them, and metadata that identifies them. Its root is the metalink: 210 metalink element. 212 namespace metalink = "urn:ietf:params:xml:ns:metalink" 213 start = metalinkMetalink 215 Metalink Documents are specified in terms of the XML Information Set, 216 serialized as XML 1.0 [REC-xml] and identified with the "application/ 217 metalink+xml" media type. 219 Metalink Documents MUST be well-formed XML. This specification does 220 not define a DTD for Metalink Documents, and hence does not require 221 them to be valid (in the sense used by XML). 223 Metalink allows the use of IRIs [RFC3987]. Every URI [RFC3986] is 224 also an IRI, so a URI may be used wherever below an IRI is named. 225 There is one special consideration: when an IRI that is not also a 226 URI is given for dereferencing, it MUST be mapped to a URI using the 227 steps in Section 3.1 of [RFC3987]. 229 Any element defined by this specification MAY have an xml:base 230 attribute [REC-xmlbase]. When xml:base is used in an Metalink 231 Document, it serves the function described in Section 5.1.1 of 232 [RFC3986], establishing the base URI (or IRI) for resolving any 233 relative references found within the effective scope of the xml:base 234 attribute. 236 Any element defined by this specification MAY have an xml:lang 237 attribute, whose content indicates the natural language for the 238 element and its descendents. The language context is only 239 significant for elements and attributes declared to be "Language- 240 Sensitive" by this specification. Requirements regarding the content 241 and interpretation of xml:lang are specified in XML 1.0 [REC-xml], 242 Section 2.12. 244 metalinkCommonAttributes = 245 attribute xml:base { metalinkUri }?, 246 attribute xml:lang { metalinkLanguageTag }?, 247 undefinedAttribute* 249 Metalink is an extensible format. See Section 7 of this document for 250 a full description of how Metalink Documents can be extended. 252 3. Common Metalink Constructs 254 Many of Metalink's elements share a few common structures. This 255 section defines those structures and their requirements for 256 convenient reference by the appropriate element definitions. 258 When an element is identified as being a particular kind of 259 construct, it inherits the corresponding requirements from that 260 construct's definition in this section. 262 Note that there MUST NOT be any white space in a Date construct or in 263 any IRI. Some XML-emitting implementations erroneously insert white 264 space around values by default, and such implementations will emit 265 invalid Metalink Documents. 267 3.1. Text Constructs 269 A Text construct contains human-readable text, usually in small 270 quantities. The content of Text constructs is Language-Sensitive. 272 metalinkTextConstruct = 273 metalinkCommonAttributes, 274 text 276 3.1.1. Text 278 Example metalink:description with text content: 280 ... 281 282 A description of the example file for download. 283 284 ... 286 The content of the Text construct MUST NOT contain child elements. 287 Such text is intended to be presented to humans in a readable 288 fashion. Thus, Metalink Processors MAY collapse white space 289 (including line breaks) and display the text using typographic 290 techniques such as justification and proportional fonts. 292 3.2. Date Constructs 294 A Date construct is an element whose content MUST conform to the 295 "date-time" production in [RFC3339]. In addition, an uppercase "T" 296 character MUST be used to separate date and time, and an uppercase 297 "Z" character MUST be present in the absence of a numeric time zone 298 offset. 300 metalinkDateConstruct = 301 metalinkCommonAttributes, 302 xsd:dateTime 304 Such date values happen to be compatible with the following 305 specifications: [ISO.8601.1988], [W3C.NOTE-datetime-19980827], and 306 [W3C.REC-xmlschema-2-20041028]. 308 Example Date constructs: 310 2008-12-13T18:30:02Z 311 2008-12-13T18:30:02.25Z 312 2008-12-13T18:30:02+01:00 313 2008-12-13T18:30:02.25+01:00 315 Date values SHOULD be as accurate as possible. For example, it would 316 be generally inappropriate for a publishing system to apply the same 317 timestamp to several entries that were published during the course of 318 a single day. 320 4. Metalink Element Definitions 322 4.1. Container Elements 323 4.1.1. The "metalink:metalink" Element 325 The "metalink:metalink" element is the document (i.e., top-level) 326 element of a Metalink Document, acting as a container for metadata 327 and data associated with the listed files. It contains one 328 "metalink:files" element whose element children consist of metadata 329 elements followed by one or more metalink:file child elements. 331 metalinkMetalink = 332 element metalink:metalink { 333 metalinkCommonAttributes, 334 (metalinkPublished? 335 & metalinkOrigin? 336 & metalinkGenerator? 337 & metalinkUpdated? 338 & extensionElement*), 339 metalinkFiles 340 } 342 The following child elements are defined by this specification (note 343 that the presence of some of these elements is required): 345 o metalink:metalink elements MUST contain exactly one metalink:files 346 element. 347 o metalink:metalink elements MAY contain exactly one metalink:origin 348 element. If metalink:type is "dynamic", metalink:metalink 349 elements MUST contain exactly one metalink:origin element. 350 o metalink:metalink elements MAY contain exactly one metalink:type 351 element. 352 o metalink:metalink elements MAY contain exactly one metalink: 353 generator element. 354 o metalink:metalink elements MAY contain exactly one metalink: 355 published element. 356 o metalink:metalink elements MAY contain exactly one metalink: 357 updated element. If metalink:type is "dynamic", metalink:metalink 358 elements MUST contain exactly one metalink:updated element. 360 4.1.1.1. Providing Textual Content 362 Experience teaches that downloads providing textual content are in 363 general more useful than those that do not. Some applications (one 364 example is full-text indexers) require a minimum amount of text to 365 function reliably and predictably. Metalink publishers should be 366 aware of these issues. It is advisable that each metalink:file 367 element contain a non-empty metalink:description element, a non-empty 368 metalink:identity element when that element is present, and a non- 369 empty metalink:version element, and a non-empty metalink:publisher 370 element. However, the absence of metalink:description is not an 371 error, and Metalink Processors MUST NOT fail to function correctly as 372 a consequence of such an absence. 374 4.1.2. The "metalink:files" Element 376 The "metalink:files" element acts as a container for metadata and 377 data associated with the listed files. It contains one or more 378 metalink:file child elements. Certain elements can be listed either 379 under metalink:files or metalink:file. If under metalink:files, they 380 apply to all files listed in each metalink:file. If under metalink: 381 file, then they apply to just that specific file. 383 metalinkFiles = 384 element metalink:files { 385 metalinkCommonAttributes, 386 (metalinkIdentity? 387 & metalinkVersion? 388 & metalinkDescription? 389 & metalinkOS? 390 & metalinkLogo? 391 & metalinkLanguage? 392 & metalinkPublisher? 393 & metalinkCopyright? 394 & metalinkLicense? 395 & extensionElement*) 396 metalinkFile 397 } 399 The following child elements are defined by this specification (note 400 that the presence of some of these elements is required): 402 o metalink:files element MUST contain one or more metalink:file 403 elements. 404 o metalink:files elements SHOULD contain exactly one metalink: 405 identity element. 406 o metalink:files elements SHOULD contain exactly one metalink: 407 version element. 408 o metalink:files elements MAY contain exactly one metalink: 409 description element. 410 o metalink:files elements MAY contain exactly one metalink:os 411 element. 412 o metalink:files elements MAY contain exactly one metalink:logo 413 element. 414 o metalink:files elements MAY contain exactly one metalink:language 415 element. 416 o metalink:files elements MAY contain exactly one metalink:publisher 417 element. 419 o metalink:files elements MAY contain exactly one metalink:copyright 420 element. 421 o metalink:files elements MAY contain exactly one metalink:license 422 element. 424 4.1.3. The "metalink:file" Element 426 The "metalink:file" element represents an individual file, acting as 427 a container for metadata and data associated with the file. 429 metalinkFile = 430 element metalink:file { 431 metalinkCommonAttributes, 432 attribute name { metalinkTextConstruct }, 433 (metalinkVerification? 434 & metalinkIdentity? 435 & metalinkVersion? 436 & metalinkDescription? 437 & metalinkSize? 438 & metalinkOS? 439 & metalinkLogo? 440 & metalinkLanguage? 441 & metalinkPublisher? 442 & metalinkCopyright? 443 & metalinkLicense? 444 & extensionElement*) 445 metalinkResources 446 } 448 This specification assigns no significance to the order of metalink: 449 file elements. 451 The following child elements are defined by this specification (note 452 that it requires the presence of some of these elements): 454 o metalink:file elements MUST contain exactly one metalink:resources 455 element. 456 o metalink:file elements SHOULD contain exactly one metalink: 457 verification element. 458 o metalink:file elements SHOULD contain exactly one metalink: 459 identity element. 460 o metalink:file elements SHOULD contain exactly one metalink:version 461 element. 462 o metalink:file elements MAY contain exactly one metalink: 463 description element. 464 o metalink:file elements SHOULD contain exactly one metalink:size 465 element. 467 o metalink:file elements MAY contain exactly one metalink:os 468 element. 469 o metalink:file elements MAY contain exactly one metalink:logo 470 element. 471 o metalink:file elements MAY contain exactly one metalink:language 472 element. 473 o metalink:file elements MAY contain exactly one metalink:publisher 474 element. 475 o metalink:file elements MAY contain exactly one metalink:copyright 476 element. 477 o metalink:file elements MAY contain exactly one metalink:license 478 element. 480 4.1.3.1. The "name" Attribute 482 metalink:file elements MUST have a "name" attribute, which contains 483 the filename of the file downloaded. 485 Directory information can also be contained in a "path/file" format 486 only, as in: 488 490 In this example, a subdirectory debian-amd64/sarge/ will be created 491 and a file named Contents-amd64.gz will be created inside it. The 492 path MUST be relative. The path MUST NOT begin with a "/", "./" or 493 "../", contain "/../", or end with "/..". Metalink Processors MUST 494 NOT allow directory traversal. 496 A Metalink Processor MAY alter the name of the subdirectory or file 497 if they contain characters which are invalid in the destination 498 filesystem. 500 4.1.4. The "metalink:resources" Element 502 The "metalink:resources" element acts as a container for metadata and 503 data associated with the listed files. It contains one or more 504 metalink:url child elements. 506 metalinkResources = 507 element metalink:resources { 508 metalinkCommonAttributes, 509 extensionElement* 510 metalinkURL* 511 } 513 This specification assigns no significance to the order of metalink: 514 url elements. Significance is determined by the value of the 515 "preference" attribute of the metalink:url elements. 517 The following child elements are defined by this specification (note 518 that the presence of some of these elements is required): 520 o metalink:resources element MAY contain at least one metalink: 521 metadata element. 522 o metalink:resources element MUST contain at least one metalink:url 523 element. Typically, such elements contain more than one metalink: 524 url element to provide multiple download sources. 526 4.1.5. The "metalink:verification" Element 528 The "metalink:verification" element acts as a container for metadata 529 and data associated with verifying the listed files. This 530 information is in the form of checksums and digital signatures. 531 Checksums are used to verify the integrity of a file or portion of a 532 file to determine if the files have been transferred without any 533 errors. Digital signatures verify that a file is from the entity 534 that has signed it. 536 metalinkVerification = 537 element metalink:verification { 538 metalinkCommonAttributes, 539 (metalinkHash* 540 & metalinkPieces* 541 & metalinkSignature 542 & extensionElement*) 543 } 545 The following child elements are defined by this specification (note 546 that the presence of some of these elements is required): 548 o metalink:verification element MAY contain one or more metalink: 549 hash elements. 550 o metalink:verification element MAY contain one or more metalink: 551 pieces elements. 552 o metalink:verification element MAY contain exactly one metalink: 553 signature elements. 555 4.1.6. The "metalink:pieces" Element 557 The "metalink:pieces" element is a Text construct that conveys a 558 human-readable piece information for a file. 560 metalinkPieces = 561 element metalink:pieces { 562 attribute length { metalinkTextConstruct }, 563 attribute type { metalinkTextConstruct }, 564 hash+ 565 }+, 567 4.1.6.1. The "type" Attribute 569 metalink:pieces elements MUST have a "type" attribute. 571 The IANA registry named "Hash Function Textual Names" defines values 572 for hash types. 574 4.1.6.2. The "length" Attribute 576 metalink:pieces elements MUST have a "length" attribute, which is an 577 integer that describes the length of the piece of the file in octets. 579 4.2. Metadata Elements 581 4.2.1. The "metalink:copyright" Element 583 The "metalink:copyright" element is a Text construct that conveys a 584 human-readable copyright for a file. 586 metalinkCopyright = 587 element metalink:copyright { 588 metalinkTextConstruct 589 } 591 4.2.2. The "metalink:description" Element 593 The "metalink:description" element is a Text construct that conveys a 594 human-readable description for a file. 596 metalinkDescription = 597 element metalink:description { 598 metalinkTextConstruct 599 } 601 4.2.3. The "metalink:generator" Element 603 The "metalink:generator" element's content identifies the agent used 604 to generate a Metalink Document, for debugging and other purposes. 606 metalinkGenerator = element metalink:generator { 607 metalinkCommonAttributes, 608 attribute uri { metalinkUri }?, 609 attribute version { text }?, 610 text 611 } 613 The content of this element, when present, MUST be a string that is a 614 human-readable name for the generating agent. Entities such as 615 "&" and "<" represent their corresponding characters ("&" and 616 "<" respectively), not markup. 618 The metalink:generator element MAY have a "uri" attribute whose value 619 MUST be an IRI reference [RFC3987]. When dereferenced, the resulting 620 URI (mapped from an IRI, if necessary) SHOULD produce a 621 representation that is relevant to that agent. 623 The metalink:generator element MAY have a "version" attribute that 624 indicates the version of the generating agent. 626 4.2.4. The "metalink:hash" Element 628 The "metalink:hash" element is a Text construct that conveys a human- 629 readable hash for a file. 631 metalinkHash = 632 element metalink:hash { 633 attribute piece { xsd:integer }?, 634 attribute type { metalinkTextConstruct }, 635 text 636 } 638 4.2.4.1. The "type" Attribute 640 metalink:hash elements MUST have a "type" attribute or a "piece" 641 attribute. metalink:hash elements with a "type" attribute contain a 642 hash of the whole file. metalink:hash elements with a "piece" 643 attribute contain a hash for that specific piece or chunk of the 644 file. All hashes are in lowercase hexadecimal format. 646 When multiple hash types methods are provided, a Metalink Processor 647 MAY verify using more than one of these hash types. Metalink 648 Processors are encouraged to check all hash types given which they 649 are able to process. 651 The IANA registry named "Hash Function Textual Names" defines values 652 for hash types. 654 4.2.4.2. The "piece" Attribute 656 metalink:hash elements MAY have a "piece" attribute, only when they 657 are a sub element of metalink:pieces. The value of "piece" starts at 658 "0" and increases, depending on the "length" attribute of metalink: 659 pieces and the size of the file. 661 4.2.5. The "metalink:identity" Element 663 The "metalink:identity" element is a Text construct that conveys a 664 human-readable identity for a file. The identity of OpenOffice.org 665 3.0 would be "OpenOffice.org". 667 metalinkIdentity = 668 element metalink:identity { 669 metalinkTextConstruct 670 } 672 4.2.6. The "metalink:language" Element 674 The "metalink:language" element is a Text construct that conveys a 675 code for the language of a file, per [ISO639-2]. 677 metalinkLanguage = 678 element metalink:language { 679 metalinkTextConstruct 680 } 682 4.2.7. The "metalink:license" Element 684 The "metalink:license" element is a Text construct that conveys a 685 human-readable license name for a file. 687 metalinkLicense = 688 element metalink:license { 689 metalinkCommonAttributes, 690 attribute uri { metalinkUri }?, 691 attribute name { metalinkTextConstruct }?, 692 } 694 The metalink:license element MAY have a "uri" attribute whose value 695 MUST be an IRI reference [RFC3987]. When dereferenced, the resulting 696 URI (mapped from an IRI, if necessary) SHOULD produce a 697 representation that is relevant to that agent. 699 The metalink:license element MAY have a "name" attribute that 700 indicates the name of the license. 702 4.2.8. 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 = element metalink:logo { 709 metalinkCommonAttributes, 710 (metalinkUri) 711 } 713 The image SHOULD have an aspect ratio of one (horizontal) to one 714 (vertical) and SHOULD be suitable for presentation at a small size. 716 4.2.9. The "metalink:metadata" Element 718 The "metalink:metadata" element contains the IRI of metadata about a 719 resource to download. For example, this could be the IRI of a 720 BitTorrent .torrent file or a Metalink Document. 722 metalinkMetadata = 723 element metalink:metadata { 724 metalinkCommonAttributes, 725 attribute preference { xsd:integer }?, 726 attribute type { metalinkTextConstruct }, 727 metalinkUri 728 }+ 730 4.2.9.1. The "preference" Attribute 732 metalink:metadata elements MAY have a preference attribute, whose 733 value MUST be a number from 1 to 100 for priority, with 100 used 734 first and 1 used last. See the "preference" attribute of the 735 metalink:url element for more information. 737 4.2.9.2. The "type" Attribute 739 metalink:metadata elements MUST have a "type" attribute that 740 indicates the MIME type of the metadata available at the IRI. In the 741 case of BitTorrent as specified in [BITTORRENT], the value "torrent" 742 is required. Types without "/" are reserved. Currently, "torrent" 743 is the only reserved value. 745 Metalink Processors that do not support a specified type of metadata 746 about a resource to download MUST ignore that metadata. 748 4.2.10. The "metalink:origin" Element 750 The "metalink:origin" element is an IRI where the Metalink Document 751 was originally published. If metalink:type is "dynamic", then 752 updated versions of the Metalink can be found at this IRI. 754 metalinkOrigin = element metalink:origin { 755 metalinkCommonAttributes, 756 (metalinkUri) 757 } 759 4.2.11. The "metalink:os" Element 761 The "metalink:os" element is a Text construct that conveys a human- 762 readable Operating System for a file. The IANA registry named 763 "Operating System Names" defines values for OS types. 765 metalinkOS = 766 element metalink:os { 767 metalinkTextConstruct 768 } 770 4.2.12. The "metalink:published" Element 772 The "metalink:published" element is a Date construct indicating an 773 instant in time associated with an event early in the life cycle of 774 the entry. 776 metalinkPublished = 777 element metalink:published { 778 metalinkDateConstruct 779 } 781 Typically, metalink:published will be associated with the initial 782 creation or first availability of the resource. 784 4.2.13. The "metalink:publisher" Element 786 The "metalink:publisher" element indicates a group or other entity 787 which has published the file. 789 metalinkPublisher = 790 element metalink:publisher { 791 metalinkCommonAttributes, 792 attribute uri { metalinkUri }?, 793 attribute name { metalinkTextConstruct }?, 794 } 795 The metalink:publisher element MAY have a "uri" attribute whose value 796 MUST be an IRI reference [RFC3987]. When dereferenced, the resulting 797 URI (mapped from an IRI, if necessary) SHOULD produce a 798 representation that is relevant to that agent. 800 The metalink:publisher element MAY have a "name" attribute that 801 indicates the name of the publisher. 803 4.2.14. The "metalink:signature" Element 805 The "metalink:signature" element is a Text construct that conveys a 806 digital signature for a file described in a Metalink Document. 808 metalinkSignature = 809 element metalink:signature { 810 attribute type { "pgp" }, 811 metalinkTextConstruct 812 } 814 4.2.14.1. The "type" Attribute 816 metalink:signature elements MUST have a "type" attribute. The inital 817 value of "type" is the string that is non-empty and matches "pgp". 818 It may be useful to extend Metalink documents with new types of 819 digital signatures, so unknown types are allowed. 821 4.2.15. The "metalink:size" Element 823 The "metalink:size" element indicates the length of the linked 824 content in octets; it is a hint about the content length of the 825 representation returned when the IRI is mapped to a URI and 826 dereferenced. Note that the "metalink:size" element MUST override 827 the actual content length of the representation as reported by the 828 underlying protocol, i.e. files with different sizes should be 829 discarded. 831 metalinkSize = 832 element metalink:size { 833 metalinkTextConstruct 834 } 836 4.2.16. The "metalink:type" Element 838 The "metalink:type" element is a Text construct that describes 839 whether the IRI from "metalink:origin" a Metalink will contain 840 dynamic updated Metalinks or static content that is not updated. 842 metalinkType = 843 element metalink:type { 844 "static" | "dynamic" 845 } 847 4.2.17. The "metalink:updated" Element 849 The "metalink:updated" element is a Date construct indicating the 850 most recent instant in time when a Metalink was modified in a way the 851 publisher considers significant. Therefore, not all modifications 852 necessarily result in a changed metalink:updated value. 854 metalinkUpdated = 855 element metalink:updated { 856 metalinkDateConstruct 857 } 859 Publishers MAY change the value of this element over time. 861 4.2.18. The "metalink:url" Element 863 The "metalink:url" element contains the IRI of a file. All IRIs MUST 864 lead to identical files. 866 metalinkURL = 867 element metalink:url { 868 metalinkCommonAttributes, 869 attribute location { xsd:string { 870 minLength = "2" maxLength="2"} 871 }?, 872 attribute preference { xsd:integer }?, 873 metalinkUri 874 }+ 876 4.2.18.1. The "preference" Attribute 878 metalink:url elements MAY have a preference attribute, whose value 879 MUST be a number from 1 to 100 for priority, with 100 used first and 880 1 used last. Multiple metalink:url elements can have the same 881 preference, i.e. ten mirrors could have preference="100". A Metalink 882 Processor MAY download different segments of a file from more than 883 one IRI simultaneously, and when doing so SHOULD first use the 884 highest priority IRIs and then use lower ones. 886 When one or more metalink:url elements have a preference attribute 887 value of "100", other metalink:url elements SHOULD NOT be used, 888 unless the elements with a preference of 100 cannot be processed 889 (e.g. if they are of a metalink:metadata element type which is not 890 supported by the Metalink Processor, such as BitTorrent, or if the 891 servers are unavailable). 893 Any metalink:url elements with a preference attribute value of "1" 894 SHOULD NOT be used unless all other metalink:url elements cannot be 895 processed (e.g. are "bittorrent" etc and this is not supported by the 896 Metalink Processor, or the servers are down). 898 4.2.18.2. The "location" Attribute 900 metalink:url elements MAY have a "location" attribute, which is a 901 [ISO3166] alpha-2 two letter country code for the geographical 902 location of the physical server an IRI is used to access. 904 4.2.19. The "metalink:version" Element 906 The "metalink:version" element is a Text construct that conveys a 907 human-readable version for a file. The version of OpenOffice.org 3.0 908 would be "3.0". 910 metalinkVersion = 911 element metalink:version { 912 metalinkTextConstruct 913 } 915 5. Client Implementation Considerations 917 Transparent content negotiation with HTTP [RFC2295] is accomplished 918 by adding the Metalink media type to the Accept request header. 919 Metalink Processors MUST check the returned content type, and if the 920 Metalink media type is used, it MUST process the Metalink. If the 921 content type does not match, then Metalink Processors MUST handle the 922 response as a normal response. Metalink Processors MUST NOT add the 923 Metalink media type to Accept when requesting a URI from a metalink: 924 url element, thus avoiding loops. Metalink Processors MUST handle 925 external redirects that might lead to a Metalink. 927 6. Securing Metalink Documents 929 Because Metalink is an XML-based format, existing XML security 930 mechanisms can be used to secure its content. 932 Producers of Metalinks may have sound reasons for signing and/or 933 encrypting otherwise-unprotected content. For example, a merchant 934 might digitally sign a Metalink that lists a file download to verify 935 its origin. Other merchants may wish to sign and encypt Metalinks 936 that list digital songs that have been purchased. Of course, many 937 other examples exist as well. 939 The algorithm requirements in this section pertain to the Metalink 940 Processor. They require that a recipient, at a minimum, be able to 941 handle messages that use the specified cryptographic algorithms. 942 These requirements do not limit the algorithms that the sender can 943 choose. 945 6.1. Digital Signatures 947 The root of a Metalink Document (i.e., metalink:metalink MAY have an 948 Enveloped Signature, as described by XML-Signature and Syntax 949 Processing [REC-xmldsig-core]. 951 Metalink Processors MUST NOT reject an Metalink Document containing 952 such a signature because they are not capable of verifying it; they 953 MUST continue processing and MAY inform the user of their failure to 954 validate the signature. 956 In other words, the presence of an element with the namespace URI 957 "http://www.w3.org/2000/09/xmldsig#" and a local name of "Signature" 958 as a child of the document element MUST NOT cause an Metalink 959 Processor to fail merely because of its presence. 961 Other elements in an Metalink Document MUST NOT be signed unless 962 their definitions explicitly specify such a capability. 964 Section 6.5.1 of [REC-xmldsig-core] requires support for Canonical 965 XML [REC-xml-c14n]. However, many implementers do not use it because 966 signed XML documents enclosed in other XML documents have their 967 signatures broken. Thus, Metalink Processors that verify signed 968 Metalink Documents MUST be able to canonicalize with the exclusive 969 XML canonicalization method identified by the URI 970 "http://www.w3.org/2001/10/xml-exc-c14n#", as specified in Exclusive 971 XML Canonicalization [REC-xml-exc-c14n]. 973 Section 4.4.2 of [REC-xmldsig-core] requires support for DSA 974 signatures and recommends support for RSA signatures. However, 975 because of the much greater popularity in the market of RSA versus 976 DSA, Metalink Processors that verify signed Metalink Documents MUST 977 be able to verify RSA signatures, but do not need be able to verify 978 DSA signatures. Due to security issues that can arise if the keying 979 material for message authentication code (MAC) authentication is not 980 handled properly, Metalink Documents SHOULD NOT use MACs for 981 signatures. 983 6.2. Encryption 985 The root of a Metalink Document (i.e., metalink:metalink in a 986 Metalink Document MAY be encrypted, using the mechanisms described by 987 XML Encryption Syntax and Processing [REC-xmlenc-core]. 989 Section 5.1 of [REC-xmlenc-core] requires support of TripleDES, AES- 990 128, and AES-256. Metalink Processors that decrypt Metalink 991 Documents MUST be able to decrypt with AES-128 in Cipher Block 992 Chaining (CBC) mode. 994 Encryption based on [REC-xmlenc-core] does not ensure integrity of 995 the original document. There are known cryptographic attacks where 996 someone who cannot decrypt a message can still change bits in a way 997 where part or all the decrypted message makes sense but has a 998 different meaning. Thus, Metalink Processors that decrypt Metalink 999 Documents SHOULD check the integrity of the decrypted document by 1000 verifying the hash in the signature (if any) in the document, or by 1001 verifying a hash of the document within the document (if any). 1003 6.3. Signing and Encrypting 1005 When an Metalink Document is to be both signed and encrypted, it is 1006 generally a good idea to first sign the document, then encrypt the 1007 signed document. This provides integrity to the base document while 1008 encrypting all the information, including the identity of the entity 1009 that signed the document. Note that, if MACs are used for 1010 authentication, the order MUST be that the document is signed and 1011 then encrypted, and not the other way around. 1013 7. Extending Metalink 1015 7.1. Extensions from Non-Metalink Vocabularies 1017 This specification describes Metalink's XML markup vocabulary. 1018 Markup from other vocabularies ("foreign markup") can be used in an 1019 Metalink Document. 1021 7.2. Extensions to the Metalink Vocabulary 1023 The Metalink namespace is reserved for future forward-compatible 1024 revisions of Metalink. Future versions of this specification could 1025 add new elements and attributes to the Metalink markup vocabulary. 1026 Software written to conform to this version of the specification will 1027 not be able to process such markup correctly and, in fact, will not 1028 be able to distinguish it from markup error. For the purposes of 1029 this discussion, unrecognized markup from the Metalink vocabulary 1030 will be considered "foreign markup". 1032 7.3. Processing Foreign Markup 1034 Metalink Processors that encounter foreign markup in a location that 1035 is legal according to this specification MUST NOT stop processing or 1036 signal an error. It might be the case that the Metalink Processor is 1037 able to process the foreign markup correctly and does so. Otherwise, 1038 such markup is termed "unknown foreign markup". 1040 When unknown foreign markup is encountered as a child of metalink: 1041 file, metalink:metalink, Metalink Processors MAY bypass the markup 1042 and any textual content and MUST NOT change their behavior as a 1043 result of the markup's presence. 1045 When unknown foreign markup is encountered in a Text Construct, 1046 software SHOULD ignore the markup and process any text content of 1047 foreign elements as though the surrounding markup were not present. 1049 7.4. Extension Elements 1051 Metalink allows foreign markup anywhere in an Metalink document, 1052 except where it is explicitly forbidden. Child elements of metalink: 1053 file and metalink:metalink are considered Metadata elements and are 1054 described below. Child elements of Person constructs are considered 1055 to apply to the construct. The role of other foreign markup is 1056 undefined by this specification. 1058 7.4.1. Simple Extension Elements 1060 A Simple Extension element MUST NOT have any attributes or child 1061 elements. The element MAY contain character data or be empty. 1062 Simple Extension elements are not Language-Sensitive. 1064 simpleExtensionElement = 1065 element * - metalink:* { 1066 text 1067 } 1069 The element can be interpreted as a simple property (or name/value 1070 pair) of the parent element that encloses it. The pair consisting of 1071 the namespace-URI of the element and the local name of the element 1072 can be interpreted as the name of the property. The character data 1073 content of the element can be interpreted as the value of the 1074 property. If the element is empty, then the property value can be 1075 interpreted as an empty string. 1077 7.4.2. Structured Extension Elements 1079 The root element of a Structured Extension element MUST have at least 1080 one attribute or child element. It MAY have attributes, it MAY 1081 contain well-formed XML content (including character data), or it MAY 1082 be empty. Structured Extension elements are Language-Sensitive. 1084 structuredExtensionElement = 1085 element * - metalink:* { 1086 (attribute * { text }+, 1087 (text|anyElement)*) 1088 | (attribute * { text }*, 1089 (text?, anyElement+, (text|anyElement)*)) 1090 } 1092 The structure of a Structured Extension element, including the order 1093 of its child elements, could be significant. 1095 This specification does not provide an interpretation of a Structured 1096 Extension element. The syntax of the XML contained in the element 1097 (and an interpretation of how the element relates to its containing 1098 element) is defined by the specification of the Metalink extension. 1100 8. IANA Considerations 1102 8.1. XML Namespace Registration 1104 This document makes use of the XML registry specified in [RFC3688]. 1105 Accordingly, IANA has made the following registration: 1107 Registration request for the Metalink namespace: 1109 URI: urn:ietf:params:xml:ns:metalink 1111 Registrant Contact: See the "Author's Address" section of this 1112 document. 1114 XML: None. Namespace URIs do not represent an XML specification. 1116 8.2. application/metalink+xml MIME type 1118 A Metalink Document, when serialized as XML 1.0, can be identified 1119 with the following media type: 1121 MIME media type name: application 1122 MIME subtype name: metalink+xml 1123 Mandatory parameters: None. 1124 Optional parameters: 1125 "charset": This parameter has semantics identical to the charset 1126 parameter of the "application/xml" media type as specified in 1127 [RFC3023]. 1128 Encoding considerations: Identical to those of "application/xml" as 1129 described in [RFC3023], Section 3.2. 1130 Security considerations: As defined in this specification. 1131 In addition, as this media type uses the "+xml" convention, it 1132 shares the same security considerations as described in [RFC3023], 1133 Section 10. 1134 Interoperability considerations: There are no known interoperability 1135 issues. 1136 Published specification: This specification. 1137 Applications that use this media type: No known applications 1138 currently use this media type. 1140 Additional information: 1142 Magic number(s): As specified for "application/xml" in [RFC3023], 1143 Section 3.2. 1144 File extension: .metalink 1145 Fragment identifiers: As specified for "application/xml" in 1146 [RFC3023], Section 5. 1147 Base URI: As specified in [RFC3023], Section 6. 1148 Macintosh File Type code: TEXT 1149 Person and email address to contact for further information: Anthony 1150 Bryan 1151 Intended usage: COMMON 1152 Author/Change controller: IESG 1154 9. Security Considerations 1156 Publishers are encouraged to offer Metalink documents via 1157 authenticated HTTP under TLS as specified in [RFC2818]. Publishers 1158 are also encouraged to include digital signatures of the files within 1159 the Metalink Documents if they are available. 1161 9.1. URIs and IRIs 1163 Metalink Processors handle URIs and IRIs. See Section 7 of [RFC3986] 1164 and Section 8 of [RFC3987] for security considerations related to 1165 their handling and use. 1167 9.2. Spoofing 1169 Metalink Processors should be aware of the potential for spoofing 1170 attacks where the attacker publishes Metalinks with false 1171 information. Malicious publishers might create Metalink Documents 1172 containing inaccurate information anywhere in the document. At best, 1173 this could deceive unaware downloaders that they are downloading a 1174 malicious or worthless file. At worst, malicious publishers could 1175 attempt a distributed denial of service attack by inserting unrelated 1176 IRIs into Metalink Documents. 1178 9.3. Encryption and Signing 1180 Metalink Documents can be encrypted and signed using 1181 [REC-xmlenc-core] and [REC-xmldsig-core], respectively, and are 1182 subject to the security considerations implied by their use. 1184 Digital signatures provide authentication, message integrity, and 1185 non-repudiation with proof of origin. Encryption provides data 1186 confidentiality. 1188 10. References 1190 10.1. Normative References 1192 [BITTORRENT] 1193 Cohen, B., "The BitTorrent Protocol Specification", 1194 BITTORRENT 11031, February 2008, 1195 . 1197 [ISO3166] International Organization for Standardization, "ISO 3166: 1198 1988 (E/F) - Codes for the representation of names of 1199 countries - The International Organization for 1200 Standardization, 3rd edition, 1988-08-15.", ISO Standard 1201 3166, 1988. 1203 [ISO639-2] 1204 International Organization for Standardization, "ISO 639- 1205 2:1998 - Codes for the representation of names of 1206 languages -- Part 2: Alpha-3 code - edition 1, 1207 1998-11-01, 66 pages, prepared by a Joint Working Group of 1208 ISO TC46/SC4 and ISO TC37/SC2.", ISO Standard 639-2, 1998. 1210 [REC-xml] Yergeau, F., Paoli, J., Bray, T., Sperberg-McQueen, C., 1211 and E. Maler, "Extensible Markup Language (XML) 1.0 1212 (Fourth Edition)", World Wide Web Consortium 1213 Recommendation REC-xml-20060816, August 2006, 1214 . 1216 [REC-xml-c14n] 1217 Boyer, J., "Canonical XML Version 1.0", W3C REC REC-xml- 1218 c14n-20010315, March 2001, 1219 . 1221 [REC-xml-exc-c14n] 1222 Eastlake, D., Boyer, J., and J. Reagle, "Exclusive XML 1223 Canonicalization Version 1.0", W3C REC REC-xml-exc-c14n- 1224 20020718, July 2002, 1225 . 1227 [REC-xml-infoset] 1228 Cowan, J. and R. Tobin, "XML Information Set (Second 1229 Edition)", World Wide Web Consortium Recommendation REC- 1230 xml-infoset-20040204, February 2004, 1231 . 1233 [REC-xml-names] 1234 Hollander, D., Bray, T., Tobin, R., and A. Layman, 1235 "Namespaces in XML 1.0 (Second Edition)", World Wide Web 1236 Consortium Recommendation REC-xml-names-20060816, 1237 August 2006, 1238 . 1240 [REC-xmlbase] 1241 Marsh, J., "XML Base", W3C REC W3C.REC-xmlbase-20010627, 1242 June 2001, 1243 . 1245 [REC-xmldsig-core] 1246 Solo, D., Reagle, J., and D. Eastlake, "XML-Signature 1247 Syntax and Processing", World Wide Web Consortium 1248 Recommendation REC-xmldsig-core-20020212, February 2002, 1249 . 1251 [REC-xmlenc-core] 1252 Eastlake, D. and J. Reagle, "XML Encryption Syntax and 1253 Processing", World Wide Web Consortium Recommendation REC- 1254 xmlenc-core-20021210, December 2002, 1255 . 1257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1258 Requirement Levels", BCP 14, RFC 2119, March 1997. 1260 [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation 1261 in HTTP", RFC 2295, March 1998. 1263 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1265 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1266 Types", RFC 3023, January 2001. 1268 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1269 Timestamps", RFC 3339, July 2002. 1271 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1272 January 2004. 1274 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1275 Resource Identifier (URI): Generic Syntax", STD 66, 1276 RFC 3986, January 2005. 1278 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1279 Identifiers (IRIs)", RFC 3987, January 2005. 1281 10.2. Informative References 1283 [ISO.8601.1988] 1284 International Organization for Standardization, "Data 1285 elements and interchange formats - Information interchange 1286 - Representation of dates and times", ISO Standard 8601, 1287 June 1988. 1289 [RELAX-NG] 1290 Clark, J., "RELAX NG Compact Syntax", December 2001, . 1294 [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication 1295 Format", RFC 4287, December 2005. 1297 [W3C.NOTE-datetime-19980827] 1298 Wolf, M. and C. Wicksteed, "Date and Time Formats", W3C 1299 NOTE NOTE-datetime-19980827, August 1998, 1300 . 1302 [W3C.REC-xmlschema-2-20041028] 1303 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1304 Second Edition", W3C REC REC-xmlschema-2-20041028, 1305 October 2004, 1306 . 1308 Appendix A. Contributors 1310 The layout and content of this document relies heavily on work 1311 pioneered in the Atom Syndication Format as specified in [RFC4287]. 1313 The following people contributed to preliminary versions of this 1314 document: Paul Burkhead, Kristian Weston, Darius Liktorius, Michael 1315 Burford, Giorgio Maone, Manuel Subredu, Tatsuhiro Tsujikawa, A. Bram 1316 Neijt, Max Velasques, Manolo Valdes, Urs Wolfer, Frederick Cheung, 1317 Nils Maier, Hampus Wessman, Neil McNab, Hayden Legendre, Danny Ayers, 1318 Nick Dominguez, Rene Leonhardt, Per Oyvind Karlsen, Gary Zellerbach, 1319 James Clark, Daniel Stenberg, Peter Poeml, Matt Domsch, Chris Newman, 1320 Lisa Dusseault, Ian Macfarlane, Dave Cridland, and Julian Reschke. 1321 The content and concepts within are a product of the Metalink 1322 community. 1324 The Metalink community has dozens of very active contributors who 1325 proposed ideas and wording for this document, including: 1327 Nicolas Alvarez, Patrick Ruckstuhl, Mike Wells, Sebastien Willemijns, 1328 Micah Cowan, Dan Fandrich, Francis Giannaros, Yazsoft, Lukas 1329 Appelhans, KGet developers, FDM Team, Orbit Team, Arne 1330 Babenhauserheide, Mathias Berchtold, Xienzhenyu and TheWorld Browser 1331 Team, Xi Software, Bridget and Ethan Fletcher, Ruben Kerkhof, 1332 Agostino Russo, Gervase Markham, Salvatore and Robin Musumeci, Steve 1333 and Rachel Eshelman, Lucas Hewett, Ryan and Darren Cronin, Dave 1334 Winquist, Bob Denison, Wes Shelton, Kees Cook, Josh Colbert, Steve 1335 Kleisath, Chad Neptune, Nick Carrabba, Chris Carrabba, Erin Solari, 1336 Derick Cordoba, Ryan Alexander, John Sowder, Sandra Amisano, Tom 1337 Mainville, Janie Wargo, Jason Hansen, Tim Bray, Dan Brickley, Markus 1338 Hofmann, Dan Connolly, Tim Berners-Lee, Harry Chen, Adrien Macneil, 1339 Louis Suarez-Potts, Ross Smith, Rahul Sundaram, Jesse Keating, Michal 1340 Bentkowski, Andrew Pantyukhin, Judd Vinet, Charles Landemaine, Pascal 1341 Bleser, Jeff@BLAG, Yuichiro Nakada, Jereme Hancock, Marcel Hauser, 1342 Jeff Covey, Doug Lang, Seth Brown, Alexander Lazic, Mayank Sharma, 1343 Robin Heggelund Hansen, Steve Langasek, Federico Parodi, Stefano 1344 Verna, Jason Green, James Linden, Matt Nederlanden, Aren Olsen, Dag 1345 Odenhall, Troy Sobotka, Corey Farwell, Ed Lee, Shawn Wilsher, Mike 1346 Connor, Anand Muttagi, Debi Goulding, the Anthony Family, the Bryan 1347 Family, Juanita Anthony and Zimmy Bryan. 1349 Appendix B. RELAX NG Compact Schema 1351 This appendix is informative. 1353 The Relax NG schema explicitly excludes elements in the Metalink 1354 namespace that are not defined in this revision of the specification. 1356 Requirements for Metalink Processors encountering such markup are 1357 given in Sections 7.2 and 7.3. 1359 # -*- rnc -*- 1360 # RELAX NG Compact Syntax Grammar for the 1361 # Metalink Format Specification Version 1 1363 namespace metalink = "urn:ietf:params:xml:ns:metalink" 1364 namespace xsd = "http://www.w3.org/2001/XMLSchema" 1366 # Common attributes 1368 metalinkCommonAttributes = 1369 attribute xml:base { metalinkUri }?, 1370 attribute xml:lang { metalinkLanguageTag }?, 1371 undefinedAttribute* 1373 # Text Constructs 1375 metalinkTextConstruct = 1376 metalinkCommonAttributes, 1377 text 1379 # Date Construct 1381 metalinkDateConstruct = 1382 metalinkCommonAttributes, 1383 xsd:dateTime 1385 start = 1386 element metalink:metalink { 1387 element metalink:generator { 1388 attribute uri { metalinkUri }?, 1389 attribute version { text }?, 1390 metalinkTextConstruct 1391 } 1392 element metalink:origin { metalinkUri }?, 1393 element metalink:type { "static" | "dynamic" }?, 1394 element metalink:published { metalinkDateConstruct }?, 1395 element metalink:updated { metalinkDateConstruct }?, 1396 element metalink:files { 1397 element metalink:file { 1398 attribute name { metalinkTextConstruct }, 1399 element metalink:identity { metalinkTextConstruct }?, 1400 element metalink:version { metalinkTextConstruct }?, 1401 element metalink:size { xsd:integer }?, 1402 element metalink:description { metalinkTextConstruct }?, 1403 element metalink:license { 1404 attribute uri { metalinkUri }?, 1405 attribute name { metalinkTextConstruct }?, 1406 }?, 1407 element metalink:logo { metalinkUri }?, 1408 element metalink:publisher { 1409 attribute uri { metalinkUri }?, 1410 attribute name { metalinkTextConstruct }?, 1411 }?, 1412 element metalink:language { metalinkTextConstruct }?, 1413 element metalink:copyright { metalinkTextConstruct }?, 1414 element metalink:license { metalinkTextConstruct }?, 1415 element metalink:os { metalinkTextConstruct }?, 1416 element metalink:verification { 1417 hash+, 1418 element metalink:pieces { 1419 attribute length { metalinkTextConstruct }, 1420 attribute type { metalinkTextConstruct }, 1421 hash+ 1422 }+, 1423 element metalink:signature { 1424 attribute type { "pgp" }, 1425 text 1426 } 1427 }?, 1428 element metalink:resources { 1429 element metalink:metadata { 1430 attribute preference { xsd:integer }?, 1431 attribute type { metalinkTextConstruct }, 1432 metalinkUri 1433 element metalink:url { 1434 attribute location { xsd:string { 1435 minLength = "2" maxLength="2"} 1436 }?, 1437 attribute preference { xsd:integer }?, 1438 metalinkUri 1439 }+ 1440 } 1441 }+ 1442 } 1443 } 1444 hash = 1445 element metalink:hash { 1446 attribute piece { metalinkTextConstruct }?, 1447 attribute type { metalinkTextConstruct }, 1448 text 1449 } 1451 # As defined in RFC 3066 1452 metalinkLanguageTag = xsd:string { 1453 pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*" 1454 } 1456 # Unconstrained; it's not entirely clear how IRI fit into 1457 # xsd:anyURI so let's not try to constrain it here 1458 metalinkUri = text 1460 # Simple Extension 1462 simpleExtensionElement = 1463 element * - metalink:* { 1464 text 1465 } 1467 # Structured Extension 1469 structuredExtensionElement = 1470 element * - metalink:* { 1471 (attribute * { text }+, 1472 (text|anyElement)*) 1473 | (attribute * { text }*, 1474 (text?, anyElement+, (text|anyElement)*)) 1475 } 1477 # Other Extensibility 1479 extensionElement = 1480 simpleExtensionElement | structuredExtensionElement 1482 undefinedAttribute = 1483 attribute * - (xml:base | xml:lang | local:*) { text } 1485 undefinedContent = (text|anyForeignElement)* 1487 anyElement = 1488 element * { 1489 (attribute * { text } 1490 | text 1491 | anyElement)* 1492 } 1494 anyForeignElement = 1495 element * - metalink:* { 1496 (attribute * { text } 1497 | text 1498 | anyElement)* 1500 } 1502 # EOF 1504 Index 1506 A 1507 application/metalink+xml Media Type 25 1509 C 1510 copyright XML element 14 1512 D 1513 description XML element 14 1515 F 1516 file XML element 11 1517 files XML element 10 1519 G 1520 generator XML element 14 1521 Grammar 1522 metalinkCommonAttributes 7 1523 metalinkCopyright 14 1524 metalinkDateConstruct 8 1525 metalinkDescription 14 1526 metalinkFile 11 1527 metalinkFiles 10 1528 metalinkGenerator 15 1529 metalinkHash 15 1530 metalinkIdentity 16 1531 metalinkLanguage 16 1532 metalinkLicense 16 1533 metalinkLogo 17 1534 metalinkMetalink 9 1535 metalinkOrigin 18 1536 metalinkOS 18 1537 metalinkPieces 14 1538 metalinkPublished 18 1539 metalinkPublisher 18 1540 metalinkResources 12 1541 metalinkSignature 19 1542 metalinkSize 19 1543 metalinkTextConstruct 7 1544 metalinkType 20 1545 metalinkUpdated 20 1546 metalinkURL 17, 20 1547 metalinkVerification 13 1548 metalinkVersion 21 1549 simpleExtensionElement 24 1550 structuredExtensionElement 25 1552 H 1553 hash XML element 15 1555 I 1556 identity XML element 16 1558 L 1559 language XML element 16 1560 license XML element 16 1561 logo XML element 17 1563 M 1564 Media Type 1565 application/metalink+xml 25 1566 metadata XML element 17 1567 metalink XML element 9 1568 metalinkCommonAttributes grammar production 7 1569 metalinkCopyright grammar production 14 1570 metalinkDateConstruct grammar production 8 1571 metalinkDescription grammar production 14 1572 metalinkFile grammar production 11 1573 metalinkFiles grammar production 10 1574 metalinkGenerator grammar production 15 1575 metalinkHash grammar production 15 1576 metalinkIdentity grammar production 16 1577 metalinkLanguage grammar production 16 1578 metalinkLicense grammar production 16 1579 metalinkLogo grammar production 17 1580 metalinkMetalink grammar production 9 1581 metalinkOrigin grammar production 18 1582 metalinkOS grammar production 18 1583 metalinkPieces grammar production 14 1584 metalinkPublished grammar production 18 1585 metalinkPublisher grammar production 18 1586 metalinkResources grammar production 12 1587 metalinkSignature grammar production 19 1588 metalinkSize grammar production 19 1589 metalinkTextConstruct grammar production 7 1590 metalinkType grammar production 20 1591 metalinkUpdated grammar production 20 1592 metalinkURL grammar production 17, 20 1593 metalinkVerification grammar production 13 1594 metalinkVersion grammar production 21 1596 O 1597 origin XML element 18 1598 os XML element 18 1600 P 1601 pieces XML element 13 1602 published XML element 18 1603 publisher XML element 18 1605 R 1606 resources XML element 12 1608 S 1609 signature XML element 19 1610 simpleExtensionElement grammar production 24 1611 size XML element 19 1612 structuredExtensionElement grammar production 25 1614 T 1615 type XML element 19 1617 U 1618 updated XML element 20 1619 url XML element 20 1621 V 1622 verification XML element 13 1623 version XML element 21 1625 X 1626 XML Elements 1627 copyright 14 1628 description 14 1629 entry 11 1630 files 10 1631 generator 14 1632 hash 15 1633 identity 16 1634 language 16 1635 license 16 1636 logo 17 1637 metadata 17 1638 metalink 9 1639 origin 18 1640 os 18 1641 pieces 13 1642 published 18 1643 publisher 18 1644 resources 12 1645 signature 19 1646 size 19 1647 type 19 1648 updated 20 1649 url 20 1650 verification 13 1651 version 21 1653 Author's Address 1655 Anthony Bryan (editor) 1656 Metalinker Project 1658 Email: anthonybryan@gmail.com 1659 URI: http://www.metalinker.org 1661 Full Copyright Statement 1663 Copyright (C) The IETF Trust (2008). 1665 This document is subject to the rights, licenses and restrictions 1666 contained in BCP 78, and except as set forth therein, the authors 1667 retain all their rights. 1669 This document and the information contained herein are provided on an 1670 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1671 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1672 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1673 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1674 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1675 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1677 Intellectual Property 1679 The IETF takes no position regarding the validity or scope of any 1680 Intellectual Property Rights or other rights that might be claimed to 1681 pertain to the implementation or use of the technology described in 1682 this document or the extent to which any license under such rights 1683 might or might not be available; nor does it represent that it has 1684 made any independent effort to identify any such rights. Information 1685 on the procedures with respect to rights in RFC documents can be 1686 found in BCP 78 and BCP 79. 1688 Copies of IPR disclosures made to the IETF Secretariat and any 1689 assurances of licenses to be made available, or the result of an 1690 attempt made to obtain a general license or permission for the use of 1691 such proprietary rights by implementers or users of this 1692 specification can be obtained from the IETF on-line IPR repository at 1693 http://www.ietf.org/ipr. 1695 The IETF invites any interested party to bring to its attention any 1696 copyrights, patents or patent applications, or other proprietary 1697 rights that may cover technology that may be required to implement 1698 this standard. Please address the information to the IETF at 1699 ietf-ipr@ietf.org.