draft-bryan-metalink-client-03.xml

<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:draft-bryan-metalink-client-03.xml"?>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocdepth="3" ?>
<?rfc tocindent="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>

<!DOCTYPE rfc
  PUBLIC "" "rfc2629.dtd">
  
<rfc category="std" docName="draft-bryan-metalink-client-03" ipr="trust200902">

    <front>        
      <title abbrev="Metalink Clients, Publishers, and Caches">Metalink/XML Clients, Publishers, and Caches</title>
	  
      <author initials="A." surname="Bryan" fullname="Anthony Bryan">
	    <organization></organization>
	    <address>
		  <postal>
			<street></street>
		    <city>Pompano Beach</city>
			<region>FL</region>
			<country>USA</country>
		  </postal>
	      <email>anthonybryan@gmail.com</email>	
	      <uri>http://www.metalinker.org</uri>		
	    </address>
      </author>
	  
      <author initials="T." surname="Tsujikawa" fullname="Tatsuhiro Tsujikawa">
        <organization></organization>
        <address>
		  <postal>
			<street></street>
			<city></city>
			<region>Shiga</region>
			<country>Japan</country>
		  </postal>
          <email>tatsuhiro.t@gmail.com</email>
          <uri>http://aria2.sourceforge.net</uri>
        </address>
      </author>
	  
	  <author initials="N." surname="McNab" fullname="Neil McNab">
        <organization></organization>
        <address>
          <email>neil@nabber.org</email>
          <uri>http://www.nabber.org</uri>
        </address>
      </author>
	  
      <author initials="P." surname="Poeml" fullname="Dr. med. Peter Poeml">
        <organization>MirrorBrain</organization>
        <address>
          <postal>
            <street>Venloer Str. 317</street>
            <city>Koeln</city>
            <code>50823</code>
            <country>DE</country>
          </postal>
          <phone>+49 221 6778 333 8</phone>
          <email>peter@poeml.de</email>
          <uri>http://mirrorbrain.org/~poeml/</uri>
        </address>
      </author>

	  <date year="2013"/>        

      <abstract>
    <t>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.</t>
      </abstract>

<note title="Editorial Note (To be removed by RFC Editor)">
  <t>

    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.
  </t>
  <t>
    The changes in this draft are summarized in <xref target="dochistory"/>.
  </t>
</note>
  </front>    

  <middle>

    <section title="Introduction">

      <t>Metalink <xref target="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.</t>

      <t>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.</t>
	  
      <t>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.</t>

      <t>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.</t>


      
      <t>Metalink/HTTP <xref target="RFC6249"/> is an alternative and complementary representation of Metalink information, using HTTP header fields instead of the XML-based document format <xref target="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.</t>
      
      

      <t>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.</t>

      <t>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.</t>

	  <t>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.</t>
   
      <section title="Notational Conventions"> 

	<t>This specification describes conformance of Metalink/HTTP.</t>
     

	<t>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, <xref target="RFC2119"/>, as scoped to those conformance targets.</t>

      </section>
	  <section title="Terminology">
	  <t>In this context, "Metalink" refers to "Metalink/XML" refers to the XML format described in <xref target="RFC5854"/>.</t>
	  <t>The following terms as used in this document are defined here:
	    <list style="symbols">

		  <t>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.</t>
		  <t>Metalink Publisher : One who uses a Metalink Generator to create Metalink/XML files that are then offered to people to improve their download experience.</t>
		  <t>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.</t>
		  <t>Metalink/XML : An XML file which describes a file that can contain information such as mirrors, cryptographic hashes, digital signatures, and more.</t>
		  <t>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.</t>
          <t>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.</t>
		  </list></t>	  
	  </section>
    </section>
	
	<section title="Metalink/XML Clients" anchor="clients">

      <t>Metalink/XML clients use the mirrors provided by a Metalink/XML file. Metalink clients SHOULD support HTTP <xref target="RFC2616"/> and SHOULD support FTP <xref target="RFC0959"/>. Metalink clients MAY support BitTorrent <xref target="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 the cryptographic hashes of parts of the file listed in Metalink/XML files, as described in <xref target="RFC5854"/>, Section 4.1.3.</t>

<t>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.</t>

