The JMAPACCESS Extension for IMAP
draft-ietf-extra-jmapaccess-00

EXTRA                                                     A. Gulbrandsen
Internet-Draft                                                     ICANN
Intended status: Standards Track                          3 January 2023
Expires: 7 July 2023

                   The JMAPACCESS Extension for IMAP
                     draft-ietf-extra-jmapaccess-00

Abstract

   This document defines an IMAP extension to let clients know that the
   messages in this IMAP server are also available via JMAP, and how.
   It is intended for clients that want to migrate gradually to JMAP.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 7 July 2023.

Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Gulbrandsen                Expires 7 July 2023                  [Page 1]
Internet-Draft               IMAP JMAPACCESS                January 2023

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   2
   3.  Details . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   4.  The JMAPACCESS Response Code  . . . . . . . . . . . . . . . .   3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   A few IMAP client maintainers have asked for ways to use features
   that are available in JMAP without having to drop their expensively
   tested IMAP code.

   This document provides a server with a way to declare that the
   messages in its mailstore are also available via JMAP.  For
   simplicity, only a complete equivalence is supported (the same set of
   messages are available via both IMAP and JMAP).

2.  Requirements Language

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

3.  Details

   By advertising the JMAPACCESS capability, the server asserts that if
   a message has a particular object ID when accessed via either IMAP or
   JMAP (see [RFC9051] and [RFC8620] respectively), then the same
   message is accessible via the other protocol, and it has the same ID.

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

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

Gulbrandsen                Expires 7 July 2023                  [Page 2]
Internet-Draft               IMAP JMAPACCESS                January 2023

   The client requests the URL of the JMAP server by issuing ENABLE
   JMAPACCESS while in authenticated or selected state.

   When the server issues ENABLED JMAPACCESS, the server considers the
   way the client authenticated.  If the same authentication would work
   with the JMAP server, then the server MUST also send an untagged OK
   response with a JMAPACCESS response code containing a link to the
   JMAP server.

   If the authentication would not succeed with the JMAP server, then
   the server SHOULD send an untagged OK response with human-readable
   text to help client developers understand why this authentication
   would not work with the JMAP server.  In this case, the human-
   readable text MUST NOT contain any personal data, or other data that
   cannot be forwarded to the client developers.

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

   Note that all JMAP servers support internationalized email addresses
   (see [RFC6530]).  If this IMAP server does not, or the IMAP client
   does not issue ENABLE UTF8=ACCEPT (see [RFC6855]), then there is a
   possibility that the client receives accurate address fields via JMAP
   and downgraded fields via IMAP (see (see [RFC6857] and [RFC6858] for
   examples).

   Open issue: What about MAILBOXID?

4.  The JMAPACCESS Response Code

   The JMAPACCESS response code is followed by a single link to a JMAP
   session resource.  The server/mailstore at that location is
   referenced as "the JMAP server" in this document.

   The formal syntax in [RFC9051] is extended thus:

   resp-code-jmap = "JMAPACCESS" SP string

   resp-text-code =/ resp-code-jmap

   Open issue: This means that the link cannot contain a "]" character.
   This seems like a nonissue in practice but difficult as a matter of
   protocol hygiene.

5.  IANA Considerations

   The IANA is requested to add the JMAPACCESS response code to the IMAP
   Response Codes registry.

Gulbrandsen                Expires 7 July 2023                  [Page 3]
Internet-Draft               IMAP JMAPACCESS                January 2023

6.  Security Considerations

   This extension reveals to clients why they cannot auhenticate to the
   JMAP server.  One normally does not want to reveal anything about why
   a client cannot authenticate, for fear of giving useful information
   to an intruder.

   However, in this case the client has already authenticated via IMAP.
   By doing so the client already gained access to all of the same mail.
   The authors believe that the debugging value of the OK response far
   outweighs its security concerns.

7.  References

7.1.  Normative References

   [RFC8474]  Gondwana, B., Ed., "IMAP Extension for Object
              Identifiers", RFC 8474, DOI 10.17487/RFC8474, September
              2018, <https://www.rfc-editor.org/info/rfc8474>.

   [RFC9051]  Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
              Access Protocol (IMAP) - Version 4rev2", RFC 9051,
              DOI 10.17487/RFC9051, August 2021,
              <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/info/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/info/rfc8174>.

7.2.  Informative References

   [RFC6530]  Klensin, J. and Y. Ko, "Overview and Framework for
              Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,
              February 2012, <https://www.rfc-editor.org/info/rfc6530>.

   [RFC6855]  Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
              Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March
              2013, <https://www.rfc-editor.org/info/rfc6855>.

   [RFC6857]  Fujiwara, K., "Post-Delivery Message Downgrading for
              Internationalized Email Messages", RFC 6857,
              DOI 10.17487/RFC6857, March 2013,
              <https://www.rfc-editor.org/info/rfc6857>.

Gulbrandsen                Expires 7 July 2023                  [Page 4]
Internet-Draft               IMAP JMAPACCESS                January 2023

   [RFC6858]  Gulbrandsen, A., "Simplified POP and IMAP Downgrading for
              Internationalized Email", RFC 6858, DOI 10.17487/RFC6858,
              March 2013, <https://www.rfc-editor.org/info/rfc6858>.

   [RFC8620]  Jenkins, N. and C. Newman, "The JSON Meta Application
              Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July
              2019, <https://www.rfc-editor.org/info/rfc8620>.

Author's Address

   Arnt Gulbrandsen
   ICANN
   6 Rond Point Schumann, Bd. 1
   1040 Brussels
   Belgium
   Email: arnt@gulbrandsen.priv.no

Gulbrandsen                Expires 7 July 2023                  [Page 5]