Internet DRAFT - draft-bryan-metalink-client
draft-bryan-metalink-client
Network Working Group A. Bryan
Internet-Draft T. Tsujikawa
Intended status: Standards Track N. McNab
Expires: July 21, 2013
P. Poeml
MirrorBrain
January 17, 2013
Metalink/XML Clients, Publishers, and Caches
draft-bryan-metalink-client-02
Abstract
This document specifies behavior for Metalink/XML clients,
publishers, and proxy caches. Metalink XML files contain multiple
download locations (mirrors and Peer-to-Peer), cryptographic hashes,
digital signatures, and other information. Metalink clients can use
this information to make file transfers more robust and reliable.
Normative requirements for Metalink/XML clients, publishers, and
proxy caches are described here.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft should take place on the apps-discuss
mailing list (apps-discuss@ietf.org), although this draft is not a WG
item.
The changes in this draft are summarized in Appendix B.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 21, 2013.
Copyright Notice
Bryan, et al. Expires July 21, 2013 [Page 1]
Internet-Draft Metalink Clients, Publishers, and Caches January 2013
Copyright (c) 2013 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Metalink/XML Clients . . . . . . . . . . . . . . . . . . . . . 5
3. Metalink/XML Publishers and Generators . . . . . . . . . . . . 7
3.1. Transparent Metalink/XML Usage . . . . . . . . . . . . . . 8
3.2. Mirror Servers . . . . . . . . . . . . . . . . . . . . . . 8
4. Metalink/XML Proxy Cache . . . . . . . . . . . . . . . . . . . 8
5. Client / Server Multi-source Download Interaction . . . . . . 9
5.1. Error Prevention, Detection, and Correction . . . . . . . 11
5.1.1. Error Prevention (Early File Mismatch Detection) . . . 11
5.1.2. Error Correction . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7.1. Directory Traversal and Safe file names . . . . . . . . . 12
7.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 12
7.3. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.4. Cache Poisoning . . . . . . . . . . . . . . . . . . . . . 12
7.5. Cryptographic Hashes . . . . . . . . . . . . . . . . . . . 12
7.6. Signing . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgements and Contributors . . . . . . . . . . 14
Appendix B. Document History . . . . . . . . . . . . . . . . . . 14
Bryan, et al. Expires July 21, 2013 [Page 2]
Internet-Draft Metalink Clients, Publishers, and Caches January 2013
1. Introduction
Metalink [RFC5854] 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.
Identical copies of a file are frequently accessible in multiple
locations on the Internet over a variety of protocols (such as FTP,
HTTP, and Peer-to-Peer). In some cases, users are shown a list of
these multiple download locations (mirrors) and must manually select
a single one on the basis of geographical location, priority, or
bandwidth. This distributes the load across multiple servers, and
should also increase throughput and resilience. At times, however,
individual servers can be slow, outdated, or unreachable, but this
can not be determined until the download has been initiated. Users
will rarely have sufficient information to choose the most
appropriate server, and will often choose the first in a list which
might not be optimal for their needs, and will lead to a particular
server getting a disproportionate share of load. The use of
suboptimal mirrors can lead to the user canceling and restarting the
download to try to manually find a better source. During downloads,
errors in transmission can corrupt the file. There are no easy ways
to repair these files. For large downloads this can be extremely
troublesome. Any of the number of problems that can occur during a
download lead to frustration on the part of users.
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
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
Bryan, et al. Expires July 21, 2013 [Page 3]
Internet-Draft Metalink Clients, Publishers, and Caches January 2013
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.
Metalink/HTTP [RFC6249] is an alternative and complementary
representation of Metalink information, using HTTP header fields
instead of the XML-based document format [RFC5854]. Metalink/HTTP is
used to list information about a file to be downloaded. This can
include lists of multiple URIs (mirrors and Peer-to-Peer
information), cryptographic hashes, and digital signatures.
Some popular sites automate the process of selecting mirrors using
DNS load balancing, both to approximately balance load between
servers, and to direct clients to nearby servers with the hope that
this improves throughput. Indeed, DNS load balancing can balance
long-term server load fairly effectively, but it is less effective at
delivering the best throughput to users when the bottleneck is not
the server but the network.
This document describes a mechanism by which the benefit of mirrors
can be automatically and more effectively realized. All the
information about a download, including mirrors, cryptographic
hashes, digital signatures, and more can be transferred in a
Metalink. This Metalink transfers the knowledge of the download
server (and mirror database) to the client. Clients can fallback to
other mirrors if the current one has an issue. With this knowledge,
the client is enabled to work its way to a successful download even
under adverse circumstances. All this can be done without
complicated user interaction and the download can be much more
reliable and efficient. Furthermore, in order to provide better load
distribution across servers and potentially faster downloads to
users, Metalinks facilitates multi-source downloads, where portions
of a file are downloaded from multiple mirrors (and optionally, Peer-
to-Peer) simultaneously.
The client will then be able to request chunks of the file from the
various sources, scheduling appropriately in order to maximize the
download rate.
1.1. Notational Conventions
This specification describes conformance of Metalink/HTTP.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Bryan, et al. Expires July 21, 2013 [Page 4]
Internet-Draft Metalink Clients, Publishers, and Caches January 2013
"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.
1.2. Terminology
In this context, "Metalink" refers to "Metalink/XML" refers to the
XML format described in [RFC5854].
The following terms as used in this document are defined here:
o Metalink Generator : Application that creates Metalink/XML files,
and includes information about the files described in the Metalink
such as locations (on Mirror servers or other methods like P2P),
file sizes, and cryptographic hashes.
o Metalink Publisher : One who uses a Metalink Generator to create
Metalink/XML files that are then offered to people to improve
their download experience.
o Mirror server : Typically FTP or HTTP servers that "mirror" the
Metalink server, as in they provide identical copies of (at least
some) files that are also on the mirrored server.
o Metalink/XML : An XML file which describes a file that can contain
information such as mirrors, cryptographic hashes, digital
signatures, and more.
o Metalink Processors or Clients : Applications that process
Metalink/XML and use them provide an improved download experience.
They support HTTP and could also support other download protocols
like FTP or various Peer-to-Peer methods.
o Metalink/HTTP : An HTTP header that contains information such as
mirrors, cryptographic hashes, and digital signatures, which could
also be in a Metalink/XML file.
2. Metalink/XML Clients
Metalink/XML clients use the mirrors provided by a Metalink/XML file.
Metalink clients SHOULD support HTTP [RFC2616] and SHOULD support FTP
[RFC0959]. Metalink clients MAY support BitTorrent [BITTORRENT], or
other download methods. Metalink clients SHOULD switch downloads
from one mirror to another if a file is not available or if a mirror
becomes unreachable. Metalink clients MAY support multi-source, or
parallel, downloads, where portions of a file can be downloaded from
multiple mirrors simultaneously (and optionally, from Peer-to-Peer
sources). Metalink clients SHOULD support error recovery by using
Bryan, et al. Expires July 21, 2013 [Page 5]
Internet-Draft Metalink Clients, Publishers, and Caches January 2013
the cryptographic hashes of parts of the file listed in Metalink/XML
files, as described in [RFC5854], Section 4.1.3.
Metalink clients SHOULD support checking digital signatures. Digital
signatures should be given preference over file hashes, if both are
included in a Metalink/XML file.
Metalink/XML clients MUST process metalinks available by URI. They
MAY process local Metalinks.
Metalink/XML clients SHOULD recognize Metalink/XML files by MIME
type. [[What about misconfigured/unupdated servers that do not have
correct MIME type? SHOULD(?) clients recognize Metalinks by file
extension as well?]]
If Metalink/XML clients support HTTP, they SHOULD support
"transparent metalink" usage to upgrade from a regular download to an
enhanced download, using the information in the Metalink/XML
file.(see Section 3.1).
If a file with same name already exists locally, Metalink/XML clients
SHOULD verify full file hash and if hash is correct, do not re-
download the file. If a file exists and full file hash is incorrect,
Metalink/XML clients MAY repair file if partial file hashes exist.
Otherwise, Metalink/XML clients MAY write to a different output file
name (file_2 or file(2) like some apps already do).
Metalink/XML clients SHOULD (or MUST?) verify full file hash after
download completes. If there is an error, MUST describe as corrupted
and MAY re-download or keep download? SHOULD verify chunk hash if
available and re-get error parts. SHOULD (or MAY?) be done during
initial download process, MAY be done after download completed or to
repair file downloaded another way?
Metalink/XML clients SHOULD(?) use BitTorrent chunk hashes with HTTP/
FTP downloads to repair file errors if the client supports torrents
downloads. (What if chunk hashes are present in torrent and
metalink, should one be preferred?)
If client supports Metalink/XML AND Metalink/HTTP, which should be
preferred (in case mirrors/hashes differ)?
Metalink/XML clients SHOULD make use of Metalink/XML origin element
if dynamic="true" to check for updated Metalink.
Metalink/XML clients MAY make use of the [ISO3166-1] alpha-2 two-
letter country code for the geographical location of the physical
server the URI is used to access, in an attempt to improve the
Bryan, et al. Expires July 21, 2013 [Page 6]
Internet-Draft Metalink Clients, Publishers, and Caches January 2013
download experience.
Metalink/XML clients could support multiple versions of Metalink/XML,
and if they do they SHOULD prefer [RFC5854] Metalink/XML files.
If a client supports Metalink/HTTP and Metalink/XML, it MAY prefer
Metalink/HTTP but still use partial file hashes in the Metalink/XML
files.
Metalink/XML clients MAY create the directory structure described in
the Metalink/XML at a relative download location, but see
Section 7.1.
Metalink clients could use the location of the original Metalink in
the "Referer" header field for these ranged requests.
Metalink clients MAY support the use of metainfo files (such as
BitTorrent) for downloading files.
Metalink clients SHOULD support the use of OpenPGP signatures.
Metalink clients SHOULD support the use of S/MIME [RFC5751]
signatures.
Previously, Metalink/XML clients that support HTTP would do Accept
header transparent content negotiation, but this has been deprecated.
[[ NOTE: A number of requirements of Metalink clients are also in
[RFC5854]. Should these be repeated or referenced?]]
3. Metalink/XML Publishers and Generators
Metalink/XML publishers MUST use correct MIME type for metalink files
Metalink/XML publishers SHOULD advertise Metalink/XML file with Link
HTTP header field from regular download for "transparent metalink"
usage (see Section 3.1).
Metalink/XML publishers SHOULD publish with chunk hashes if error
recovery ability is desired (and files meet certain criteria like
"large enough" - no point for 10k size file).
Metalink Generators SHOULD offer Metalink/XML documents that contain
cryptographic hashes of parts of the file (and other information) if
error recovery is desirable.
Metalink/XML publishers SHOULD publish with size element if it refers
to a specific file.
Bryan, et al. Expires July 21, 2013 [Page 7]
Internet-Draft Metalink Clients, Publishers, and Caches January 2013
Metalink/XML publishers MAY do Accept header transparent content
negotiation (deprecated?)
Metalink/XML publishers SHOULD include Metalink/XML origin element
and dynamic="true" if updated metalinks will be offered.
Metalink publishers SHOULD include digital signatures, as described
in [RFC5854] Section 4.2.13.
3.1. Transparent Metalink/XML Usage
Metalink/XML files for a given resource MAY be provided in a Link
header field [RFC5988] as shown in this example:
This example shows a brief HTTP response header with .meta4:
Link: <http://example.com/example.ext.meta4>; rel=describedby;
type="application/metalink4+xml"
Metalink/XML files are specified in [RFC5854], and they are
particularly useful for providing metadata such as cryptographic
hashes of parts of a file (see [RFC5854] Section 4.1.3), allowing a
client to recover from errors (see Section 5.1.2). Metalink servers
SHOULD provide Metalink/XML files with partial file hashes in Link
header fields, and Metalink clients SHOULD use them for error
recovery.
3.2. Mirror Servers
Mirror servers are typically FTP or HTTP servers that "mirror"
another server. That is, they provide identical copies of (at least
some) files that are also on the mirrored server. Mirror servers
SHOULD support serving partial content.
4. Metalink/XML Proxy Cache
Metalink/XML proxy cache could detect and log Metalink usage.
Metalink/XML proxy cache MUST? use a whitelist for trusted sources by
domain name (ie kde.org, ubuntu.com, fedoraproject.org) to prevent
cache poisoning.
Metalink/XML proxy cache SHOULD use preferred mirrors (those that are
most cost efficient/better/local)
Metalink/XML proxy cache MAY? repair errors or use hashes? I guess
so, but the client will also be verifying hashes.
Bryan, et al. Expires July 21, 2013 [Page 8]
Internet-Draft Metalink Clients, Publishers, and Caches January 2013
5. Client / Server Multi-source Download Interaction
Metalink clients begin with a Metalink/XML document. They parse the
XML and obtain a list of ways to retrieve a file or files from FTP or
HTTP mirrors or P2P.
After that, the client follows with a GET request to the desired
mirrors.
From the Metalink/XML file, the client learns some or all of the
following metadata about the requested object:
o Mirror list, which can describe the mirror's priority and
geographical location.
o Whole and partial file cryptographic hash.
o Object size.
o Peer-to-peer information.
o Digital signature.
Next, the Metalink client requests a Range of the object from a
mirror server:
GET /example.ext HTTP/1.1
Host: www2.example.com
Range: bytes=7433802-
Referer: http://www.example.com/distribution/example.ext
Metalink clients SHOULD use partial file cryptographic hashes as
described in Section 5.1.2, if available, to detect if the mirror
server returned the correct data. Errors in transmission and
substitutions of incorrect data on mirrors, whether deliberate or
accidental, can be detected with error correction as described in
Section 5.1.2.
Here, the mirror server has the correct file and responds with a 206
Partial Content HTTP status code and appropriate "Content-Length" and
"Content Range" header fields. In this example, the mirror server
responds, with data, to the above request:
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Length: 7433801
Content-Range: bytes 7433802-14867602/14867603
Bryan, et al. Expires July 21, 2013 [Page 9]
Internet-Draft Metalink Clients, Publishers, and Caches January 2013
Metalink clients MAY start a number of parallel ranged downloads (one
per selected mirror server other than the first) using mirrors
provided by the Metalink/XML. Metalink clients MUST limit the number
of parallel connections to mirror servers, ideally based on observing
how the aggregate throughput changes as connections are opened. It
would be pointless to blindly open connections once the path
bottleneck is filled. After establishing a new connection, a
Metalink client SHOULD monitor whether the aggregate throughput
increases over all connections that are part of the download. The
client SHOULD NOT open additional connections during this period. If
the aggregate throughput has increased, the client MAY open an
additional connection and repeat these steps. Otherwise, the client
SHOULD NOT open a new connection until an established one closes.
The Metalink client can determine the size and number of ranges
requested from each server, based upon the type and number of mirrors
and performance observed from each mirror. Note that Range requests
impose an overhead on servers and clients need to be aware of that
and not abuse them. When dowloading a particular file, metalink
clients MUST NOT make more than one concurrent request to each mirror
server that it downloads from.
Metalink clients SHOULD close all but the fastest connection if any
Ranged requests generated after the first request end up with a
complete response, instead of a partial response (as some mirrors
might not support HTTP ranges), if the goal is the fastest transfer.
Metalink clients MAY monitor mirror conditions and dynamically switch
between mirrors to achieve the fastest download possible. Similarly,
Metalink clients SHOULD abort extremely slow or stalled range
requests and finish the request on other mirrors. If all ranges have
finished except for the final one, the Metalink client can split the
final range into multiple range requests to other mirrors so the
transfer finishes faster.
Metalink clients MUST reject individual downloads from mirrors where
the file size does not match the file size as reported by the
Metalink server.
If a Metalink client does not support certain download methods (such
as FTP or BitTorrent) that a file is available from, and there are no
available download methods that the client supports, then the
download will have no way to complete.
Metalink clients MUST verify the cryptographic hash of the file once
the download has completed. If the cryptographic hash offered in the
Metalink/XML does not match the cryptographic hash of the downloaded
file, see Section 5.1.2 for a possible way to repair errors.
Bryan, et al. Expires July 21, 2013 [Page 10]
Internet-Draft Metalink Clients, Publishers, and Caches January 2013
If the download can not be repaired, it is considered corrupt. The
client can attempt to re-download the file.
Metalink clients that support verifying digital signatures MUST
verify digital signatures of requested files if they are included.
Digital signatures MUST validate back to a trust anchor as described
in the validation rules in [RFC3156] and [RFC5280].
5.1. Error Prevention, Detection, and Correction
Error prevention, or early file mismatch detection, is possible
before file transfers with the use of file sizes provided in
Metalink/XML. Error detection requires full file cryptographic
hashes in the Metalink/XML to detect errors in transfer after the
transfers have completed. Error correction, or download repair, is
possible with partial file cryptographic hashes.
5.1.1. Error Prevention (Early File Mismatch Detection)
To verify the individual ranges of files, which might have been
requested from different sources, see Section 5.1.2.
5.1.2. Error Correction
Partial file cryptographic hashes can be used to detect errors during
the download. Metalink servers SHOULD provide Metalink/XML files
with partial file hashes in Link header fields as specified in
Section 3.1, and Metalink clients SHOULD use them for error
correction.
An error in transfer or a substitution attack will be detected by a
cryptographic hash of the object not matching the full file checksum
from the Metalink/XML. If the cryptographic hash of the object does
not match the full file checksum from the Metalink/XML, then the
client SHOULD use the partial file cryptographic hashes (if
available). This may contain partial file cryptographic hashes which
will allow detection of which mirror server returned incorrect data.
Metalink clients SHOULD use the Metalink/XML data to figure out what
ranges of the downloaded data can be recovered and what needs to be
fetched again.
Other methods can be used for error correction. For example, some
other metainfo files also include partial file hashes that can be
used to check for errors.
Bryan, et al. Expires July 21, 2013 [Page 11]
Internet-Draft Metalink Clients, Publishers, and Caches January 2013
6. IANA Considerations
None.
7. Security Considerations
7.1. Directory Traversal and Safe file names
Metalink/XML clients MUST sanitize directory traversal information as
specified in [RFC5854] Section 4.1.2.1. Also see [RFC2183] Section 5
and [RFC6266] Section 4.3 for similar considerations when creating
file names supplied by Metalink/XML files which could be created
without user input or awareness.
7.2. URIs and IRIs
Metalink clients 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
Metalinks with false information. In that case, this could deceive
unaware downloaders into downloading a malicious or worthless file.
As with all downloads, users should only download from trusted
sources. Also, malicious publishers could attempt a distributed
denial of service attack by inserting unrelated URIs into Metalinks.
[RFC4732] contains information on amplification attacks and denial of
service attacks.
7.4. Cache Poisoning
Proxy caches MUST prevent cache poisoning.
7.5. 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.
Metalink Generators and Processors MUST support "sha-256", which is
SHA-256, as specified in [FIPS-180-3], and MAY support stronger
hashes.
Bryan, et al. Expires July 21, 2013 [Page 12]
Internet-Draft Metalink Clients, Publishers, and Caches January 2013
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".
7.6. Signing
Metalinks SHOULD include digital signatures, as described in
[RFC5854] Section 4.2.13.
Digital signatures provide authentication, message integrity, and
enable non-repudiation with proof of origin.
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.
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol",
STD 9, RFC 0959, October 1985.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156, August 2001.
[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.
Bryan, et al. Expires July 21, 2013 [Page 13]
Internet-Draft Metalink Clients, Publishers, and Caches January 2013
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose
Internet Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC5854] Bryan, A., Tsujikawa, T., McNab, N., and P. Poeml, "The
Metalink Download Description Format", RFC 5854,
June 2010.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
8.2. Informative References
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183,
August 1997.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-
of-Service Considerations", RFC 4732, December 2006.
[RFC6249] Bryan, A., McNab, N., Tsujikawa, T., Poeml, P., and H.
Nordstrom, "Metalink/HTTP: Mirrors and Hashes",
RFC 6249, June 2011.
[RFC6266] Reschke, J., "Use of the Content-Disposition Header
Field in the Hypertext Transfer Protocol (HTTP)",
RFC 6266, June 2011.
Appendix A. Acknowledgements and Contributors
Some text borrowed from our previous RFCs: [RFC5854] and [RFC6249].
Thanks to the Metalink community, Daniel Stenberg, Micah Cowan,
Guiseppe Scrivano, Ilim Ugur, Jack Bates, and Mark Nottingham.
This document is dedicated to Zimmy Bryan and Juanita Anthony.
Appendix B. Document History
[[ to be removed by the RFC editor before publication as an RFC. ]]
Known issues concerning this draft:
Bryan, et al. Expires July 21, 2013 [Page 14]
Internet-Draft Metalink Clients, Publishers, and Caches January 2013
o Intro, term, downloads.
o Repeat requirements from RFC5854 or add pointer to them?
-02 : January 17, 2013.
o Minor tweaks.
-01 : July 16, 2012.
o Minor tweaks.
-00 : July 4, 2012.
o Initial draft.
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
EMail: neil@nabber.org
URI: http://www.nabber.org
Bryan, et al. Expires July 21, 2013 [Page 15]
Internet-Draft Metalink Clients, Publishers, and Caches January 2013
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. Expires July 21, 2013 [Page 16]