<t>Metalink/XML clients MUST process metalinks available by URI. They MAY process local Metalinks.</t>

<t>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?]]</t>

<t>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 <xref target="metalinkxml"/>).</t>

<t>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).</t>

<t>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?</t>

<t>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?)</t>

<t>If client supports Metalink/XML AND Metalink/HTTP, which should be preferred (in case mirrors/hashes differ)?</t>

<t>Metalink/XML clients SHOULD make use of Metalink/XML origin element if dynamic="true" to check for updated Metalink.</t>

<t>Metalink/XML clients MAY make use of the <xref target="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 download experience.</t>

<t>Metalink/XML clients could support multiple versions of Metalink/XML, and if they do they SHOULD prefer <xref target="RFC5854"/> Metalink/XML files.</t>
<t>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.</t>
   
<t>Metalink/XML clients MAY create the directory structure described in the Metalink/XML at a relative download location, but see <xref target="traversalfilenames"/>.</t>

<t>Metalink clients could use the location of the original Metalink in the "Referer" header field for these ranged requests.</t>

<t>Metalink clients MAY support the use of metainfo files (such as BitTorrent) for downloading files.</t>

<t>Metalink clients SHOULD support the use of OpenPGP signatures.</t>

<t>Metalink clients SHOULD support the use of S/MIME <xref target="RFC5751"/> signatures.</t>

<t>Previously, Metalink/XML clients that support HTTP would do Accept header transparent content negotiation, but this has been deprecated.</t>

<t>[[ NOTE: A number of requirements of Metalink clients are also in <xref target="RFC5854"/>. Should these be repeated or referenced?]]</t>

	</section>

	<section title="Metalink/XML Publishers and Generators" anchor="publishers">
<t>Metalink/XML publishers MUST use correct MIME type for metalink files</t>

<t>Metalink/XML publishers SHOULD advertise Metalink/XML file with Link HTTP header field from regular download for "transparent metalink" usage (see <xref target="metalinkxml"/>).</t>

<t>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).</t>
<t>Metalink Generators SHOULD offer Metalink/XML documents that contain cryptographic hashes of parts of the file (and other information) if error recovery is desirable.</t>

<t>Metalink/XML publishers SHOULD publish with size element if it refers to a specific file.</t>

<t>Metalink/XML publishers MAY do Accept header transparent content negotiation (deprecated?)</t>

<t>Metalink/XML publishers SHOULD include Metalink/XML origin element and dynamic="true" if updated metalinks will be offered.</t>

<t>Metalink publishers SHOULD include digital signatures, as described in <xref target="RFC5854"/> Section 4.2.13.</t>
    
	<section title="Transparent Metalink/XML Usage" anchor="metalinkxml">
      <t>Metalink/XML files for a given resource MAY be provided in a Link header field <xref target="RFC5988"/> as shown in this example:</t>

<t><figure> 
          <preamble>This example shows a brief HTTP response header with .meta4:</preamble>        
          <artwork type="example">
Link: &lt;http://example.com/example.ext.meta4&gt;; rel=describedby;
type="application/metalink4+xml"
</artwork></figure></t>
          <t>Metalink/XML files are specified in <xref target="RFC5854"/>, and they are particularly useful for providing metadata such as cryptographic hashes of parts of a file (see <xref target="RFC5854"/> Section 4.1.3), allowing a
      client to recover from errors (see <xref target="errorcorrection"/>). 
Metalink servers SHOULD provide Metalink/XML files with partial file hashes in
Link header fields, and Metalink clients SHOULD use them for error recovery.</t>
    </section>

	<section title="Mirror Servers" anchor="mirrors">
	  <t>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.</t>
	</section>
	</section>
	
	<section title="Metalink/XML Proxy Cache" anchor="cache">
<t>Metalink/XML proxy cache could detect and log Metalink usage.</t>
<t>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.</t>
<t>Metalink/XML proxy cache SHOULD use preferred mirrors (those that are most cost efficient/better/local)</t>
<t>Metalink/XML proxy cache MAY? repair errors or use hashes? I guess so, but the client will also be verifying hashes.</t>
	</section>
	
	



    <section title="Client / Server Multi-source Download Interaction" anchor="clientserver">
	  <t>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.</t>


