[Extra] AD review of draft-ietf-extra-imap-replace-00.txt

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 01 October 2018 12:44 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8474E130E60 for <extra@ietfa.amsl.com>; Mon, 1 Oct 2018 05:44:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpI7gqxYL8pr for <extra@ietfa.amsl.com>; Mon, 1 Oct 2018 05:43:59 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id CB616130E61 for <extra@ietf.org>; Mon, 1 Oct 2018 05:43:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1538397838; d=isode.com; s=june2016; i=@isode.com; bh=clcyYU66ezYz3x8QxSMW8/8g26YRhhel2FIbp8TObT4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=uZB420fSswn1l0r7LD0NI57nzNNJD+b1ww/sLZdS05sDUFQTO0YQsgvGChc2WjUQFpy5Tr pdRZEXCkTeZizi+Ssi27rVURAvScnTO4ra04pIj87Ypaq0OXqM3P/uZBu604SSMd6BkduS q9vU9lOSjaBqWPyjU8F4+u+0y4vwo3E=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <W7IWjQAG7Ygl@statler.isode.com>; Mon, 1 Oct 2018 13:43:57 +0100
To: extra@ietf.org
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <7c4a8162-e29e-bddb-1b9a-8d4ec6b623dc@isode.com>
Date: Mon, 01 Oct 2018 13:43:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/KNbnqVI5gHyTShy-6tINT54StDk>
Subject: [Extra] AD review of draft-ietf-extra-imap-replace-00.txt
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, 01 Oct 2018 12:44:01 -0000

Hi,

The document is generally in a good state and covers lots of tricky 
interactions with other extensions. But I have a small list of minor 
issues/nits that I would like to discuss:


3.4.  Semantics of REPLACE and UID REPLACE

    While it may be common for the named mailbox argument to match the
    selected mailbox for the common use case of replacing a draft, the
    REPLACE extension intentionally does not require the two to be the
    same.  As an example, it's possible to use the REPLACE command to
    replace a message in the \Drafts special-use mailbox with a message
    in the \Sent special-use mailbox following message submission.

I think this needs an informative reference to the Special Use RFC to 
help readers not familiar with the term.

4.3.  RFC 4315, UIDPLUS

    Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD send
    APPENDUID in response to a UID REPLACE command.  For additional
    information see section 3 of RFC4315.  Servers implementing REPLACE
    and UIDPLUS are also advised to send the APPENDUID response code in
    an untagged OK before sending the EXPUNGE or replaced responses.

All examples are using:

  * APPENDUID ...


instead of

  * OK [APPENDUID ...] some text

What is in the draft is syntactically invalid, as it is not a response code.

    (Sending the APPENDUID in the tagged OK, as described in the UIDPLUS
    specification means that the client first receives an EXPUNGE for a
    message and afterwards APPENDUID for the new message.  It can be
    unnecessarily difficult to process that sequence usefully.)

5.  Formal Syntax

    capability     =/ "REPLACE"

    command-select =/ replace
    replace        = "REPLACE" SP seq-number SP mailbox append-message

RFC 4466 allows for multiple "append-message", if MULTIAPPEND extension 
is present. I think your document should say explicitly that REPLACE is 
not affected by MULTIAPPEND.

    uid            = "UID" SP (copy / fetch/ search / store / move /
                               replace)