The Metalink Download Description Format
Extracted elements (28)
The document layout and shape borrows heavily from the Atom Syndication Format (RFC 4287), including the use of Text and Date constructs, extensibility model, and RELAX NG schema approach. This leverages established XML feed design patterns for a download-description use case.
The Metalink format was designed to address failures in traditional HTTP mirror redirects, which convey only a single server referral with no fallback. By encoding multiple URIs, cryptographic hashes, and digital signatures in a machine-readable document, clients can transparently retry mirrors and verify integrity, improving reliability for large downloads.
The metalink:os element uses values from the IANA registry named 'Operating System Names', and hash type attributes use values from the IANA registry named 'Hash Function Textual Names', ensuring interoperability with other specifications that reference these registries.
All metalink:url elements in a metalink:file SHOULD lead to identical files as alternative download locations. Metalink:metaurl elements SHOULD provide metadata to retrieve the same file via another mechanism such as a P2P network.
Date constructs MUST conform to the 'date-time' production in RFC 3339. An uppercase 'T' MUST separate date and time, and an uppercase 'Z' MUST be present in the absence of a numeric time zone offset.
Each unique file described in a Metalink Document MUST have its own metalink:file element. metalink:file elements MUST contain at least one metalink:url element or at least one metalink:metaurl element.
Metalink Documents MUST be well-formed XML 1.0. All leading and trailing whitespace is part of element content and MUST NOT be ignored. Documents that do not follow the specification are invalid and SHOULD NOT be used by Metalink Processors.
metalink:pieces elements MUST have a 'length' attribute specifying piece size in octets. Every piece MUST be the same size except the last, which is the remainder of the file.
Metalink Processors MUST filter out invalid files obtained from metalink:url elements by using information in the metalink:size and metalink:hash elements. The metalink:size element MUST override the actual content length as reported by the underlying protocol, and downloads that do not match MUST be discarded.
Metalink Processors that encounter foreign markup in a legal location MUST ignore it; they MUST NOT stop processing or signal an error due to unrecognized markup from the Metalink vocabulary or other namespaces.
Metalink Processors that verify signed Metalink Documents MUST be able to canonicalize using exclusive XML canonicalization (URI: 'http://www.w3.org/2001/10/xml-exc-c14n#') and MUST be able to verify RSA signatures. Metalink Documents SHOULD NOT use MACs for signatures.
Priority values of metalink:metaurl and metalink:url elements are compared collectively; those with the lowest values (starting with 1) are used first. Multiple elements MAY share the same priority value.
The 'name' attribute of metalink:file MUST be unique for each file element. The path MUST NOT contain any directory traversal directives; it MUST be relative and MUST NOT begin with '/', './', or '../'; contain '/../'; or end with '/..'.
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 RFC 3987.
The 'metalink:file' element represents an individual file and acts as a container for its metadata. It MUST have a unique 'name' attribute and MUST contain at least one metalink:url or metalink:metaurl element. It SHOULD contain exactly one metalink:size element.
The 'metalink:hash' element conveys a cryptographic hash for a complete file or a piece. All hashes are encoded in lowercase hexadecimal. Hash elements with a 'type' attribute MUST contain a hash of the complete file; those inside metalink:pieces MUST NOT have a 'type' attribute.
The 'metalink:metalink' element is the document root element of a Metalink Document, acting as a container for metadata and data. It MUST contain one or more metalink:file child elements, and MAY contain metalink:generator, metalink:origin, metalink:published, and metalink:updated elements (at most one each).
The 'metalink:metaurl' element contains the IRI of a metadata file (e.g., a BitTorrent .torrent file or another Metalink Document). It MUST have a 'mediatype' attribute; for BitTorrent the value 'torrent' is REQUIRED. It MAY have 'priority' and 'name' attributes.
The 'metalink:origin' element is an IRI where the Metalink Document was originally published. Its optional 'dynamic' boolean attribute, when 'true', indicates that updated versions of the Metalink can be found at that IRI.
The 'metalink:pieces' element contains a list of cryptographic hashes for contiguous, non-overlapping pieces of a file. It MUST have a 'type' attribute (hash algorithm) and a 'length' attribute (piece size in octets). Hashes MUST be listed in file order.
The 'metalink:signature' element conveys a digital signature (e.g., OpenPGP) for a file described in a Metalink Document. It MUST have a 'mediatype' attribute indicating the MIME type of the signature. Support for processing this element in Metalink Processors is OPTIONAL.
The 'metalink:url' element contains a file IRI and MAY have a 'priority' attribute (positive integer 1–999999, lower = higher priority) and a 'location' attribute (ISO 3166-1 alpha-2 country code). Elements without a priority attribute are treated as lowest priority (999999).
IANA registered the 'application/metalink4+xml' MIME type for Metalink Documents serialized as XML 1.0. File extension is .meta4.
IANA registered the XML namespace 'urn:ietf:params:xml:ns:metalink' in the IETF XML registry per RFC 3688.
For digital signatures on Metalink Documents, implementations that support signing or verifying SHOULD implement RSA with a minimum key size of 2048 bits with SHA-256. Metalink Processors MUST reject Metalink Documents with invalid signatures but MUST NOT reject a document solely because they cannot verify its signature.
Publishers are encouraged to serve Metalink Documents via authenticated HTTP under TLS. Metalink Processors SHOULD normally accept the cryptographic strength chosen by the publisher, though applications may choose to reject weak cryptography.
Some hash types in the IANA 'Hash Function Textual Names' registry (e.g., MD family) are cryptographically weak and susceptible to collision attacks. Metalink Generators and Processors MUST support 'sha-256' and SHOULD include SHA-256 or stronger when including hashes in a Metalink Document.
Spoofing attacks are possible where malicious publishers create Metalink Documents with false information, potentially deceiving users into downloading malicious content or directing traffic as a DDoS vector. Digital signatures address this threat.