<t>After that, the client follows with a GET request to the desired mirrors.</t>

<t>From the Metalink/XML file, the client learns some or all of the following metadata
about the requested object:</t>
<t>
<list style="symbols">
<t>Mirror list, which can describe the mirror's priority and geographical location.</t>
<t>Whole and partial file cryptographic hash.</t>
<t>Object size.</t>
<t>Peer-to-peer information.</t>
<t>Digital signature.</t>
</list></t>

<t>Next, the Metalink client requests a Range of the object from a mirror server:

<figure> 
	  <artwork type="example">
GET /example.ext HTTP/1.1
Host: www2.example.com
Range: bytes=7433802-
Referer: http://www.example.com/distribution/example.ext
</artwork></figure></t>

<t>Metalink clients SHOULD use partial file cryptographic hashes as described in <xref target="errorcorrection"/>, 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 <xref target="errorcorrection"/>.</t>

<t>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:

<figure> 
	  <artwork type="example">
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Length: 7433801
Content-Range: bytes 7433802-14867602/14867603
</artwork></figure></t>

<t>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.
</t>


<t>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.</t>

<t>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.</t>

<t>Metalink clients MUST reject individual downloads from mirrors where the file size does not match the file size as reported by the Metalink server.</t>

<t>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.</t>

<t>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 <xref target="errorcorrection"/> for a possible way to repair errors.</t>

<t>If the download can not be repaired, it is considered corrupt. The client can attempt to re-download the file.</t>

<t>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 <xref target="RFC3156"/> and <xref target="RFC5280"/>.</t>

<section title="Error Prevention, Detection, and Correction">

<t>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.</t>

<section title="Error Prevention (Early File Mismatch Detection)" anchor="earlyfilemismatchdetection">

<t>To verify the individual ranges of files, which might have been requested from different sources, see <xref target="errorcorrection"/>.</t>

</section>

<section title="Error Correction" anchor="errorcorrection">

<t>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 <xref target="metalinkxml"/>, and Metalink clients SHOULD use them for error correction.</t>

<t>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. 
</t>

<t>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.</t>

</section>

</section>

    </section>

	<section title="IANA Considerations" anchor="IANA">

	<t>None.</t>

	</section>

	<section title="Security Considerations">

        <section title="Directory Traversal and Safe file names" anchor="traversalfilenames">
		<t>Metalink/XML clients MUST sanitize directory traversal information as specified in <xref target="RFC5854"/> Section 4.1.2.1. Also see <xref target="RFC2183"/> Section 5 and <xref target="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.</t>
		</section>

	    <section title="URIs and IRIs">

	      <t>Metalink clients handle URIs and IRIs. See Section 7 of <xref target="RFC3986"/> and Section 8 of <xref target="RFC3987"/> for security
          considerations related to their handling and use.</t>

	    </section>

	    <section title="Spoofing">

	      <t>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. 
		  <xref target="RFC4732"/> contains information on amplification attacks and denial of service attacks.</t>

	    </section>	
		
		<section title="Cache Poisoning">
		
		  <t>Proxy caches MUST prevent cache poisoning.</t>
		  
		</section>

	    <section title="Cryptographic Hashes" anchor="security.hash">

	      <t>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.</t>
		  <t>Metalink Generators and Processors MUST support "sha-256", which is SHA-256, as specified in <xref target="FIPS-180-3"/>, and MAY support stronger hashes.</t>
          <t>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".</t>

	    </section>	
		
		
	    <section title="Signing">

	      <t>Metalinks SHOULD include digital signatures, as described in <xref target="RFC5854"/> Section 4.2.13.</t>

	      <t>Digital signatures provide authentication, message integrity, and enable non-repudiation with proof of origin.</t>

	    </section>

	  </section>
    
	</middle> 

	<back> 
	  
	  <references title="Normative References">

<reference anchor="BITTORRENT" target="http://www.bittorrent.org/beps/bep_0003.html">
<front>
<title>The BitTorrent Protocol Specification</title>

<author initials="B" surname="Cohen" fullname="Bram Cohen">
    <organization/>
</author>


<date month="February" day="28" year="2008"/>
</front>

