Re: [Extra] AD Review of draft-ietf-extra-imap4rev2

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 06 January 2021 23:06 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 0BAE33A0AFA for <extra@ietfa.amsl.com>; Wed, 6 Jan 2021 15:06:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 TRpakkuRdUrI for <extra@ietfa.amsl.com>; Wed, 6 Jan 2021 15:06:07 -0800 (PST)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 6303E3A09E9 for <extra@ietf.org>; Wed, 6 Jan 2021 15:06:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1609974366; d=isode.com; s=june2016; i=@isode.com; bh=MO/i4nKy3G+vko4NAhqdNdhe/pxFAU9yWKjf2F8aP6Q=; 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=pzEnprB67IafNsM/ybO6WfsNlMyQHAjhYjhC3vgA5GeY+QxDLTuK3A23ps5yT3+IK4gJH/ LbBzqO9z3pSbpFSCDtFoaBAAR4H5g7ArVsXGJonShPABoNttaMWEdgLOHv0wO0Dt0mqTRn INEZIsW1txqr5CY23EqPnejzKYivkpM=;
Received: from [192.168.0.2] ((unknown) [176.252.130.164]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <X=ZCXQBqmr2O@statler.isode.com>; Wed, 6 Jan 2021 23:06:06 +0000
X-SMTP-Protocol-Errors: NORDNS
From: Alexey Melnikov <alexey.melnikov@isode.com>
X-Mailer: iPad Mail (16G102)
In-Reply-To: <CAL0qLwYXqj577yxiHuQBR1E70uik4fpQuizYaBFqa2DaXCmbmw@mail.gmail.com>
Date: Wed, 06 Jan 2021 23:06:04 +0000
Cc: extra@ietf.org
Message-Id: <A8EBAAED-3DCE-4101-8A4C-44A42A1DDB6E@isode.com>
References: <CAL0qLwaLa+PuGWRrKTbpmDa_SWKT9ZQUEQ9dsPgXfUmTzcYAYw@mail.gmail.com> <bb662e64-626c-914b-de59-f85ef18ee5e3@isode.com> <CAL0qLwYXht2r_83PCZo6+tJUJAoYCd0EoGyCHm6BQEQ=YhWT-A@mail.gmail.com> <5bd4c4e9-4414-e9b5-48f4-520f3185239b@isode.com> <CAL0qLwYXqj577yxiHuQBR1E70uik4fpQuizYaBFqa2DaXCmbmw@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="Apple-Mail-41249058-1ECC-4792-9170-11234A5E65EB"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/v9cPDpRs84Xb_2_qRS26QI1sKR4>
Subject: Re: [Extra] AD Review of draft-ietf-extra-imap4rev2
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, 06 Jan 2021 23:06:09 -0000

Hi Murray,

> On 6 Jan 2021, at 22:53, Murray S. Kucherawy <superuser@gmail.com> wrote:
> 
>> On Tue, Jan 5, 2021 at 5:56 AM Alexey Melnikov <alexey.melnikov@isode.com> wrote:


>>>>> 
>>>>>  It’s weird to say “renaming INBOX is permitted”
>>>> This is saying that the server wouldn't return "BAD" to it.
>>>>> followed immediately by “some servers don’t let you do this”.
>>>> But this is saying that the server can still return "NO".
>>>>> Which is the standard for this version of IMAP?  If it’s an implementation choice, I think that’s what this should say.
>>>> Yes, it is.
>>> 
>>> That's fine, then, if this is clarified.  I just found that bit to be self-contradicting as written in -22.
>> I think IMAP is a bit subtle in places, as NO and BAD have very different semantics. "BAD" means that the client shouldn't have tried this. "NO" means some other reason why this fails, which can be entirely server specific.
>> 
>> Anyway, I clarified this.
>> 
> 
> Thanks!
> 
> -24 covers all of the major stuff except the text duplication (nice work!).  Did we figure out how you'd like to deal with that?  That's not a Last Call blocker for me -- I'll send -24 if you think it's ready -- but I wouldn't be surprised if some downstream reviewer or AD makes the same observation.

Yes, please start IETF LC on -24 and I fix the rest in -25.

Thank you,
Alexey