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/