<seriesInfo name="BITTORRENT" value="11031"/>
</reference>	

<reference anchor="RFC0959">

<front>
<title>File Transfer Protocol</title>
<author initials="J." surname="Postel" fullname="J. Postel">
<organization/></author>
<author initials="J." surname="Reynolds" fullname="J. Reynolds">
<organization/></author>
<date year="1985" month="October"/></front>

<seriesInfo name="STD" value="9"/>
<seriesInfo name="RFC" value="0959"/>
</reference>

<reference anchor="RFC2119">

<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year="1997" month="March"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      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
      RFC 2119.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>

<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
</reference>


<reference anchor="RFC2616">

<front>
<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding" fullname="R. Fielding">
<organization/></author>
<author initials="J." surname="Gettys" fullname="J. Gettys">
<organization/></author>
<author initials="J." surname="Mogul" fullname="J. Mogul">
<organization/></author>
<author initials="H." surname="Frystyk" fullname="H. Frystyk">
<organization/></author>
<author initials="L." surname="Masinter" fullname="L. Masinter">
<organization/></author>
<author initials="P." surname="Leach" fullname="P. Leach">
<organization/></author>
<author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
<organization/></author>
<date year="1999" month="June"/></front>

<seriesInfo name="RFC" value="2616"/>
</reference>

<reference anchor='RFC3156'>

<front>
<title>MIME Security with OpenPGP</title>
<author initials='M.' surname='Elkins' fullname='M. Elkins'>
<organization /></author>
<author initials='D.' surname='Del Torto' fullname='D. Del Torto'>
<organization /></author>
<author initials='R.' surname='Levien' fullname='R. Levien'>
<organization /></author>
<author initials='T.' surname='Roessler' fullname='T. Roessler'>
<organization /></author>
<date year='2001' month='August' />
<abstract>

<t>This document describes how the OpenPGP Message Format can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='3156' />
<format type='TXT' octets='26809' target='http://www.rfc-editor.org/rfc/rfc3156.txt' />
</reference>




<reference anchor="RFC3986">

<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
<organization/></author>
<author initials="R." surname="Fielding" fullname="R. Fielding">
<organization/></author>
<author initials="L." surname="Masinter" fullname="L. Masinter">
<organization/></author>
<date year="2005" month="January"/></front>

<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
</reference>
 

<reference anchor="RFC3987">

<front>
<title>Internationalized Resource Identifiers (IRIs)</title>
<author initials="M." surname="Duerst" fullname="M. Duerst">
<organization/></author>
<author initials="M." surname="Suignard" fullname="M. Suignard">
<organization/></author>
<date year="2005" month="January"/></front>

<seriesInfo name="RFC" value="3987"/>
</reference>

<reference anchor='RFC5280'>

<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'>
<organization /></author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'>
<organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'>
<organization /></author>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'>
<organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'>
<organization /></author>

<author initials='W.' surname='Polk' fullname='W. Polk'>
<organization /></author>
<date year='2008' month='May' />
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='5280' />
<format type='TXT' octets='352580' target='http://www.rfc-editor.org/rfc/rfc5280.txt' />
</reference>


<reference anchor="RFC5988">
  <front>
    <title abbrev="Web Linking">Web Linking</title>
    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
	  <organization></organization>
      <address><email>mnot@mnot.net</email></address>
    </author>
    <date month="October" year="2010"/>
  </front>
  <seriesInfo name="RFC" value="5988"/>
</reference>

<reference anchor="FIPS-180-3">
<front>
<title>Secure Hash Standard (SHS)</title>
<author>
    <organization>National Institute of Standards and Technology (NIST)</organization>
</author>
<date year="2008" month="October"></date>
</front>
<seriesInfo name="FIPS PUB" value="180-3"></seriesInfo>
</reference>

<reference anchor='RFC5751'>

<front>
<title>Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification</title>
<author initials='B.' surname='Ramsdell' fullname='B. Ramsdell'>
<organization /></author>
<author initials='S.' surname='Turner' fullname='S. Turner'>
<organization /></author>
<date year='2010' month='January' />
<abstract>
<t>This document defines Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.2.  S/MIME provides a consistent way to send and receive secure MIME data.  Digital signatures provide authentication, message integrity, and non-repudiation with proof of origin.  Encryption provides data confidentiality.  Compression can be used to reduce data size.  This document obsoletes RFC 3851. [STANDARDS-TRACK]</t></abstract></front>

