draft-bryan-ftp-range-02.xml

<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:draft-bryan-ftp-range-02.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 comments="yes" ?>
<?rfc inline="yes" ?>
<!DOCTYPE rfc
  PUBLIC "" "rfc2629.dtd">
<rfc category="std" docName="draft-bryan-ftp-range-02" ipr="trust200902">
    <front>        
      <title abbrev="FTP RANG Command for Byte Ranges">File Transfer Protocol RANG Command for Byte Ranges</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="D." surname="Stenberg" fullname="Daniel Stenberg">
	    <organization></organization>
	    <address>
	      <email>daniel@haxx.se</email>
	      <uri>http://www.haxx.se/</uri>
	    </address>
      </author>
	<date year="2011"/>
      <abstract>
	<t>The File Transfer Protocol offers the REST command, to designate a starting point for a transfer, but does not currently offer any method to specify an end point.
       This document specifies a new FTP RANG command to be used by clients to designate a start and end point for STREAM mode transfers with RETR.
</t>
      </abstract>
	  
<note title="Editorial Note (To be removed by RFC Editor)">
  <t>

    Discussion of this draft should take place on the FTPEXT2 working group
    mailing list (ftpext@ietf.org), although this draft is not a WG item.
	Related documents (including fancy diffs) can be found at
    <eref target="http://tools.ietf.org/wg/ftpext2/"/>.
  </t>
  <t>
    The changes in this draft are summarized in <xref target="dochistory"/>.
  </t>
</note>
	  
  </front>    

  <middle>
    <section title="Introduction">
	<t>The File Transfer Protocol offers the REST command <xref target="RFC3659"/>, to designate a starting point for a transfer, but does not currently offer any method to specify an end point.
       This document specifies a new FTP RANG command to be used by clients to designate a start and end point for STREAM mode transfers with RETR.</t>
	   
	<t>The current alternatives, without being able to specify an end point, are to issue an ABOR command or close the data connection.</t>
    <t>HTTP offers similar functionality with the Range: header in Section 14.35 of <xref target="RFC2616"/>, where a specific byte range can optionally be requested.</t>

	</section>

      <section title="Document Conventions"> 

	<t>This specification describes conformance of File Transfer Protocol Extension for RANG, a start and end point in a byte range.</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>
	
	<t>This document also uses notation defined in STD 9, <xref target="RFC0959"/>.
	In particular, the terms or commands "reply", "user", "file", "FTP commands", "user-PI" (user protocol interpreter), "server-FTP process",
    "server-PI", "mode", "Image type", "Stream transfer mode", "type", "STOR", "RETR", and "ASCII", are all used here as defined there. The command "REST" is used as defined in Section 5 of <xref target="RFC3659"/>.</t>

	<t>In the examples of FTP dialogs presented in this document, lines that
   begin "C&gt; " were sent over the control connection from the user-PI to
   the server-PI, and lines that begin "S&gt; " were sent over the control
   connection from the server-PI to the user-PI. In all cases, the
   prefixes shown above, including the one space, have been added for
   the purposes of this document, and are not a part of the data
   exchanged between client and server.</t>

	
	<t>Syntax required is defined using the Augmented BNF defined in <xref target="RFC5234"/>.</t>

<section title="Basic Tokens">
   <t>This document imports the core definitions given in Appendix B of
   <xref target="RFC5234"/>.  There definitions will be found for basic ABNF elements
   like ALPHA, DIGIT, SP, etc.  To that, the following term is added
   for use in this document.</t>

   

<t><figure> 
	  <preamble></preamble>
	  <artwork type="ABNF">
   TCHAR = VCHAR / SP / HTAB    ; visible plus white space
</artwork></figure></t>

   <t>The VCHAR (from <xref target="RFC5234"/>) and TCHAR rules give basic character
   types from varying sub-sets of the ASCII character set for use in
   various commands and responses.</t>

   <t>Note that in ABNF, string literals are case insensitive.  That
   convention is preserved in this document, and implies that FTP
   commands and parameters that are added by this specification have
   values that can be represented in any case.  That is, "RANG" is the
   same as "rang", "Rang", "RaNg", etc., and "ftp.example.com" is the
   same as "Ftp.Example.Com", "fTp.eXample.cOm", etc.</t>
