Subject: [Extra] Progressing the fcc and objectid documents

From: Bron Gondwana <[email-masked]>
Date: Mon, 07 May 2018 22:52:48 +1000

Hi All,

There's two documents which I believe are nearly ready for last call.
fcc and objectid
https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-fcc/

Ken uploaded this version a week ago.  It would be great to have
feedback (I'll go write my own too)
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-objectid/

I uploaded this one a couple of weeks ago, which resolved all the
feedback I've had.  More feedback here would be great too.  I've already
implemented it in Cyrus IMAPd master, but that's no surprise since I
knew what was required when I wrote the spec!
I'd like to progress these to working group last call fairly soon so
there's time for them to get some good attention and be published
before Montreal.
Cheers,

Bron.

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 7 May 2018 14:07:20 +0100

On Monday 7 May 2018 13:52:48 IST, Bron Gondwana wrote:
> I uploaded this one a couple of weeks ago, which resolved all 
> the feedback I've had.  More feedback here would be great too. 

Maybe...

"Servers that implement both RFC 6154 and this specification SHOULD 
optimize their execution of command like UID SEARCH OR EMAILID 1234 EMAILID 
4321. Clients may assume that searching the all-mail mailbox using 
OR/EMAILID or OR/THREADID is a fast way to find messages again if some 
other client has moved them out of the mailbox where they were previously 
seen."

Or not. Your call.

Arnt

---

From: Bron Gondwana <[email-masked]>
Date: Mon, 07 May 2018 23:16:23 +1000

On Mon, 7 May 2018, at 23:07, Arnt Gulbrandsen wrote:
> optimize their execution of command like UID SEARCH OR EMAILID
> 1234 EMAILID> 4321. Clients may assume that searching the all-mail mailbox using
> OR/EMAILID or OR/THREADID is a fast way to find messages again if some> other client has moved them out of the mailbox where they were
> previously> seen."
> 
> Or not. Your call.

It's definitely not normative advice, but that definitely looks like
something to put in the appendix area.
Thanks,

Bron.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 7 May 2018 14:23:43 +0100

On Monday 7 May 2018 14:16:23 IST, Bron Gondwana wrote:
> It's definitely not normative advice, but that definitely looks 
> like something to put in the appendix area.

Normative advice. What a spiffing phrase. What a spiffffing phrase. Time to 
update RFC 2119 ;)

Arnt

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 08 May 2018 06:52:06 +1000

On Mon, 7 May 2018, at 23:23, Arnt Gulbrandsen wrote:
> Normative advice. What a spiffing phrase. What a spiffffing
> phrase. Time to> update RFC 2119 ;)

In my defense, I was tired and typing random words, random words.
spifffff.
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 26 May 2018 22:51:37 +1000

Non smartass version created and uploaded as -02.

I'm going to ask Jiankang to progress this document to Working Group
Last Call.  There's been no substantive feedback on the last couple of
rounds except for this, and it's implemented and working at FastMail now
- we're using MAILBOXID internally.
Bron.

On Mon, May 7, 2018, at 23:07, Arnt Gulbrandsen wrote:
> _________________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

---

From: "Jiankang Yao" <[email-masked]>
Date: Mon, 28 May 2018 15:28:13 +0800

Hello,

   I have read through the document. It is in good state.

   Before WGLC, could you kindly clear or clarify the fllowing issues in
    https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-extra-imap-objectid-02.txt ?
:****************************************************************************
------------------------------------------------------------------
  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  -- The draft header indicates that this document updates RFC3501, but the
     abstract doesn't seem to mention this, which it should.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

     (Using the creation date from RFC3501, updated by this document, for
     RFC5378 checks: 2002-09-15)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Missing Reference: 'UIDVALIDITY 1524195797' is mentioned on line 193,
     but not defined

  == Missing Reference: 'THIS RFC' is mentioned on line 522, but not defined

--------------------------------------------------------------------------------------------
******************************************************************

Best Regards

Jiankang Yao

From: Bron Gondwana
Date: 2018-05-26 20:51
To: extra
Subject: Re: [Extra] Progressing the fcc and objectid documents
Non smartass version created and uploaded as -02.

I'm going to ask Jiankang to progress this document to Working Group Last Call.  There's been no substantive feedback on the last couple of rounds except for this, and it's implemented and working at FastMail now - we're using MAILBOXID internally.

Bron.

Maybe...

seen."

Or not. Your call.

Arnt

_______________________________________________

Extra mailing list

[email-masked]

--

  [email-masked]

---

From: Bron Gondwana <[email-masked]>
Date: Mon, 28 May 2018 18:49:31 +1000

On Mon, May 28, 2018, at 17:28, Jiankang Yao wrote:
>    Before WGLC, could you kindly clear or clarify the fllowing
>    issues in>     https://tools.ietf.org/idnits?url=
>     https://tools.ietf.org/id/draft-ietf-extra-imap-objectid-02.txt ?> :********************************************************************-
> :********> ------------------------------------------------------------------
>   Checking nits according to https://www.ietf.org/id-info/checklist :>   --------------------------------------------------------------------
>   --------> 
>   -- The draft header indicates that this document updates RFC3501,
>   but the>      abstract doesn't seem to mention this, which it should.

Oh yeah, sorry - I missed this one.  Fixed.

> 
>   Miscellaneous warnings:
>   --------------------------------------------------------------------
>   --------> 
>      (Using the creation date from RFC3501, updated by this document,
>      for>      RFC5378 checks: 2002-09-15)
> 
>   -- The document seems to lack a disclaimer for pre-RFC5378 work,
>   but may>      have content which was first submitted before 10 November 2008.
>      If you>      have contacted all the original authors and they are all willing
>      to grant>      the BCP78 rights to the IETF Trust, then this is fine, and you
>      can ignore>      this comment.  If not, you may need to add the pre-RFC5378
>      disclaimer.>      (See the Legal Provisions document at

This document has no pre-November 2008 content in it.  

>   --------------------------------------------------------------------
>   --------> 
>      (See RFCs 3967 and 4897 for information about using normative
>      references>      to lower-maturity documents in RFCs)

I'm not sure what they're talking about here - I guess JMAP?  Everything
else appears to be Proposed Standard or higher.  We have a chicken/egg
problem with JMAP, so I've changed that to an informative reference.
It's only in "future considerations" section.
Yep, it stopped complaining now :)

>   == Missing Reference: 'UIDVALIDITY 1524195797' is mentioned on line
>   == 193,>      but not defined

This looks like a parser issue.  I don't know how to encode this (at
least in the text version) such that the parser doesn't think it's a
reference!
I just removed it entirely, it's not really necessary.

>   == Missing Reference: 'THIS RFC' is mentioned on line 522, but not
>   == defined
I'm not sure how to reference the current document.  I'm trying [[THIS
RFC]] now, which matches how it looks in the text version of the
important draft.  I'm using markdown and mmark to generate this.
Version -03 uploaded :)