<seriesInfo name='RFC' value='5751' />

</reference>


<reference anchor="RFC5854">
  <front>
      <title abbrev="Metalink Download Description Format">The Metalink Download Description Format</title>		
      <author initials="A." surname="Bryan" fullname="Anthony Bryan">
	    <organization>Metalinker Project</organization>
	    <address>		
	      <email>anthonybryan@gmail.com</email>	
	      <uri>http://www.metalinker.org</uri>		
	    </address>
      </author>
      <author initials="T." surname="Tsujikawa" fullname="Tatsuhiro Tsujikawa">
        <organization>Metalinker Project</organization>
        <address>
          <email>tatsuhiro.t@gmail.com</email>
          <uri>http://aria2.sourceforge.net</uri>
        </address>
      </author>
      <author initials="N." surname="McNab" fullname="Neil McNab">
        <organization>Metalinker Project</organization>
        <address>
          <email>neil@nabber.org</email>
          <uri>http://www.nabber.org</uri>
        </address>
      </author>
      <author initials="P." surname="Poeml" fullname="Peter Poeml">
        <organization>MirrorBrain</organization>
        <address>
          <email>peter@poeml.de</email>
          <uri>http://mirrorbrain.org/~poeml/</uri>
        </address>
      </author>
    <date month="June" year="2010"/>
  </front>
<seriesInfo name="RFC" value="5854"/>
</reference>






<reference anchor="ISO3166-1">

<front>
<title>ISO 3166-1:2006.  Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes</title>
<author>
<organization>International Organization for Standardization</organization>
</author>
<date month="November" year="2006"/></front>
</reference>

	  </references>

      <references title="Informative References">

<reference anchor="RFC2183">
<front>
<title abbrev="Content-Disposition">
Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
</title>
<author initials="R." surname="Troost" fullname="Rens Troost">
<organization>New Century Systems</organization>
<address>
<postal>
<street>324 East 41st Street #804</street>
<street>New York</street>
<street>NY</street>
<street>10017</street>
<country>USA</country>
</postal>
<phone>+1 (212) 557-2050</phone>
<facsimile>+1 (212) 557-2049</facsimile>
<email>rens@century.com</email>
</address>
</author>
<author initials="S." surname="Dorner" fullname="Steve Dorner">
<organization>QUALCOMM Incorporated</organization>
<address>
<postal>
<street>6455 Lusk Boulevard</street>
<street>San Diego</street>
<street>CA 92121</street>
<country>USA</country>
</postal>
<email>sdorner@qualcomm.com</email>
</address>
</author>
<author initials="K." surname="Moore" fullname="Keith Moore">
<organization>Department of Computer Science</organization>
<address>
<postal>
<street>University of Tennessee</street>
<street>Knoxville</street>
<street>107 Ayres Hall</street>
<street>Knoxville TN 37996-1301</street>
<country>USA</country>
</postal>
<phone>+1 (423) 974-5067</phone>
<facsimile>+1 (423) 974-8296</facsimile>
<email>moore@cs.utk.edu</email>
</address>
</author>
<date year="1997" month="August"/>
<area>Applications</area>
<keyword>MIME</keyword>
<keyword>internet message</keyword>
<keyword>multipurpose internet mail extensions</keyword>
<abstract>
<t>
This memo provides a mechanism whereby messages conforming to the MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049] can convey presentational information. It specifies the "Content-Disposition" header field, which is optional and valid for any MIME entity ("message" or "body part"). Two values for this header field are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values.
</t>
<t>
This document is intended as an extension to MIME. As such, the reader is assumed to be familiar with the MIME specifications, and [RFC 822]. The information presented herein supplements but does not replace that found in those documents.
</t>
<t>
This document is a revision to the Experimental protocol defined in RFC 1806. As compared to RFC 1806, this document contains minor editorial updates, adds new parameters needed to support the File Transfer Body Part, and references a separate specification for the handling of non-ASCII and/or very long parameter values.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2183"/>
<format type="TXT" octets="23150" target="http://www.rfc-editor.org/rfc/rfc2183.txt"/>
<format type="HTML" octets="42115" target="http://xml.resource.org/public/rfc/html/rfc2183.html"/>
<format type="XML" octets="24289" target="http://xml.resource.org/public/rfc/xml/rfc2183.xml"/>
</reference>

