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/