</section>

<section title="Server Replies">

   <t>Section 4.2 of <xref target="RFC0959"/> defines the format and meaning of replies
   by the server-PI to FTP commands from the user-PI.  Those reply
   conventions are used here without change.</t>

<t><figure> 
	  <preamble></preamble>
	  <artwork type="ABNF">
   error-response = error-code SP *TCHAR CRLF
   error-code     = ("4" / "5") 2DIGIT
</artwork></figure></t>

   <t>Implementers should note that the ABNF syntax (which was not used in
   <xref target="RFC0959"/>) used in this document, and other FTP related documents,
   sometimes shows replies using the one line format.  Unless otherwise
   explicitly stated, that is not intended to imply that multi-line
   responses are not permitted.  Implementers should assume that, unless
   stated to the contrary, any reply to any FTP command (including QUIT)
   can be of the multi-line format described in <xref target="RFC0959"/>.</t>

   <t>Throughout this document, replies will be identified by the three
   digit code that is their first element.  Thus the term "500 reply"
   means a reply from the server-PI using the three digit code "500".</t>

</section>
      </section>

<section title="Byte Ranges in STREAM Mode">

<t>
   To get a specific part of a file without sending entire file,
   both sides need some way to agree on where in
   the data stream to start and end the data transfer.
</t><t>
   In STREAM mode, the data connection contains just a stream of
   unformatted octets of data.  Explicit restart markers thus cannot be
   inserted into the data stream, they would be indistinguishable from
   data.  For this reason, the FTP specification <xref target="RFC0959"/> did not provide the
   ability to do restarts in stream mode.  However, there is not really
   a need to have explicit restart markers in this case, as restart
   markers can be implied by the octet offset into the data stream.
</t><t>
   Because the data stream defines the file in STREAM mode, a different
   data stream would represent a different file.  Thus, an offset will
   always represent the same position within a file.  On the other hand,
   in other modes than STREAM, the same file can be transferred using
   quite different octet sequences and yet be reconstructed into the one
   identical file.  Thus an offset into the data stream in transfer
   modes other than STREAM would not give an unambiguous restart or end point.
</t><t>
   If the data representation TYPE is IMAGE and the STRUcture is File,
   for many systems the file will be stored exactly in the same format
   as it is sent across the data connection.  It is then usually very
   easy for the receiver to determine how much data was previously
   received, and notify the sender of the offset where the transfer
   should be restarted.  In other representation types and structures
   more effort will be required, but it remains always possible to
   determine the offset with finite, but perhaps non-negligible, effort.
   In the worst case, an FTP process may need to open a data connection
   to itself, set the appropriate transfer type and structure, and
   actually transmit the file, counting the transmitted octets.
</t><t>
   If the user-FTP process is intending to restart a retrieve, it will
   directly calculate the restart marker and send that information in
   the RESTart command.  However, if the user-FTP process is intending
   to restart sending the file, it needs to be able to determine how
   much data was previously sent, and correctly received and saved.
   The purpose of the SIZE command, as documented in Section 4 of <xref target="RFC3659"/>, is to get this information.
</t>

<section title="Error Recovery and Range Requests">

<t>
  STREAM mode transfers with FILE STRUcture may be range requested even
  though no restart marker has been transferred in addition to the data
  itself.  This is done by using the SIZE command, if needed, in
  combination with the RANG command, and one of the standard
  file transfer commands.
</t><t>
  When using TYPE ASCII or IMAGE, the SIZE command will return the
  number of octets that would actually be transferred if the file were
  to be sent between the two systems, i.e., with type IMAGE, the SIZE
  normally would be the number of octets in the file.  With type ASCII,
  the SIZE would be the number of octets in the file including any
  modifications required to satisfy the TYPE ASCII CR-LF end-of-line
  convention.
</t>   
</section>
   
</section>
	  
