Re: [Extra] Publication has been requested for draft-ietf-extra-quota-05

Alexey Melnikov <alexey.melnikov@isode.com> Fri, 27 August 2021 11:05 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 3321D3A2E6B; Fri, 27 Aug 2021 04:05:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.901
X-Spam-Level: **
X-Spam-Status: No, score=2.901 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, GB_SUMOF=5, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 OqgFtEa-tv18; Fri, 27 Aug 2021 04:04:54 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 412333A2E68; Fri, 27 Aug 2021 04:04:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1630062292; d=isode.com; s=june2016; i=@isode.com; bh=8/qvcaT5n6gjOh0fttoxC9DUcgsGn1nQ8MY4je1vIIA=; 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=qFebbGNuBnWMjjq2jnEvGlKQvBpscbO9XPrNAxbv82ZIwDmjFo2IDwGL2k4yLJbZkv2MRa mGrS8aq6TR1jKozlJ+NV71L11cJHXs1A6Hy6nH213obwhC6JY5Pmhzu3nuxd5/Q2hMxsAL 5LV/6qhQn3o5jPQWqyYNmQy4tl5LWks=;
Received: from [192.168.1.222] (host5-81-100-126.range5-81.btcentralplus.com [5.81.100.126]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <YSjG0wBGjYhG@waldorf.isode.com>; Fri, 27 Aug 2021 12:04:52 +0100
To: "Murray S. Kucherawy" <superuser@gmail.com>, Bron Gondwana via Datatracker <noreply@ietf.org>
Cc: extra@ietf.org, Bron Gondwana <brong@fastmailteam.com>, DraftTracker Mail System <iesg-secretary@ietf.org>, extra-chairs@ietf.org
References: <162938074585.31851.14261488584404618572@ietfa.amsl.com> <CAL0qLwaZq52=xvq-bc11ijpQQ6+GzJiyQjXSXJXMHMDPP_b+DA@mail.gmail.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <7b89dc9b-3b4f-bbe4-6009-01582229f58a@isode.com>
Date: Fri, 27 Aug 2021 12:04:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
In-Reply-To: <CAL0qLwaZq52=xvq-bc11ijpQQ6+GzJiyQjXSXJXMHMDPP_b+DA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------EFA83B2E10665E7F7DAAD637"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/IoQ3hRdpz63EHV2NWLFhfuxp8kM>
Subject: Re: [Extra] Publication has been requested for draft-ietf-extra-quota-05
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: Fri, 27 Aug 2021 11:05:00 -0000

Hi Murray,

Thank you for your review.

On 27/08/2021 08:02, Murray S. Kucherawy wrote:

> AD review time!
>
> Generally, should RFC 3501 references that are used as the main IMAP 
> reference be replaced by RFC 9051? (Congratulations, by the way!)
I think it is important to make it clear that this works with both 
IMAP4rev1 and IMAP4rev2 implementations. So I prefer to have both.
>
> I note the comment in the shepherd writeup about the downward 
> reference to something with Experimental status. Would you like to 
> change the status of that document before processing this one, or did 
> you have something else in mind?
I don't think any change was intended. Just noting it for the IETF LC.
> I note the last paragraph of Section 2.  Is what this document 
> describes backward compatible with implementations of RFC 2087?

"It is complicated" :-). I think the answer is yes, but to give you some 
background:

RFC 2087 was written by John Myers who worked for CMU and worked on 
Cyrus IMAP server at the time. Other than some minor cleanup Cyrus IMAP 
remains compatible with this document. I also believe Thunderbird is 
compatible both with RFC 2087 and this document.

However RFC 2087 was underspecified and if anybody wanted to implement 
it they could have done an incompatible implementation, unless they 
coded it to interoperate with Cyrus IMAP. This document is addressing 
various ambiguities.

I hope the above answers your question.

> Section 3.1.1 uses the term "quota root" before it's defined later.  I 
> suggest a forward reference, or perhaps (although this is more work) a 
> bit of a reordering.
I added a forward reference.
> Section 3.1.2 has a "must" that should probably be a "MUST".
Changed.
> Section 3.2 refers to this document as a "memo" but everywhere else 
> it's a "document".  I suggest changing this to match.
Changed, thanks.
> In Section 4.1.4, if the server opts to provide the cheaper 
> calculation by summing the RFC822.size of all deleted messages, is it 
> appropriate to indicate to the client that this is an estimate and not 
> a calculation?  i.e., does it need to know?

No, the client doesn't need to know because the true reclamed storage 
size would be >= than the sum of sizes of all deleted messages.

The client also doesn't need to know, because changes can happen on the 
server (for example if a message gets deleted or undeleted by another 
email client) after this information is returned, but before it is used 
anyway.

> The description of STORAGE in Section 5.1 doesn't make it clear that 
> you're getting two values, and specifically what they are.  It reads 
> like you only get one.  Or have I misunderstood something?
QUOTA response returns 2 values: limit and current usage. Section 5.1 
(and other 5.X sections) is only talking about the current usage value.
> In Section 9, the third paragraph refers to "the IMAP quota resource 
> type registry established above", but it's not actually established 
> until two paragraphs later.  Also, while it's certainly not necessary, 
> I would suggest putting each requested IANA action in its own 
> subsection.  Similarly the batch of registrations in Section 9.1 could 
> be better separated.
I've split registrations into 3 subsections and fixed internal references.
> Also in Section 9, BCP 26 states that for Specification Required 
> registries, a designated expert will be appointed, and thus this 
> document should provide some general review advice or guidance to that 
> expert for this registry being created.  That seems to be missing here.

I added some suggested text.

Best Regards,

Alexey

>
> -MSK
>
>
> On Thu, Aug 19, 2021 at 6:45 AM Bron Gondwana via Datatracker 
> <noreply@ietf.org <mailto:noreply@ietf.org>> wrote:
>
>     Bron Gondwana has requested publication of
>     draft-ietf-extra-quota-05 as Proposed Standard on behalf of the
>     EXTRA working group.
>
>     Please verify the document's state at
>     https://datatracker.ietf.org/doc/draft-ietf-extra-quota/
>     <https://datatracker.ietf.org/doc/draft-ietf-extra-quota/>
>
>
>
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra