<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC2060 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2060.xml">
	<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]> 
<rfc
	category="std"
	docName="draft-yocto-imap-inboxes-00"
	ipr="trust200902">

	<front>

		<title>IMAP4 INBOXES extension</title>

		<author
			fullname="Ben van Hartingsveldt"
			initials="B.J."
			role="editor"
			surname="van Hartingsveldt"/>

		<date
			day="23"
			month="November"
			year="2019"/>

		<abstract>

			<t>The INBOXES extension to the Internet Message Access Protocol - Version 4rev1 (IMAP4rev1) protocol gives the client the possibility to manage multiple inboxes (mail addresses) with the same username and password. Without this extension you only have access to one inbox.</t>

		</abstract>

	</front>

	<middle>
		
		<section
			anchor="section-1"
			title="Introduction">

			<t>The IMAP4rev1 protocol described in <xref target="RFC2060"/> provides a method for accessing remote mail stores, but it provides no facility to access multiple inboxes with only one username and password. This makes it impossible to access other inboxes where the user also has access to and forces the mail provider to make the other inboxes accessible using an REST API for example.</t>

			<t>The INBOXES command provides a facility to get a list of inboxes that are available for the user and gives the possiblilty to switch from inbox and get all the data belonging to that inbox, like subscriptions, drafts, sent items and other mailboxes (folders).</t>

		</section>

		<section
			anchor="section-2"
			title="Conventions Used in this Document">

			<t>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 <xref target="RFC2119"/>. The conventions used in this document are the same as specified in <xref target="RFC2060"/>. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. Line breaks have been inserted for readability.</t>

		</section>

		<section
			anchor="section-3"
			title="Specification">

			<t>The sole purpose of the INBOXES extension is to enable clients and servers to access multiple inboxes using only one username and password.</t>

			<section
				anchor="section-3.1"
				title="INBOXES Command">

				<t>

					<list
						style="hanging">

						<t
							hangText="Arguments:">mail-address or NIL</t>

						<t
							hangText="Responses:">OPTIONAL untagged response: INBOXES</t>

						<t
							hangText="Result:">

							<vspace/>
							OK	inboxes successfully shown or switched inbox successfully
							<vspace/>
							BAD	command unknown or arguments invalid

						</t>

					</list>

				</t>

				<t>The INBOXES command is used to get a list of inboxes as well as switching to one of this mailboxes.</t>

				<t>This command is valid in the Authenticated State.</t>

			</section>

			<section
				anchor="section-3.2"
				title="INBOXES Response">

				<t>If NIL is given as parameter, the server MUST NOT switch from mailbox, but MUST send untagged INBOXES responses back for every inbox the user has access to. If there is only one inbox, it isn't possible to switch inbox. There is no need to return this inbox in the response, but the server MAY do it. If there is at least one inbox, there should be one inbox which is the default inbox. That inbox has "DEFAULT" behind the mail address.</t>

				<t>After switching inbox, you are able to access other inboxes other then the DEFAULT inbox. Every inbox can have his own INBOX mailbox. It is also possible for the server to give two different users access to one shared inbox with that inbox having a username and password on itself.</t>

				<t>The first example shows how to get a list of inboxes:</t>

				<figure
					title="Example 1">

					<artwork>C:	a023 INBOXES NIL
S:	* INBOXES info@example.com
S:	* INBOXES user@example.com DEFAULT
S:	* INBOXES verification@example.com
S:	a023 OK Shown all inboxes</artwork>

				</figure>

				<t>The second example shows how to get switch inbox:</t>

				<figure
					title="Example 2">

					<artwork>C:	a023 INBOXES info@example.com
S:	a023 OK Switched inbox</artwork>

				</figure>

			</section>

		</section>

		<section
			anchor="section-4"
			title="Formal Syntax">

			<t>This  syntax is intended to augment the grammar specified in <xref target="RFC2060"/> in order to provide for the INBOXES command.  This specification uses the augmented Backus-Naur Form (BNF) notation as used in <xref target="RFC2060"/>.</t>

			<figure>

				<artwork
					type="abnf">command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command / inboxes
	;; adds inboxes command to command_any in [RFC2060]

inboxes ::= "INBOXES" [SPACE inboxes_param_email]

inboxes_response ::= "INBOXES" [SPACE inboxes_param_email [SPACE "DEFAULT"]]

inboxes_param_email ::= string "@" string

response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye /
	mailbox_data / message_data / capability_data / inboxes_response)</artwork>

			</figure>

		</section>

	</middle>

	<back>

		<references
			title="References">

			&RFC2060;

			&RFC2119;

		</references>

	</back>

</rfc>