<section title="The RANGe Command (RANG)" anchor="RANG">
<t>A new command "RANG" is added to the FTP command set to allow the
client to specify both a start point byte range and an end point
byte range of a file from a server-FTP process.</t>
<t>The syntax for the RANG command when the current transfer mode is STREAM is:

<figure> 
	  <preamble></preamble>
	  <artwork type="ABNF">
   range-command = "RANG" SP start-point SP end-point CRLF
   start-point = 1*DIGIT
   end-point = 1*DIGIT	  
</artwork></figure></t>

<t>[NOTE: end-point is inclusive.]</t>

   
<t>'start-point' gives the number of octets of the
immediately-following transfer to not actually send, effectively
causing the transmission to be started at a later point. A
value of zero effectively causes the transmission to be started
at first byte.  'end-point' gives the number of octets, counted from the beginning of the file, of the
immediately-following transfer to stop sending at, effectively
causing the transmission to be ended.  (That is, the end point is relative to the start of the file and not relative to the start point). The server-PI will
respond to the RANG command with a 350 reply, indicating that
RANG parameters have been saved, and that another command, which
should be RETR, should then follow to complete the ranged request.</t>

<t><figure> 
	  <preamble></preamble>
	  <artwork type="ABNF">
   range-response = range-ok / error-response
   range-ok       = "350" SP *TCHAR CRLF	  
</artwork></figure></t>

<t>The RANG command is intended to select the partial data of a file.
When the RANG command is used with RETR, the client bears the
responsibility of merging the retrieved data with the partially
retrieved file.  It may choose to use the data obtained other
than to complete an earlier transfer, or to re-retrieve data that
had been retrieved before.</t>

<t>To reset the range command, "RANG 1 0" should be issued. 
Invalid RANG requests where 'start-point' is larger than 'end-point' 
automatically reset the byte selection to the default, which is the whole file.
The server-PI MUST reply with a 350 reply if "RANG 1 0" is issued
by client-PI because it is a valid way of resetting range. (The range would also be reset if the session
is reinitialized with REIN but this terminates the user and resets all parameters).</t>

<t>The RANG command MUST be the last command issued before the data
transfer command that is to cause a partial data transfer.  The
effect of issuing a RANG command at any other time is undefined.
The server-PI may react to a badly positioned RANG command by
issuing an error response to the following command, not being a
restartable data transfer command, or it may save the start-point
and/or end-point byte range value and apply it to the next data
transfer command, or it may silently ignore the inappropriate
restart attempt.  Because of this, a user-PI that has issued a
RANG command, but that has not successfully transmitted the
following data transfer command for any reason, should send
another RANG command before the next data transfer command.  If
that transfer is not to be restarted, then "RANG 1 0" should be
issued.</t>

<t>An error response will follow a RANG command only when the server
does not implement the command, or when command syntax is
invalid.  Any other errors, including such problems as
start-point and/or end-point byte range out of range, should be
reported when the following transfer command is issued.  Such
errors will cause that transfer request to be rejected with an
error indicating the invalid restart attempt.</t>

<section title="FEAT Command Response for RANG Command">

<t>When replying to the FEAT command <xref target="RFC2389"/>, a server-FTP process that supports the RANG command, as specified here, MUST include, a line containing exactly the string "RANG STREAM".
This string is case insensitive, and MAY be sent in any mixture of upper or lower case, however it SHOULD be sent in upper case. That is, the response SHOULD be:</t>

<t><figure> 
	  <preamble></preamble>
	  <artwork type="example">
   C&gt; FEAT
   S&gt; 211-Extensions supported:
   S&gt;  ...
   S&gt;  RANG STREAM
   S&gt;  ...
   S&gt; 211 END
</artwork></figure></t>

<t>The ellipses indicate place holders where other features may be included, and are not required. The one-space indentation of the feature lines is mandatory <xref target="RFC2389"/>.</t>

<t><figure> 
	  <preamble></preamble>
	  <artwork type="ABNF">	
   range-feat = SP "RANG" SP "STREAM"
</artwork></figure></t>

</section>


<section title="User-PI usage of RANG">

<t>The user-PI issues the FEAT command to query the server-PI if it supports the RANG command. In this example, the server-PI also supports REST.</t>

