<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
        <!ENTITY rfc2087 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2087.xml'>
        <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
        <!ENTITY rfc3501 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3501.xml'>
        <!ENTITY rfc3502 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3502.xml'>
        <!ENTITY rfc3516 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3516.xml'>
        <!ENTITY rfc4466 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4466.xml'>
        <!ENTITY rfc4469 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4469.xml'>
        <!ENTITY rfc5161 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5161.xml'>
        <!ENTITY rfc5092 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5092.xml'>
        <!ENTITY rfc5550 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5550.xml'>
        <!ENTITY rfc7888 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7888.xml'>
        <!ENTITY rfc7889 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7889.xml'>
]>

<!--///The IPR might need sorting out-->

<rfc category="std" ipr="pre5378Trust200902" docName="draft-ietf-extra-imap-64bit-03.txt" updates="2087, 3501, 4466, 5092, 5550, 7888, 7889">
	<?xml-stylesheet href="rfc5162_files/rfc2629.htm" type="text/xsl"?>
        <?rfc strict="yes" ?>
        <?rfc toc="yes" ?>
	<?rfc symrefs="yes" ?>
	<?rfc sortrefs="yes"?>
	<?rfc iprnotified="no" ?>
	<?rfc strict="yes" ?>
	<?rfc comments="yes" ?>
	<?rfc inline="yes" ?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<front>
		<title>64bit body part and message sizes in IMAP4</title>

    <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
			<organization>Isode Ltd</organization>
			<address>
				<postal>
					<street>14 Castle Mews</street>
					<city>Hampton</city>
					<region>Middlesex</region>
					<code>TW12 2NP</code>
					<country>UK</country>
				</postal>
				<email>Alexey.Melnikov@isode.com</email>
			</address>
		</author>
    <author initials="SB." surname="Jayantheesh" fullname="Jayantheesh S B">
      <organization>Samsung Electronics America</organization>
      <address>
        <postal>
          <street>685 US Highway 202/206</street>
          <city>Bridgewater</city>
          <region>New Jersey</region>
          <code>08807</code>
          <country>USA</country>
        </postal>
        <email>jayantheesh.sb@gmail.com</email>
      </address>
    </author>

    <date year="2018"/>
    
    <keyword>IMAP</keyword>
    <keyword>64bit</keyword>

    <abstract>
	  <t>
		This document defines an IMAPv4rev1 extension that extends the existing
		IMAPv4rev1 32 Bit message and body part sizes to 63 bit. Both the base IMAP
    specification (RFC 3501) and several extensions are updated.
    </t>
    </abstract>
	</front>
	<middle>
		
	<section title="Introduction">
    <t>
		IMAP <xref target="RFC3501"/> only allows body parts or message sizes which are 32 bit.
		This document introduces an IMAP extension that allows for message and body part sizes to be 63 bit.
    63-bit values were chosen instead of 64-bit values in order to make implementations on various platforms
    (such as Java) easier.
      
      <!--////Alexey: Should the capability name be 63BIT?-->
      
    </t>

    <t>
		The client wishing to use this extension MUST issue ENABLE 64BIT. Refer <xref target="RFC5161"/>
		for the usage of ENABLE command.
    
    <!--////Alexey: add an example session where this is shown?
    This applies also to all extensions like BINARY.-->
    </t>
    
	</section>

    
	<section title="Requirements Notation">
	<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 <xref target="RFC2119"/>.
	</t>
	<t>
		In examples, "C:" and "S:" indicate lines sent by
		the client and server respectively. If a single "C:" or "S:"
		label applies to multiple lines, then the line breaks between
		those lines are for editorial clarity only and are not part
		of the actual protocol exchange.
	</t>
	</section>
	
	<section title="64bit Extension">
	<t>
		An IMAP server that supports the 64bit extension advertises
		this by including the name 64BIT in its CAPABILITY list in the
		authenticated state.  The server may also advertise this extension
		before the user has logged in.
    <!--///The following might be obvious, so maybe it should be deleted:-->
    If this capability is omitted, no
		information is conveyed about the server's status of supporting this
		extension.
	</t>
	<t>
		IMAP server should respond with BAD response for the 64bit message
		size messages sent by the IMAP client unless it issues "ENABLE 64BIT"
    and the server responds with untagged ENABLED response that contains 64BIT
		in the current connection.
	</t>
	</section>
	
	<section title="IMAP Protocol Changes">
	<t>
    This document updates various fields in IMAP <xref target="RFC3501"/> to allow for 63 bit message sizes and body part sizes.
    It also updates the following IMAP extensions: QUOTA <xref target="RFC2087"/>, BINARY <xref target="RFC3516"/>,
    URL-PARTIAL <xref target="RFC5550"/> and APPENDLIMIT <xref target="RFC7889"/>.

    This document also updates the IMAP URL specification <xref target="RFC5092"/> to allow use of such message sizes and offsets in URL.
	</t>
    
	<t>
    These changes are described in more details below.
	</t>

    <section title="Changes to IMAP APPENDLIMIT extension">
      <t>
      When an IMAP server implements both 64BIT and APPENDLIMIT <xref target="RFC7889"/> extensions,
      number64 values (see <xref target="abnf"/>) are allowed after the "APPENDLIMIT="
      capability and "APPENDLIMIT" status data item.
      </t>

    </section>

    <section title="Changes to IMAP BINARY extension">
      <t>
      When an IMAP server implements both 64BIT and BINARY <xref target="RFC3516"/> extensions,
      number64 values (see <xref target="abnf"/>) are allowed in "literal8"
      and "partial" ABNF non terminals.
      </t>

    </section>

    <section title="Changes to IMAP URL-PARTIAL extension and IMAP URL">
      <t>
      When an IMAP server implements both 64BIT and URL-PARTIAL <xref target="RFC5550"/> extensions,
      number64 values (see <xref target="abnf"/>) are allowed in the "partial-range"
      ABNF non terminal. The "partial-range" ABNF non terminal is defined in <xref target="RFC5092"/>,
      so it also affects what is allowed in IMAP URLs.
      </t>

    </section>

    <section title="Changes to IMAP QUOTA extension">
      <t>
        When an IMAP server implements both 64BIT and QUOTA <xref target="RFC2087"/> extensions,
        number64 values (see <xref target="abnf"/>) are allowed in resource usage and resource limit values.
      </t>

    </section>

  </section>

	<section title="Examples">
    
  <!--////Alexey: Note that ENABLE capability is not advertised in this example.-->

	<t>
		C: t1 CAPABILITY<vspace />
		S: * CAPABILITY IMAP4rev1 ID 64BIT<vspace />
		S: t1 OK foo<vspace />
		C: t2 ENABLE 64BIT<vspace />
		S: * ENABLED 64BIT<vspace />
		S: t2 OK foo<vspace />
	</t>
	</section>

    <section title="Formal Syntax" anchor="abnf">
	<t>
		The following syntax specification uses the Augmented Backus-Naur 
		Form (ABNF) notation as specified in <xref target="ABNF"/>.
	</t>
      
	<t>
		Non-terminals referenced but not defined below are as defined by 
		<xref target="RFC3501"/> or <xref target="RFC4466"/>.
	</t>
	<t>
		All alphabetic characters are case-insensitive.  The use of upper or
		lower case characters to define token strings is for editorial
		clarity only.  Implementations MUST accept these strings in a case-
		insensitive fashion.
	</t>

  <t>[[Would it be helpful to split up ABNF by extension?]]</t>
      
