metalink4-ruby 1.0.0

data/metalink4-ruby.gemfile

@@ -0,0 +1,19 @@
+# coding: utf-8
+
+Gem::Specification.new do |s|
+  s.name        = 'metalink4-ruby'
+  s.version     = '1.0.0'
+  s.summary     = "Class to format Metalink 4 / rfc5854 / .meta4 XML"
+  s.authors     = ["Sudrien"]
+  s.email       = '_+github@sudrien.net'
+  s.files       = ['lib/metalink4.rb', 'metalink4-ruby.gemfile','README.md','rfc5854.txt','LICENSE']
+  s.require_paths = ["lib"]
+  s.homepage    = 'https://github.com/Sudrien/metalink4-ruby'
+  s.license     = 'MIT'
+
+  s.required_ruby_version = Gem::Requirement.new(">= 1.9.3")
+  
+  s.add_runtime_dependency "builder"
+  s.add_runtime_dependency "mime-types"
+  s.add_runtime_dependency "nokogiri"
+end

data/rfc5854.txt

@@ -0,0 +1,2187 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          A. Bryan
+Request for Comments: 5854                                  T. Tsujikawa
+Category: Standards Track                                       N. McNab
+ISSN: 2070-1721
+                                                                P. Poeml
+                                                             MirrorBrain
+                                                               June 2010
+
+
+                The Metalink Download Description Format
+
+Abstract
+
+   This document specifies Metalink, an XML-based download description
+   format.  Metalink describes download locations (mirrors),
+   cryptographic hashes, and other information.  Clients can
+   transparently use this information to reliably transfer files.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5854.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+Bryan, et al.                Standards Track                    [Page 1]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  4
+     1.2.  Namespace and Version  . . . . . . . . . . . . . . . . . .  5
+     1.3.  Notational Conventions . . . . . . . . . . . . . . . . . .  5
+   2.  Metalink Documents . . . . . . . . . . . . . . . . . . . . . .  6
+   3.  Common Metalink Constructs . . . . . . . . . . . . . . . . . .  7
+     3.1.  Text Constructs  . . . . . . . . . . . . . . . . . . . . .  7
+     3.2.  Date Constructs  . . . . . . . . . . . . . . . . . . . . .  8
+   4.  Metalink Element Definitions . . . . . . . . . . . . . . . . .  8
+     4.1.  Container Elements . . . . . . . . . . . . . . . . . . . .  8
+       4.1.1.  The "metalink:metalink" Element  . . . . . . . . . . .  8
+       4.1.2.  The "metalink:file" Element  . . . . . . . . . . . . .  9
+       4.1.3.  The "metalink:pieces" Element  . . . . . . . . . . . . 12
+     4.2.  Metadata Elements  . . . . . . . . . . . . . . . . . . . . 12
+       4.2.1.  The "metalink:copyright" Element . . . . . . . . . . . 12
+       4.2.2.  The "metalink:description" Element . . . . . . . . . . 13
+       4.2.3.  The "metalink:generator" Element . . . . . . . . . . . 13
+       4.2.4.  The "metalink:hash" Element  . . . . . . . . . . . . . 14
+       4.2.5.  The "metalink:identity" Element  . . . . . . . . . . . 15
+       4.2.6.  The "metalink:language" Element  . . . . . . . . . . . 15
+       4.2.7.  The "metalink:logo" Element  . . . . . . . . . . . . . 16
+       4.2.8.  The "metalink:metaurl" Element . . . . . . . . . . . . 16
+       4.2.9.  The "metalink:origin" Element  . . . . . . . . . . . . 18
+       4.2.10. The "metalink:os" Element  . . . . . . . . . . . . . . 18
+       4.2.11. The "metalink:published" Element . . . . . . . . . . . 18
+       4.2.12. The "metalink:publisher" Element . . . . . . . . . . . 18
+       4.2.13. The "metalink:signature" Element . . . . . . . . . . . 19
+       4.2.14. The "metalink:size" Element  . . . . . . . . . . . . . 20
+       4.2.15. The "metalink:updated" Element . . . . . . . . . . . . 20
+       4.2.16. The "metalink:url" Element . . . . . . . . . . . . . . 20
+       4.2.17. The "metalink:version" Element . . . . . . . . . . . . 21
+   5.  Extending Metalink . . . . . . . . . . . . . . . . . . . . . . 21
+     5.1.  Extensions from Non-Metalink Vocabularies  . . . . . . . . 21
+     5.2.  Extensions to the Metalink Vocabulary  . . . . . . . . . . 21
+     5.3.  Processing Foreign Markup  . . . . . . . . . . . . . . . . 22
+     5.4.  Extension Elements . . . . . . . . . . . . . . . . . . . . 22
+       5.4.1.  Simple Extension Elements  . . . . . . . . . . . . . . 22
+       5.4.2.  Structured Extension Elements  . . . . . . . . . . . . 23
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
+     6.1.  XML Namespace Registration . . . . . . . . . . . . . . . . 23
+     6.2.  application/metalink4+xml MIME type  . . . . . . . . . . . 23
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
+     7.1.  Digital Signatures . . . . . . . . . . . . . . . . . . . . 25
+     7.2.  URIs and IRIs  . . . . . . . . . . . . . . . . . . . . . . 26
+     7.3.  Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 26
+     7.4.  Cryptographic Hashes . . . . . . . . . . . . . . . . . . . 26
+
+
+
+Bryan, et al.                Standards Track                    [Page 2]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 28
+   Appendix A.  Acknowledgements and Contributors . . . . . . . . . . 30
+   Appendix B.  RELAX NG Compact Schema . . . . . . . . . . . . . . . 31
+   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
+
+1.  Introduction
+
+   Metalink is a document format based on Extensible Markup Language
+   (XML) that describes a file or list of files to be downloaded from a
+   server.  Metalinks can list a number of files, each with an
+   extensible set of attached metadata.  Each listed file can have a
+   description, multiple cryptographic hashes, and a list of Uniform
+   Resource Identifiers (URIs) from which it is available.
+
+   Often, identical copies of a file are accessible in multiple
+   locations on the Internet over a variety of protocols, such as File
+   Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), and
+   Peer-to-Peer (P2P).  In some cases, users are shown a list of these
+   multiple download locations (mirror servers) and must manually select
+   one based on geographical location, priority, or bandwidth.  This is
+   done to distribute the load across multiple servers, and to give
+   human users the opportunity to choose a download location that they
+   expect to work best for them.
+
+   At times, individual servers can be slow, outdated, or unreachable,
+   but this cannot be determined until the download has been initiated.
+   This can lead to the user canceling the download and needing to
+   restart it.  During downloads, errors in transmission can corrupt the
+   file.  There are no easy ways to repair these files.  For large
+   downloads, this can be especially troublesome.  Any of the number of
+   problems that can occur during a download lead to frustration on the
+   part of users, and bandwidth wasted with retransmission.
+
+   Knowledge about availability of a download on mirror servers can be
+   acquired and maintained by the operators of the origin server or by a
+   third party.  This knowledge, together with cryptographic hashes,
+   digital signatures, and more, can be stored in a machine-readable
+   Metalink file.  The Metalink file can transfer this knowledge to the
+   user agent, which can peruse it in automatic ways or present the
+   information to a human user.  User agents can fall back to alternate
+   mirrors if the current one has an issue.  Thereby, clients are
+   enabled to work their way to a successful download under adverse
+   circumstances.  All this can be done transparently to the human user
+   and the download is much more reliable and efficient.  In contrast, a
+
+
+
+
+
+Bryan, et al.                Standards Track                    [Page 3]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   traditional HTTP redirect to one mirror conveys only comparatively
+   minimal information -- a referral to a single server, and there is no
+   provision in the HTTP protocol to handle failures.
+
+   Other features that some clients provide include multi-source
+   downloads, where chunks of a file are downloaded from multiple
+   mirrors (and optionally, Peer-to-Peer) simultaneously, which
+   frequently results in a faster download.  Metalinks can leverage
+   HTTP, FTP, and Peer-to-Peer protocols together, because regardless of
+   the protocol over which the Metalink was obtained, it can make a
+   resource accessible through other protocols.  If the Metalink was
+   obtained from a trusted source, included verification metadata can
+   solve trust issues when downloading files from replica servers
+   operated by third parties.  Metalinks also provide structured
+   information about downloads that can be indexed by search engines.
+
+1.1.  Examples
+
+   A brief, Metalink Document that describes a single file:
+
+   <?xml version="1.0" encoding="UTF-8"?>
+   <metalink xmlns="urn:ietf:params:xml:ns:metalink">
+     <file name="example.ext">
+       <size>14471447</size>
+       <url>ftp://ftp.example.com/example.ext</url>
+       <url>http://example.com/example.ext</url>
+       <metaurl mediatype="torrent">
+       http://example.com/example.ext.torrent</metaurl>
+     </file>
+   </metalink>
+
+   A more extensive Metalink Document that describes two files:
+
+ <?xml version="1.0" encoding="UTF-8"?>
+ <metalink xmlns="urn:ietf:params:xml:ns:metalink">
+   <published>2009-05-15T12:23:23Z</published>
+   <file name="example.ext">
+     <size>14471447</size>
+     <identity>Example</identity>
+     <version>1.0</version>
+     <language>en</language>
+     <description>
+     A description of the example file for download.
+     </description>
+     <hash type="sha-256">f0ad929cd259957e160ea442eb80986b5f01...</hash>
+     <url location="de"
+          priority="1">ftp://ftp.example.com/example.ext</url>
+
+
+
+
+Bryan, et al.                Standards Track                    [Page 4]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+     <url location="fr"
+          priority="1">http://example.com/example.ext</url>
+     <metaurl mediatype="torrent"
+          priority="2">http://example.com/example.ext.torrent</metaurl>
+   </file>
+   <file name="example2.ext">
+     <size>14471447</size>
+     <identity>Example2</identity>
+     <version>1.0</version>
+     <language>en</language>
+     <description>
+     Another description for a second file.
+     </description>
+     <hash type="sha-256">2f548ce50c459a0270e85a7d63b2383c5523...</hash>
+     <url location="de"
+          priority="1">ftp://ftp.example.com/example2.ext</url>
+     <url location="fr"
+          priority="1">http://example.com/example2.ext</url>
+     <metaurl mediatype="torrent"
+          priority="2">http://example.com/example2.ext.torrent</metaurl>
+   </file>
+ </metalink>
+
+1.2.  Namespace and Version
+
+   The XML Namespaces URI [REC-xml-names] for the XML data format
+   described in this specification is:
+
+   urn:ietf:params:xml:ns:metalink
+
+   For convenience, this data format may be referred to as "Metalink",
+   which this specification uses internally.
+
+1.3.  Notational Conventions
+
+   This specification describes conformance of Metalink Documents.
+   Additionally, it places some requirements on Metalink Processors.
+
+   This specification uses the namespace prefix "metalink:" for the
+   Namespace URI identified in Section 1.2, above.  Note that the choice
+   of namespace prefix is arbitrary and not semantically significant.
+
+   Metalink is specified using terms from the XML Infoset
+   [REC-xml-infoset].  However, this specification uses a shorthand for
+   two common terms: the phrase "Information Item" is omitted when
+   naming Element Information Items and Attribute Information Items.
+   Therefore, when this specification uses the term "element," it is
+   referring to an Element Information Item in Infoset terms.  Likewise,
+
+
+
+Bryan, et al.                Standards Track                    [Page 5]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   when it uses the term "attribute," it is referring to an Attribute
+   Information Item.
+
+   Some sections of this specification are illustrated with fragments of
+   a non-normative RELAX NG Compact schema [RELAX-NG].  However, the
+   text of this specification provides the definition of conformance.  A
+   complete schema appears in Appendix B.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, [RFC2119], as
+   scoped to those conformance targets.
+
+2.  Metalink Documents
+
+   This specification describes Metalink Documents.
+
+   A Metalink Document describes a file or group of files, how to access
+   them, and metadata that identifies them.  Its root is the metalink:
+   metalink element.
+
+   namespace metalink = "urn:ietf:params:xml:ns:metalink"
+   start = metalinkMetalink
+
+   Metalink Documents are specified in terms of the XML Information Set,
+   serialized as XML 1.0 [REC-xml] and identified with the "application/
+   metalink4+xml" media type.
+
+   Metalink Documents MUST be well-formed XML.  This specification does
+   not define a Document Type Definition (DTD) for Metalink Documents,
+   and hence it does not require them to be valid (in the sense used by
+   XML).
+
+   Metalink allows the use of Internationalized Resource Identifiers
+   (IRIs), encoded according to [RFC3987].  Every URI [RFC3986] is also
+   an IRI, so a URI may be used wherever an IRI is named below.  There
+   is one special consideration: when an IRI that is not also a URI is
+   given for dereferencing, it MUST be mapped to a URI using the steps
+   in Section 3.1 of [RFC3987].
+
+   Any element defined by this specification MAY have an xml:lang
+   attribute, whose content indicates the natural language for the
+   element and its descendents.  The language context is only
+   significant for elements and attributes declared to be "Language-
+   Sensitive" by this specification.  Requirements regarding the content
+   and interpretation of xml:lang are specified in XML 1.0 [REC-xml],
+   Section 2.12.
+
+
+
+
+Bryan, et al.                Standards Track                    [Page 6]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   metalinkCommonAttributes =
+      attribute xml:lang { metalinkLanguageTag }?,
+      undefinedAttribute*
+
+   All leading and trailing whitespace is part of the element content
+   and MUST NOT be ignored.  Consequently, it is disallowed for elements
+   where the defined type does not allow whitespace, such as dates,
+   integers, or IRIs.  Some XML-generating implementations erroneously
+   insert whitespace around values by default, and such implementations
+   will generate invalid Metalink Documents.
+
+   Metalink Documents that do not follow this specification are invalid
+   and SHOULD NOT be used by Metalink Processors.
+
+   Metalink is an extensible format.  See Section 5 of this document for
+   a full description of how Metalink Documents can be extended.
+
+3.  Common Metalink Constructs
+
+   Many Metalink elements share common structures.  This section defines
+   those structures and their requirements for convenient reference by
+   the appropriate element definitions.
+
+   When an element is identified as being a particular kind of
+   construct, it inherits the corresponding requirements from that
+   construct's definition in this section.
+
+3.1.  Text Constructs
+
+   A Text construct contains human-readable text, usually short in
+   length.
+
+   metalinkTextConstruct =
+      metalinkCommonAttributes,
+      text
+
+   For example, a metalink:description with text content:
+
+   ...
+   <description>
+   A description of the example file for download.
+   </description>
+   ...
+
+   The content of the Text construct MUST NOT contain child elements.
+   Such text is intended to be presented to humans in a readable
+   fashion.  Thus, whitespace could be collapsed (including line
+
+
+
+
+Bryan, et al.                Standards Track                    [Page 7]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   breaks), and text could be displayed using typographic techniques
+   such as justification and proportional fonts.
+
+3.2.  Date Constructs
+
+   A Date construct is an element whose content MUST conform to the
+   "date-time" production in [RFC3339].  In addition, an uppercase "T"
+   character MUST be used to separate date and time, and an uppercase
+   "Z" character MUST be present in the absence of a numeric time zone
+   offset.
+
+   metalinkDateConstruct =
+      metalinkCommonAttributes,
+      xsd:dateTime
+
+   Such date values happen to be compatible with the following
+   specifications: [ISO.8601.1988], [NOTE-datetime-19980827], and
+   [REC-xmlschema-2-20041028].
+
+   Example Date constructs:
+
+   ...
+   <updated>2010-05-01T12:15:02Z</updated>
+   ...
+   <updated>2010-05-01T12:15:02.25Z</updated>
+   ...
+   <updated>2010-05-01T12:15:02+01:00</updated>
+   ...
+   <updated>2010-05-01T12:15:02.25+01:00</updated>
+   ...
+
+4.  Metalink Element Definitions
+
+4.1.  Container Elements
+
+4.1.1.  The "metalink:metalink" Element
+
+   The "metalink:metalink" element is the document (i.e., top-level)
+   element of a Metalink Document, acting as a container for metadata
+   and data associated with the listed files.  It contains one or more
+   metalink:file child elements that consist of Metadata elements.
+
+   metalinkMetalink =
+      element metalink:metalink {
+         metalinkCommonAttributes,
+         (metalinkFile+
+          & metalinkGenerator?
+          & metalinkOrigin?
+
+
+
+Bryan, et al.                Standards Track                    [Page 8]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+          & metalinkPublished?
+          & metalinkUpdated?
+          & extensionElement*)
+      }
+
+   The following child elements are defined by this specification (note
+   that the presence of some of these elements is required):
+
+   o  metalink:metalink elements MUST contain one or more metalink:file
+      elements.
+
+   o  metalink:metalink elements MAY contain exactly one metalink:
+      generator element and MUST NOT contain more than one such element.
+
+   o  metalink:metalink elements SHOULD contain exactly one metalink:
+      origin element and MUST NOT contain more than one such element.
+
+   o  metalink:metalink elements MAY contain exactly one metalink:
+      published element and MUST NOT contain more than one such element.
+
+   o  metalink:metalink elements MAY contain exactly one metalink:
+      updated element and MUST NOT contain more than one such element.
+
+4.1.1.1.  Providing Textual Content
+
+   Experience teaches that downloads providing textual content are, in
+   general, more useful than those that do not.  Some applications (one
+   example is full-text indexers) require a minimum amount of text to
+   function reliably and predictably.  Metalink publishers should be
+   aware of this.  It is RECOMMENDED that each metalink:file element
+   contain a non-empty metalink:description element, a non-empty
+   metalink:identity element, a non-empty metalink:version element, and
+   a non-empty metalink:publisher element when these elements are
+   present.  However, the absence of metalink:description, metalink:
+   identity, metalink:version, and metalink:publisher is not an error,
+   and Metalink Processors MUST NOT fail to function correctly as a
+   consequence of such an absence.
+
+4.1.2.  The "metalink:file" Element
+
+   The "metalink:file" element represents an individual file, acting as
+   a container for metadata and data associated with the file.  Each
+   unique file described in a Metalink Document MUST have its own
+   metalink:file element.
+
+   All metalink:url elements contained in each metalink:file element
+   SHOULD lead to identical files.  That is, each metalink:url element
+   should be an alternative location for the same file and each
+
+
+
+Bryan, et al.                Standards Track                    [Page 9]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   metalink:metaurl element should provide metadata to retrieve the same
+   file in another way, such as a Peer-to-Peer network.  Refer to
+   Sections 4.2.8 and 4.2.16 for more information.
+
+   metalinkFile =
+      element metalink:file {
+         metalinkCommonAttributes,
+         attribute name { text },
+         (metalinkCopyright?
+          & metalinkDescription?
+          & metalinkHash*
+          & metalinkIdentity?
+          & metalinkLanguage*
+          & metalinkLogo?
+          & metalinkMetaURL*
+          & metalinkOS*
+          & metalinkPieces*
+          & metalinkPublisher?
+          & metalinkSignature?
+          & metalinkSize?
+          & metalinkURL*
+          & metalinkVersion?
+          & extensionElement*)
+      }
+
+   This specification assigns no significance to the order of metalink:
+   file elements or to the order of metalink:url or metalink:metaurl
+   elements.  Significance is determined by the value of the "priority"
+   attribute of the metalink:url or metalink:metaurl elements.
+
+   The following child elements are defined by this specification (the
+   presence of some of them is required):
+
+   o  metalink:file elements MAY contain exactly one metalink:copyright
+      element and MUST NOT contain more than one such element.
+
+   o  metalink:file elements MAY contain exactly one metalink:
+      description element and MUST NOT contain more than one such
+      element.
+
+   o  metalink:file elements MAY contain exactly one metalink:identity
+      element and MUST NOT contain more than one such element.
+
+   o  metalink:file elements MAY contain one or more metalink:hash
+      elements.
+
+   o  metalink:file elements MAY contain one or more metalink:language
+      elements.
+
+
+
+Bryan, et al.                Standards Track                   [Page 10]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   o  metalink:file elements MAY contain exactly one metalink:logo
+      element and MUST NOT contain more than one such element.
+
+   o  metalink:file elements MAY contain one or more metalink:os
+      element.
+
+   o  metalink:file elements MUST contain at least one metalink:url
+      element or at least one metalink:metaurl element.  Typically,
+      metalink:file elements contain more than one metalink:url element
+      to provide multiple download sources.
+
+   o  metalink:file elements MAY contain one or more metalink:pieces
+      elements.
+
+   o  metalink:file elements MAY contain exactly one metalink:publisher
+      element and MUST NOT contain more than one such element.
+
+   o  metalink:file elements MAY contain one or more metalink:signature
+      elements.
+
+   o  metalink:file elements SHOULD contain exactly one metalink:size
+      element and MUST NOT contain more than one such element.
+
+   o  metalink:file elements MAY contain exactly one metalink:version
+      element and MUST NOT contain more than one such element.
+
+4.1.2.1.  The "name" Attribute
+
+   metalink:file elements MUST have a "name" attribute, which contains
+   the local file name to which the downloaded file will be written.
+   Hence, if a Metalink Document contains multiple metalink:file
+   elements, the value of the "name" attribute MUST be unique for each.
+
+   Directory information can also be contained in a "path/file" format
+   only, as in:
+
+   <file name="debian-amd64/sarge/Contents-amd64.gz">
+
+   In this example, a subdirectory "debian-amd64/sarge/" will be created
+   and a file named "Contents-amd64.gz" will be created inside it.
+
+      Security Note: The path MUST NOT contain any directory traversal
+      directives or information.  The path MUST be relative.  The path
+      MUST NOT begin with a "/", "./", or "../"; contain "/../"; or end
+      with "/..".
+
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 11]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+4.1.3.  The "metalink:pieces" Element
+
+   The "metalink:pieces" element acts as a container for a list of
+   cryptographic hashes of contiguous, non-overlapping pieces of the
+   file.  The cryptographic hashes MUST be listed in the same order as
+   the corresponding pieces appear in the file, starting at the
+   beginning of the file.  Metalink Documents MAY contain one or
+   multiple metalink:pieces container elements, if each "type" attribute
+   of metalink:pieces has a unique value.
+
+   metalinkPieces =
+      element metalink:pieces {
+         attribute length { xsd:positiveInteger },
+         attribute type { text },
+         metalinkHash+
+      }
+
+4.1.3.1.  The "type" Attribute
+
+   metalink:pieces elements MUST have a "type" attribute.
+
+   The Internet Assigned Numbers Authority (IANA) registry named "Hash
+   Function Textual Names" defines values for hash types.  See
+   Section 7.4 for security implications.
+
+4.1.3.2.  The "length" Attribute
+
+   metalink:pieces elements MUST have a "length" attribute, which is a
+   positive integer that describes the length of the pieces of the file
+   in octets.  The whole file is divided into non-overlapping pieces of
+   this length, starting from the beginning of the file.  That is, every
+   piece MUST be the same size, apart from the last piece, which is the
+   remainder.  The last piece extends to the end of the file, and it
+   therefore MAY be shorter than the other pieces.
+
+4.2.  Metadata Elements
+
+4.2.1.  The "metalink:copyright" Element
+
+   The "metalink:copyright" element is a Text construct that conveys a
+   human-readable copyright for a file.  It is Language-Sensitive.
+
+   metalinkCopyright =
+      element metalink:copyright {
+        metalinkTextConstruct
+      }
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 12]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+4.2.2.  The "metalink:description" Element
+
+   The "metalink:description" element is a Text construct that conveys a
+   human-readable file description.  It is Language-Sensitive.
+
+   metalinkDescription =
+      element metalink:description {
+        metalinkTextConstruct
+      }
+
+4.2.3.  The "metalink:generator" Element
+
+   The "metalink:generator" element's content identifies the generating
+   agent name and version used to generate a Metalink Document, for
+   debugging and other purposes.
+
+   metalinkGenerator =
+      element metalink:generator {
+        metalinkTextConstruct
+      }
+
+   The metalink:generator element's content is defined below in ABNF
+   notation [RFC5234].
+
+   token          = 1*<any CHAR except CTLs or separators>
+   separators     = "(" / ")" / "<" / ">" / "@"
+                  / "," / ";" / ":" / "\" / DQUOTE
+                  / "/" / "[" / "]" / "?" / "="
+                  / "{" / "}" / SP / HTAB
+   agent         = token ["/" agent-version]
+   agent-version = token
+
+   Examples:
+
+   ...
+   <generator>MirrorBrain/2.11</generator>
+   ...
+   <generator>MirrorManager/1.2.11</generator>
+   ...
+   <generator>metalinktools/0.3.6</generator>
+   ...
+   <generator>MetalinkEditor/1.2.0</generator>
+   ...
+
+   Although any token character MAY appear in an agent-version, this
+   token SHOULD only be used for a version identifier (i.e., successive
+   versions of the same agent SHOULD only differ in the agent-version
+   portion of the agent value).
+
+
+
+Bryan, et al.                Standards Track                   [Page 13]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+4.2.4.  The "metalink:hash" Element
+
+   The "metalink:hash" element is a Text construct that conveys a
+   cryptographic hash for a file.  All hashes are encoded in lowercase
+   hexadecimal format.  Hashes are used to verify the integrity of a
+   complete file or portion of a file to determine if the file has been
+   transferred without any errors.
+
+   metalinkHash =
+      element metalink:hash {
+        attribute type { text }?,
+        text
+      }
+
+   Metalink Documents MAY contain one or multiples hashes of a complete
+   file. metalink:hash elements with a "type" attribute MUST contain a
+   hash of the complete file.  In this example, both SHA-1 and SHA-256
+   hashes of the complete file are included.
+
+ ...
+   <hash type="sha-1">a97fcf6ba9358f8a6f62beee4421863d3e52b080</hash>
+   <hash type="sha-256">fc87941af7fd7f03e53b34af393f4c14923d74...</hash>
+ ...
+
+   Metalink Documents MAY also contain hashes for individual pieces of a
+   file. metalink:hash elements that are inside a metalink:pieces
+   container element have a hash for that specific piece or chunk of the
+   file, and are of the same hash type as the metalink:pieces element in
+   which they are contained.  Metalink Documents MAY contain one or
+   multiple metalink:pieces container elements, if each "type" attribute
+   of metalink:pieces has a unique value.
+
+   metalink:hash elements without a "type" attribute MUST contain a hash
+   for that specific piece or chunk of the file and MUST be listed in
+   the same order as the corresponding pieces appear in the file,
+   starting at the beginning of the file.  The size of the piece is
+   equal to the value of the "length" attribute of the metalink:pieces
+   element, apart from the last piece, which is the remainder.  See
+   Section 4.1.3.2 for more information on the size of pieces.
+
+
+
+
+
+
+
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 14]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   In this example, SHA-1 and SHA-256 hashes of the complete file are
+   included, along with four SHA-1 piece hashes.
+
+ ...
+   <hash type="sha-1">a97fcf6ba9358f8a6f62beee4421863d3e52b080</hash>
+   <hash type="sha-256">fc87941af7fd7f03e53b34af393f4c14923d74...</hash>
+   <pieces length="1048576" type="sha-1">
+     <hash>d96b9a4b92a899c2099b7b31bddb5ca423bb9b30</hash>
+     <hash>10d68f4b1119014c123da2a0a6baf5c8a6d5ba1e</hash>
+     <hash>3e84219096435c34e092b17b70a011771c52d87a</hash>
+     <hash>67183e4c3ab892d3ebe8326b7d79eb62d077f487</hash>
+   </pieces>
+ ...
+
+4.2.4.1.  The "type" Attribute
+
+   metalink:hash elements MUST have a "type" attribute, if and only if
+   it contains a hash of the complete file.  The IANA registry named
+   "Hash Function Textual Names" defines values for hash types.
+   metalink:hash elements MUST NOT have a "type" attribute, if they are
+   inside a metalink:pieces container element.  See Section 7.4 for
+   security implications.
+
+4.2.5.  The "metalink:identity" Element
+
+   The "metalink:identity" element is a Text construct that conveys a
+   human-readable identity for a file.  For example, the identity of
+   Firefox 3.5 would be "Firefox".
+
+   metalinkIdentity =
+      element metalink:identity {
+        metalinkTextConstruct
+      }
+
+4.2.6.  The "metalink:language" Element
+
+   The "metalink:language" element is a Text construct that conveys a
+   code for the language of a file, per [RFC5646].
+
+   Multiple metalink:language elements are allowed, for instance, to
+   describe a file such as an binary installation program that provides
+   multiple language options, a movie with multiple language tracks, or
+   a document in multiple languages.
+
+   metalinkLanguage =
+      element metalink:language {
+        metalinkTextConstruct
+      }
+
+
+
+Bryan, et al.                Standards Track                   [Page 15]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+4.2.7.  The "metalink:logo" Element
+
+   The "metalink:logo" element's content is an IRI reference [RFC3987]
+   that identifies an image that provides visual identification for a
+   file.
+
+   metalinkLogo =
+      element metalink:logo {
+        metalinkCommonAttributes,
+        (metalinkUri)
+      }
+
+   The image SHOULD have an aspect ratio of one (horizontal) to one
+   (vertical) and SHOULD be suitable for presentation at a small size.
+
+4.2.8.  The "metalink:metaurl" Element
+
+   The "metalink:metaurl" element contains the IRI of a metadata file,
+   also known as a metainfo file, about a resource to download.  For
+   example, this could be the IRI of a BitTorrent .torrent file, a
+   Metalink Document, or other type of metadata file.  Note that the
+   information in the metalink:hash element does not apply to these
+   metadata files but to the files that are described by them.
+
+   metalinkMetaURL =
+      element metalink:metaurl {
+         metalinkCommonAttributes,
+         attribute priority { xsd:positiveInteger {
+            maxInclusive = "999999"}}?,
+         attribute mediatype { text },
+         attribute name { text }?,
+         (metalinkUri)
+      }
+
+4.2.8.1.  The "priority" Attribute
+
+   metalink:metaurl elements MAY have a priority attribute.  Values MUST
+   be positive integers between 1 and 999999.  Lower values indicate a
+   higher priority. metalink:metaurl elements without a priority
+   attribute are considered to have the lowest priority, i.e., 999999.
+   The priority values of metalink:metaurl and metalink:url elements are
+   compared and those with the lowest values, starting with 1, are used
+   first.  Multiple metalink:metaurl and metalink:url elements MAY have
+   the same priority, i.e., one BitTorrent .torrent file and three FTP
+   URIs could have priority="1".  See also the "priority" attribute of
+   the metalink:url element.
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 16]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+4.2.8.2.  The "mediatype" Attribute
+
+   metalink:metaurl elements MUST have a "mediatype" attribute that
+   indicates the Multipurpose Internet Mail Extensions (MIME) media type
+   [RFC4288] of the metadata file available at the IRI.  In the case of
+   BitTorrent as specified in [BITTORRENT], the value "torrent" is
+   REQUIRED.  Types without "/" are reserved.  Currently, "torrent" is
+   the only reserved value.
+
+   Values for this attribute are defined below in ABNF notation
+   [RFC5234].
+
+   media-type = (type-name "/" subtype-name) / media-reserved
+   media-reserved = "torrent"
+   type-name = <Defined in Section 4.2 of RFC 4288>
+   subtype-name = <Defined in Section 4.2 of RFC 4288>
+
+4.2.8.3.  The "name" Attribute
+
+   metalink:metaurl elements MAY have a "name" attribute that indicates
+   a specific file in a BitTorrent .torrent file or a Metalink Document
+   that describes multiple files.
+
+   Directory information can also be contained in a "path/file" format
+   only, as in:
+
+   <metaurl
+        mediatype="torrent" name="debian-amd64/sarge/Contents-amd64.gz">
+
+   In this example, a file named "Contents-amd64.gz" is indicated, in a
+   "debian-amd64/sarge/" subdirectory.  The path MUST NOT contain any
+   directory traversal directives or information.  The path MUST be
+   relative.  The path MUST NOT begin with a "/", "./", or "../";
+   contain "/../"; or end with "/..".
+
+4.2.9.  The "metalink:origin" Element
+
+   The "metalink:origin" element is an IRI where the Metalink Document
+   was originally published.  If the dynamic attribute of metalink:
+   origin is "true", then updated versions of the Metalink can be found
+   at this IRI.
+
+   metalinkOrigin =
+      element metalink:origin {
+        metalinkCommonAttributes,
+        attribute dynamic { xsd:boolean }?,
+        (metalinkUri)
+      }
+
+
+
+Bryan, et al.                Standards Track                   [Page 17]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+4.2.9.1.  The "dynamic" Attribute
+
+   The metalink:origin element MAY have a "dynamic" attribute, set to
+   "true" or "false", which tells if a Metalink at the origin IRI will
+   contain dynamic updated information or if it is static and not likely
+   to be updated.
+
+4.2.10.  The "metalink:os" Element
+
+   The "metalink:os" element is a Text construct that conveys an
+   Operating System that a file is suitable for.  The IANA registry
+   named "Operating System Names" defines values for OS types.
+
+   metalinkOS =
+      element metalink:os {
+        metalinkTextConstruct
+      }
+
+4.2.11.  The "metalink:published" Element
+
+   The "metalink:published" element is a Date construct indicating an
+   instant in time associated with an event early in the life cycle of
+   the entry.
+
+   metalinkPublished =
+      element metalink:published {
+        metalinkDateConstruct
+      }
+
+   Typically, metalink:published will be associated with the initial
+   creation or first availability of the resource.  The metalink:updated
+   element is used when a Metalink Document has been updated after
+   initial publication.
+
+4.2.12.  The "metalink:publisher" Element
+
+   The "metalink:publisher" element contains a human-readable group or
+   other entity that has published the file described in the Metalink
+   Document and an IRI for more information.
+
+   metalinkPublisher =
+      element metalink:publisher {
+        metalinkCommonAttributes,
+        attribute name { text },
+        attribute url { metalinkUri }?
+      }
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 18]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+4.2.12.1.  The "name" Attribute
+
+   The metalink:publisher element MUST have a "name" attribute that
+   indicates the human-readable name of the publisher.
+
+4.2.12.2.  The "url" Attribute
+
+   The metalink:publisher element MAY have a "url" attribute whose value
+   MUST be an IRI reference [RFC3987].
+
+4.2.13.  The "metalink:signature" Element
+
+   The "metalink:signature" element is a Text construct that conveys a
+   digital signature for a file described in a Metalink Document.
+   Digital signatures verify that a file is from the entity that has
+   signed it.
+
+   Support in Metalink Processors for digital signatures included in
+   this element is OPTIONAL.  Note that the signing of Metalink
+   Documents, as opposed to a digital signature of a file described in a
+   Metalink Document, is covered in Section 7.1.
+
+   metalinkSignature =
+      element metalink:signature {
+        attribute mediatype { text },
+        metalinkTextConstruct
+      }
+
+   Example with an OpenPGP signature [RFC4880]:
+
+   <signature mediatype="application/pgp-signature">
+   -----BEGIN PGP SIGNATURE-----
+   Version: GnuPG v1.4.10 (GNU/Linux)
+
+   iEYEABECAAYFAkrxdXQACgkQeOEcayedXJHqFwCfd1p/HhRf/iDvYhvFbTrQPz+p
+   p3oAoO9lKHoOqOE0EMB3zmMcLoYUrNkg
+   =ggAf
+   -----END PGP SIGNATURE-----
+   </signature>
+
+4.2.13.1.  The "mediatype" Attribute
+
+   metalink:signature elements MUST have a "mediatype" attribute that
+   indicates the MIME media type [RFC4288] of the included digital
+   signature.
+
+   Values for this attribute are defined below in ABNF notation
+   [RFC5234].
+
+
+
+Bryan, et al.                Standards Track                   [Page 19]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   media-type = type-name "/" subtype-name
+   type-name = <Defined in Section 4.2 of RFC 4288>
+   subtype-name = <Defined in Section 4.2 of RFC 4288>
+
+4.2.14.  The "metalink:size" Element
+
+   The "metalink:size" element indicates the length of the linked
+   content in octets.  This is the content length of the representation
+   returned when the IRI is mapped to a URI and dereferenced.  Note that
+   the "metalink:size" element MUST override the actual content length
+   of the representation as reported by the underlying protocol, and
+   those that do not match MUST be discarded by Metalink Processors.
+   This value MUST be a non-negative integer.
+
+   metalinkSize =
+      element metalink:size {
+        xsd:nonNegativeInteger
+      }
+
+4.2.15.  The "metalink:updated" Element
+
+   The "metalink:updated" element is a Date construct indicating the
+   most recent instant in time when a Metalink was modified in a way the
+   publisher considers significant.  Therefore, not all modifications
+   necessarily result in a changed metalink:updated value.
+
+   metalinkUpdated =
+      element metalink:updated {
+        metalinkDateConstruct
+      }
+
+   Publishers MAY change the value of this element over time.
+
+4.2.16.  The "metalink:url" Element
+
+   The "metalink:url" element contains a file IRI.  Most metalink:file
+   container elements will contain multiple metalink:url elements, and
+   each one SHOULD be a valid alternative to download the same file.
+
+   The metalink:url elements SHOULD be resolvable and, if resolvable,
+   SHOULD lead to identical files.
+
+   Metalink Processors MUST filter out invalid files obtained from
+   "metalink:url" elements by using information in the metalink:size
+   element and metalink:hash elements.
+
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 20]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   metalinkURL =
+      element metalink:url {
+         metalinkCommonAttributes,
+         attribute location { xsd:string {
+            minLength = "2"  maxLength="2"}
+         }?,
+         attribute priority { xsd:positiveInteger {
+            maxInclusive = "999999"}}?,
+         (metalinkUri)
+      }
+
+4.2.16.1.  The "priority" Attribute
+
+   metalink:url elements MAY have a priority attribute.  Values MUST be
+   positive integers between 1 and 999999.  Lower values indicate a
+   higher priority. metalink:url elements without a priority attribute
+   are considered to have the lowest priority, i.e., 999999.  Multiple
+   metalink:url elements can have the same priority, i.e., ten different
+   mirrors could have priority="1".
+
+4.2.16.2.  The "location" Attribute
+
+   metalink:url elements MAY have a "location" attribute, which is a
+   [ISO3166-1] alpha-2 two letter country code for the geographical
+   location of the physical server an IRI is used to access.
+
+4.2.17.  The "metalink:version" Element
+
+   The "metalink:version" element is a Text construct that conveys a
+   human-readable version for a file.  The version of Firefox 3.5 would
+   be "3.5".
+
+   metalinkVersion =
+      element metalink:version {
+        metalinkTextConstruct
+      }
+
+5.  Extending Metalink
+
+5.1.  Extensions from Non-Metalink Vocabularies
+
+   This specification describes Metalink's XML vocabulary.
+
+5.2.  Extensions to the Metalink Vocabulary
+
+   The Metalink namespace is reserved for future forward-compatible
+   revisions of Metalink.  Future versions of this specification could
+   add new elements and attributes to the Metalink markup vocabulary.
+
+
+
+Bryan, et al.                Standards Track                   [Page 21]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   Software written to conform to this version of the specification will
+   not be able to process such markup correctly and, in fact, will not
+   be able to distinguish it from markup error.  For the purposes of
+   this discussion, unrecognized markup from the Metalink vocabulary
+   will be considered "foreign markup".
+
+5.3.  Processing Foreign Markup
+
+   Metalink Processors that encounter foreign markup in a location that
+   is legal according to this specification MUST ignore such foreign
+   markup, in particular they MUST NOT stop processing or signal an
+   error.  It might be the case that the Metalink Processor is able to
+   process the foreign markup correctly and does so.  Otherwise, such
+   markup is termed "unknown foreign markup".
+
+   When unknown foreign markup is encountered as a child of metalink:
+   file, metalink:metalink, Metalink Processors MAY bypass the markup
+   and any textual content and MUST NOT change their behavior as a
+   result of the markup's presence.
+
+5.4.  Extension Elements
+
+   Metalink allows foreign markup anywhere in a Metalink document,
+   except where it is explicitly forbidden.  Child elements of metalink:
+   file and metalink:metalink are considered Metadata elements and are
+   described below.  The role of other foreign markup is undefined by
+   this specification.
+
+5.4.1.  Simple Extension Elements
+
+   A Simple Extension element MUST NOT have any attributes or child
+   elements.  The element MAY contain character data or be empty.
+   Simple Extension elements are not Language-Sensitive.
+
+   simpleExtensionElement =
+      element * - metalink:* {
+         text
+      }
+
+   The element can be interpreted as a simple property (or name/value
+   pair) of the parent element that encloses it.  The pair consisting of
+   the namespace URI of the element and the local name of the element
+   can be interpreted as the name of the property.  The character data
+   content of the element can be interpreted as the value of the
+   property.  If the element is empty, then the property value can be
+   interpreted as an empty string.
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 22]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+5.4.2.  Structured Extension Elements
+
+   The root element of a Structured Extension element MUST have at least
+   one attribute or child element.  It MAY have attributes, it MAY
+   contain well-formed XML content (including character data), or it MAY
+   be empty.  Structured Extension elements are Language-Sensitive.
+
+   structuredExtensionElement =
+      element * - metalink:* {
+         (attribute * { text }+,
+            (text|anyElement)*)
+       | (attribute * { text }*,
+          (text?, anyElement+, (text|anyElement)*))
+      }
+
+   The structure of a Structured Extension element, including the order
+   of its child elements, could be significant.
+
+   This specification does not provide an interpretation of a Structured
+   Extension element.  The syntax of the XML contained in the element
+   (and an interpretation of how the element relates to its containing
+   element) is defined by the specification of the Metalink extension.
+
+6.  IANA Considerations
+
+6.1.  XML Namespace Registration
+
+   This document makes use of the XML registry specified in [RFC3688].
+   Accordingly, IANA has made the following registration:
+
+   Registration request for the Metalink namespace:
+
+   URI: urn:ietf:params:xml:ns:metalink
+
+   Registrant Contact: See the "Authors' Addresses" section of this
+   document.
+
+   XML: None.  Namespace URIs do not represent an XML specification.
+
+6.2.  application/metalink4+xml MIME type
+
+   A Metalink Document, when serialized as XML 1.0, can be identified
+   with the following media type:
+
+   Type name:  application
+
+   Subtype name:  metalink4+xml
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 23]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   Required parameters:  None.
+
+   Optional parameters:
+
+      "charset":  This parameter has semantics identical to the charset
+         parameter of the "application/xml" media type as specified in
+         [RFC3023].
+
+   Encoding considerations:  Identical to those of "application/xml" as
+      described in [RFC3023], Section 3.2.
+
+   Security considerations:  As defined in this specification.
+
+      In addition, as this media type uses the "+xml" convention, it
+      shares the same security considerations as described in [RFC3023],
+      Section 10.
+
+   Interoperability considerations:  There are no known interoperability
+      issues.
+
+   Published specification:  This specification.
+
+   Applications that use this media type:  File transfer applications.
+
+   Additional information:
+
+   Magic number(s):  None.
+
+   File extension:  .meta4
+
+   Macintosh File Type code:  TEXT
+
+   Person and email address to contact for further information:
+      Anthony Bryan <anthonybryan@gmail.com>
+
+   Intended usage:  COMMON
+
+   Restrictions on usage:  None.
+
+   Author:  Anthony Bryan <anthonybryan@gmail.com>
+
+   Change controller:  IESG
+
+7.  Security Considerations
+
+   Because Metalink is an XML-based format, existing XML security
+   mechanisms can be used to secure its content.
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 24]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   Publishers of Metalink Documents may have sound reasons for signing
+   otherwise-unprotected content.  For example, a merchant might
+   digitally sign a Metalink that lists a file download to verify its
+   origin.  Other merchants may wish to sign and encrypt Metalink
+   Documents that list digital songs that have been purchased.  Many
+   other examples are conceivable.
+
+   Publishers are encouraged to offer Metalink documents via
+   authenticated HTTP under Transport Layer Security (TLS) as specified
+   in [RFC2818].  The choice of a secure content layer rests entirely
+   with the content providers.
+
+   Publishers are also encouraged to include digital signatures of the
+   files within the Metalink Documents, if they are available, as
+   described in Section 4.2.13.
+
+   Normally, a publisher is in the best position to know how strong the
+   protective signing ought to be on their content.  Thus, a publisher
+   can choose weak or strong cryptography, and a Metalink Processor
+   SHOULD normally accept that.  There are potential applications where
+   the Metalink Processor chooses to reject weak cryptography, but that
+   is not envisioned as the common use case.
+
+7.1.  Digital Signatures
+
+   The root of a Metalink Document (i.e., metalink:metalink) or any
+   metalink:file element MAY have an Enveloped Signature, as described
+   by XML-Signature and Syntax Processing [REC-xmldsig-core].
+
+   Although signing and verifying signatures are both OPTIONAL, an
+   implementation that supports either feature SHOULD implement RSA with
+   a minimum key size of 2048 with SHA-256.
+
+   Metalink Processors that support verifying signatures MUST reject
+   Metalink Documents with invalid signatures.
+
+   Metalink Processors MUST NOT reject a Metalink Document containing
+   such a signature because they are not capable of verifying it; they
+   MUST continue processing and MAY inform the user of their failure to
+   validate the signature.
+
+   In other words, the presence of an element with the namespace URI
+   "http://www.w3.org/2000/09/xmldsig#" and a local name of "Signature"
+   as a child of the document element MUST NOT cause a Metalink
+   Processor to fail merely because of its presence.
+
+   Other elements in a Metalink Document MUST NOT be signed unless their
+   definitions explicitly specify such a capability.
+
+
+
+Bryan, et al.                Standards Track                   [Page 25]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   Section 6.5.1 of [REC-xmldsig-core] requires support for Canonical
+   XML [REC-xml-c14n].  However, many - implementers do not use it
+   because signed XML documents - enclosed in other XML documents have
+   their signatures - broken.  Thus, Metalink Processors that verify
+   signed Metalink Documents MUST be able to canonicalize with the
+   exclusive XML canonicalization method identified by the URI
+   "http://www.w3.org/2001/10/xml-exc-c14n#", as specified in Exclusive
+   XML Canonicalization [REC-xml-exc-c14n].
+
+   Section 4.4.2 of [REC-xmldsig-core] requires support for Digital
+   Signature Algorithm (DSA) signatures and recommends support for RSA
+   signatures.  However, because of the much greater popularity in the
+   market of RSA versus DSA, Metalink Processors that verify signed
+   Metalink Documents MUST be able to verify RSA signatures, but do not
+   need be able to verify DSA signatures.  Due to security issues that
+   can arise if the keying material for message authentication code
+   (MAC) authentication is not handled properly, Metalink Documents
+   SHOULD NOT use MACs for signatures.
+
+7.2.  URIs and IRIs
+
+   Metalink Processors handle URIs and IRIs.  See Section 7 of [RFC3986]
+   and Section 8 of [RFC3987] for security considerations related to
+   their handling and use.
+
+7.3.  Spoofing
+
+   There is potential for spoofing attacks where the attacker publishes
+   Metalink Documents with false information.  Malicious publishers
+   might create Metalink Documents containing inaccurate information
+   anywhere in the document.  Unaware downloaders could be deceived into
+   downloading malicious or worthless content.  Malicious publishers
+   could attempt a distributed denial-of-service attack by inserting
+   unrelated IRIs into Metalink Documents.
+
+   Digital signatures address the issue of spoofing.
+
+7.4.  Cryptographic Hashes
+
+   Currently, some of the hash types defined in the IANA registry named
+   "Hash Function Textual Names" are considered insecure.  These include
+   the whole Message Digest family of algorithms that are not suitable
+   for cryptographically strong verification.  Malicious parties could
+   provide files that appear to be identical to another file because of
+   a collision, i.e., the weak cryptographic hashes of the intended file
+   and a substituted malicious file could match.
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 26]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   Metalink Generators and Processors MUST support "sha-256", which is
+   SHA-256, as specified in [FIPS-180-3], and MAY support stronger
+   hashes.
+
+   If a Metalink Document contains hashes, it SHOULD include "sha-256",
+   which is SHA-256, or stronger.  It MAY also include other hashes from
+   the IANA registry named "Hash Function Textual Names".
+
+8.  References
+
+8.1.  Normative References
+
+   [BITTORRENT] Cohen, B., "The BitTorrent Protocol Specification",
+                BITTORRENT 11031, February 2008,
+                <http://www.bittorrent.org/beps/bep_0003.html>.
+
+   [FIPS-180-3] National Institute of Standards and Technology (NIST),
+                "Secure Hash Standard (SHS)", FIPS PUB 180-3,
+                October 2008.
+
+   [ISO3166-1]  International Organization for Standardization, "ISO
+                3166- 1:2006.  Codes for the representation of names of
+                countries and their subdivisions -- Part 1: Country
+                codes", November 2006.
+
+   [REC-xml]    Yergeau, F., Paoli, J., Bray, T., Sperberg-McQueen, C.,
+                and E. Maler, "Extensible Markup Language (XML) 1.0
+                (Fifth Edition)", W3C REC-xml-20081126, November 2008,
+                <http://www.w3.org/TR/2008/REC-xml-20081126/>.
+
+   [REC-xml-c14n]
+                Boyer, J., "Canonical XML Version 1.0", W3C REC REC-xml-
+                c14n-20010315, March 2001,
+                <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
+
+   [REC-xml-exc-c14n]
+                Eastlake, D., Boyer, J., and J. Reagle, "Exclusive XML
+                Canonicalization Version 1.0", W3C REC REC-xml-exc-c14n-
+                20020718, July 2002,
+                <http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/>.
+
+   [REC-xml-infoset]
+                Cowan, J. and R. Tobin, "XML Information Set (Second
+                Edition)", W3C REC-xml-infoset-20040204, February 2004,
+                <http://www.w3.org/TR/2004/REC-xml-infoset-20040204/>.
+
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 27]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   [REC-xml-names]
+                Hollander, D., Bray, T., Tobin, R., and A. Layman,
+                "Namespaces in XML 1.0 (Third Edition)", W3C REC-xml-
+                names-20091208, December 2009,
+                <http://www.w3.org/TR/2009/REC-xml-names-20091208/>.
+
+   [REC-xmldsig-core]
+                Solo, D., Reagle, J., and D. Eastlake, "XML-Signature
+                Syntax and Processing (Second Edition)",
+                W3C REC-xmldsig- core-20080610, June 2008,
+                <http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2818]    Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC3023]    Murata, M., St. Laurent, S., and D. Kohn, "XML Media
+                Types", RFC 3023, January 2001.
+
+   [RFC3339]    Klyne, G. and C. Newman, "Date and Time on the Internet:
+                Timestamps", RFC 3339, July 2002.
+
+   [RFC3986]    Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+                Resource Identifier (URI): Generic Syntax", STD 66,
+                RFC 3986, January 2005.
+
+   [RFC3987]    Duerst, M. and M. Suignard, "Internationalized Resource
+                Identifiers (IRIs)", RFC 3987, January 2005.
+
+   [RFC4288]    Freed, N. and J. Klensin, "Media Type Specifications and
+                Registration Procedures", BCP 13, RFC 4288,
+                December 2005.
+
+   [RFC5234]    Crocker, D., Ed. and P. Overell, "Augmented BNF for
+                Syntax Specifications: ABNF", STD 68, January 2008.
+
+   [RFC5646]    Phillips, A. and M. Davis, "Tags for Identifying
+                Languages", BCP 47, RFC 5646, September 2009.
+
+8.2.  Informative References
+
+   [ISO.8601.1988]
+                International Organization for Standardization, "Data
+                elements and interchange formats - Information
+                interchange - Representation of dates and times",
+                ISO Standard 8601, June 1988.
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 28]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   [NOTE-datetime-19980827]
+                Wolf, M. and C. Wicksteed, "Date and Time Formats",
+                W3C NOTE-datetime-19980827, August 1998,
+                <http://www.w3.org/TR/1998/NOTE-datetime-19980827>.
+
+   [REC-xmlschema-2-20041028]
+                Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
+                Second Edition", W3C REC-xmlschema-2-20041028,
+                October 2004,
+                <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
+
+   [RELAX-NG]   Clark, J., "RELAX NG Compact Syntax", December 2001,
+                <http ://www.oasis-open.org/committees/relax-ng/
+                compact-20021121.html>.
+
+   [RFC3688]    Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+                January 2004.
+
+   [RFC4287]    Nottingham, M. and R. Sayre, "The Atom Syndication
+                Format", RFC 4287, December 2005.
+
+   [RFC4880]    Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and
+                R. Thayer, "OpenPGP Message Format", RFC 4880,
+                November 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 29]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+Appendix A.  Acknowledgements and Contributors
+
+   The layout and shape of this document relies heavily on work
+   pioneered in the Atom Syndication Format as specified in [RFC4287].
+
+   The content and concepts within are a product of the Metalink
+   community.  Key contributors provided early implementations: A. Bram
+   Neijt, Hampus Wessman, Darius Liktorius, Manuel Subredu, Michael
+   Burford, Giorgio Maone, Nils Maier, Max Velasques, Manolo Valdes,
+   Hayden Legendre, Frederick Cheung, Rene Leonhardt, Per Oyvind
+   Karlsen, Matt Domsch, Yazsoft, KGet developers, Free Download Manager
+   developers, Orbit developers, Arne Babenhauserheide, Mathias
+   Berchtold, Xienzhenyu and TheWorld Browser developers, Xi Software,
+   Agostino Russo, and James Antill.
+
+   The Metalink community has dozens of contributors who contributed to
+   the evolution of Metalink or proposed ideas and wording for this
+   document, including:
+
+   Paul Burkhead, Kristian Weston, Nicolas Alvarez, Urs Wolfer, Bridget
+   and Ethan Fletcher, Patrick Ruckstuhl, Sebastien Willemijns, Micah
+   Cowan, Ruben Kerkhof, Danny Ayers, Nick Dominguez, Gary Zellerbach,
+   James Clark, Daniel Stenberg, John and Sandra Sowder, Salvatore
+   Musumeci, Steve Eshelman, Lucas Hewett, Ryan Cronin, Dave Winquist,
+   Bob Denison, Wes Shelton, Josh Colbert, Steve Kleisath, Chad Neptune,
+   Derick Cordoba, Nick Carrabba, Chris Carrabba, Erin Solari, Ryan
+   Alexander, Tom Mainville, Janie Wargo, Jason Hansen, Tim Bray, Dan
+   Brickley, Markus Hofmann, Dan Connolly, Tim Berners-Lee, Louis
+   Suarez-Potts, Ross Smith, Jeff Covey, Ed Lee, Shawn Wilsher, Mike
+   Connor, Johan Svedberg, Kees Cook, Dedric Carter, and Debi Goulding.
+   We also thank the Anthony Family, the Bryan Family, Juanita Anthony,
+   and Zimmy Bryan.
+
+   Special thanks to Eran Hammer-Lahav, document shepherd, and Lisa
+   Dusseault, Area Director.  We also thank the following contributors
+   for assistance and review: Mark Nottingham, Peter Saint-Andre, Julian
+   Reschke, Chris Newman, Ian Macfarlane, Dave Cridland, Barry Leiba,
+   Uri Blumenthal, Paul Hoffman, Felix Sasaki, Matthias Fuchs, Mark
+   Baker, Scott Cantor, Brian Carpenter, Alexey Melnikov, Lars Eggert,
+   Pasi Eronen, Tim Polk, Dan Romascanu, and Bjoern Hoehrmann.
+
+   Peter Poeml wishes to acknowledge the support of SUSE Linux Products
+   GmbH / Novell Inc., where he was employed during much of the work on
+   this document.
+
+   This document is dedicated to Sonora Bryan.
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 30]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+Appendix B.  RELAX NG Compact Schema
+
+   This appendix is informative.
+
+   The Relax NG schema explicitly excludes elements in the Metalink
+   namespace that are not defined in this revision of the specification.
+   Requirements for Metalink Processors encountering such markup are
+   given in Sections 5.2 and 5.3.
+
+   # -*- rnc -*-
+   # RELAX NG Compact Syntax Grammar for the
+   # Metalink Format Specification Version 4
+   # Based on RFC 4287 schema
+
+   namespace local = ""
+   namespace metalink = "urn:ietf:params:xml:ns:metalink"
+   namespace xsd = "http://www.w3.org/2001/XMLSchema"
+
+   # Common attributes
+
+   metalinkCommonAttributes =
+      attribute xml:lang { metalinkLanguageTag }?,
+      undefinedAttribute*
+
+   # Text Constructs
+
+   metalinkTextConstruct =
+      metalinkCommonAttributes,
+      text
+
+   # Date Construct
+
+   metalinkDateConstruct =
+      metalinkCommonAttributes,
+      xsd:dateTime
+
+   start = metalinkMetalink
+
+   metalinkMetalink =
+      element metalink:metalink {
+         metalinkCommonAttributes,
+         (metalinkFile+
+          & metalinkGenerator?
+          & metalinkOrigin?
+          & metalinkPublished?
+          & metalinkUpdated?
+          & extensionElement*)
+      }
+
+
+
+Bryan, et al.                Standards Track                   [Page 31]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   metalinkFile =
+      element metalink:file {
+         metalinkCommonAttributes,
+         attribute name { text },
+         (metalinkCopyright?
+          & metalinkDescription?
+          & metalinkHash*
+          & metalinkIdentity?
+          & metalinkLanguage*
+          & metalinkLogo?
+          & metalinkMetaURL*
+          & metalinkOS*
+          & metalinkPieces*
+          & metalinkPublisher?
+          & metalinkSignature?
+          & metalinkSize?
+          & metalinkURL*
+          & metalinkVersion?
+          & extensionElement*)
+      }
+
+   metalinkPieces =
+      element metalink:pieces {
+         attribute length { xsd:positiveInteger },
+         attribute type { text },
+         metalinkHash+
+      }
+
+   metalinkCopyright =
+      element metalink:copyright {
+         metalinkTextConstruct
+      }
+
+   metalinkDescription =
+      element metalink:description {
+         metalinkTextConstruct
+      }
+
+   metalinkGenerator =
+      element metalink:generator {
+         metalinkTextConstruct
+      }
+
+   metalinkHash =
+        element metalink:hash {
+          attribute type { text }?,
+          text
+        }
+
+
+
+Bryan, et al.                Standards Track                   [Page 32]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   metalinkIdentity =
+      element metalink:identity {
+         metalinkTextConstruct
+      }
+
+   metalinkLanguage =
+      element metalink:language {
+         metalinkTextConstruct
+      }
+
+   metalinkLogo =
+      element metalink:logo {
+         metalinkCommonAttributes,
+         (metalinkUri)
+      }
+
+   metalinkMetaURL =
+      element metalink:metaurl {
+         metalinkCommonAttributes,
+         attribute priority { xsd:positiveInteger {
+            maxInclusive = "999999"}}?,
+         attribute mediatype { text },
+         attribute name { text }?,
+         (metalinkUri)
+      }
+
+   metalinkOrigin =
+      element metalink:origin {
+         metalinkCommonAttributes,
+         attribute dynamic { xsd:boolean }?,
+         (metalinkUri)
+      }
+
+   metalinkOS =
+      element metalink:os {
+         metalinkTextConstruct
+      }
+
+   metalinkPublished =
+      element metalink:published {
+         metalinkDateConstruct
+      }
+
+   metalinkPublisher =
+      element metalink:publisher {
+         metalinkCommonAttributes,
+         attribute name { text },
+         attribute url { metalinkUri }?
+
+
+
+Bryan, et al.                Standards Track                   [Page 33]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+      }
+
+   metalinkSignature =
+      element metalink:signature {
+         attribute mediatype { text },
+         metalinkTextConstruct
+      }
+
+   metalinkSize =
+      element metalink:size {
+         xsd:nonNegativeInteger
+      }
+
+   metalinkUpdated =
+      element metalink:updated {
+         metalinkDateConstruct
+      }
+
+   metalinkURL =
+      element metalink:url {
+         metalinkCommonAttributes,
+         attribute location { xsd:string {
+            minLength = "2"  maxLength="2"}
+         }?,
+         attribute priority { xsd:positiveInteger {
+            maxInclusive = "999999"}}?,
+         (metalinkUri)
+      }
+
+   metalinkVersion =
+      element metalink:version {
+         metalinkTextConstruct
+      }
+
+   # As defined in RFC 3066 and compatible with RFC 5646
+   metalinkLanguageTag = xsd:string {
+      pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*"
+   }
+
+   # Unconstrained; it's not entirely clear how IRI fit into
+   # xsd:anyURI so let's not try to constrain it here
+   metalinkUri = text
+
+   # Simple Extension
+
+   simpleExtensionElement =
+      element * - metalink:* {
+         text
+
+
+
+Bryan, et al.                Standards Track                   [Page 34]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+      }
+
+   # Structured Extension
+
+   structuredExtensionElement =
+      element * - metalink:* {
+         (attribute * { text }+,
+            (text|anyElement)*)
+       | (attribute * { text }*,
+          (text?, anyElement+, (text|anyElement)*))
+      }
+
+   # Other Extensibility
+
+   extensionElement =
+      simpleExtensionElement | structuredExtensionElement
+
+   undefinedAttribute =
+     attribute * - (xml:lang | local:*) { text }
+
+   undefinedContent = (text|anyForeignElement)*
+
+   anyElement =
+      element * {
+         (attribute * { text }
+          | text
+          | anyElement)*
+      }
+
+   anyForeignElement =
+      element * - metalink:* {
+         (attribute * { text }
+          | text
+          | anyElement)*
+   }
+
+   # EOF
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 35]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+Index
+
+   A
+      ABNF
+         metalinkGenerator  13
+         metaurl mediatype  17
+         signature mediatype  19
+      application/metalink4+xml Media Type  23
+
+   C
+      copyright XML element  12
+
+   D
+      description XML element  13
+
+   F
+      file XML element  10
+
+   G
+      generator XML element  13
+      Grammar
+         metalinkCommonAttributes  7
+         metalinkCopyright  13
+         metalinkDateConstruct  8
+         metalinkDescription  13
+         metalinkFile  10
+         metalinkGenerator  13
+         metalinkHash  14
+         metalinkIdentity  15
+         metalinkLanguage  15
+         metalinkLogo  16
+         metalinkMetalink  8
+         metalinkMetaURL  16
+         metalinkOrigin  17
+         metalinkOS  18
+         metalinkPieces  12
+         metalinkPublished  18
+         metalinkPublisher  18
+         metalinkSignature  19
+         metalinkSize  20
+         metalinkTextConstruct  7
+         metalinkUpdated  20
+         metalinkURL  21
+         metalinkVersion  21
+         simpleExtensionElement  22
+         structuredExtensionElement  23
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 36]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   H
+      hash XML element  14
+
+   I
+      identity XML element  15
+
+   L
+      language XML element  15
+      logo XML element  16
+
+   M
+      Media Type
+         application/metalink4+xml  23
+      metalink XML element  8
+      metalinkCommonAttributes grammar production  7
+      metalinkCopyright grammar production  12
+      metalinkDateConstruct grammar production  8
+      metalinkDescription grammar production  13
+      metalinkFile grammar production  10
+      metalinkGenerator ABNF  13
+      metalinkGenerator grammar production  13
+      metalinkHash grammar production  14
+      metalinkIdentity grammar production  15
+      metalinkLanguage grammar production  15
+      metalinkLogo grammar production  16
+      metalinkMetalink grammar production  8
+      metalinkMetaURL grammar production  16
+      metalinkOrigin grammar production  17
+      metalinkOS grammar production  18
+      metalinkPieces grammar production  12
+      metalinkPublished grammar production  18
+      metalinkPublisher grammar production  18
+      metalinkSignature grammar production  19
+      metalinkSize grammar production  20
+      metalinkTextConstruct grammar production  7
+      metalinkUpdated grammar production  20
+      metalinkURL grammar production  21
+      metalinkVersion grammar production  21
+      metaurl mediatype ABNF  16
+      metaurl XML element  16
+
+   O
+      origin XML element  17
+      os XML element  18
+
+
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 37]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+   P
+      pieces XML element  12
+      published XML element  18
+      publisher XML element  18
+
+   S
+      signature mediatype ABNF  19
+      signature XML element  19
+      simpleExtensionElement grammar production  22
+      size XML element  20
+      structuredExtensionElement grammar production  23
+
+   U
+      updated XML element  20
+      url XML element  20
+
+   V
+      version XML element  21
+
+   X
+      XML Elements
+         copyright  12
+         description  13
+         file  9
+         generator  13
+         hash  14
+         identity  15
+         language  15
+         logo  16
+         metalink  8
+         metaurl  16
+         origin  17
+         os  18
+         pieces  12
+         published  18
+         publisher  18
+         signature  19
+         size  20
+         updated  20
+         url  20
+         version  21
+
+
+
+
+
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 38]
+
+RFC 5854          Metalink Download Description Format         June 2010
+
+
+Authors' Addresses
+
+   Anthony Bryan
+   Pompano Beach, FL
+   USA
+
+   EMail: anthonybryan@gmail.com
+   URI:   http://www.metalinker.org
+
+
+   Tatsuhiro Tsujikawa
+   Shiga
+   Japan
+
+   EMail: tatsuhiro.t@gmail.com
+   URI:   http://aria2.sourceforge.net
+
+
+   Neil McNab
+   San Diego, CA
+   USA
+
+   EMail: neil@nabber.org
+   URI:   http://www.nabber.org
+
+
+   Dr. med. Peter Poeml
+   MirrorBrain
+   Venloer Str. 317
+   Koeln  50823
+   DE
+
+   Phone: +49 221 6778 333 8
+   EMail: peter@poeml.de
+   URI:   http://mirrorbrain.org/~poeml/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bryan, et al.                Standards Track                   [Page 39]
+