Re: [Extra] [EXT] Re: I-D Action: draft-ietf-extra-imap4rev2-15.txt

Stephan Bosch <stephan.bosch@open-xchange.com> Wed, 02 September 2020 20:06 UTC

Return-Path: <stephan.bosch@open-xchange.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 8BFEF3A0DEF for <extra@ietfa.amsl.com>; Wed, 2 Sep 2020 13:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.047
X-Spam-Level:
X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.948, 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 (2048-bit key) header.d=open-xchange.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 TL6WWHIL0Peu for <extra@ietfa.amsl.com>; Wed, 2 Sep 2020 13:06:30 -0700 (PDT)
Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335343A0E05 for <extra@ietf.org>; Wed, 2 Sep 2020 13:06:26 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 018CE6A303; Wed, 2 Sep 2020 22:06:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1599077185; bh=Yc7J1xzKlUjDLM3T17f5ctOSSAhCCMPZI+uPgEZDde4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=V1flxSHP8i9pjZvlOzsKOlG0a7f5Ga/VV8UkY0Lt+oYwz9POje+8/5j2KeAzDz5h1 Kxvf9BrtCSyXcj0NkxOsaNi/kCJqT9/u/EYRu0zF85kjaGbSQD0zCnKP4BafiDSABc iY+XyojBZGcdCuwx8fWxJegTxcsXvi2RGiXBc7uczlf9DRwkFPvI0Xu1uurDl6qvsu 9sbkF7X6x8PW5hNGfoMOjmtGzcP03NUw7buzU9Jbu+7ck/GdFj6b+m81ediL3bsjKG FGDl1VDG5O37EEpFV+2kPQpuv25rJxsgXe1cZOxuGoBaGJLV/PXgtxh1M1M+UfsDVY erGi8tCarwJUQ==
Received: from [10.168.3.2] (unknown [10.217.131.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id B55723C0431; Wed, 2 Sep 2020 22:06:24 +0200 (CEST)
To: Alexey Melnikov <alexey.melnikov@isode.com>, extra@ietf.org
References: <159238763595.1803.574245566610096074@ietfa.amsl.com> <b4390473-241f-6860-2ebb-fdf4dad06ec8@isode.com> <a7304716-b160-4731-e145-934cb127d28e@open-xchange.com> <b908d009-5ee4-9caa-63ea-23788a270188@open-xchange.com> <de1f23c9-5516-91d7-039e-9354ce73ffea@isode.com>
From: Stephan Bosch <stephan.bosch@open-xchange.com>
Message-ID: <66611b2f-e1aa-1609-f296-4b4f5db92bbb@open-xchange.com>
Date: Wed, 2 Sep 2020 22:06:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <de1f23c9-5516-91d7-039e-9354ce73ffea@isode.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/Jk4h03EqtKIJ6v89Ok-DfHSitbM>
Subject: Re: [Extra] [EXT] Re: I-D Action: draft-ietf-extra-imap4rev2-15.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: Wed, 02 Sep 2020 20:06:33 -0000

Hi Alexey,

On 29/07/2020 17:55, Alexey Melnikov wrote:
> Hi Stephan,
> 
> Thank you very much for your detailed review. Replying to most of your 
> comments below. Your remaining issues I will address in a later 
> revision/reply to later.
> 

>>> section-6.3.9:
>>>
>>> -> This section mentions several examples of specific selection and 
>>> return options without introduction. It should maybe refer to 
>>> subsequent sections at the first instance of this.
> 
> The document already says:
> 
>     Initial selection options and return options are defined in the
>     following subsections, and new ones will also be defined in
>     extensions.
> 
> Do you think this is not sufficient?

Right. I seem to have overlooked that sentence.

>>>    Future extensions to this
>>>    specification should keep parallelism in mind and define a pair of
>>>    corresponding options.
>>> -> So, what exactly is meant by "parallelism" here? Do you mean 
>>> "dualism" or something like that (which I actually find equally 
>>> confusing)?
> 
> I think I clarified this a bit, but expanding the description:
> 
>        In general, each selection option except RECURSIVEMATCH will have
>        a corresponding return option with the same name.  The REMOTE 
> selection option is an anomaly
>        in this regard, and does not have a corresponding return option.
>        That is because it expands, rather than restricts, the set of 
> mailboxes
>        that are returned.  Future extensions to this specification 
> should keep
>        this parallelism in mind and define a pair of corresponding
>        selection and return options.
> 

Yeah, better.

>>>    It is an error for the server to return both a \HasChildren and a
>>>    \HasNoChildren attribute in the same LIST response.
>>> -> Any recommendation for what clients should do if this does happen? 
>>> Provisionally treat it as \HasChildren?

No word on this? Do we want to avoid recommending error mitigation 
strategies in the document?

>>> section-7.4.1:
>>>
>>> -> Isn't this sub-section supposed to be in the section before? It is 
>>> about the mailbox size, not message data.
> Arguably EXPUNGE is about message status (the message is no longer 
> there). But I can go either way on this.

I don't have an opinion really. I was just worried this was wrong 
somehow. Maybe others can weigh in.

>>> section-12.1:
>>>
>>>    As this specification revises the AUTH= prefix, STARTTLS and
>>>    LOGINDISABLED extensions previously defined in [IMAP-TLS], IANA is
>>>    requested to update registry entries for these 3 extensions to point
>>>    to this document.
>>> -> This is not noted in the document header.
> 
> Can you explain what is the issue with this text? Are you talking about 
> documents listed as Updated/Obsolete?

Yes.

Regards,

Stephan.