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