Diff: rfc9698.original

	rfc9698.original	rfc9698.txt


	EXTRA A. Gulbrandsen	Internet Engineering Task Force (IETF) A. Gulbrandsen
	Internet-Draft ICANN	Request for Comments: 9698 ICANN
	Intended status: Standards Track B. Gondwana	Category: Standards Track B. Gondwana
	Expires: 16 November 2024 Fastmail	ISSN: 2070-1721 Fastmail
	15 May 2024	December 2024

	The JMAPACCESS Extension for IMAP	The JMAPACCESS Extension for IMAP

	draft-ietf-extra-jmapaccess-09

	Abstract	Abstract

	This document defines an IMAP extension to let clients know that the	This document defines an IMAP extension to let clients know that the

	messages in this IMAP server are also available via JMAP, and how.	messages in this IMAP server are also available via the JSON Meta
	It is intended for clients that want to migrate gradually to JMAP or	Application Protocol (JMAP), and how. It is intended for clients
	use JMAP extensions within an IMAP client.	that want to migrate gradually to JMAP or use JMAP extensions within
		an IMAP client.

	Status of This Memo	Status of This Memo


	This Internet-Draft is submitted in full conformance with the	This is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.

	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.


	Internet-Drafts are draft documents valid for a maximum of six months	This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any	(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference	received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."	Internet Engineering Steering Group (IESG). Further information on
		Internet Standards is available in Section 2 of RFC 7841.


	This Internet-Draft will expire on 16 November 2024.	Information about the current status of this document, any errata,
		and how to provide feedback on it may be obtained at
		https://www.rfc-editor.org/info/rfc9698.

	Copyright Notice	Copyright Notice

	Copyright (c) 2024 IETF Trust and the persons identified as the	Copyright (c) 2024 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 (https://trustee.ietf.org/	Provisions Relating to IETF Documents
	license-info) in effect on the date of publication of this document.	(https://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights	publication of this document. Please review these documents
	and restrictions with respect to this document. Code Components	carefully, as they describe your rights and restrictions with respect
	extracted from this document must include Revised BSD License text as	to this document. Code Components extracted from this document must
	described in Section 4.e of the Trust Legal Provisions and are	include Revised BSD License text as described in Section 4.e of the
	provided without warranty as described in the Revised BSD License.	Trust Legal Provisions and are provided without warranty as described
		in the Revised BSD License.

	Table of Contents	Table of Contents


	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2	1. Introduction
	2. Requirements Language . . . . . . . . . . . . . . . . . . . . 2	2. Requirements Language
	3. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 2	3. Details
	4. The GETJMAPACCESS command and the JMAPACCESS response . . . . 3	4. The GETJMAPACCESS Command and the JMAPACCESS Response
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4	5. Examples
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5	6. IANA Considerations
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 5	7. Security Considerations
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6	8. References
	8.1. Normative References . . . . . . . . . . . . . . . . . . 6	8.1. Normative References
	8.2. Informative References . . . . . . . . . . . . . . . . . 6	8.2. Informative References
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7	Authors' Addresses

	1. Introduction	1. Introduction

	An IMAP server can declare that the messages in its mailstore are	An IMAP server can declare that the messages in its mailstore are
	also available via JMAP. For simplicity, only a complete equivalence	also available via JMAP. For simplicity, only a complete equivalence
	is supported (the same set of messages are available via both IMAP	is supported (the same set of messages are available via both IMAP
	and JMAP).	and JMAP).

	2. Requirements Language	2. Requirements Language

	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in	"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.	capitals, as shown here.

	3. Details	3. Details

	By advertising the JMAPACCESS capability, the server asserts that if	By advertising the JMAPACCESS capability, the server asserts that if
	a mailbox or message has a particular object ID when accessed via	a mailbox or message has a particular object ID when accessed via

	either IMAP or JMAP (see [RFC3501], [RFC9051] and [RFC8620]), then	either IMAP or JMAP (see [RFC3501], [RFC9051], and [RFC8620]), then
	the same mailbox or message is accessible via the other protocol, and	the same mailbox or message is accessible via the other protocol, and
	it has the same ID.	it has the same ID.

	The server MUST also advertise the OBJECTID extension, defined by	The server MUST also advertise the OBJECTID extension, defined by
	[RFC8474]. The JMAP session resource that allows access to the same	[RFC8474]. The JMAP session resource that allows access to the same
	messages is called "the JMAP server" below.	messages is called "the JMAP server" below.

	This specification does not affect message lifetime: If a client	This specification does not affect message lifetime: If a client
	accesses a message via IMAP and half a second later via JMAP, then	accesses a message via IMAP and half a second later via JMAP, then
	the message may have been deleted between the two accesses.	the message may have been deleted between the two accesses.

	skipping to change at page 3, line 13 ¶	skipping to change at line 104 ¶
	authenticated. If the IMAP server can infer from the client's	authenticated. If the IMAP server can infer from the client's
	authentication process that its credentials suffice to authenticate	authentication process that its credentials suffice to authenticate
	via JMAP, then the server MUST include a JMAPACCESS capability in any	via JMAP, then the server MUST include a JMAPACCESS capability in any
	capability list sent after that point. This includes the capability	capability list sent after that point. This includes the capability
	list that some servers send immediately when authentication succeeds.	list that some servers send immediately when authentication succeeds.

	Servers are encouraged to report the same message flags and other	Servers are encouraged to report the same message flags and other
	data via both protocols, as far as possible.	data via both protocols, as far as possible.

	This specification does not require mailboxes to have the same name	This specification does not require mailboxes to have the same name

	in IMAP and JMAP, even if they share mailbox ID. However, the JMAP	in IMAP and JMAP, even if they share a mailbox ID. However, the JMAP
	specification regulates that, in the text about the name and role	specification regulates that in the text about the name and role
	properties in [RFC8620] section 2.	properties described in Section 2 of [RFC8620].

	Note that all JMAP servers support internationalized email addresses	Note that all JMAP servers support internationalized email addresses

	(see [RFC6530]). If this IMAP server does not, or the IMAP client	(see [RFC6530]). If this IMAP server does not or if the IMAP client
	does not issue ENABLE UTF8=ACCEPT (see [RFC6855]), then there is a	does not issue ENABLE UTF8=ACCEPT (see [RFC6855]), then it is
	possibility that the client receives accurate address fields via JMAP	possible that the client will receive accurate address fields via
	and downgraded fields via IMAP (see (see [RFC6857] and [RFC6858] for	JMAP and downgraded fields via IMAP (see [RFC6857] and [RFC6858] for
	examples). Issuing ENABLE UTF8=ACCEPT is a simple way to sidestep	examples). Issuing ENABLE UTF8=ACCEPT is a simple way to sidestep
	the issue.	the issue.


	4. The GETJMAPACCESS command and the JMAPACCESS response	4. The GETJMAPACCESS Command and the JMAPACCESS Response

	The GETJMAPACCESS command requests that the server respond with the	The GETJMAPACCESS command requests that the server respond with the
	session URL for the JMAP server that provides access to the same	session URL for the JMAP server that provides access to the same
	mail.	mail.

	If such a JMAP server is known to this server, the server MUST	If such a JMAP server is known to this server, the server MUST
	respond with an untagged JMAPACCESS response containing the JMAP	respond with an untagged JMAPACCESS response containing the JMAP
	server's session resource (a URL) followed by a tagged OK response.	server's session resource (a URL) followed by a tagged OK response.

	If such a JMAP server is not known, the server MUST respond with a	If such a JMAP server is not known, the server MUST respond with a
	tagged BAD response (and MUST NOT include JMAPACCESS in the	tagged BAD response (and MUST NOT include JMAPACCESS in the
	capability list).	capability list).

	The JMAPACCESS response is followed by a single link to a JMAP	The JMAPACCESS response is followed by a single link to a JMAP

	session resource. The server/mailstore at that location is	session resource.
	referenced as "the JMAP server" in this document.


	The formal syntax in [RFC9051] is extended thus:	The formal syntax in [RFC9051] is extended as follows:

	command-auth =/ "GETJMAPACCESS"	command-auth =/ "GETJMAPACCESS"

	mailbox-data =/ resp-jmapaccess	mailbox-data =/ resp-jmapaccess

	resp-jmapaccess = "JMAPACCESS" SP quoted	resp-jmapaccess = "JMAPACCESS" SP quoted


	The syntax in [RFC3501] is extended similarly (this extension may be	The syntax in [RFC3501] is extended similarly (this extension may be
	used with IMAP4rev1 as well as IMAP4rev2).	used with IMAP4rev1 as well as IMAP4rev2).

	5. Examples	5. Examples


	Lines sent by the client are preceded by C:, lines sent by the server	Lines sent by the client are preceded by C: and lines sent by the
	by S:. Each example starts with the IMAP banner issued by the server	server are preceded by S:. Each example starts with the IMAP banner
	on connection, and generally abbreviates the capability lists to	issued by the server on connection, and generally abbreviates the
	what's required by the example itself.	capability lists to what's required by the example itself.

	Real connections use longer capability lists, much longer	Real connections use longer capability lists, much longer

	AUTHENTICATE arguments and of course use TLS. These examples focus	AUTHENTICATE arguments and of course use TLS. However, these
	on JMAPACCESS, though.	examples focus on JMAPACCESS.


	Example 1. A client connects, sees that SASL OAUTH is available, and	Example 1:

		A client connects, sees that SASL OAuth [RFC7628] is available, and
	authenticates in that way.	authenticates in that way.

	S: * OK [CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR] example1	S: * OK [CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR] example1
	C: 1 AUTHENTICATE OAUTHBEARER bixhPXVzZ...QEB	C: 1 AUTHENTICATE OAUTHBEARER bixhPXVzZ...QEB

	The server processes the command successfully. It knows that the	The server processes the command successfully. It knows that the

	client used Oauth, and that it and its JMAP alter ego use the same	client used OAuth, and that it and its JMAP alter ego use the same
	Oauth backend subsystem. Because of that it infers that the (next)	OAuth backend subsystem. Because of that it infers that the (next)
	access token is just as usable via JMAP as via IMAP. It includes a	access token is just as usable via JMAP as via IMAP. It includes a
	JMAPACCESS capability in its reply (again, real capability lists are	JMAPACCESS capability in its reply (again, real capability lists are
	much longer):	much longer):

	S: 1 OK [CAPABILITY IMAP4rev1 JMAPACCESS] done	S: 1 OK [CAPABILITY IMAP4rev1 JMAPACCESS] done
	C: 1b GETJMAPACCESS	C: 1b GETJMAPACCESS
	S: * JMAPACCESS "https://example.com/jmap"	S: * JMAPACCESS "https://example.com/jmap"
	S: 1b OK done	S: 1b OK done


	SASL OAUTH is specified by [RFC7628], and the argument in this	SASL OAuth is specified by [RFC7628], and the argument in this
	example is abbreviated from the more realistic length used in	example is abbreviated from the more realistic length used in RFC
	RFC7628.	7628.


	Example 2. A client connects, sees no SASL method it recognises, and	Example 2:
	issues a LOGIN command.
		A client connects, sees no SASL method it recognizes, and issues a
		LOGIN command.

	S: * OK [CAPABILITY IMAP4rev2] example2	S: * OK [CAPABILITY IMAP4rev2] example2
	C: 2 LOGIN "arnt" "trondheim"	C: 2 LOGIN "arnt" "trondheim"

	The server sees that the password is accepted, knows that it and its	The server sees that the password is accepted, knows that it and its
	JMAP alter ego use the same password database, and issues a	JMAP alter ego use the same password database, and issues a
	JMAPACCESS capability:	JMAPACCESS capability:


	S: * OK [CAPABILITY IMAP4rev2 JMAPACCESS] done	S: * OK [CAPABILITY IMAP4rev2 JMAPACCESS] done
	S: 2 OK done	S: 2 OK done
	C: 2b JMAPACCESS	C: 2b JMAPACCESS
	S: * JMAPACCESS "https://example.com/.s/[jmap]"	S: * JMAPACCESS "https://example.com/.s/[jmap]"
	S: 2b OK done	S: 2b OK done

	The URL uses the same quoting rules as most other IMAP strings.	The URL uses the same quoting rules as most other IMAP strings.


	Example 3. A client connects, sees no SASL method it recognises, and	Example 3:
	issues a LOGIN command with a correct password.
		A client connects, sees no SASL method it recognizes, and issues a
		LOGIN command with a correct password.

	S: * OK [CAPABILITY IMAP4rev1 IMAP4rev2] example3	S: * OK [CAPABILITY IMAP4rev1 IMAP4rev2] example3
	C: 3 LOGIN "arnt" "trondheim"	C: 3 LOGIN "arnt" "trondheim"

	The server operator has decided to disable password use with JMAP,	The server operator has decided to disable password use with JMAP,

	but allow it for a while with IMAP to cater to older clients, so the	but allow it for a while with IMAP to cater to older clients.
	login succeeds, but there is no JMAPACCESS capability.	Therefore, the login succeeds, but there is no JMAPACCESS capability.

	S: 3 OK done	S: 3 OK done


	Example 4. A client connects, sees no SASL method it recognises, and	Example 4:
	issues a LOGIN command. Its password is incorrect.
		A client connects, sees no SASL method it recognizes, and issues a
		LOGIN command. Its password is incorrect.

	S: * OK [CAPABILITY IMAP4rev2 AUTH=GSS] example4	S: * OK [CAPABILITY IMAP4rev2 AUTH=GSS] example4
	C: 4 LOGIN "arnt" "oslo"	C: 4 LOGIN "arnt" "oslo"

	The server does not enter Authenticated state, so nothing requires it	The server does not enter Authenticated state, so nothing requires it
	to mention JMAPACCESS. It replies curtly:	to mention JMAPACCESS. It replies curtly:

	S: 4 NO done	S: 4 NO done

	6. IANA Considerations	6. IANA Considerations


	The IANA is requested to add the JMAPACCESS capability the IMAP	The IANA has added the JMAPACCESS capability to the "Internet Message
	Capabilities registry, with this document as reference.	Access Protocol (IMAP) Capabilities Registry" and listed this
		document as the reference.

	7. Security Considerations	7. Security Considerations

	JMAPACCESS reveals to authenticated IMAP clients that they would be	JMAPACCESS reveals to authenticated IMAP clients that they would be

	able to authenticate via JMAP using the same credentials, and that	able to authenticate via JMAP using the same credentials and that the
	the object IDs match.	object IDs match.

	One does not normally reveal anything at all about authentication.	One does not normally reveal anything at all about authentication.

	However, in this case information is revealed to an authenticated	However, if the client is an attacker, then the attacker is known to
	client, the revealed URL can usually be found via JMAP autodiscovery,	have valid credentials, and Section 2.2 of [RFC8620] tells the
	and an attacker would only need to try the credentials it has with an	attacker how to find the revealed URL without the help of this
	autodiscovered JMAP URL (a matter of a second or two). Therefore, it	extension. Therefore, it is believed that this document does not
	is believed that this document does not benefit an attacker	benefit an attacker noticeably, and its value for migration far
	noticeably, and its value for migration far outweighs its risk.	outweighs its risk.

	8. References	8. References

	8.1. Normative References	8.1. Normative References


		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
		Requirement Levels", BCP 14, RFC 2119,
		DOI 10.17487/RFC2119, March 1997,
		<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/rfc/rfc3501>.	<https://www.rfc-editor.org/info/rfc3501>.

		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
		May 2017, <https://www.rfc-editor.org/info/rfc8174>.

	[RFC8474] Gondwana, B., Ed., "IMAP Extension for Object	[RFC8474] Gondwana, B., Ed., "IMAP Extension for Object
	Identifiers", RFC 8474, DOI 10.17487/RFC8474, September	Identifiers", RFC 8474, DOI 10.17487/RFC8474, September

	2018, <https://www.rfc-editor.org/rfc/rfc8474>.	2018, <https://www.rfc-editor.org/info/rfc8474>.

	[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message	[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
	Access Protocol (IMAP) - Version 4rev2", RFC 9051,	Access Protocol (IMAP) - Version 4rev2", RFC 9051,
	DOI 10.17487/RFC9051, August 2021,	DOI 10.17487/RFC9051, August 2021,

	<https://www.rfc-editor.org/rfc/rfc9051>.	<https://www.rfc-editor.org/info/rfc9051>.

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/rfc/rfc2119>.

	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

	8.2. Informative References	8.2. Informative References

	[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for	[RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
	Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,	Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,

	February 2012, <https://www.rfc-editor.org/rfc/rfc6530>.	February 2012, <https://www.rfc-editor.org/info/rfc6530>.

	[RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP	[RFC6855] Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
	Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March	Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March

	2013, <https://www.rfc-editor.org/rfc/rfc6855>.	2013, <https://www.rfc-editor.org/info/rfc6855>.

	[RFC6857] Fujiwara, K., "Post-Delivery Message Downgrading for	[RFC6857] Fujiwara, K., "Post-Delivery Message Downgrading for
	Internationalized Email Messages", RFC 6857,	Internationalized Email Messages", RFC 6857,
	DOI 10.17487/RFC6857, March 2013,	DOI 10.17487/RFC6857, March 2013,

	<https://www.rfc-editor.org/rfc/rfc6857>.	<https://www.rfc-editor.org/info/rfc6857>.

	[RFC6858] Gulbrandsen, A., "Simplified POP and IMAP Downgrading for	[RFC6858] Gulbrandsen, A., "Simplified POP and IMAP Downgrading for
	Internationalized Email", RFC 6858, DOI 10.17487/RFC6858,	Internationalized Email", RFC 6858, DOI 10.17487/RFC6858,

	March 2013, <https://www.rfc-editor.org/rfc/rfc6858>.	March 2013, <https://www.rfc-editor.org/info/rfc6858>.

	[RFC7628] Mills, W., Showalter, T., and H. Tschofenig, "A Set of	[RFC7628] Mills, W., Showalter, T., and H. Tschofenig, "A Set of
	Simple Authentication and Security Layer (SASL) Mechanisms	Simple Authentication and Security Layer (SASL) Mechanisms
	for OAuth", RFC 7628, DOI 10.17487/RFC7628, August 2015,	for OAuth", RFC 7628, DOI 10.17487/RFC7628, August 2015,

	<https://www.rfc-editor.org/rfc/rfc7628>.	<https://www.rfc-editor.org/info/rfc7628>.

	[RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application	[RFC8620] Jenkins, N. and C. Newman, "The JSON Meta Application
	Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July	Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July

	2019, <https://www.rfc-editor.org/rfc/rfc8620>.	2019, <https://www.rfc-editor.org/info/rfc8620>.

	Authors' Addresses	Authors' Addresses

	Arnt Gulbrandsen	Arnt Gulbrandsen
	ICANN	ICANN
	6 Rond Point Schumann, Bd. 1	6 Rond Point Schumann, Bd. 1
	1040 Brussels	1040 Brussels
	Belgium	Belgium
	Email: arnt@gulbrandsen.priv.no	Email: arnt@gulbrandsen.priv.no
	URI: https://icann.org/ua	URI: https://icann.org/ua

End of changes. 38 change blocks.
	104 lines changed or deleted	111 lines changed or added
This html diff was produced by rfcdiff 1.48.