Subject: Re: [Extra] Opsdir last call review of draft-ietf-extra-imap-status-size-01

From: Bron Gondwana <[email-masked]>
Date: Fri, 15 Jun 2018 15:40:19 +1000

On Tue, May 15, 2018, at 02:00, Barry Leiba wrote:
>> On Mon, 14 May 2018, at 11:57, Linda Dunbar wrote:
>> 
>> Reviewer: Linda Dunbar
>> Review result: Not Ready
>> 
>> Reviewer: Linda Dunbar
>> Review result: need more complete description
>> 
>> After reading through the document, I find the description is
>> not very>> clear.
>> For example:
>> Section 1 Introduction:
>> Is the “mailbox” referring to the IMAP client’s mailbox or the server>> mailbox
>> where all emails are stored?
>> 
>> 
>> Why do Webmail clients need to know the server side mailbox size?
>> 
>> Does the “mailbox size” change overtime?
>> 
>> Thanks. Linda Dunbar
>> 
>> 
>> Thanks Linda.  I admit that none of these questions occurred to me,
>> clearly>> I'm too embedded in the IMAP world already, so I would say that the
>> answers>> to your questions are:
>> 
>> 1) like all STATUS responses, this is the state of the mailbox on the>> server.
>> 
>> 2) any clients which don't keep a full copy of the IMAP mailbox may
>>    still>> wish to be able to quickly identify the mailboxes using the most
>> amount of>> storage - for example to allow the the user to remove large
>> messages when>> they are approaching their storage quota.
>> 
>> 3) as defined in this document, "mailbox size" is based on the
>>    storage used>> by the messages in the mailbox, so it will naturally change if
>> the set of>> messages in the mailbox change, either through adding new
>> messages, or>> expunging existing messages.
>> 
>> I will send this back to the author and request clarifying language
>> be added>> to address these three questions.
> 
> Really?  I don't think there's anything the author needs to do: all of> this is clear to people familiar with the relevant IMAP specs, and
> people implementing this have to be familiar with the relevant IMAP
> specs.
> 
> It doesn't hurt to have a look and see whether there are reasonable
> clarifications to make, but I don't think we should spend too much
> time on that for these issues.

Following on from this - the document is currently  held in "Waiting
on Authors".
The author made an update in -02 to clarify some wording for those who
aren't familiar with the related specifications.
Linda - can you please review -02 and see if it resolves your
objections.
Thanks,

Bron.

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

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 22 Jun 2018 07:59:35 +1000

The author has contacted me to see if I can figure out what's going on.
As far as he's aware he made the changes in -02 which the working group
agreed were necessary.
What's the next step here?

Thanks,

Bron.

On Fri, Jun 15, 2018, at 15:40, Bron Gondwana wrote:
>>> not very>>> clear.
>>> Is the “mailbox” referring to the IMAP client’s mailbox or the
>>> server>>> mailbox
>>> clearly>>> I'm too embedded in the IMAP world already, so I would say that the
>>> answers>>> to your questions are:
>>> 
>>> 1) like all STATUS responses, this is the state of the mailbox on
>>>    the>>> server.
>>> 
>>>    still>>> wish to be able to quickly identify the mailboxes using the most
>>> amount of>>> storage - for example to allow the the user to remove large
>>> messages when>>> they are approaching their storage quota.
>>> 
>>>    storage used>>> by the messages in the mailbox, so it will naturally change if the
>>> set of>>> messages in the mailbox change, either through adding new
>>> messages, or>>> expunging existing messages.
>>> 
>>> be added>>> to address these three questions.
>> 
>> Really?  I don't think there's anything the author needs to
>> do: all of>> this is clear to people familiar with the relevant IMAP specs, and
> on Authors".> 
> aren't familiar with the related specifications.> 
> objections.> 
> _________________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 21 Jun 2018 22:07:06 +0000

I thought I responded. The updated 02 version is clear.

Thanks, linda

From: Bron Gondwana [mailto:[email-masked]]
Sent: Thursday, June 21, 2018 5:00 PM
To: Barry Leiba <[email-masked]>
Cc: [email-masked]; Linda Dunbar <[email-masked]>
Subject: Re: [Extra] Opsdir last call review of draft-ietf-extra-imap-status-size-01

The author has contacted me to see if I can figure out what's going on. As far as he's aware he made the changes in -02 which the working group agreed were necessary.

Thanks,

Bron.

Reviewer: Linda Dunbar
Review result: Not Ready

Reviewer: Linda Dunbar

After reading through the document, I find the description is not very
clear.
For example:
Section 1 Introduction:
Is the “mailbox” referring to the IMAP client’s mailbox or the server
mailbox
where all emails are stored?

Thanks. Linda Dunbar