<t><figure> 
	  <preamble></preamble>
	  <artwork type="example">
   C&gt; FEAT
   S&gt; 211-Extensions supported:
   S&gt;  ...
   S&gt;  REST STREAM
   S&gt;  RANG STREAM   
   S&gt;  ...
   S&gt; 211 END
</artwork></figure></t>

<t>
   Assume that the transfer of a largish file has previously been
   interrupted after 802816 octets had been received, that the transfer should stop at octet 1000000 of the file, that the previous
   transfer was with TYPE=I, and that it has been verified that the file
   on the server has not since changed.
<figure>
	  <preamble></preamble>
	  <artwork type="example">
   C&gt; TYPE I
   S&gt; 200 Type set to I.
   C&gt; PORT 127,0,0,1,15,107
   S&gt; 200 PORT command successful.
   C&gt; RANG 802816 1000000
   S&gt; 350 Restarting at 802816. End Byte range at 1000000.
   C&gt; RETR cap60.pl198.tar
   S&gt; 150 Opening BINARY mode data connection
   [...]
   S&gt; 226 Transfer complete.
</artwork></figure></t>

<t>In the above example, data is sent from offset 802816 to, and including, offset 1000000.</t>

</section>

<section title="RANG Command Errors">


<t>The server-PI SHOULD reply with a 500 reply if the RANG command is unrecognized or unimplemented.</t>

<t>The server-PI SHOULD reply with a 550 reply if the RANG command is used on a file that can not be found.</t>

<t>The server-PI SHOULD reply with a 551 reply if the server-PI is unable to deliver the file with TYPE I and MODE S.</t>

<t>The server-PI SHOULD reply with a 552 reply if the user is not allowed to use the RANG command.</t>

<t>The server-PI SHOULD reply with a 553 reply if the user requests the RANG of a directory, which is not allowed.</t>

<t>The server-PI SHOULD reply with a 5yz reply if the specified end point is larger than the actual file.</t>

</section>

</section>

<section title="RANG Command Use with Other Commands">

<t>This specification defines the use of RANG in a certain way. Other commands could decide to use RANG in a similar way, to select a byte range, and their specification would
define how they operate with RANG. The HASH command <xref target="draft-ietf-ftpext2-hash"/> uses RANG to select a byte range for partial file hashing.</t>

</section>


	<section title="IANA Considerations" anchor="IANA">
	<t>This new command is added to the "FTP Commands and Extensions" registry created by <xref target="RFC5797"/>.</t>
	<t>Command Name: RANG</t>
	<t>Description: End point byte range (for STREAM mode).</t>
	<t>FEAT String: RANG STREAM</t>
	<t>Command Type: Service execution/parameter setting</t>
	<t>Conformance Requirements: Optional</t>
	<t>Reference: This specification</t>


   
	</section>
	
	  <section title="Security Considerations">
	  
<t>
   This memo does not directly concern security.  It is not believed
   that any of the mechanisms documented here impact in any particular
   way upon the security of FTP.</t>
		
	  </section>
	  


	</middle>

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

<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="RFC2389">

<front>
<title>Feature negotiation mechanism for the File Transfer Protocol</title>
<author initials="P." surname="Hethmon" fullname="P. Hethmon">
<organization/></author>
<author initials="R." surname="Elz" fullname="R. Elz">
<organization/></author>
<date year="1998" month="August"/></front>

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


<reference anchor="RFC3659">

<front>
<title>Extensions to FTP</title>
<author initials="P." surname="Hethmon" fullname="P. Hethmon">
<organization/></author>
<date year="2007" month="March"/></front>

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

<reference anchor="RFC5234">

<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials="D." surname="Crocker" fullname="D. Crocker">
<organization/></author>
<author initials="P." surname="Overell" fullname="P. Overell">
<organization/></author>
<date year="2008" month="January"/></front>

<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
</reference>


	  </references>


	  <references title="Informative References">

<reference anchor='RFC2616'>

<front>
<title abbrev='HTTP/1.1'>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='UC Irvine'>Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>

