Re: [Last-Call] Genart last call review of draft-ietf-extra-sieve-mailboxid-05

Bron Gondwana <brong@fastmailteam.com> Tue, 01 December 2020 07:58 UTC

Return-Path: <brong@fastmailteam.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A460E3A0936; Mon, 30 Nov 2020 23:58:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=k0C5viqF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nh2Eyc0d
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 vX3qsMbiU6vt; Mon, 30 Nov 2020 23:58:21 -0800 (PST)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68CAD3A0937; Mon, 30 Nov 2020 23:58:21 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 618051291; Tue, 1 Dec 2020 02:58:20 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Tue, 01 Dec 2020 02:58:20 -0500
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=fm1; bh=Lf+0 zLQxsEEFpINtqZMmzT/qDFPkQqxvkCMLf8oyl6Y=; b=k0C5viqFOSxZZpTKDIW2 VmDEPFFfyLju20dmNzlljMKAKjF22ukuccDOyibRv5EhuD3zFEjoiC1hY5g1DJeg 2eDItKbwfkGn0uL9SpQR1KqKsbs24pfVXTlVzld678s1DrYiNOHp+TA4lM74VYpV OVMuwDqgycGOCvA4QubNKHBiS8logMKgldXEH9I20iAf0MDf7I32dE5BpwYM7+BI FtMaNbsQmBeTMp/EqI4tdQ81kx/hXNqCcVyz8MmRw14fzIUzsf3Y0Xzb5dKI6dRO GIJPoQHDI3meCHPpu8YGFmzLe4C6o+4SO31+Sc+0fTPXowyNh69RyQfvCjAeyDqf ew==
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=fm1; bh=Lf+0zL QxsEEFpINtqZMmzT/qDFPkQqxvkCMLf8oyl6Y=; b=nh2Eyc0dV/kV7KQJ8HGd0W RxlJMDBa9M7xRqHLcaXQQ9h/w2CQCQj+o9mLu+zWZ7wfvn57ZVK8nUGm8SkIhqnr 7CSepRXcAc7yLnkBIcQ/H7ODc6aBqbckrjOu5upU9u8ORSVUf8MXvBCaWvRP9OBY 5CrIA0RXKEQDZlqS6YuzNtmx1o2IupiyXtAAAgQa/5Zw/Rt0PW1Dih6mqVbQCEnW SDNh5H1EYlm5f+kgfcdklw40c1+HwwIDDstlNXh0OADtYX9BApnO6fHVhR/kuYVf XYuhn9qhOz1Bee71kEDKhRYs4MmTTx/ENih2bktt50tzZ4YsH0q0kHTVxXpP6kjw ==
X-ME-Sender: <xms:mvfFX0pTtsR-Y6d6T_HEg5YzsguyOgOyMcU2LdTdSbQafYHII3ceTQ> <xme:mvfFX6oOpMwhrKKPljOgGrCEpeu-2gZKPLQ6kWETPTuyoNGAAC9VCwjBs-5Tq1mE2 Md8i1mxZXw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeiuddgudduvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehr ohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtoh hmqeenucggtffrrghtthgvrhhnpeevudfgjedtveetkeffkeekleeiueelkeevheekhfdv fefgfeekffeludffgfeljeenucffohhmrghinhepihgvthhfrdhorhhgpdhnvghvvghrrd gsvgenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegs rhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh
X-ME-Proxy: <xmx:mvfFX5NSH29Mqb5b5vluK4johFs1gOCF4eAszTxSNv_7TQJvCDl4OQ> <xmx:mvfFX76m7VIGFpkK3_mSYc-KJryN2K9Kw8JjGfnCHDhasdfxA3fWXQ> <xmx:mvfFXz53aopEJFxfd1qagHyi0PaaHZSLMmK1kHulGS08PUewd58kPw> <xmx:nPfFXzHuiXLMx-sl1NKTdTS_f60lDOVx42vN3p0UgGPnNhkxd85pQQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3614C180093; Tue, 1 Dec 2020 02:58:18 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3
Mime-Version: 1.0
Message-Id: <04396f38-431b-48e8-8b0f-65e2518d8ed4@dogfood.fastmail.com>
In-Reply-To: <160680275991.19519.15021073145558109806@ietfa.amsl.com>
References: <160680275991.19519.15021073145558109806@ietfa.amsl.com>
Date: Tue, 01 Dec 2020 18:57:58 +1100
From: Bron Gondwana <brong@fastmailteam.com>
To: Pete Resnick <resnick@episteme.net>, gen-art@ietf.org
Cc: extra@ietf.org, draft-ietf-extra-sieve-mailboxid.all@ietf.org, last-call@ietf.org
Content-Type: multipart/alternative; boundary="fce01c17df83433c9ca0054f487211e9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/AtacpgieXjORpeZHLpduJDFtYMM>
Subject: Re: [Last-Call] Genart last call review of draft-ietf-extra-sieve-mailboxid-05
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Dec 2020 07:58:24 -0000

Thanks Pete, fair enough - I can see how a semantically pointless example is a problem.  I'll update that in my copy and wait for any other review changes before uploading again.

And yeah - if the latest mmark is causing artifacts I'll see what I can do about those.  I admit I didn't read through the whole thing in detail again after making the last updates.

Cheers,

Bron

On Tue, Dec 1, 2020, at 17:05, Pete Resnick via Datatracker wrote:
> Reviewer: Pete Resnick
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-extra-sieve-mailboxid-05
> Reviewer: Pete Resnick
> Review Date: 2020-11-30
> IETF LC End Date: 2020-12-02
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Looking good. Just one minor issue and one nit.
> 
> Major issues:
> 
> None.
> 
> Minor issues:
> 
> Section 4 says:
> 
>    If there is no such mailbox, the "fileinto" action proceeds as it
>    would without the ":mailboxid" argument.
> 
> But the in the example in section 6, it shows:
> 
>        if mailboxidexists "F6352ae03-b7f5-463c-896f-d8b48ee3" {
>            fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3"
>                                "INBOX.harassment";
>        } else {
>            fileinto "INBOX.harassment";
>        }
> 
> That appears correct, but as far as I can tell, it is semantically identical to:
> 
>            fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3"
>                                "INBOX.harassment";
> 
> That is, the rule in section 4 means that fileinto already does an implicit
> existence check and only uses the named mailbox if the one specified by the
> mailboxid doesn't exist. It's not that the example is particularly a problem,
> but it did confuse me for a few minutes while I tried to figure out what it was
> trying to do. Perhaps if the example was:
> 
>        if mailboxidexists "F6352ae03-b7f5-463c-896f-d8b48ee3" {
>            fileinto :mailboxid "F6352ae03-b7f5-463c-896f-d8b48ee3"
>                                "this.name.will.never.be.used";
>        } else {
>            fileinto "INBOX.harassment";
>        }
> 
> or an example that did something other than "fileinto" it would have made a bit
> more sense. Certainly not absolutely necessary to fix, but a change might
> improve understanding.
> 
> Nits/editorial comments:
> 
> In sections 4.1 and 4.2, you have references that appear as "[!@RFC5490]" and
> "[!@RFC5879]". I assume that's some sort of markdown or other formatting tool
> mistake.
> 
> 
> 

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