]>
64bit body part and message sizes in IMAP4Isode Ltd14 Castle MewsHamptonMiddlesexTW12 2NPUKAlexey.Melnikov@isode.comSamsung Electronics America685 US Highway 202/206BridgewaterNew Jersey08807USAjayantheesh.sb@gmail.comIMAP64bit
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.
IMAP 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.
The client wishing to use this extension MUST issue ENABLE 64BIT. Refer
for the usage of ENABLE command.
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 .
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.
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.
If this capability is omitted, no
information is conveyed about the server's status of supporting this
extension.
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.
This document updates various fields in IMAP to allow for 63 bit message sizes and body part sizes.
It also updates the following IMAP extensions: QUOTA , BINARY ,
URL-PARTIAL and APPENDLIMIT .
This document also updates the IMAP URL specification to allow use of such message sizes and offsets in URL.
These changes are described in more details below.
When an IMAP server implements both 64BIT and APPENDLIMIT extensions,
number64 values (see ) are allowed after the "APPENDLIMIT="
capability and "APPENDLIMIT" status data item.
When an IMAP server implements both 64BIT and BINARY extensions,
number64 values (see ) are allowed in "literal8"
and "partial" ABNF non terminals.
When an IMAP server implements both 64BIT and URL-PARTIAL extensions,
number64 values (see ) are allowed in the "partial-range"
ABNF non terminal. The "partial-range" ABNF non terminal is defined in ,
so it also affects what is allowed in IMAP URLs.
When an IMAP server implements both 64BIT and QUOTA extensions,
number64 values (see ) are allowed in resource usage and resource limit values.
C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID 64BIT
S: t1 OK foo
C: t2 ENABLE 64BIT
S: * ENABLED 64BIT
S: t2 OK foo
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in .
Non-terminals referenced but not defined below are as defined by
.
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.
[[Would it be helpful to split up ABNF by extension?]]
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 = ""
; 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 =
]]>
TBD.
This document doesn't raise any other security concerns not already raised
by .
IANA is asked to add "64BIT" to the IMAP Capabilities
registry, using this document as its reference.
TBD.Augmented BNF for Syntax Specifications: ABNFInternet 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]
&rfc2119;
&rfc3501;
&rfc3516;
&rfc4466;
&rfc5092;
&rfc5161;
&rfc5550;
&rfc7888;
&rfc7889;
&rfc2087;