Subject: [Extra] Call for adoption, draft-gondwana-sieve-mailboxid

From: Bron Gondwana <[email-masked]>
Date: Sat, 11 Aug 2018 15:26:55 +1000

As promised, I've written up a way of adding mailboxid support to Sieve.
This draft is absolutely a first pass - I'm interested in feedback.
Particularly the mailboxidexists test is a little clunky.
I'd  like to formally adopt this work into the EXTRA working group, it's
within scope and fits with the other work we've been doing.  I suggest
doing that in 2 weeks (Aug 24th) unless there are objections to taking
on the work.
Cheers,

Bron.

----- Original message -----
From: [email-masked]
To: Bron Gondwana <[email-masked]>
Subject: New Version Notification for draft-gondwana-sieve-mailboxid-00.txtDate: Fri, 10 Aug 2018 22:23:27 -0700

A new version of I-D, draft-gondwana-sieve-mailboxid-00.txt
has been successfully submitted by Bron Gondwana and posted to the
IETF repository.

Name:  draft-gondwana-sieve-mailboxid
Revision: 00
Title:  Sieve Email Filtering: delivery by mailboxid
Document date: 2018-08-11
Group:  Individual Submission
Pages:  6
URL:            https://www.ietf.org/internet-drafts/draft-gondwana-sieve-mailboxid-00.txtStatus:         https://datatracker.ietf.org/doc/draft-gondwana-sieve-mailboxid/Htmlized:       https://tools.ietf.org/html/draft-gondwana-sieve-mailboxid-00Htmlized:       https://datatracker.ietf.org/doc/html/draft-gondwana-sieve-mailboxid

Abstract:
  The OBJECTID capability of the IMAP protocol (I-D.ietf-extra-imap-
  objectid) allows clients to identify mailboxes by a unique identifier  which survives rename.  In contrast, the Sieve mail filtering
  language (RFC 5228) currently has no such capability.  This memo
  defines a Sieve extension that fills this gap: it adds a method for
  specifying the unique identifier of a mailbox as a target for
  fileinto rules, and a method for testing the existence of a mailbox
  by its unique identifier.

Please note that it may take a couple of minutes from the time of
submissionuntil the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

---

From: Ken Murchison <[email-masked]>
Date: Sat, 11 Aug 2018 14:19:10 -0400

This extension can probably interact with :fcc.  Should the interop be 
described in this draft of the :fcc draft?

Additionally, the :mailboxid argument probably doesn't play well with 
:create, or at least I don't see how it could without a mailbox name.

On 08/11/2018 01:26 AM, Bron Gondwana wrote:
> I'd like to formally adopt this work into the EXTRA working group, 
> it's within scope and fits with the other work we've been doing.  I 
> suggest doing that in 2 weeks (Aug 24th) unless there are objections 
> to taking on the work.
>
> Cheers,
>
> Bron.
>
>
> From: [email-masked] <mailto:[email-masked]>
> To: Bron Gondwana <[email-masked] <mailto:[email-masked]>>
> Subject: New Version Notification for 
> draft-gondwana-sieve-mailboxid-00.txt
> Date: Fri, 10 Aug 2018 22:23:27 -0700
>
>
> URL: 
> https://www.ietf.org/internet-drafts/draft-gondwana-sieve-mailboxid-00.txt
> Status: https://datatracker.ietf.org/doc/draft-gondwana-sieve-mailboxid/
> Htmlized: https://tools.ietf.org/html/draft-gondwana-sieve-mailboxid-00
> Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-gondwana-sieve-mailboxid
>
>
> Abstract:
>   objectid) allows clients to identify mailboxes by a unique identifier
>   which survives rename.  In contrast, the Sieve mail filtering
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
> --
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ned Freed <[email-masked]>
Date: Sat, 11 Aug 2018 11:55:48 -0700 (PDT)

> This extension can probably interact with :fcc.

Definitely.

>  Should the interop be

Why not have it build on the :fcc draft instead of creating a dependency
in the other direction?

> :create, or at least I don't see how it could without a mailbox name.

Not sure I see the conflict. Of course you can't create a mailbox
with the specified objectid, but in the fallback case :create would
still be valid.

It just needs to be spelled out in the document.

				Ned

---

From: Ken Murchison <[email-masked]>
Date: Sat, 11 Aug 2018 16:18:53 -0400

> Why not have it build on the :fcc draft instead of creating a dependency

Agreed.

> It just needs to be spelled out in the document.

:create wouldn't have a mailbox name to use if :mailboxid is specified.  
:mailboxid changes the positional parameter in fileinto from a name to 
an id (unless I'm reading it incorrectly).

>> > Status: 
>> https://datatracker.ietf.org/doc/draft-gondwana-sieve-mailboxid/
>> > Htmlized: 
>> https://tools.ietf.org/html/draft-gondwana-sieve-mailboxid-00
>> > Htmlized:

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ned Freed <[email-masked]>
Date: Sat, 11 Aug 2018 15:56:16 -0700 (PDT)

> an id (unless I'm reading it incorrectly).

Missed that, sorry.

I'm not sure I agree with this approach. Why not use the :specialuse
approach instead, where :specialuse takes an argument specifying the
specialuse mailbox and if it doesn't exist then the regular fileinto
argument is used instead.

Wouldn't a similar semantic make sense for objectid in the event
that the folder with the specified objectid is gone?

				Ned

---

From: Bron Gondwana <[email-masked]>
Date: Sun, 12 Aug 2018 10:32:22 +1000

On Sun, Aug 12, 2018, at 08:56, Ned Freed wrote:
>>> Why not have it build on the :fcc draft instead of creating a
>>> dependency>>> in the other direction?
> 
>> Agreed.
> 
> 
> 
>>>> Additionally, the :mailboxid argument probably doesn't play
>>>> well with>>>> :create, or at least I don't see how it could without a mailbox
>>>> name.>>> 
>>> with the specified objectid, but in the fallback case :create would>>> still be valid.
>>> 
>> :create wouldn't have a mailbox name to use if :mailboxid is
>> specified.>> :mailboxid changes the positional parameter in fileinto from a
>> name to>> an id (unless I'm reading it incorrectly).
> 
> Missed that, sorry.
> 

Hrmm... yeah, I guess you could do that with a fallback of INBOX if you
didn't have a different name to specify.
I wasn't sure if that would be too confusing to somebody reading:

fileinto :mailboxid "F213478" "INBOX.Foo";

And then having both INBOX.Foo and a different renamed folder exist.

I do agree that it's more consistent to match the specialuse draft
though - especially by not repurposing the positional parameter.  I'm
happy to update the draft and my implementation.
Bron.

---

From: Bron Gondwana <[email-masked]>
Date: Sun, 12 Aug 2018 21:42:03 +1000

OK - I've posted version -01 which I believe addresses all the
concerns :)
* Switch to :mailboxid tagged parameter value with fallback
  mailbox name.* Document interation with special-use.
* Document security considerations around :mailboxid and :create.

I've also updated our implementation, which was very easy.

(and I forgot to mention - I also documented interaction with :fcc.
I'll add that to my .mdown file now)
Bron.