draft-ietf-extra-imap-64bit-00.txt   draft-ietf-extra-imap-64bit-01.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Updates: 3501 (if approved) SB. Jayantheesh Updates: 3501, 4466, 7888 (if approved) SB. Jayantheesh
Intended status: Standards Track Samsung Electronics America Intended status: Standards Track Samsung Electronics America
Expires: March 16, 2018 September 12, 2017 Expires: March 22, 2018 September 18, 2017
64bit body part and message sizes in IMAP4 64bit body part and message sizes in IMAP4
draft-ietf-extra-imap-64bit-00 draft-ietf-extra-imap-64bit-01.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.
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.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 16, 2018. This Internet-Draft will expire on March 22, 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 26 skipping to change at page 2, line 26
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2
3. 64bit Extension . . . . . . . . . . . . . . . . . . . . . . . 3 3. 64bit Extension . . . . . . . . . . . . . . . . . . . . . . . 3
4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 3 4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 3
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 3
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 3 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 3
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
10. Normative References . . . . . . . . . . . . . . . . . . . . 5 10. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
IMAP [RFC3501] only allows body parts or message sizes which are IMAP [RFC3501] only allows body parts or message sizes which are 32
32bit. 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 63bit. message and body part sizes to be 63 bit.
The client wishing to use this extension MUST issue ENABLE 64BIT The client wishing to use this extension MUST issue ENABLE 64BIT.
command. 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].
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. If a single "C:" or "S:" label applies to server respectively. If a single "C:" or "S:" label applies to
multiple lines, then the line breaks between those lines are for multiple lines, then the line breaks between those lines are for
skipping to change at page 3, line 22 skipping to change at page 3, line 23
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. in the current connection.
4. IMAP Protocol Changes 4. IMAP Protocol Changes
TBD. TBD.
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
6. Formal Syntax 6. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
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
lower case characters to define token strings is for editorial
clarity only. Implementations MUST accept these strings in a case-
insensitive fashion.
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 ["<" number "." nz-number ">"] / fetch-att =/ "BODY" section ["<" number64 "." nz-number64 ">"] /
"BODY.PEEK" section ["<" number "." nz-number ">"] "BODY.PEEK" section ["<" number64 "." nz-number64 ">"]
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
msg-att-static =/ "RFC822.SIZE" SP number 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]
search-key =/ "LARGER" SP number / "SMALLER" SP number 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)
CHAR8 = <defined in RFC 3501> CHAR8 = <defined in RFC 3501>
literal8 = <defined in RFC 4466>
; Alexey: this needs updating as well
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
IMAP4 capabilities are registered by publishing a standards track or IANA is asked to add "64BIT" to the IMAP Capabilities registry, using
IESG approved experimental RFC. The registry is currently located this document as its reference.
at:
http://www.iana.org/assignments/imap-capabilities
This document requests that IANA adds to the above registry to
include the entry for 64BIT capability pointing to this document.
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,
DOI 10.17487/RFC2088, January 1997,
<https://www.rfc-editor.org/info/rfc2088>.
[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,
skipping to change at page 5, line 42 skipping to change at page 5, line 48
<https://www.rfc-editor.org/info/rfc4466>. <https://www.rfc-editor.org/info/rfc4466>.
[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>.
Authors' Addresses Authors' Addresses
Alexey Melnikov Alexey Melnikov
Isode Ltd Isode Ltd
14 Castle 14 Castle Mews
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
 End of changes. 17 change blocks. 
34 lines changed or deleted 42 lines changed or added

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