<figure>
<artwork>
               <![CDATA[
  body-extension  =/ number64

  body-fld-lines  = number64

  body-fld-octets = number64
  
  capability =/ "APPENDLIMIT" ["=" number64]
               ;; capability is defined in RFC 3501.
               ;; APPENDLIMIT capability is defined in RFC 7889.

  fetch-att       =/ "BODY" section [partial] /
                     "BODY.PEEK" section [partial] /
                    ; When BINARY extension is supported:
                     "BINARY" [".PEEK"] section-binary [partial]

  literal         = "{" number64 ["+"] "}" CRLF *CHAR8
                    ; number64 represents the number of CHAR8s.
                    ; NOTE: "+" can only present when LITERAL+/LITERAL-
                    ; is also advertised

  literal8        = "~{" number64 ["+"] "}" CRLF *OCTET
                    ;; Updating RFC 4466 version.
                    ;; A string that might contain NULs.
                    ;; <number> represents the number of OCTETs
                    ;; in the response string.
                    ;; The "+" is only allowed when both LITERAL+/LITERAL-
                    ;; and BINARY extensions are supported by the server
                    ;; [RFC7888]

  msg-att-static  =/ "RFC822.SIZE" SP number64

  number64    = 1*DIGIT
                ; Unsigned 63-bit integer	 		
                ; (0 <= n <= 9,223,372,036,854,775,807)

  nz-number64 = digit-nz *DIGIT
                ; Unsigned 63-bit integer	 		
                ; (0 < n <= 9,223,372,036,854,775,807)
      
  partial-range  = number64 ["." nz-number64]
                    ; Updates definition from RFC 5092 (IMAP URL).
                    ; This also affect URL-PARTIAL (RFC 5550).
                    
  partial        = "<" number64 "." nz-number64 ">"
                    ; Partial FETCH request. 0-based offset of
                    ; the first octet, followed by the number of octets
                    ; in the fragment.


  quota_resource = atom SP resource-usage SP resource-limit
                    ; Updates definition in RFC 2087.

  setquota_resource = atom SP resource-limit
                    ; Updates definition in RFC 2087.

  resource-limit = number64
  
  resource-usage = number64


  search-key      =/ "LARGER" SP number64 / "SMALLER" SP number64

  status-att-val =/ "APPENDLIMIT" SP (number64 / nil)
               ;; status-att-val is defined in RFC 4466
               ;; APPENDLIMIT status data item is defined in RFC 7889.


  CHAR8   = <defined in RFC 3501>
]]></artwork>
</figure>
	</section>
    
	<section title="Security Considerations">

    <t>
		This document doesn't raise any new security concerns not already raised
		by <xref target="RFC3501"/>.
    
    <!--////Easier to DoS if a server allocates resources for the specified literal sizes.-->
    
    </t>
    
	</section>

	<section title="IANA Considerations">
	<t>
		IANA is asked to add "64BIT" to the IMAP Capabilities
		registry, using this document as its reference.
	</t>
  </section>

  <section title="Acknowledgments">
    
      <t>Thank you to Stephan Bosch for pointing out which IMAP extensions were not covered in earlier versions of this document.</t>
    
	</section>
    
	</middle>
	<back>
		<references title="Normative References">

      <reference anchor="ABNF">
<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"/>
<abstract>
<t>Internet technical specifications often need to define a formal syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF.  It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS TRACK]</t></abstract></front>

<seriesInfo name="STD" value="68"/>

<seriesInfo name="RFC" value="5234"/>
<format type="TXT" octets="26359" target="ftp://ftp.isi.edu/in-notes/rfc5234.txt"/>
			</reference>

      &rfc2119;
      &rfc3501;
      &rfc3516;
      &rfc4466;
      &rfc5092;
      &rfc5161;
      &rfc5550;
      &rfc7888;
      &rfc7889;
      &rfc2087;

    </references>

<!--
		<references title="Informative References">

    </references>
-->

  </back>
</rfc>