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

From: Bron Gondwana via Datatracker <[email-masked]>
Date: Thu, 19 Aug 2021 06:45:45 -0700

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/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 27 Aug 2021 00:02:12 -0700

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 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 note the last paragraph of Section 2.  Is what this document describes
backward compatible with implementations of RFC 2087?

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.

Section 3.1.2 has a "must" that should probably be a "MUST".

Section 3.2 refers to this document as a "memo" but everywhere else it's a
"document".  I suggest changing this to match.

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?

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?

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.

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.

-MSK

On Thu, Aug 19, 2021 at 6:45 AM Bron Gondwana via Datatracker <
[email-masked]> 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/
>
>
>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 27 Aug 2021 12:04:36 +0100

Hi Murray,

Thank you for your review.

> 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.

> 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.
> 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 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Bron Gondwana has requested publication of
>     draft-ietf-extra-quota-05 as Proposed Standard on behalf of the
>     EXTRA working group.
>
>     <https://datatracker.ietf.org/doc/draft-ietf-extra-quota/>
>
>
>
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

---

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 27 Aug 2021 22:57:49 +1000

On Fri, Aug 27, 2021, at 21:04, Alexey Melnikov wrote:
> 
> 
>> 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?

Yes, that's correct - just noting that there is a downreference and that I don't believe it needs to be resolved.

There is a question of whether we want to revisit per-message annotations, and possibly align them more with RFC5464 metadata.  They are designed on an earlier draft of 5464 (which Cyrus IMAP still supports as well for horrible legacy reasons).

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]