draft-ietf-extra-imap-64bit-01.txt   draft-ietf-extra-imap-64bit-02.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Updates: 3501, 4466, 7888 (if approved) SB. Jayantheesh Updates: 2087, 3501, 4466, 5092, 5550, SB. Jayantheesh
Intended status: Standards Track Samsung Electronics America 7888, 7889 (if approved) Samsung Electronics America
Expires: March 22, 2018 September 18, 2017 Intended status: Standards Track October 28, 2017
Expires: May 1, 2018
64bit body part and message sizes in IMAP4 64bit body part and message sizes in IMAP4
draft-ietf-extra-imap-64bit-01.txt draft-ietf-extra-imap-64bit-02.txt
Abstract Abstract
This document defines an IMAPv4rev1 extension that extends the This document defines an IMAPv4rev1 extension that extends the
existing IMAPv4rev1 32 Bit message and body part sizes to 63 bit. existing IMAPv4rev1 32 Bit message and body part sizes to 63 bit.
Both the base IMAP specification (RFC 3501) and several extensions
are updated.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 22, 2018. This Internet-Draft will expire on May 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 22
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. 64bit Extension . . . . . . . . . . . . . . . . . . . . . . . 3 3. 64bit Extension . . . . . . . . . . . . . . . . . . . . . . . 3
4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 3 4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 3
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Changes to IMAP APPENDLIMIT extension . . . . . . . . . . 3
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 3 4.2. Changes to IMAP BINARY extension . . . . . . . . . . . . 3
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4.3. Changes to IMAP URL-PARTIAL extension and IMAP URL . . . 4
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4.4. Changes to IMAP QUOTA extension . . . . . . . . . . . . . 4
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4
10. Normative References . . . . . . . . . . . . . . . . . . . . 5 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
IMAP [RFC3501] only allows body parts or message sizes which are 32 IMAP [RFC3501] only allows body parts or message sizes which are 32
bit. This document introduces an IMAP extension that allows for bit. This document introduces an IMAP extension that allows for
message and body part sizes to be 63 bit. 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. The client wishing to use this extension MUST issue ENABLE 64BIT.
Refer [RFC5161] for the usage of ENABLE command. Refer [RFC5161] for the usage of ENABLE command.
2. Requirements Notation 2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 3, line 15 skipping to change at page 3, line 27
3. 64bit Extension 3. 64bit Extension
An IMAP server that supports the 64bit extension advertises this by An IMAP server that supports the 64bit extension advertises this by
including the name 64BIT in its CAPABILITY list in the authenticated including the name 64BIT in its CAPABILITY list in the authenticated
state. The server may also advertise this extension before the user state. The server may also advertise this extension before the user
has logged in. If this capability is omitted, no information is has logged in. If this capability is omitted, no information is
conveyed about the server's status of supporting this extension. conveyed about the server's status of supporting this extension.
IMAP server should respond with BAD response for the 64bit message IMAP server should respond with BAD response for the 64bit message
size messages sent by the IMAP client unless it issues "ENABLE 64BIT" size messages sent by the IMAP client unless it issues "ENABLE 64BIT"
in the current connection. and the server responds with untagged ENABLED response that contains
64BIT in the current connection.
4. IMAP Protocol Changes 4. IMAP Protocol Changes
TBD. This document updates various fields in IMAP [RFC3501] to allow for
63 bit message sizes and body part sizes. It also updates the
following IMAP extensions: QUOTA [RFC2087], BINARY [RFC3516], URL-
PARTIAL [RFC5550] and APPENDLIMIT [RFC7889]. This document also
updates the IMAP URL specification [RFC5092] to allow use of such
message sizes and offsets in URL.
These changes are described in more details below.
4.1. Changes to IMAP APPENDLIMIT extension
When an IMAP server implements both 64BIT and APPENDLIMIT [RFC7889]
extensions, number64 values (see Section 6) are allowed after the
"APPENDLIMIT=" capability and "APPENDLIMIT" status data item.
4.2. Changes to IMAP BINARY extension
When an IMAP server implements both 64BIT and BINARY [RFC3516]
extensions, number64 values (see Section 6) are allowed in "literal8"
and "partial" ABNF non terminals.
4.3. Changes to IMAP URL-PARTIAL extension and IMAP URL
When an IMAP server implements both 64BIT and URL-PARTIAL [RFC5550]
extensions, number64 values (see Section 6) are allowed in the
"partial-range" ABNF non terminal. The "partial-range" ABNF non
terminal is defined in [RFC5092], so it also affects what is allowed
in IMAP URLs.
4.4. Changes to IMAP QUOTA extension
When an IMAP server implements both 64BIT and QUOTA [RFC2087]
extensions, number64 values (see Section 6) are allowed in resource
usage and resource limit values.
5. Examples 5. Examples
C: t1 CAPABILITY C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID 64BIT S: * CAPABILITY IMAP4rev1 ID 64BIT
S: t1 OK foo S: t1 OK foo
C: t2 ENABLE 64BIT C: t2 ENABLE 64BIT
S: * ENABLED 64BIT S: * ENABLED 64BIT
S: t2 OK foo S: t2 OK foo
skipping to change at page 4, line 5 skipping to change at page 4, line 41
Form (ABNF) notation as specified in [ABNF]. Form (ABNF) notation as specified in [ABNF].
Non-terminals referenced but not defined below are as defined by Non-terminals referenced but not defined below are as defined by
[RFC3501]. [RFC3501].
All alphabetic characters are case-insensitive. The use of upper or All alphabetic characters are case-insensitive. The use of upper or
lower case characters to define token strings is for editorial lower case characters to define token strings is for editorial
clarity only. Implementations MUST accept these strings in a case- clarity only. Implementations MUST accept these strings in a case-
insensitive fashion. insensitive fashion.
[[Would it be helpful to split up ABNF by extension?]]
body-extension =/ number64 body-extension =/ number64
; Alexey: I am not sure if this change is absolutely needed! ; Alexey: I am not sure if this change is absolutely needed!
body-fld-lines = number64 body-fld-lines = number64
body-fld-octets = number64 body-fld-octets = number64
fetch-att =/ "BODY" section ["<" number64 "." nz-number64 ">"] / capability =/ "APPENDLIMIT" ["=" number64]
"BODY.PEEK" section ["<" number64 "." nz-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 literal = "{" number64 ["+"] "}" CRLF *CHAR8
; number64 represents the number of CHAR8s. ; number64 represents the number of CHAR8s.
; NOTE: "+" can only present when LITERAL+/LITERAL- ; NOTE: "+" can only present when LITERAL+/LITERAL-
; is also advertised ; is also advertised
literal8 = "~{" number64 ["+"] "}" CRLF *OCTET literal8 = "~{" number64 ["+"] "}" CRLF *OCTET
;; Updating RFC 4466 version. ;; Updating RFC 4466 version.
;; A string that might contain NULs. ;; A string that might contain NULs.
;; <number> represents the number of OCTETs ;; <number> represents the number of OCTETs
;; in the response string. ;; in the response string.
;; The "+" is only allowed when both LITERAL+/LITERAL- ;; The "+" is only allowed when both LITERAL+/LITERAL-
;; and BINARY extensions are supported by the server ;; and BINARY extensions are supported by the server
;; [RFC7888] ;; [RFC7888]
msg-att-static =/ "RFC822.SIZE" SP number64 msg-att-static =/ "RFC822.SIZE" SP number64
search-key =/ "LARGER" SP number64 / "SMALLER" SP number64
number64 = 1*DIGIT number64 = 1*DIGIT
; Unsigned 63-bit integer ; Unsigned 63-bit integer
; (0 <= n <= 9,223,372,036,854,775,807) ; (0 <= n <= 9,223,372,036,854,775,807)
nz-number64 = digit-nz *DIGIT nz-number64 = digit-nz *DIGIT
; Unsigned 63-bit integer ; Unsigned 63-bit integer
; (0 < n <= 9,223,372,036,854,775,807) ; (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> CHAR8 = <defined in RFC 3501>
7. Security Considerations 7. Security Considerations
TBD. TBD.
This document doesn't raise any other security concerns not already This document doesn't raise any other security concerns not already
raised by [RFC3501]. raised by [RFC3501].
8. IANA Considerations 8. IANA Considerations
skipping to change at page 5, line 19 skipping to change at page 6, line 35
9. Acknowledgments 9. Acknowledgments
TBD. TBD.
10. Normative References 10. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC2088] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087,
DOI 10.17487/RFC2088, January 1997, DOI 10.17487/RFC2087, January 1997,
<https://www.rfc-editor.org/info/rfc2088>. <https://www.rfc-editor.org/info/rfc2087>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>. <https://www.rfc-editor.org/info/rfc3501>.
[RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
DOI 10.17487/RFC3516, April 2003, DOI 10.17487/RFC3516, April 2003,
<https://www.rfc-editor.org/info/rfc3516>. <https://www.rfc-editor.org/info/rfc3516>.
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006,
<https://www.rfc-editor.org/info/rfc4466>. <https://www.rfc-editor.org/info/rfc4466>.
[RFC5092] Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme",
RFC 5092, DOI 10.17487/RFC5092, November 2007,
<https://www.rfc-editor.org/info/rfc5092>.
[RFC5161] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP [RFC5161] Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP
ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March
2008, <https://www.rfc-editor.org/info/rfc5161>. 2008, <https://www.rfc-editor.org/info/rfc5161>.
[RFC5550] Cridland, D., Ed., Melnikov, A., Ed., and S. Maes, Ed.,
"The Internet Email to Support Diverse Service
Environments (Lemonade) Profile", RFC 5550,
DOI 10.17487/RFC5550, August 2009,
<https://www.rfc-editor.org/info/rfc5550>.
[RFC7888] Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals",
RFC 7888, DOI 10.17487/RFC7888, May 2016,
<https://www.rfc-editor.org/info/rfc7888>.
[RFC7889] SrimushnamBoovaraghamoorthy, J. and N. Bisht, "The IMAP
APPENDLIMIT Extension", RFC 7889, DOI 10.17487/RFC7889,
May 2016, <https://www.rfc-editor.org/info/rfc7889>.
Authors' Addresses Authors' Addresses
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
14 Castle Mews 14 Castle Mews
Hampton, Middlesex TW12 2NP Hampton, Middlesex TW12 2NP
UK UK
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
Jayantheesh S B Jayantheesh S B
Samsung Electronics America Samsung Electronics America
685 US Highway 202/206 685 US Highway 202/206
Bridgewater, New Jersey 08807 Bridgewater, New Jersey 08807
USA USA
Email: jayantheesh.sb@gmail.com Email: jayantheesh.sb@gmail.com
 End of changes. 17 change blocks. 
23 lines changed or deleted 116 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/