Thanks Linda.  I admit that none of these questions occurred to me, clearly
I'm too embedded in the IMAP world already, so I would say that the answers
to your questions are:

1) like all STATUS responses, this is the state of the mailbox on the
server.

2) any clients which don't keep a full copy of the IMAP mailbox may still
wish to be able to quickly identify the mailboxes using the most amount of
storage - for example to allow the the user to remove large messages when
they are approaching their storage quota.

3) as defined in this document, "mailbox size" is based on the storage used
by the messages in the mailbox, so it will naturally change if the set of
messages in the mailbox change, either through adding new messages, or
expunging existing messages.

I will send this back to the author and request clarifying language be added
to address these three questions.

Really?  I don't think there's anything the author needs to do: all of
this is clear to people familiar with the relevant IMAP specs, and
people implementing this have to be familiar with the relevant IMAP
specs.

Following on from this - the document is currently held in "Waiting on Authors".

The author made an update in -02 to clarify some wording for those who aren't familiar with the related specifications.

Linda - can you please review -02 and see if it resolves your objections.

Thanks,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]<mailto:[email-masked]>

_______________________________________________
Extra mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/extra

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]<mailto:[email-masked]>

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 22 Jun 2018 08:09:35 +1000

Can you please clear the needs edit in data tracker.

Ta,

Bron.

> *From:* Bron Gondwana [mailto:[email-masked]] *Sent:*
> Thursday, June 21, 2018 5:00 PM *To:* Barry Leiba
> <[email-masked]> *Cc:* [email-masked]; Linda Dunbar
> <[email-masked]> *Subject:* Re: [Extra] Opsdir last call
> review of draft-ietf-extra-imap-status-size-01>  

> The author has contacted me to see if I can figure out what's going
> on. As far as he's aware he made the changes in -02 which the working
> group agreed were necessary.>  

>>>> not very>>>> clear.

>>>> server>>>> mailbox

>>>> Why do Webmail clients need to know the server side mailbox size?>>>>  

>>>> clearly>>>> I'm too embedded in the IMAP world already, so I would say that the
>>>> answers>>>> to your questions are:

>>>>    the>>>> server.

>>>>    still>>>> wish to be able to quickly identify the mailboxes using the most
>>>> amount of>>>> storage - for example to allow the the user to remove large
>>>> messages when>>>> they are approaching their storage quota.

>>>>    storage used>>>> by the messages in the mailbox, so it will naturally change if the
>>>> set of>>>> messages in the mailbox change, either through adding new
>>>> messages, or>>>> expunging existing messages.

>>>> be added>>>> to address these three questions.

>>> Really?  I don't think there's anything the author needs to do:
>>> all of>>> this is clear to people familiar with the relevant IMAP specs, and>>> people implementing this have to be familiar with the relevant IMAP>>> specs.

>>> It doesn't hurt to have a look and see whether there are reasonable>>> clarifications to make, but I don't think we should spend too much>>> time on that for these issues.

>> on Authors".>>  

>> The author made an update in -02 to clarify some wording for those
>> who aren't familiar with the related specifications.>>  

>> objections.>>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 21 Jun 2018 18:18:04 -0400

> The author has contacted me to see if I can figure out what's going on. As
> far as he's aware he made the changes in -02 which the working group agreed
> were necessary.
>

There's no next step: the document has been approved by the IESG and
is in the RFC Editor queue.
The directorate reviews are not blocking -- just as with other
last-call comments, we need to consider the comments and make a
reasonable effort to respond to them and to addres the ones that make
sense to address.  We think we did that, the IESG thinks we did that,
and all is good.

I wonder if the author was confused.  He'd have gotten a note from
IANA that required a response, and it seems like it took him a while
to respond to it.  But it looks like he did respond, and today the
IANA status changed from "waiting on authors" to "waiting on RFC
Editor".

So, again: the document is approved and in the RFC Editor queue.
Nothing needed now.

Barry

-- 
Barry
--
Barry Leiba  ([email-masked])
http://internetmessagingtechnology.org/

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 22 Jun 2018 08:20:37 +1000

Ok great! Thanks Barry and Linda. Sorry, I'm still very new at this so
that wasn't clear to me.
Cheers,

Bron.

On Fri, Jun 22, 2018, at 08:18, Barry Leiba wrote:
>> The author has contacted me to see if I can figure out what's
>> going on. As>> far as he's aware he made the changes in -02 which the working
>> group agreed>> were necessary.
>> 
> reasonable effort to respond to them and to addres the ones that make> sense to address.  We think we did that, the IESG thinks we did that,> and all is good.
> 
>> Following on from this - the document is currently held in
>> "Waiting on>> Authors".
>> 
>> The author made an update in -02 to clarify some wording for
>> those who>> aren't familiar with the related specifications.
>>