<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email></address></author>
<author initials='J.' surname='Gettys' fullname='James Gettys'>
<organization abbrev='Compaq/W3C'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>

<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email></address></author>
<author initials='J.' surname='Mogul' fullname='Jeffrey C. Mogul'>
<organization abbrev='Compaq'>Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>

<city>Palo Alto</city>
<region>CA</region>
<code>94305</code></postal>
<email>mogul@wrl.dec.com</email></address></author>
<author initials='H.' surname='Frystyk' fullname='Henrik Frystyk Nielsen'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>

<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Xerox'>Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>

<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<email>masinter@parc.xerox.com</email></address></author>
<author initials='P.' surname='Leach' fullname='Paul J. Leach'>
<organization abbrev='Microsoft'>Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>

<city>Redmond</city>
<region>WA</region>
<code>98052</code></postal>
<email>paulle@microsoft.com</email></address></author>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>

<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email></address></author>
<date year='1999' month='June' />
<abstract>
<t>
   The Hypertext Transfer Protocol (HTTP) is an application-level
   protocol for distributed, collaborative, hypermedia information
   systems. It is a generic, stateless, protocol which can be used for
   many tasks beyond its use for hypertext, such as name servers and
   distributed object management systems, through extension of its
   request methods, error codes and headers . A feature of HTTP is
   the typing and negotiation of data representation, allowing systems
   to be built independently of the data being transferred.
</t>
<t>

   HTTP has been in use by the World-Wide Web global information
   initiative since 1990. This specification defines the protocol
   referred to as "HTTP/1.1", and is an update to RFC 2068 .
</t></abstract></front>

<seriesInfo name='RFC' value='2616' />
<format type='TXT' octets='422317' target='http://www.rfc-editor.org/rfc/rfc2616.txt' />
<format type='PS' octets='5529857' target='http://www.rfc-editor.org/rfc/rfc2616.ps' />
<format type='PDF' octets='550558' target='http://www.rfc-editor.org/rfc/rfc2616.pdf' />
<format type='HTML' octets='636125' target='http://xml.resource.org/public/rfc/html/rfc2616.html' />
<format type='XML' octets='493420' target='http://xml.resource.org/public/rfc/xml/rfc2616.xml' />
</reference>

<reference anchor="RFC5797">

<front>
<title>FTP Command and Extension Registry</title>
<author initials="J." surname="Klensin" fullname="J. Klensin">
<organization/></author>
<author initials="A." surname="Hoenes" fullname="A. Hoenes">
<organization/></author>
<date year="2010" month="March"/></front>

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

<reference anchor="draft-ietf-ftpext2-hash">
  <front>
      <title abbrev="FTP Extensions for Cryptographic Hashes">FTP Extensions for Cryptographic Hashes</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="Kosse" fullname="Tim Kosse">
	    <organization></organization>
	    <address>
	      <email>tim.kosse@filezilla-project.org</email>	
	      <uri>http://filezilla-project.org/</uri>		
	    </address>
      </author>
      <author initials="D." surname="Stenberg" fullname="Daniel Stenberg">
	    <organization></organization>
	    <address>
	      <email>daniel@haxx.se</email>
	      <uri>http://www.haxx.se/</uri>
	    </address>
      </author>
	<date month="November" year="2010"/>   
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-ftpext2-hash-00"/>
</reference>

	    </references> 

	    <section title="Acknowledgements and Contributors">
		  <t>Thanks to the FTPEXT2 Working Group and Kamil Dudka.</t>
		  <t>Portions of <xref target="RFC3659"/> were wholly reused in this document.</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>Expand current alternatives (ABOR, close data connection) and why they are not optimal.</t>

	    </list></t>

<t>draft-bryan-ftp-range-02 : February 1, 2011.
	    
	    <list style="symbols">

	      <t>Refinements.</t>
	    </list></t>
		
<t>draft-bryan-ftp-range-01 : January 25, 2011.
	    
	    <list style="symbols">

	      <t>Refinements. "RANG 1 0" resets byte selection.</t>
	    </list></t>
		
		
<t>draft-bryan-ftp-range-00 : December 13, 2010.
	    
	    <list style="symbols">

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