[Extra] draft-ietf-extra-imap4rev2-04 review

Timo Sirainen <tss@iki.fi> Mon, 25 March 2019 12:05 UTC

Return-Path: <tss@iki.fi>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A93781203EF for <extra@ietfa.amsl.com>; Mon, 25 Mar 2019 05:05:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 18Sl3zT-59X3 for <extra@ietfa.amsl.com>; Mon, 25 Mar 2019 05:05:00 -0700 (PDT)
Received: from tss.iki.fi (tss.iki.fi []) by ietfa.amsl.com (Postfix) with ESMTP id 74F55120396 for <extra@ietf.org>; Mon, 25 Mar 2019 05:05:00 -0700 (PDT)
Received: from [] (unknown []) by tss.iki.fi (Postfix) with ESMTPSA id 061BE2B3C91 for <extra@ietf.org>; Mon, 25 Mar 2019 12:04:58 +0000 (UTC)
From: Timo Sirainen <tss@iki.fi>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Message-Id: <44234C00-7A5D-4B41-9E85-4CF839B48214@iki.fi>
Date: Mon, 25 Mar 2019 14:04:58 +0200
To: extra@ietf.org
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/gX6XSKw-kzvfHLMiB5mnULpr4ww>
Subject: [Extra] draft-ietf-extra-imap4rev2-04 review
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2019 12:05:04 -0000


Here's my review of draft-ietf-extra-imap4rev2-04:

> 1.2.  Conventions Used in This Document
>    "Session" refers to the sequence of client/server interaction from
>    the time that a mailbox is selected (SELECT or EXAMINE command) until
>    the time that selection ends (SELECT or EXAMINE of another mailbox,
>    CLOSE command, or connection termination).

UNSELECT missing from the list

>  Unique Identifier (UID) Message Attribute
>    The unique identifier validity value is sent in a UIDVALIDITY
>    response code in an OK untagged response at mailbox selection time.
>    If unique identifiers from an earlier session fail to persist in this
>    session, the unique identifier validity value MUST be greater than
>    the one used in the earlier session.

I see this was already in RFC 3501, but this "MUST be greater" has commonly been violated by servers. I think it should say "MUST be different". This is mainly because RENAME commonly doesn't change UIDVALIDITY, so:

RENAME mailbox-with-uidvalidity2 mailbox-with-uidvalidity2b
RENAME mailbox-with-uidvalidity1 mailbox-with-uidvalidity2

Would result in mailbox-with-uidvalidity2 shrinking UIDVALIDITY from 2 to 1.

> 3.4.  Logout State

>    A server MUST NOT unilaterally close the connection without sending
>    an untagged BYE response that contains the reason for having done so.

Also already in RFC 3501, but this MUST NOT has to be violated sometimes. For example otherwise it would allow client to FETCH a large message and keep reading it very very slowly over days, and server wouldn't be allowed to disconnect it, because it can't send BYE in the middle of the large mail literal.

> 4.5.  NIL

This is pretty easy to get wrong. It would help to have some examples of NIL and "NIL" in astring and nstring and what they mean. Like:

* LIST () "/" NIL
is equivalent to:
* LIST () "/" "NIL"


is not equivalent to:
* FETCH 1 (BODY[1] "NIL")

> 5.1.  Mailbox Naming

> servers MAY accept a de-normalized UTF-8 mailbox name and convert it to Net-Unicode prior to mailbox creation).
> Some server implementations
>    are fully case-sensitive in ASCII range; others preserve case of a
>    newly-created name but otherwise are case-insensitive; and yet others
>    coerce names to a particular case.

This seems rather difficult from client's point of view. It CREATEs a mailbox, but the client can't find it anymore because it changed. Seems to me it would be less strange if the server simply failed the CREATE entirely.

If this is allowed for CREATE, is such conversion done for SELECT/EXAMINE/APPEND as well? What about LIST "" <non-normalized name> - would it return the normalized name?

> A.1.  Mailbox International Naming Convention
>    By convention, international mailbox names in IMAP4rev2 are specified
>    using a modified version of the UTF-7 encoding described in [UTF-7].

This chapter needs removal or rewrite.

> 6.2.2.  AUTHENTICATE Command

> Client and server
>       implementations SHOULD implement additional [SASL] mechanisms that
>       do not use plaintext passwords, such the GSSAPI mechanism
>       described in [SASL] and/or the [DIGEST-MD5] mechanism.

