Re: [Extra] Review: draft-ietf-extra-imap4rev2-11

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 09 March 2020 15:39 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 4116D3A1239 for <extra@ietfa.amsl.com>; Mon, 9 Mar 2020 08:39:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 LFdLVDmyNV7x for <extra@ietfa.amsl.com>; Mon, 9 Mar 2020 08:39:22 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id B33D73A1238 for <extra@ietf.org>; Mon, 9 Mar 2020 08:39:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1583768357; d=isode.com; s=june2016; i=@isode.com; bh=+yT3SmSXBazRvxAzN2Be0CdtMz+6rzju3N6gLeV4ixg=; 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=aqdAbYNOtzQRmuFgjKJEOy4+1dA+qoe4tLR77yDRu7wwCIYoaghdwW7yVz/ma62A1MVM50 dS0/AnNVswJaazhRazzT9aWWfK6eh6BG4ge+yioDq8Ldy+Mk9lMl8BR0d6faOwmZ7JiKAj oKFoPg8s1Nm1Lw+4hUOjg+VSnXFDUSU=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <XmZjJQApVSpO@waldorf.isode.com>; Mon, 9 Mar 2020 15:39:17 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
To: Bron Gondwana <brong@fastmailteam.com>, extra@ietf.org
Cc: Barry Leiba <barryleiba@computer.org>
References: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com>
Message-ID: <d1aed0d2-eb18-bd85-26c9-444c91fb130a@isode.com>
Date: Mon, 9 Mar 2020 15:39:14 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1
In-Reply-To: <9fdfa8e8-147d-4248-a0c1-48de171ac675@dogfood.fastmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------338EE19ED86927065B8790FE"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/a85_sxyc-lINkU1epPKvnQUQk1I>
Subject: Re: [Extra] Review: draft-ietf-extra-imap4rev2-11
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, 09 Mar 2020 15:39:24 -0000

Hi Bron,

I addressed several more comments from you in -13:

On 29/01/2020 12:08, Bron Gondwana wrote:
> *2.2.1 Client protocol*
> *
> *
> /"A different tag is generated by the client for each command"./  
> There's no "MUST" on this, and certainly I've seen clients which 
> don't.  Do we want to make that more strict in rev2?  It would be a 
> bit of a pain on the commandline where I normally use ".", but it's 
> also annoying as a server author that you can't rely on tag uniqueness.
>
> Maybe the client SHOULD generate a different tag for every command, 
> but a server MUST accept tag reuse (could restrict concurrency, a tag 
> can only be reused after it's been "returned")

I added:

    (More formally: the client SHOULD generate a unique tag for every 
command,
    but a server MUST accept tag reuse.)
/*
*/

>
> *2.3.1.1 UID Attribute
> *
> /
> /
> Both UID and UIDVALIDITY say "unsigned 32-bit value" - but strictly 
> (as seen later in the ABNF) they aren't allowed to be zero.  It would 
> be good to say "non-zero" when each is first mentioned, but I don't 
> care strongly about this one.

Clarified.

>
> *2.3.2 Flags Message Attribute
> *
>
> Should this section also reference 
> https://www.iana.org/assignments/imap-jmap-keywords/imap-jmap-keywords.xhtml 
> ?
Added
>
> *5.1 Mailbox Naming
> *
>
> This doesn't solve one of my naming bugbears.  The spec says things 
> like /"servers MAY accept a de-normalized UTF-8 mailbox name and 
> conver it to Net-Unicode prior to mailbox creation." -/*//*there is no 
> clear way to know what the SELECTable name will be after creating a 
> mailbox.
>
> If I was designing this myself from scratch I would say that "SELECT 
> of the same octets that were passed to CREATE MUST open that same 
> mailbox" or something to that effect.  Since we're messing with how 
> mailbox naming works somewhat for imap4rev2, I'd be keen to add this 
> restriction on server behaviour so that clients don't fall into a 
> "CREATE -> ALREADY EXISTS / SELECT -> DOESN'T EXIST" loop.
>
> It still doesn't mean that you can reliably tell the correct octets 
> for the matching mailbox from the LIST response though :(
>
I believe I clarified this with the following text:

    However, servers MAY accept a de-normalized UTF-8
    mailbox name and convert it to Unicode normalization form "NFC"
    (as per Net-Unicode requirements) prior to mailbox creation.
    Servers that choose to accept such de-normalized UTF-8 mailbox
    names MUST accept them in all IMAP commands that have a mailbox name 
parameter.
    In particular SELECT &lt;name&gt; must open the same mailbox that
    was successfully created with CREATE &lt;name&gt;, even if &lt;name&gt;
    is a de-normalized UTF-8 mailbox name.


>
> *7.2.3 LIST Response
> *
>
> This is the interesting bit for SPECIAL-USE - it should reference that 
> here - as well as referencing the registry since it reproduces some of 
> it inline.
>
> https://www.iana.org/assignments/imap-mailbox-name-attributes/imap-mailbox-name-attributes.xhtml

I've added the IANA registry reference.

_
_

> __
> __
> *7.4.2 FETCH Response
> *
>
> I remember past bugs with UID in "unsolicited" FLAGS responses.  Do we 
> need to require that including UID only happen after ENABLE IMAP4REV2 
> (as it is for ENABLE QRESYNC)?

I am border line on this, but I don't think so. This should be common 
enough that even IMAP4rev1 clients should be able to handle this.


> *Appendix C: Changes
> *
>
> Right now it's still stated as "the planned changes" and there's still 
> some TODO in there (some of which I think could be well handled by 
> referencing the registries rather than replicating them inline).

I cleaned this up and there are only 2 smaller items remaining, that we 
might want to discuss in the WG.

Best Regards,

Alexey