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

Bron Gondwana <brong@fastmailteam.com> Mon, 07 September 2020 01:02 UTC

Return-Path: <brong@fastmailteam.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAA93A1369; Sun, 6 Sep 2020 18:02:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=04s+XsIv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LKCmlSc+
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36QX4nEqv5zf; Sun, 6 Sep 2020 18:02:05 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4A93A1367; Sun, 6 Sep 2020 18:02:04 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 271025C00A2; Sun, 6 Sep 2020 21:02:04 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Sun, 06 Sep 2020 21:02:04 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm3; bh=PycZ Ql7l1RxDt+UhB22qp3X8i1xJkwruwWwM+ri/KFE=; b=04s+XsIvRq7IohRVCuxV mFLRTIp4Q2bm2qnWl2g0GEMzi1K0b6vEA0CZTrRMi0yOkdnspCqQTc4Wm3Bc/j4A v44+TeLJXYxg/lfH4YGVAp5lKU0wV9deIXF8mHl5thdiQC42ZOoNOV+TacWtiv9y 5G8LEMjG5zG1MMF8MLwsf9NLW3LOa7pDXnT5KlGagUHHMn0lvu+2e0dJaw+NRb7Z VtpQxNf3XkD5xxNJ2uT/WYLD/yw4oVLEbEeZBJh3DL4MDFA/rsqLmMVknPfpPP+T rU0Iso0A6skJZX3svc/BMP4ZpJuSzXHPM3biJ4dwkyr5E+IiC6i7nP95371mTmoF TA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=PycZQl 7l1RxDt+UhB22qp3X8i1xJkwruwWwM+ri/KFE=; b=LKCmlSc++PrTxtWOUpuqqO BM5XcEJP1WnzjPNMROx/TywQWTChIpBVBUv+QyTxJkP+R7UjJsayTtCZui50JC6h STwmC5ohYT540lPegjYt/M6Q1EpdyYbQwKGbPQIQTm5BBxzX5wLyIxLoknhdth5n uB+WMpZlwjZM9WCXEiCi54DaN7SAMTwbC6Wy4Q8i3g26S7iHhr8IwWv1CpdEXaja YGgGnmwcmZhhJJoPgoC9VsBdxtaP3Ne3Xryvy9U3eC24kh17FR95sPVVa5QAJUGh yOJwb4+oAQxhwnxxGSHXgUcreA5z92v4GVpBZ/mptwJi7kjCREZznECbTZ0Af5Pg ==
X-ME-Sender: <xms:i4ZVX8-l2h5lDIqaP_Xs1BiCTUyMLCXdc8BYnz9o5Arld2DBt13K0A> <xme:i4ZVX0uv2jhc5s3-nvTJGlb9a9cR_dl8F92dJxIHirq4gsCLWx0oj-kIrgFDuRIXm VesXfaVR-U>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudegkedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepffdvkeefgeelieeutedttdffheevvefffeekuddvtddt keeigfejuddvhfdvudelnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhm rghilhhtvggrmhdrtghomh
X-ME-Proxy: <xmx:i4ZVXyBdHknfS7b5T4AInMeA2BkuHFeKhiwLth3Cdaasp0nfb3I5zA> <xmx:i4ZVX8fS-0eOlhsyLp0jV8aWNTIra1J2fvujtzdhG0ACoPnDRDvnlA> <xmx:i4ZVXxNNTwO-SIDDrp5cyjbp9R05u8ey8xWgqCBkEm5kwqncQQufdA> <xmx:jIZVXzX-rcaAhgl3opaCTrEXX2wOovxdp1wu1XGK53RQaQNDSDsaWg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 707F4180096; Sun, 6 Sep 2020 21:02:03 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-259-g88fbbfa-fm-20200903.003-g88fbbfa3
Mime-Version: 1.0
Message-Id: <bff22cc7-aa9e-4c4a-ab29-df0dd5e08cce@www.fastmail.com>
In-Reply-To: <CALaySJ+zuKm=eK=KxfyFNecZPXN_F0TxQAERxapmnHNYLdj_hg@mail.gmail.com>
References: <CALaySJ+zuKm=eK=KxfyFNecZPXN_F0TxQAERxapmnHNYLdj_hg@mail.gmail.com>
Date: Mon, 07 Sep 2020 11:01:42 +1000
From: Bron Gondwana <brong@fastmailteam.com>
To: Barry Leiba <barryleiba@computer.org>, draft-ietf-extra-sieve-mailboxid.all@ietf.org
Cc: extra@ietf.org
Content-Type: multipart/alternative; boundary="d6e76896e6ef4e6f8d78536a24bc70a9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/zaZ9f9C3tIIFj7AUcgmj760qNSk>
Subject: Re: [Extra] AD review of draft-ietf-extra-sieve-mailboxid-03
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Sep 2020 01:02:07 -0000


On Sat, Sep 5, 2020, at 03:23, Barry Leiba wrote:
> 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

Fair, I'll do that.

> — Section 3 —
> 
>    The server advertises the capability "mailboxid"
> 
> How are sieve capabilities advertised?

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

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

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

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

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/

> — 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?

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.

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

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.

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

Fair - I will make them normative.

Thanks for the review,

Bron.


--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com