I don't think we should be recommending DIGEST-MD5 anymore. Maybe SCRAM-SHA-256 instead?

> 6.3.9.  LIST Command

>       Note: The interpretation of the reference argument is
>       implementation-defined.  It depends upon whether the server
>       implementation has a concept of the "current working directory"
>       and leading "break out characters", which override the current
>       working directory.

Is there really any point in having the reference argument anymore? We could just require clients to use "" for it and simplify the protocol a lot?

> 6.3.10.  LSUB Command
>    A special situation occurs when using LSUB with the % wildcard.
>    Consider what happens if "foo/bar" (with a hierarchy delimiter of
>    "/") is subscribed but "foo" is not.  A "%" wildcard to LSUB must
>    return foo, not foo/bar, in the LSUB response, and it MUST be flagged
>    with the \Noselect attribute.
>    6.   Possibly fold in the following extensions/RFC: Base LIST-
>         EXTENDED syntax plus deprecate LSUB (replace it with LIST
>         \Subscribed) minus the requirement to support multiple list
>         patterns, STATUS-in-LIST, SEARCHRES, BINARY (only the FETCH
>         changes on leaf body part and make APPEND related ones optional.
>         See the mailing list discussion) - done.

I think at the very least we could remove the \Noselect kludge and return \Nonexistent instead.

> 6.3.11.  NAMESPACE Command

>  If a client is configured such that it is required to
>    create a certain mailbox, there can be circumstances where it is
>    unclear which Personal Namespaces it should create the mailbox in.
>    In these situations a client SHOULD let the user select which
>    namespaces to create the mailbox in.

Is any client ever going to actually implement this? Maybe just change it to say to use the first personal namespace?

> 6.4.1.  CHECK Command

Time to drop this command?

> 6.4.5.  SEARCH Command

> In all search keys that use strings, a message matches the key if the
>    string is a substring of the associated text.
>    11.  Allow word-based searching (as per Chris Newman)?

Yes, I think we can't require substring matching anymore, since there's no practical way of implementing it efficiently for large installations. And many servers no longer support it.

> 6.4.6.  FETCH Command

>    ALL  Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
>    FAST  Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE)
>       BODY)

Time to simplify and drop all macros?

>    BINARY[<section-binary>]<<partial>>
>    BODY[<section>]<<partial>>
>          The \Seen flag is implicitly set; if this causes the flags to
>          change, they SHOULD be included as part of the FETCH responses.

Time to simplify and require .PEEK versions? The auto-\Seen flag has just caused unnecessary complications.

> 6.4.10.  UID Command
>    Responses:  untagged responses: FETCH, ESEARCH

EXPUNGEs can also be returned by UID EXPUNGE.

> 7.4.2.  FETCH Response

>    RFC822  Functionally equivalent to BODY[], differing in the syntax of
>       the resulting untagged FETCH data (RFC822 is returned).
>    RFC822.HEADER  Functionally equivalent to BODY.PEEK[HEADER],
>       differing in the syntax of the resulting untagged FETCH data
>       (RFC822.HEADER is returned).
>    RFC822.TEXT  Functionally equivalent to BODY[TEXT], differing in the
>       syntax of the resulting untagged FETCH data (RFC822.TEXT is
>       returned).

Time to simplify and drop support for these?

>    CAPABILITY  Followed by a list of capabilities.  This can appear in
>       the initial OK or PREAUTH response to transmit an initial
>       capabilities list.  This makes it unnecessary for a client to send
>       a separate CAPABILITY command if it recognizes this response.

Could also mention that it is often sent in LOGIN or AUTHENTICATE tagged reply.

> 6.3.11.  NAMESPACE Command
> 7.2.5.  NAMESPACE Response

These are talking about "Namespace_Response_Extensions" but it's not explained anywhere. I've no idea what that is.

There are also some old imap-list discussions I had gathered in https://www.imapwiki.org/Specs/Rfc3501Problems - I think the relevant ones are:

 * LIST reply should never mix namespace separators. Different namespaces can have different separators, but in that case LIST shouldn't be listing those namespaces without explicitly being asked to.
 * Except INBOX is special and can have a different separator from others (I wouldn't mind dropping this though)
 * Should FLAGS / PERMANENTFLAGS be sent after a new keyword is created within the session
 * SEARCH TEXT includes searching MIME headers, while SEARCH BODY doesn't