<reference anchor='RFC4732'>

<front>
<title>Internet Denial-of-Service Considerations</title>
<author initials='M.' surname='Handley' fullname='M. Handley'>
<organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<author>
<organization>IAB</organization></author>
<date year='2006' month='December' />
<abstract>
<t>This document provides an overview of possible avenues for denial-of-service (DoS) attack on Internet systems.  The aim is to encourage protocol designers and network engineers towards designs that are more robust.  We discuss partial solutions that reduce the effectiveness of attacks, and how some solutions might inadvertently open up alternative vulnerabilities.  This memo provides information for the Internet community.</t></abstract></front>

<seriesInfo name='RFC' value='4732' />
<format type='TXT' octets='91844' target='http://www.rfc-editor.org/rfc/rfc4732.txt' />
</reference>

<reference anchor="RFC6249">
<front>
<title>Metalink/HTTP: Mirrors and Hashes</title>
<author initials="A." surname="Bryan" fullname="A. Bryan">
<organization/>
</author>
<author initials="N." surname="McNab" fullname="N. McNab">
<organization/>
</author>
<author initials="T." surname="Tsujikawa" fullname="T. Tsujikawa">
<organization/>
</author>
<author initials="P." surname="Poeml" fullname="P. Poeml">
<organization/>
</author>
<author initials="H." surname="Nordstrom" fullname="H. Nordstrom">
<organization/>
</author>
<date year="2011" month="June"/>
<abstract>
<t>
This document specifies Metalink/HTTP: Mirrors and Cryptographic Hashes in HTTP header fields, a different way to get information that is usually contained in the Metalink XML-based download description format. Metalink/HTTP describes multiple download locations (mirrors), Peer-to-Peer, cryptographic hashes, digital signatures, and other information using existing standards for HTTP header fields. Metalink clients can use this information to make file transfers more robust and reliable. Normative requirements for Metalink/HTTP clients and servers are described here. [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6249"/>
<format type="TXT" octets="45303" target="http://www.rfc-editor.org/rfc/rfc6249.txt"/>
</reference>
	  
<reference anchor="RFC6266">
<front>
<title>
Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)
</title>
<author initials="J." surname="Reschke" fullname="J. Reschke">
<organization/>
</author>
<date year="2011" month="June"/>
<abstract>
<t>
RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects. [STANDARDS-TRACK]
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6266"/>
<format type="TXT" octets="26080" target="http://www.rfc-editor.org/rfc/rfc6266.txt"/>
</reference>



      </references>	  


	    <section title="Acknowledgements and Contributors">
		  <t>Some text borrowed from our previous RFCs: <xref target="RFC5854"/> and <xref target="RFC6249"/>.</t>
		  <t>Thanks to the Metalink community, Daniel Stenberg, Micah Cowan, Guiseppe Scrivano, Ilim Ugur, Jack Bates, and Mark Nottingham.</t>  
		  
		  <t>This document is dedicated to Zimmy Bryan and Juanita Anthony.</t>

	    </section> 



	    <section title="Document History" anchor="dochistory">
		<t>[[ to be removed by the RFC editor before publication as an RFC. ]]</t>
		<t>Known issues concerning this draft:
	    <list style="symbols"> 
	      
	      <t>Intro, term, downloads.</t>
		  <t>Repeat requirements from RFC5854 or add pointer to them?</t>
	    </list></t>
<t>-02 : January 17, 2013.
	    
	    <list style="symbols">

	      <t>Minor tweaks.</t>
	    </list></t>

<t>-01 : July 16, 2012.
	    
	    <list style="symbols">

	      <t>Minor tweaks.</t>
	    </list></t>
		
<t>-00 : July 4, 2012.
	    
	    <list style="symbols">

	      <t>Initial draft.</t>
	    </list></t>
		
	    </section>
	  </back> 
	</rfc>