Subject: [Extra] AD review of draft-ietf-extra-sieve-mailboxid-03

From: Barry Leiba <[email-masked]>
Date: Fri, 4 Sep 2020 13:23:07 -0400

Here's my AD review of the subject document.  I have some issues to
discuss about the specification, so please read my comments and let's
have the discussion.  I'll set the substrate to "AD Followup".

— Section 1 —

   By extending "fileinto" to reference the immutable mailboxid
   specified by [RFC8474] , sieve rules can continue to target the same
   mailbox, even if it gets renamed.

The sieve rules are not extending fileinto; this document is.

NEW
   By telling "fileinto" to reference the immutable mailboxid
   specified by [RFC8474], using the extension specified herein,
   sieve rules can continue to target the same mailbox even if
   it gets renamed.
END

— Section 3 —

   The server advertises the capability "mailboxid"

How are sieve capabilities advertised?

— Section 4 —

Two things here:

1. I think this is underspecified.  It’s not clear what the behaviour
is when the specified mailboxid does exist, but matches a mailbox with
a different name that what’s specified.  If I say:

   fileinto :mailboxid “12” “xyzzy”

…and there’s a mailbox named “xyzzy” with mailboxid 4, and a mailbox
named “plugh” with mailboxid 12, what happens?  It needs to be
explicitly clear.

2. Did the working group consider not requiring the mailbox name at
all, if the mailboxid is specified?  So I could say:

   fileinto :mailboxid “12”

…and in the example above it would behave as though I’d said:

   fileinto :mailboxid “12” “plugh”

I’m not sure that it ever makes sense to specify both the mailbox name
and the mailboxid.

— Section 4.1 —

This doesn’t make any sense to me, and ties into my item 2 in Secton
4.  If I care about the mailboxid, why would I want that to be
ignored?  The point of mailboxid is to override the name (such as in
the case of renames), and I would think that in the example in Section
4.1, if mailboxid Fnosuch isn’t what I think I’m looking for, I’d want
that to be an error condition, rather than creating a new mailbox, no?

— Section 4.2 —

What’s the use case for prioritising the mailboxid over the special
use?  That also seems an odd choice, given the context of special use
mailboxes.  The combination just seems strange — I would normally
specify *either* the special use of the mailbox *or* the name, but not
both.  Adding mailboxid to that just adds more weirdness.

— Section 14 —
According to the IESG Statement on Normative and Informative
References <https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/>:

   Note 1: Even references that are relevant only for optional
   features must be classified as normative if they meet the
   above conditions for normative references.

I think that makes 5490 and 8579 normative, not informative, as
Sections 4.1 and 4.2 are not understandable without those references.

-- 
Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 4 Sep 2020 18:53:24 +0100

Hi Barry,

Thank you for the comments. Quick reply from a non author:

>     sieve rules can continue to target the same mailbox even if
Yes, sounds reasonable.
> How are sieve capabilities advertised?
The text from the draft you quoted is a bit misleading. Scripts specify 
that they require an extension by listing it in "require". Server can 
advertise supported Sieve extensions through ManageSieve or JMAP Sieve 
extension, but this is outside the scope of this draft.
> named “plugh” with mailboxid 12, what happens?  It needs to be
I thought Section 4 is quite clear that :mailboxid takes precedence if 
there is a mailbox with the correspond id. So in your case it is mailbox 
with name “plugh”.
> I’m not sure that it ever makes sense to specify both the mailbox name

RFC 5228 (basic Sieve) requires mailbox name parameter to be present.

  [snip]

> Sections 4.1 and 4.2 are not understandable without those references.

Well spotted.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 4 Sep 2020 14:51:12 -0400

Thanks for the quick reply, Alexey.

> extension, but this is outside the scope of this draft.

Yes, exactly.  I'm asking that the text be changed, either to not talk
about the capability being advertised or saying just a few more words
to make the situation clearer.

> there is a mailbox with the correspond id. So in your case it is mailbox

I don't think it's clear, and would like to see the text be clearer.
That should be easy to fix.

> RFC 5228 (basic Sieve) requires mailbox name parameter to be present.

Sure, but it could be "" (so, fileinto :mailboxid “12” "").

Alternatively, ":mailboxid" could take no argument, but would instead
change the meaning of the required string from being a mailbox name to
being a mailboxid.  Of course, that would mean you couldn't specify
both name and id on the same command, so that might not work.  What's
the use case for including both?  It still seems to me that one would
want one or the other, but why both?

Barry

---

From: Ken Murchison <[email-masked]>
Date: Fri, 4 Sep 2020 15:08:50 -0400

> want one or the other, but why both?

The behavior of :mailboxid is similar to that of :specialuse. You want 
the name argument because its the fallback mailbox in case no mailbox 
with the given id can be found.

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

---

From: "Bron Gondwana" <[email-masked]>
Date: Mon, 07 Sep 2020 11:01:42 +1000

>    sieve rules can continue to target the same mailbox even if

Fair, I'll do that.

> How are sieve capabilities advertised?

As Ken noted - via MANAGESIEVE or JMAP Sieve, however I will update this to say "the server supports".

> named “plugh” with mailboxid 12, what happens?  It needs to be

I thought it was - but I can try to reword that to be clearer.

> I’m not sure that it ever makes sense to specify both the mailbox name

We definitely discussed this in person, it's so long ago that my memory is kinda fuzzy but we definitely decided that it would be much less complex for implementation to keep the syntax as similar to specialuse as possible.

Yeah... found it.

https://www.ietf.org/archive/id/draft-gondwana-sieve-mailboxid-00.txt did it the way you suggest, and the working group review changed that:

https://mailarchive.ietf.org/arch/msg/extra/nOT5BJJfp_Tkj6V-uK4A6gWK6Qg/

> that to be an error condition, rather than creating a new mailbox, no?

An "error condition" in sieve context means fileinto INBOX, at least with our server.  It has to be a runtime error unless your sieve engine is so tightly integrated that you can reject renames that would create an error, which would the confuse IMAP clients.

I think the having a priority order for lookups and fileinto the first one found is the right approach still.

> both.  Adding mailboxid to that just adds more weirdness.

That's fair - I would be willing to change the order there.  I expect that nobody will do it, but I don't want to forbid it either, and I want to define a fixed order that works the same across servers.

I will write an email to the list about this particular issue, so it doesn't get lost in this.

> Sections 4.1 and 4.2 are not understandable without those references.

Fair - I will make them normative.

Thanks for the review,

Bron.

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