From nobody Fri Oct 2 08:02:00 2020 Return-Path: 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 A22E03A1650; Fri, 2 Oct 2020 08:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 4Y0aUTnI9rii; Fri, 2 Oct 2020 08:01:57 -0700 (PDT) Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A763A164E; Fri, 2 Oct 2020 08:01:57 -0700 (PDT) Received: by mail-ej1-f50.google.com with SMTP id u21so2442745eja.2; Fri, 02 Oct 2020 08:01:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=vkXXlPmFsMUzS6QegAR6IpM65q+QeKYM5OJ8NKSX650=; b=AFzujQG7IM6BTxgza7evyRP/XvdPEsOGOVco7wY3UOxOCOQbslPuFO85wEh62/rg9+ YPykdrqX5vH+qBGQclfelMgJmZqsS9CeMDZz4KllTaWl0ZkPKf+uzF4vRnksmN+MUJYJ Ye+DsXN9KobVRlb6I4huhlv+PRK83B9rfIv8Ml+tJV1n4ZqcC8O8VbyEpdQ0k7FZ4/fK TFbH+jJCqlBmLMMdk3tl8tsPJVAuTedou6N4/tRUESRdaX2oY874E4+245EsI7uErUeH jUIL0M/JEGrXOdkfZLDHIyVkYjrI24ItfFWqbEgGhetT6fMheNhrOW+4uK0Iu01+t3c1 UBqA== X-Gm-Message-State: AOAM533lPI9uMQvBghCY4zGu6+SJKDYYjpgIY1ERvpTvedtVEJWJrbbr bxJ7vLyYjFnQy+M2uyvoZNyoQKoElrwsF2XpIH0= X-Google-Smtp-Source: ABdhPJwVFCbP4ZuulWWOB5gtVQCnsQvqmH+KONRnvyj3m/3ZSS6DUEfK1GfFHXhtSkWLcAE5+nsKgQ6ppCzIg2CQSDo= X-Received: by 2002:a17:906:d97b:: with SMTP id rp27mr2857906ejb.18.1601650915332; Fri, 02 Oct 2020 08:01:55 -0700 (PDT) MIME-Version: 1.0 References: <160085317360.24429.9473480615397529741@ietfa.amsl.com> <1873162322.20797.1600929014863@appsuite.open-xchange.com> In-Reply-To: From: Barry Leiba Date: Fri, 2 Oct 2020 11:01:43 -0400 Message-ID: To: "Rob Wilton (rwilton)" Cc: Michael Slusarz , Arnt Gulbrandsen , "extra@ietf.org" , Bron Gondwana , The IESG , "extra-chairs@ietf.org" , "draft-ietf-extra-imap-fetch-preview@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Extra] [EXT] Re: Robert Wilton's Discuss on draft-ietf-extra-imap-fetch-preview-09: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 15:01:59 -0000 Hi, Rob. Please check version -10, which removes the "and that won't change later" t= ext. Thanks, Barry On Thu, Sep 24, 2020 at 5:09 AM Rob Wilton (rwilton) wr= ote: > > In case it helps reach a quicker resolution, one solution could be to del= ete the clause =E2=80=9Cand that decision won=E2=80=99t change later=E2=80= =9D: > > > > I.e. old: > > > > It is possible that the server has determined that no meaningful > > preview text can be generated for a particular message, and that > > decision won't change later. ... > > > > New: > > It is possible that the server has determined that no meaningful > > preview text can be generated for a particular message. ... > > > > Full paragraph (new): > > It is possible that the server has determined that no meaningful > > preview text can be generated for a particular message. Examples > > of this involve encrypted messages, content types the server does > > not support previews of, and other situations where the server is > > not able to extract information for a preview. In such cases, the > > server MUST return a zero-length string. Clients SHOULD NOT send > > another FETCH for a preview for such messages. (As discussed > > previously, preview data is not immutable so there is chance that at > > some point in the future the server would be able to generate > > meaningful text. However, this scenario is expected to be rare so > > a client should not continually send out requests to try to capture > > this infrequent occurrence.) > > > > Regards, > Rob > > > > > > From: Michael Slusarz > Sent: 24 September 2020 07:30 > To: Arnt Gulbrandsen ; Rob Wilton (rwilton) > Cc: Barry Leiba ; extra@ietf.org; Bron Gondwana = ; The IESG ; extra-chairs@ietf.org; = draft-ietf-extra-imap-fetch-preview@ietf.org > Subject: Re: [EXT] Re: [Extra] Robert Wilton's Discuss on draft-ietf-extr= a-imap-fetch-preview-09: (with DISCUSS and COMMENT) > > > > The case study we are analysing is expected to be rare. > > > > Real world: a server handling large amounts of incoming mail is going to = deal with preview generation at delivery, rather than display. Any delays a= t delivery are not normally apparent to the end user. For a server supporti= ng this extension, preview data will exist in almost every access, so gener= ation issues will be irrelevant purposes of UX. > > > > If a client is worried about the tiny fraction of requests where a previe= w can not be generated by the server, that client can have code to fallback= to attempting to generating the preview itself (I.e. the current behavior = for many clients). The situation of a single email where a preview cannot b= e generated is going to be interpreted by the end user as an exception... A= nd the lack of preview has no bearing on whether an end user can view the f= ull contents of the message. > > > > michael > > On 09/23/2020 2:47 PM Arnt Gulbrandsen wrote: > > > > > > On Wednesday 23 September 2020 22:18:47 CEST, Rob Wilton (rwilton) wrote: > > It states what to do for the case that the server both (i) > > cannot generate the preview AND (ii) this is not a transient > > error. > > IMAP doesn't report transient errors (which is perhaps wrong, but that's > > how it is). The server has no way to report transient errors for the othe= r > > dozen or more FETCH items. Why makes this one different? > > > > IMO, the document shouldn't mention transient errors at all, since they'r= e > > alien to IMAP and orthogonal to this extension. > > > > Arnt From nobody Mon Oct 5 01:54:11 2020 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC333A0E51; Mon, 5 Oct 2020 01:54:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-extra-imap-fetch-preview@ietf.org, extra-chairs@ietf.org, extra@ietf.org, Bron Gondwana , brong@fastmailteam.com X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <160188804962.31479.1235486223674945852@ietfa.amsl.com> Date: Mon, 05 Oct 2020 01:54:09 -0700 Archived-At: Subject: [Extra] Robert Wilton's No Objection on draft-ietf-extra-imap-fetch-preview-10: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 08:54:10 -0000 Robert Wilton has entered the following ballot position for draft-ietf-extra-imap-fetch-preview-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Discuss cleared. One minor comment: This standardized display can reduce user confusion when using multiple clients, as abbreviated message representations in clients will show identical message contents. I didn't really find this reasoning to be compelling, and perhaps it could be removed. In my experience the amount of preview displayed depends on client behaviour or settings (e.g., how much space to allow for previews). Regards, Rob From nobody Mon Oct 5 01:54:42 2020 Return-Path: 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 22B7F3A0E51; Mon, 5 Oct 2020 01:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ScTqr7du; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PRKFo21u 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 5OuhBAC9GT5h; Mon, 5 Oct 2020 01:54:39 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198903A0E5B; Mon, 5 Oct 2020 01:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6524; q=dns/txt; s=iport; t=1601888079; x=1603097679; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xbe4TAYvFpMZUB+F8RlEeUjtqvwMqxvjc8y17Tcnmkw=; b=ScTqr7duY8mrhNULochJFpN2P4UE5C/mIoDksQBxwBMW7DR5g/fjDtQY 8vr8noS32EwcfvKDjZ+ZieixmaNakgQ+iA7R56RauTiNviPZXFnd1qsJ/ 8dxIvoPY/y6y6jxUcjIcQuM4I8ZEXxz8cCrfDK+ImUJCj9jUjT7zBxg9X E=; IronPort-PHdr: =?us-ascii?q?9a23=3ASkWNhBT+JeXgnh1NwYyarDyah9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB92J4PVBk/fKvrqmXnYPst6Ns3EHJZpLUR?= =?us-ascii?q?JNycAbhBcpD8PND0rnZOXrYCo3EIUnNhdl8ni3PFITFJP4YFvf8Xa16CYPBh?= =?us-ascii?q?jlcw1vKbe9Fovblc/i0ee09tXaaBlJgzzoZ7R0IV22oAzdu9NQj5FlL/M6yw?= =?us-ascii?q?DCpT1DfOEFyA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvCQCS3npf/5JdJa1gHgEBCxIMQIM?= =?us-ascii?q?hKSgHgUkvLAqEM4NGA41vmHuBQoERA1ULAQEBDQEBLQIEAQGESgIXgiECJTg?= =?us-ascii?q?TAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEBAQMSEREMAQE3AQsEAgEIEQQBAQE?= =?us-ascii?q?CAh8HAgICMBUICAIEDgUIEwQDhVADLgEDnBwCgTmIYXaBMoMBAQEFhRIYghA?= =?us-ascii?q?JgQ4qgnKDaYY5HRuBQT+BEUOCTT6ECAERAgEIGhWDADOCLZMBPJMCkRIKgme?= =?us-ascii?q?bA4MOigKRYIIvlQ2eHQIEAgQFAg4BAQWBayNncHAVgyRQFwINjh83bgEMgj+?= =?us-ascii?q?KVnQCNQIGAQkBAQMJfIsGB4EuAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,338,1596499200"; d="scan'208";a="554438975" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Oct 2020 08:54:37 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 0958sbGZ004178 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2020 08:54:37 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 5 Oct 2020 03:54:36 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 5 Oct 2020 03:54:36 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 5 Oct 2020 03:54:36 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AllW9UBFtX0OBWl4+7LsBDNLQGqlf5TN8pt+rfTFkBOE1VRm6W5VtMxhymThlJObuRuB+9LExtBD3aTth5JQyE5KsI1IpE5vWXqBH5UWKG+1qJ+sRNuSipryWqbBlMdoKfAThj/CrRJ617GhPfXOJx4PikMKjOoLBUDbvHNHE8dG41rGZqnSIU/3WG9E8FBQqlgrmVJMN3NQotL1wshrWwpSwhvqoKdE/cvs9lpUIcFt9B+KpvlrlepzEXLyXeFiXwzfmxotgg1GzcrbUIQ6v+GxRIZ8EQxLRN0bW0aZfQlO//hcW+In6w1eXq2lbRZg6OV9impmEKHm5JWOC+yPXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xbe4TAYvFpMZUB+F8RlEeUjtqvwMqxvjc8y17Tcnmkw=; b=oGfZLYNmvOUOLJCDUCmMJSFF+IzwBO+2t0KjS7hx2BMkd1R2PucDEBpE3NaHoqQOYvbt1JBwws9OD99ofAFXOcEhPXMQGaRY31RgqVMcrHLiViRSyJVvuh4KN5MRh+A2ivxXpHc/GYgE0QHBT/5rBRfvR0Lpe5FB7Tzp7Dg5NPmXnCwz+F0dOOMIPeUOE7Lhl/OilhBUq7X9wVnYbglYW8Z8Nc3yxKs7PFxZcElWPs/NJ9NKYgF6Ki+2VJ17xFSz0N1NUa5JbvTxdYxr1eM4rXB6aP3ELFv32SHMuBqg5UA58bZSRdrzCDTPCYYDvaF2Pt/UsWT45m5FwHIE0hMzCw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xbe4TAYvFpMZUB+F8RlEeUjtqvwMqxvjc8y17Tcnmkw=; b=PRKFo21uPZQx29eWu141Qzp3bASDiD2SdsnopIY4scOoqh74CAk66jWJcEjMjZv2RtqSu0Lqa1WACYNXITRnfqqBCrRulheKijRjoHqqdi6UU2xONNM0pYKW/twT0uUHFqnxcBUKeIevcQyjgCarPP8Qg7IFCGYapHLhLSw5W9A= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3361.namprd11.prod.outlook.com (2603:10b6:208:6d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.32; Mon, 5 Oct 2020 08:54:34 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3433.043; Mon, 5 Oct 2020 08:54:33 +0000 From: "Rob Wilton (rwilton)" To: Barry Leiba CC: "draft-ietf-extra-imap-fetch-preview@ietf.org" , "extra@ietf.org" , Bron Gondwana , Arnt Gulbrandsen , The IESG , "extra-chairs@ietf.org" , Michael Slusarz Thread-Topic: [EXT] Re: [Extra] Robert Wilton's Discuss on draft-ietf-extra-imap-fetch-preview-09: (with DISCUSS and COMMENT) Thread-Index: AQHWkYurchLaEd0LLEekS3MA3yfp+Kl2Hq4AgAAODKCAAEd9gIAAAYBggAAS5wCAAAVa0IAAJGQAgACi3gCAABvXQIANBbiAgARQVQA= Date: Mon, 5 Oct 2020 08:54:33 +0000 Message-ID: References: <160085317360.24429.9473480615397529741@ietfa.amsl.com> <1873162322.20797.1600929014863@appsuite.open-xchange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eae9cf8a-adec-49d7-66de-08d8690c47e0 x-ms-traffictypediagnostic: BL0PR11MB3361: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: x3UAZXBYrgWr4xmROPerg7jhAyjfZRnZrkeCt3olnx7c4gAb5ucPyBdvNll0q838DViwwWWa6SmgurA4Q5QTyyG4L0/pEsTi+rsDK8NwfjBFeB8QDD1ZxUWTBvEqo8UkXsUxeV7NuXxzKYc190uQegkaqBhPKqmhwyd824re6NBmwQkAFHRX2cqzSw2I86mU2rbDmoFPFYQ+N2Jd4w7YAvKLyY7TJK4OX4gTwT8pA8QDka7thIg19Nkwu9OpmX07CrzNVNZXaIr7DckrDQkigJrTEm3R5vkUnSe/ERRROmtdU3Vis57w4tWUHHQomtuACtcp3C0bsAQdPV1Ar2Jaxg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(39860400002)(346002)(366004)(376002)(6506007)(54906003)(83380400001)(316002)(86362001)(7696005)(478600001)(8676002)(55016002)(9686003)(26005)(53546011)(33656002)(4326008)(186003)(2906002)(76116006)(6916009)(66476007)(66946007)(66556008)(71200400001)(64756008)(8936002)(5660300002)(66446008)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: usBqZZ/umNLTLX3rM2eTAkxojM/Qxy6C0jteFMu7q+ZYm2QDJOUQtFqP54ZmZ2AXBaHjT1zkT3/EXWnoVNqtASizq1zttQl7xCFX9gQrmf6dUwwPvq9JCP1jJKpzfWZkrQW9Jwu3f93X37bU4Go26Ah51+ZYPtWA7aDGQhTYY1L3QJJSBJNqB4+XHkE4OFlxlBvTNjG++5Bvjz6xBWjtHvARQlvUT4kmcM91GywvKXZrwMSkShclw8cTkcwNPIrU1Ki88XH8vptFlVjH3zFv+YHy/vX6VNRiw+kWiuoxOxgJMI6w1/aMdlzufdorEWwUv0IKiz09+a4et6mgaWQfoPUQelpj05MMLXx/bizJYaBLiZ6Gn73egvp201yVltO/yKZ3+kAjfHrzLQ0h60tQoGKRlSqPFdNyiLbjM2xwla+XU18h7fJylr0P//YXm3/Cgl+w6Z/u2sel22H0nYF2Hq26jhuT2dzzz+RIYP22TSLdGGepCHuM4b4ZcyfhUr+aIOtueyxOvt7EXORADzyKAz9kIu2mM2cFN2c3/ku0RWJe6aRn+Ky7Gr74crK1FQ1m+qviA1zVDt8zeeOkkX+ibYZhwrdUrqzUxUx8jGMsLT4l5DIRL9FqgyObNBN1z0rcBsKk2mDL2cxkWk8DtgY4FQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eae9cf8a-adec-49d7-66de-08d8690c47e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2020 08:54:33.7349 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3SD9W6iV4+hIMJh7jEmzZK7X9vF88rI9I4NPFQeQwH7NBz2jjceeeJOSdaNKr7qVunH8hIWsPLmnWZ6ZQfNsNg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3361 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Extra] [EXT] Re: Robert Wilton's Discuss on draft-ietf-extra-imap-fetch-preview-09: (with DISCUSS and COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 08:54:41 -0000 SSd2ZSBjbGVhcmVkIG15IGRpc2N1c3MuDQoNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZS4NCg0KUm9i DQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpZXNnIDxpZXNnLWJv dW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBCYXJyeSBMZWliYQ0KPiBTZW50OiAwMiBPY3Rv YmVyIDIwMjAgMTY6MDINCj4gVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2Nv LmNvbT4NCj4gQ2M6IGRyYWZ0LWlldGYtZXh0cmEtaW1hcC1mZXRjaC1wcmV2aWV3QGlldGYub3Jn OyBleHRyYUBpZXRmLm9yZzsgQnJvbg0KPiBHb25kd2FuYSA8YnJvbmdAZmFzdG1haWx0ZWFtLmNv bT47IEFybnQgR3VsYnJhbmRzZW4NCj4gPGFybnRAZ3VsYnJhbmRzZW4ucHJpdi5ubz47IFRoZSBJ RVNHIDxpZXNnQGlldGYub3JnPjsgZXh0cmEtDQo+IGNoYWlyc0BpZXRmLm9yZzsgTWljaGFlbCBT bHVzYXJ6IDxtaWNoYWVsLnNsdXNhcno9NDBvcGVuLQ0KPiB4Y2hhbmdlLmNvbUBkbWFyYy5pZXRm Lm9yZz4NCj4gU3ViamVjdDogUmU6IFtFWFRdIFJlOiBbRXh0cmFdIFJvYmVydCBXaWx0b24ncyBE aXNjdXNzIG9uIGRyYWZ0LWlldGYtDQo+IGV4dHJhLWltYXAtZmV0Y2gtcHJldmlldy0wOTogKHdp dGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IEhpLCBSb2IuDQo+IFBsZWFzZSBjaGVjayB2 ZXJzaW9uIC0xMCwgd2hpY2ggcmVtb3ZlcyB0aGUgImFuZCB0aGF0IHdvbid0IGNoYW5nZSBsYXRl ciINCj4gdGV4dC4NCj4gDQo+IFRoYW5rcywNCj4gQmFycnkNCj4gDQo+IE9uIFRodSwgU2VwIDI0 LCAyMDIwIGF0IDU6MDkgQU0gUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29t Pg0KPiB3cm90ZToNCj4gPg0KPiA+IEluIGNhc2UgaXQgaGVscHMgcmVhY2ggYSBxdWlja2VyIHJl c29sdXRpb24sIG9uZSBzb2x1dGlvbiBjb3VsZCBiZSB0bw0KPiBkZWxldGUgdGhlIGNsYXVzZSDi gJxhbmQgdGhhdCBkZWNpc2lvbiB3b27igJl0IGNoYW5nZSBsYXRlcuKAnToNCj4gPg0KPiA+DQo+ ID4NCj4gPiBJLmUuIG9sZDoNCj4gPg0KPiA+DQo+ID4NCj4gPiAgICBJdCBpcyBwb3NzaWJsZSB0 aGF0IHRoZSBzZXJ2ZXIgaGFzIGRldGVybWluZWQgdGhhdCBubyBtZWFuaW5nZnVsDQo+ID4NCj4g PiAgICBwcmV2aWV3IHRleHQgY2FuIGJlIGdlbmVyYXRlZCBmb3IgYSBwYXJ0aWN1bGFyIG1lc3Nh Z2UsIGFuZCB0aGF0DQo+ID4NCj4gPiAgICBkZWNpc2lvbiB3b24ndCBjaGFuZ2UgbGF0ZXIuIC4u Lg0KPiA+DQo+ID4NCj4gPg0KPiA+IE5ldzoNCj4gPg0KPiA+ICAgIEl0IGlzIHBvc3NpYmxlIHRo YXQgdGhlIHNlcnZlciBoYXMgZGV0ZXJtaW5lZCB0aGF0IG5vIG1lYW5pbmdmdWwNCj4gPg0KPiA+ ICAgIHByZXZpZXcgdGV4dCBjYW4gYmUgZ2VuZXJhdGVkIGZvciBhIHBhcnRpY3VsYXIgbWVzc2Fn ZS4gLi4uDQo+ID4NCj4gPg0KPiA+DQo+ID4gRnVsbCBwYXJhZ3JhcGggKG5ldyk6DQo+ID4NCj4g PiAgICBJdCBpcyBwb3NzaWJsZSB0aGF0IHRoZSBzZXJ2ZXIgaGFzIGRldGVybWluZWQgdGhhdCBu byBtZWFuaW5nZnVsDQo+ID4NCj4gPiAgICBwcmV2aWV3IHRleHQgY2FuIGJlIGdlbmVyYXRlZCBm b3IgYSBwYXJ0aWN1bGFyIG1lc3NhZ2UuICBFeGFtcGxlcw0KPiA+DQo+ID4gICAgb2YgdGhpcyBp bnZvbHZlIGVuY3J5cHRlZCBtZXNzYWdlcywgY29udGVudCB0eXBlcyB0aGUgc2VydmVyIGRvZXMN Cj4gPg0KPiA+ICAgIG5vdCBzdXBwb3J0IHByZXZpZXdzIG9mLCBhbmQgb3RoZXIgc2l0dWF0aW9u cyB3aGVyZSB0aGUgc2VydmVyIGlzDQo+ID4NCj4gPiAgICBub3QgYWJsZSB0byBleHRyYWN0IGlu Zm9ybWF0aW9uIGZvciBhIHByZXZpZXcuICBJbiBzdWNoIGNhc2VzLCB0aGUNCj4gPg0KPiA+ICAg IHNlcnZlciBNVVNUIHJldHVybiBhIHplcm8tbGVuZ3RoIHN0cmluZy4gIENsaWVudHMgU0hPVUxE IE5PVCBzZW5kDQo+ID4NCj4gPiAgICBhbm90aGVyIEZFVENIIGZvciBhIHByZXZpZXcgZm9yIHN1 Y2ggbWVzc2FnZXMuICAoQXMgZGlzY3Vzc2VkDQo+ID4NCj4gPiAgICBwcmV2aW91c2x5LCBwcmV2 aWV3IGRhdGEgaXMgbm90IGltbXV0YWJsZSBzbyB0aGVyZSBpcyBjaGFuY2UgdGhhdCBhdA0KPiA+ DQo+ID4gICAgc29tZSBwb2ludCBpbiB0aGUgZnV0dXJlIHRoZSBzZXJ2ZXIgd291bGQgYmUgYWJs ZSB0byBnZW5lcmF0ZQ0KPiA+DQo+ID4gICAgbWVhbmluZ2Z1bCB0ZXh0LiAgSG93ZXZlciwgdGhp cyBzY2VuYXJpbyBpcyBleHBlY3RlZCB0byBiZSByYXJlIHNvDQo+ID4NCj4gPiAgICBhIGNsaWVu dCBzaG91bGQgbm90IGNvbnRpbnVhbGx5IHNlbmQgb3V0IHJlcXVlc3RzIHRvIHRyeSB0byBjYXB0 dXJlDQo+ID4NCj4gPiAgICB0aGlzIGluZnJlcXVlbnQgb2NjdXJyZW5jZS4pDQo+ID4NCj4gPg0K PiA+DQo+ID4gUmVnYXJkcywNCj4gPiBSb2INCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4g RnJvbTogTWljaGFlbCBTbHVzYXJ6IDxtaWNoYWVsLnNsdXNhcno9NDBvcGVuLQ0KPiB4Y2hhbmdl LmNvbUBkbWFyYy5pZXRmLm9yZz4NCj4gPiBTZW50OiAyNCBTZXB0ZW1iZXIgMjAyMCAwNzozMA0K PiA+IFRvOiBBcm50IEd1bGJyYW5kc2VuIDxhcm50QGd1bGJyYW5kc2VuLnByaXYubm8+OyBSb2Ig V2lsdG9uIChyd2lsdG9uKQ0KPiA8cndpbHRvbkBjaXNjby5jb20+DQo+ID4gQ2M6IEJhcnJ5IExl aWJhIDxiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz47IGV4dHJhQGlldGYub3JnOyBCcm9uIEdvbmR3 YW5hDQo+IDxicm9uZ0BmYXN0bWFpbHRlYW0uY29tPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+ OyBleHRyYS1jaGFpcnNAaWV0Zi5vcmc7DQo+IGRyYWZ0LWlldGYtZXh0cmEtaW1hcC1mZXRjaC1w cmV2aWV3QGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtFWFRdIFJlOiBbRXh0cmFdIFJvYmVy dCBXaWx0b24ncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtDQo+IGV4dHJhLWltYXAtZmV0Y2gtcHJl dmlldy0wOTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gPg0KPiA+DQo+ID4NCj4gPiBU aGUgY2FzZSBzdHVkeSB3ZSBhcmUgYW5hbHlzaW5nIGlzIGV4cGVjdGVkIHRvIGJlIHJhcmUuDQo+ ID4NCj4gPg0KPiA+DQo+ID4gUmVhbCB3b3JsZDogYSBzZXJ2ZXIgaGFuZGxpbmcgbGFyZ2UgYW1v dW50cyBvZiBpbmNvbWluZyBtYWlsIGlzIGdvaW5nIHRvDQo+IGRlYWwgd2l0aCBwcmV2aWV3IGdl bmVyYXRpb24gYXQgZGVsaXZlcnksIHJhdGhlciB0aGFuIGRpc3BsYXkuIEFueSBkZWxheXMNCj4g YXQgZGVsaXZlcnkgYXJlIG5vdCBub3JtYWxseSBhcHBhcmVudCB0byB0aGUgZW5kIHVzZXIuIEZv ciBhIHNlcnZlcg0KPiBzdXBwb3J0aW5nIHRoaXMgZXh0ZW5zaW9uLCBwcmV2aWV3IGRhdGEgd2ls bCBleGlzdCBpbiBhbG1vc3QgZXZlcnkgYWNjZXNzLA0KPiBzbyBnZW5lcmF0aW9uIGlzc3VlcyB3 aWxsIGJlIGlycmVsZXZhbnQgcHVycG9zZXMgb2YgVVguDQo+ID4NCj4gPg0KPiA+DQo+ID4gSWYg YSBjbGllbnQgaXMgd29ycmllZCBhYm91dCB0aGUgdGlueSBmcmFjdGlvbiBvZiByZXF1ZXN0cyB3 aGVyZSBhDQo+IHByZXZpZXcgY2FuIG5vdCBiZSBnZW5lcmF0ZWQgYnkgdGhlIHNlcnZlciwgdGhh dCBjbGllbnQgY2FuIGhhdmUgY29kZSB0bw0KPiBmYWxsYmFjayB0byBhdHRlbXB0aW5nIHRvIGdl bmVyYXRpbmcgdGhlIHByZXZpZXcgaXRzZWxmIChJLmUuIHRoZSBjdXJyZW50DQo+IGJlaGF2aW9y IGZvciBtYW55IGNsaWVudHMpLiBUaGUgc2l0dWF0aW9uIG9mIGEgc2luZ2xlIGVtYWlsIHdoZXJl IGENCj4gcHJldmlldyBjYW5ub3QgYmUgZ2VuZXJhdGVkIGlzIGdvaW5nIHRvIGJlIGludGVycHJl dGVkIGJ5IHRoZSBlbmQgdXNlciBhcw0KPiBhbiBleGNlcHRpb24uLi4gQW5kIHRoZSBsYWNrIG9m IHByZXZpZXcgaGFzIG5vIGJlYXJpbmcgb24gd2hldGhlciBhbiBlbmQNCj4gdXNlciBjYW4gdmll dyB0aGUgZnVsbCBjb250ZW50cyBvZiB0aGUgbWVzc2FnZS4NCj4gPg0KPiA+DQo+ID4NCj4gPiBt aWNoYWVsDQo+ID4NCj4gPiBPbiAwOS8yMy8yMDIwIDI6NDcgUE0gQXJudCBHdWxicmFuZHNlbiA8 YXJudEBndWxicmFuZHNlbi5wcml2Lm5vPiB3cm90ZToNCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+ DQo+ID4gT24gV2VkbmVzZGF5IDIzIFNlcHRlbWJlciAyMDIwIDIyOjE4OjQ3IENFU1QsIFJvYiBX aWx0b24gKHJ3aWx0b24pDQo+IHdyb3RlOg0KPiA+DQo+ID4gSXQgc3RhdGVzIHdoYXQgdG8gZG8g Zm9yIHRoZSBjYXNlIHRoYXQgdGhlIHNlcnZlciBib3RoIChpKQ0KPiA+DQo+ID4gY2Fubm90IGdl bmVyYXRlIHRoZSBwcmV2aWV3IEFORCAoaWkpIHRoaXMgaXMgbm90IGEgdHJhbnNpZW50DQo+ID4N Cj4gPiBlcnJvci4NCj4gPg0KPiA+IElNQVAgZG9lc24ndCByZXBvcnQgdHJhbnNpZW50IGVycm9y cyAod2hpY2ggaXMgcGVyaGFwcyB3cm9uZywgYnV0IHRoYXQncw0KPiA+DQo+ID4gaG93IGl0IGlz KS4gVGhlIHNlcnZlciBoYXMgbm8gd2F5IHRvIHJlcG9ydCB0cmFuc2llbnQgZXJyb3JzIGZvciB0 aGUNCj4gb3RoZXINCj4gPg0KPiA+IGRvemVuIG9yIG1vcmUgRkVUQ0ggaXRlbXMuIFdoeSBtYWtl cyB0aGlzIG9uZSBkaWZmZXJlbnQ/DQo+ID4NCj4gPg0KPiA+DQo+ID4gSU1PLCB0aGUgZG9jdW1l bnQgc2hvdWxkbid0IG1lbnRpb24gdHJhbnNpZW50IGVycm9ycyBhdCBhbGwsIHNpbmNlDQo+IHRo ZXkncmUNCj4gPg0KPiA+IGFsaWVuIHRvIElNQVAgYW5kIG9ydGhvZ29uYWwgdG8gdGhpcyBleHRl bnNpb24uDQo+ID4NCj4gPg0KPiA+DQo+ID4gQXJudA0KDQo= From nobody Mon Oct 5 23:00:49 2020 Return-Path: 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 9E6EC3A0E62; Mon, 5 Oct 2020 23:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 T9oRO_3wG70D; Mon, 5 Oct 2020 23:00:41 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9623A045E; Mon, 5 Oct 2020 23:00:40 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09660XIH027868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 6 Oct 2020 02:00:36 -0400 Date: Mon, 5 Oct 2020 23:00:33 -0700 From: Benjamin Kaduk To: Michael Slusarz Cc: draft-ietf-extra-imap-fetch-preview@ietf.org, extra@ietf.org, Benjamin Kaduk via Datatracker , The IESG , extra-chairs@ietf.org, Bron Gondwana Message-ID: <20201006060033.GI89563@kduck.mit.edu> References: <160080490190.9778.18063295243922914906@ietfa.amsl.com> <954798175.17578.1600838053373@appsuite.open-xchange.com> <20200925000653.GK89563@kduck.mit.edu> <1912951289.2653.1601526787409@appsuite.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1912951289.2653.1601526787409@appsuite.open-xchange.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Extra] [EXT] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-fetch-preview-09: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 06:00:43 -0000 Hi Michael, On Wed, Sep 30, 2020 at 10:33:07PM -0600, Michael Slusarz wrote: > > On 09/24/2020 6:06 PM Benjamin Kaduk wrote: > > > > On Tue, Sep 22, 2020 at 11:14:13PM -0600, Michael Slusarz wrote: > > > > On 09/22/2020 2:01 PM Benjamin Kaduk via Datatracker wrote: > > > > > > > > results are stored on the server after generation. Servers MAY limit > > > > the resources that preview generation uses. In order to mitigate > > > > > > > > Would this result in the server generating empty-string previews for > > > > some messages that it would otherwise have produced a non-empty preview > > > > for? I'd like to see a little more description of expected server > > > > behavior in the case of excessive resource usage for preview generation. > > > > > > For historical context: this is the exact issue that was discussed and addressed in the last draft (-09). Previously, we would have allow a NIL response in this case that could have been returned in this situation. However, we decided instead that a non-LAZY request must always return some sort of determinative response. > > > > > > Preview data is "nice-to-have" info, as opposed to "must have" information like the actual message bodies. As such, I feel it needs to be left up to the server to decide in extreme cases that it would rather provide no preview, which is an annoyance, than causing access to the mail data to be affected, which is a critical problem. > > > > > > It may not be preview generation that is *causing* the excessive resource usage. It could be the system is overloaded in general due to other problems. The server is best positioned to determine which ancillary activities it may have to curtail in order to provide the basic mail access, and it is reasonable to predict that preview generation may be one of those activities. > > > > > > As to what the expected server behavior should be? I think that's dependent on the reasons behind the excessive resource usage. The document defines a server's options: send nothing or send something less than a perfect preview. The server should make the decision based on the information available to it; I don't think it's the job of this document to demand a specific kind of response. > > > > I agree: we should not demand particular behavior. I was wondering if we > > wanted to give an example of server behavior without mandating it, e.g., > > "such resource limitations might, for example, cause a server to return a > > preview that is the empty string for a message that otherwise would have > > had a nonempty preview". > > I've come around to agreeing that there is little confusion if we can provide example behavior. > > New text (split into 2 paragraphs): > > Implementation of this extension might enable denial-of-service > attacks against server resources, due to excessive memory or CPU usage > during preview generation or increased storage usage if preview results > are stored on the server after generation. In order to mitigate such > attacks, servers SHOULD log the client authentication identity on FETCH > PREVIEW operations in order to facilitate tracking of abusive > clients. > > Servers MAY limit the resources that preview generation uses. Such > resource limitations might, in an extreme example, cause a server to > return a preview that is the empty string for a message that otherwise > would have had a non-empty preview. However, it is recommended that at > least some preview text be provided in this situation, even if the > quality of the preview is degraded. Thanks; this looks quite good to me. -Ben From nobody Wed Oct 7 09:42:47 2020 Return-Path: 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 B1DA23A0ADA; Wed, 7 Oct 2020 09:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=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=open-xchange.com 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 ThfOS1cynwO9; Wed, 7 Oct 2020 09:42:40 -0700 (PDT) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064563A08BD; Wed, 7 Oct 2020 09:42:39 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 5E4B56A275; Wed, 7 Oct 2020 18:42:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1602088957; bh=SWmsTbP3QSvIU817do5zpfD4vtobUS8de3L+MW/tC0Y=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=WYrZb+Q/eSdnAuD9C6rSrS9SdOAEu9nHXi29Qqogxv7HcATr/kPu9eT/nqTCRxu43 YlSg3ZCrqDTdGl+8GzWVUl68NScqHou3pBfrTZL74ts5Dqn79h3JKqq/FSBwfHHjWl KZJeVIrLHutm4f2oNq/H0IDdN+J/qEeTudrT8aU5pKAB37WeT/V3BV5bG6kjeb6JsE Z0tOA3wkhQi0PFCU2euaUaeSVISeswubJdFpoqO1rKJGnz+KVON1DipH55J/WUEkV8 CwkUF92KTopMuR6hKsc2uLsT5Na1rBeVb7P4oB7Me1lUO7ZKxcV27o5s8mhgHYW/b7 mLumSZ3BwCr5w== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 4F11F3C0116; Wed, 7 Oct 2020 18:42:37 +0200 (CEST) Date: Wed, 7 Oct 2020 10:42:37 -0600 (MDT) From: Michael Slusarz To: Robert Wilton , Robert Wilton via Datatracker , The IESG Cc: draft-ietf-extra-imap-fetch-preview@ietf.org, extra-chairs@ietf.org, extra@ietf.org, Bron Gondwana Message-ID: <1353023108.13757.1602088957209@appsuite.open-xchange.com> In-Reply-To: <160188804962.31479.1235486223674945852@ietfa.amsl.com> References: <160188804962.31479.1235486223674945852@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.4-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [Extra] [EXT] Robert Wilton's No Objection on draft-ietf-extra-imap-fetch-preview-10: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 16:42:42 -0000 > On 10/05/2020 2:54 AM Robert Wilton via Datatracker wrote: > > One minor comment: > > This standardized display can reduce user confusion when using > multiple clients, as abbreviated message representations in clients > will show identical message contents. > > I didn't really find this reasoning to be compelling, and perhaps it could be > removed. In my experience the amount of preview displayed depends on client > behaviour or settings (e.g., how much space to allow for previews). Hypothetical: a message with two alternative parts - text and HTML. The text part is a "your client doesn't support HTML message" placeholder, the HTML part is the "real" data. One client may try to create a preview out of the most feature-rich alternative (HTML); another will create a preview out of the first sequential text part it finds. Another example would be competency in HTML -> plaintext parsing. I will agree that user confusion is not a major issue if preview display differs based on UI concerns: Are the first 40 characters displayed or the first 100 characters? However, if the content is vastly different then I do think there is chances for confusion, especially for users that use previews as a way to contextually scan their mailboxes. "Consistent previews across clients" was a product ask when this feature was first being developed. Is it the most important feature? Maybe not. But it seems important enough to justify a mention since it does clean up, at best, a minor annoyance and, at worst, a real source of confusion that end-users have complained about in the past. michael From nobody Wed Oct 7 12:08:02 2020 Return-Path: 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 ECBCE3A1313; Wed, 7 Oct 2020 12:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 xa8Xy4FwI8rg; Wed, 7 Oct 2020 12:07:57 -0700 (PDT) Received: from mail-vk1-f194.google.com (mail-vk1-f194.google.com [209.85.221.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6860A3A1311; Wed, 7 Oct 2020 12:07:57 -0700 (PDT) Received: by mail-vk1-f194.google.com with SMTP id e5so784323vkm.2; Wed, 07 Oct 2020 12:07:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4bI9zlY+9Sqo+uKVtY+HEahGKoNBeQX9DTQhoGTCutg=; b=ILhKuqTPbOdH9EaU3s0/tm+k0d9UbEu11dy13JbIMfDRoDniSJaq4vbwAZbXiceBJQ m+XkMFvV2F83AV2HZ9wooYE0GKOo8IMqsWvI/+eyiNe9xeOs6CobZE9MTmCWjUjfR9oB T629xXSmyCR1FZFDoeLAxafWhFDrIkXWtnlOt5yih67XnfUmDsdgoFhFSeEhzu5BETRV upQOFdVj//sjQlCs5FjS42HorI7FBsP9rxI9QqtGfbNvRGnGJ+kZlU/YvxRzbuXasSI3 sPDLfhUmE8xq65zEdAycrqWdeEJ4n2/EYxS2uFSz1/QXEW4EII98UlYTUl6fqf2H9VCV Bo6g== X-Gm-Message-State: AOAM532bPmmXcS1M2RRblrP4OYDSVabac81oeKbIAaoQPWzSrwZ2zqIq nJe+KC3pflgcPSmpRM7YCL4dAmKdch8G++MJGD4= X-Google-Smtp-Source: ABdhPJwqowCMVV7EoUv6rzEgqS0s0dXtT0p0soOqc7f3hkB/1/iqbuQY4m6gqlDJU0ZRjFLu5I+4VuAbfbE/q8yQ2Yc= X-Received: by 2002:a1f:1f0d:: with SMTP id f13mr2782150vkf.1.1602097676215; Wed, 07 Oct 2020 12:07:56 -0700 (PDT) MIME-Version: 1.0 References: <160188804962.31479.1235486223674945852@ietfa.amsl.com> <1353023108.13757.1602088957209@appsuite.open-xchange.com> In-Reply-To: <1353023108.13757.1602088957209@appsuite.open-xchange.com> From: Barry Leiba Date: Wed, 7 Oct 2020 15:07:44 -0400 Message-ID: To: Michael Slusarz Cc: Robert Wilton , Robert Wilton via Datatracker , The IESG , extra@ietf.org, Bron Gondwana , extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Extra] [EXT] Robert Wilton's No Objection on draft-ietf-extra-imap-fetch-preview-10: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 19:07:59 -0000 I had suggested wording for this; did you see it? Michael? Rob? Barry On Wed, Oct 7, 2020 at 12:43 PM Michael Slusarz wrote: > > > On 10/05/2020 2:54 AM Robert Wilton via Datatracker = wrote: > > > > One minor comment: > > > > This standardized display can reduce user confusion when using > > multiple clients, as abbreviated message representations in clients > > will show identical message contents. > > > > I didn't really find this reasoning to be compelling, and perhaps it co= uld be > > removed. In my experience the amount of preview displayed depends on c= lient > > behaviour or settings (e.g., how much space to allow for previews). > > Hypothetical: a message with two alternative parts - text and HTML. The = text part is a "your client doesn't support HTML message" placeholder, the = HTML part is the "real" data. One client may try to create a preview out o= f the most feature-rich alternative (HTML); another will create a preview o= ut of the first sequential text part it finds. Another example would be co= mpetency in HTML -> plaintext parsing. > > I will agree that user confusion is not a major issue if preview display = differs based on UI concerns: Are the first 40 characters displayed or the = first 100 characters? However, if the content is vastly different then I d= o think there is chances for confusion, especially for users that use previ= ews as a way to contextually scan their mailboxes. > > "Consistent previews across clients" was a product ask when this feature = was first being developed. Is it the most important feature? Maybe not. = But it seems important enough to justify a mention since it does clean up, = at best, a minor annoyance and, at worst, a real source of confusion that e= nd-users have complained about in the past. > > michael > From nobody Thu Oct 8 01:54:19 2020 Return-Path: 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 49B4D3A0F01; Thu, 8 Oct 2020 01:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=RRRIRytH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FCGN5NsD 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 8sexTLxiXozB; Thu, 8 Oct 2020 01:54:15 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD693A0EFD; Thu, 8 Oct 2020 01:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4168; q=dns/txt; s=iport; t=1602147255; x=1603356855; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YM5bm6ubNuA78QghlDSdIExUCJkMbUp/6POTVrvIy20=; b=RRRIRytHg/REtFjg62yeDqIU8GemLEoNU/OEnDyrFWAgJyhBX/v3m5dh TrvA07C34mifvBSkMgbtstWZtqGkJlmlshA9GtYJOb/NxRWAEbS/d2nUG 79BgS73B/pNPirl0STr30irOvVzPJTH2Ps+sOdSENrqxuoGS29T+cqoWq k=; IronPort-PHdr: =?us-ascii?q?9a23=3A9QrUxhKaHYMPqQkZltmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGv60/h1jMRZjH5ugCjPDZ4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS835YkXPvnCoqzkIFU?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AAA/035f/5NdJa1gHQEBAQEJARI?= =?us-ascii?q?BBQUBQIE9BgELAYFRUQeBSS8sCoQzg0YDjXWYe4EuFIERA1ULAQEBDQEBLQI?= =?us-ascii?q?EAQGESgIXgXICJTYHDgIDAQELAQEFAQEBAgEGBG2FLwcmDIVyAQEBAQIBEhE?= =?us-ascii?q?EDQwBATcBBAcEAgEIEQQBAQECAiYCAgIwFQgIAgQOBQgahVADDiABA516AoE?= =?us-ascii?q?5iGF2fzODAQEBBYUkGIIQCYEOKgGCcYNrhlYbgUE/gRFDgU9+PoJcBIFDAho?= =?us-ascii?q?VgwAzgi2TBzykGQqCaJVghSmhLZMaoBsCBAIEBQIOAQEFgVsJKoFXcBWDJFA?= =?us-ascii?q?XAg2DJop5DBcUgzqKVnQCATQCBgoBAQMJfIw7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,350,1596499200"; d="scan'208";a="591841262" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Oct 2020 08:54:13 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0988sAc6028751 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Oct 2020 08:54:10 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 03:54:10 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 03:54:09 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 8 Oct 2020 03:54:09 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M2Xl4AobOSd+q7TaNc84y8wvK6wtXwpQz6J9dXhFJoJIB/0k5GuJWttcQlDGKnTfradW/FiHJJzY5lfdMqdYor+gT3sXKZ3sL/i+mHj3uaT+TTAfO0N8esUZEcapZhxJ+pLLvTEKu7pVPe+VSQRj8NUz+z7DPGjdTvv87MO9mxvqZoqHOs0HUIT0dBE/yJju+2TkSsjl88PYkdKBDCji264wtPB/z849nbqwS421AHF+8HvQsgTKnku3n+74N11AEyhRQIDpPx01QZxzo4NtPdfQxLitBuUlOY501JsAu+iOlLNNWCphfgKtNmVCVCrOCCp4yOVbWMQJxyiDHn6tYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YM5bm6ubNuA78QghlDSdIExUCJkMbUp/6POTVrvIy20=; b=XH3DOUy/WB/Y/TPM0hf9d2RiG79aQZYExrLEKximHCvl/NU85xv0B82MTcJ9YZDikOmC79ig44k2dlFpkOoDnwGcyixK8fMqyvJ8+Om+Y3ynuGbWPk//vCILElH6aQsG6XuewUTVoJPklsen9PKW7n64mrexlZYoi6GeqWPHb9skRNLfSAbOI2eOe0mQhyViyErBh4dmgs+rTtZxwOnLCp4HjXlgcGBfcaog04S7SaQy/Z4+UJkxxjDkpuX0TZBS9MKVUQEoMN5/+xugidRR+FV8IybKTxAVgoY6PVg37ySKYZtqVbdyfrW+PQBecUDy7CoB+r5b2gJfA8Vpp65hFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YM5bm6ubNuA78QghlDSdIExUCJkMbUp/6POTVrvIy20=; b=FCGN5NsDnZQVaZxYlm5PytPLLgiv0cQtlhlaYkPabD9X/rv74UEzRihBfekZvxw0V8mq0pBpKP/Kl+V7bbl83hiBcTJs8CRKrpqxzPnSHdwiz2R4bSA3+uIpd2zc273Dwo5odmYkuI34QzvLhHlIAHJXoszJuUHKDIMMCMcLfOw= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4568.namprd11.prod.outlook.com (2603:10b6:208:266::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.32; Thu, 8 Oct 2020 08:54:08 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3433.045; Thu, 8 Oct 2020 08:54:08 +0000 From: "Rob Wilton (rwilton)" To: Barry Leiba , Michael Slusarz CC: Robert Wilton via Datatracker , The IESG , "extra@ietf.org" , Bron Gondwana , "extra-chairs@ietf.org" , "draft-ietf-extra-imap-fetch-preview@ietf.org" Thread-Topic: [EXT] Robert Wilton's No Objection on draft-ietf-extra-imap-fetch-preview-10: (with COMMENT) Thread-Index: AQHWmvUhTXgrwTML50W6XBdrTIWRkqmMW8+AgAAojACAAOZSEA== Date: Thu, 8 Oct 2020 08:54:08 +0000 Message-ID: References: <160188804962.31479.1235486223674945852@ietfa.amsl.com> <1353023108.13757.1602088957209@appsuite.open-xchange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5d7ee368-e314-498d-170d-08d86b67b7e1 x-ms-traffictypediagnostic: MN2PR11MB4568: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vYOJbcT3J4z8iCBAEYb68jKaD5K8LhpyqLAGwmNY2YdKTUmSNVKE1KSOFwwweuZx1NXLLnbX2i0iKbMDz3OocLcLYzAa9MFGcubiHp9HTEprQK6PBwrImz1PHOIHr6c+7AiSDVD2o/3mYCMFaUlNBC8BmsOLo6GFRW3uYKt67p7Nsvbj14hNJmV9xtOa3w8JpjQMrFjhsvG/SZYkCoqZQmoRXyZO9sFOmY10iYBdks8KTzGhgPCvDEwKdMt16U7Mg62JZ0aPb8RNXNAyvFaIJWzFRvgyHyzXnrqqZFrwioF5bn0Su8/sDr3uMVzdxlnvpMi0zPJ9uI2rjv6NmXrW7Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(376002)(396003)(346002)(366004)(136003)(2906002)(316002)(4326008)(478600001)(54906003)(110136005)(9686003)(8936002)(6506007)(53546011)(7696005)(55016002)(8676002)(186003)(86362001)(52536014)(26005)(5660300002)(33656002)(66946007)(66446008)(64756008)(66476007)(66556008)(71200400001)(83380400001)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: DDypG3n+OlXUAulZcXOZ5Riti5OXpk0M1h19qNfOGi/MhxXPm7EkaLxPIghWwOG5nCXkEkTug6m1tjTzonkT0VBnENCNs/mscJWIqrWt9ilIUcAQ5ktmEwhj2EQsI+cENngjm70fF0NgaqsL0GdbSeGo8jCs5lz2JG+e9ypq4sQ/g0zWkMGJiV1s8Gfb++zCfE2vnPz/54LYzwO2iu3W6kEZ9P0GWr030TmcjvUSY6HwzMqtlPqSFfAjq4mPlZrhx68ricRQcMXH/S+GuOTje7K9XFjNPKrSfeGy95nv/v3nMnvE+k//848UT4Eqp2phv1nM8JDqJ7DFuMVSSDNEj+GPZ6gk9a61ERXXBXzVurZ6xgOoJ5dEgSS89A0hbNpIMbcs0CwklR7R1Ce5tsfhfU2p5tLR1NdfXCIeIxYhO8n9Xhcovzc4RuRSwCUP8mMz7W3qjs9buUtyHztxllYUUPRXMfuBgZHPrunYxiTP8dRbAQuCPOi3CHbJ5imLEj+AV3G2BYwMHvn3gSxdxhuu+30gB6KoYTgKsYJk0xwecp2+7P7y9aB7vWCH/Au9KFgXPnjlo8BNGaeVV13IJ3fdyAJVxet2W1OmN6biFeyxmTaS3mo29JO9aKPSs5NHnmdFQXUmqoQMUGjoTsz2uwgCaw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5d7ee368-e314-498d-170d-08d86b67b7e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2020 08:54:08.2841 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eRzMZUduLZLkRXZ154KMB779Th5rAiebWwi7/v+5HLHJPAj29g5WdDVzclvV44Akh3mX0JKTzBUtJ/CB1MB1Gw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4568 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Extra] [EXT] Robert Wilton's No Objection on draft-ietf-extra-imap-fetch-preview-10: (with COMMENT) X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 08:54:17 -0000 VGhhdCBpcyBqdXN0IGEgc3RhbGUgY29tbWVudCBpbiB0aGUgZGF0YXRyYWNrZXIgZnJvbSBteSBw cmV2aW91cyBiYWxsb3QgcmV2aWV3Lg0KDQpZZXMsIEkgaGFkIGFscmVhZHkgYWdyZWVkIHdpdGgg dGhlIHRleHQgdGhhdCBCYXJyeSBwcmV2aW91cyBzdWdnZXN0ZWQuICBSZXByb2R1Y2VkIGhlcmUg Zm9yIGNsYXJpdHk6DQoNCj4gT24gdGhpbmtpbmcgYWJvdXQgcmUtcGhyYXNpbmcsIGhvdyBkb2Vz IHRoaXMgc291bmQ/Og0KPiANCj4gTkVXDQo+IFdoaWxlIGRpZmZlcmVudCBjbGllbnRzIG1pZ2h0 IGdlbmVyYXRlIHF1aXRlIGRpZmZlcmVudCBwcmV2aWV3IHRleHQsDQo+IGhhdmluZyBjb21tb24g cHJldmlldyB0ZXh0IGdlbmVyYXRlZCBieSB0aGUgc2VydmVyIGNhbiBnaXZlIGEgbW9yZQ0KPiBj b25zaXN0ZW50IHVzZXIgZXhwZXJpZW5jZSB0byB0aG9zZSB3aG8gdXNlIG11bHRpcGxlIGNsaWVu dHMuDQo+IEVORA0KPiANCj4gQmFycnkNCg0KUmVnYXJkcywNClJvYg0KDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCYXJyeSBMZWliYSA8YmFycnlsZWliYUBjb21w dXRlci5vcmc+DQo+IFNlbnQ6IDA3IE9jdG9iZXIgMjAyMCAyMDowOA0KPiBUbzogTWljaGFlbCBT bHVzYXJ6IDxtaWNoYWVsLnNsdXNhcno9NDBvcGVuLXhjaGFuZ2UuY29tQGRtYXJjLmlldGYub3Jn Pg0KPiBDYzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPjsgUm9iZXJ0 IFdpbHRvbiB2aWENCj4gRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+OyBUaGUgSUVTRyA8 aWVzZ0BpZXRmLm9yZz47IGV4dHJhQGlldGYub3JnOw0KPiBCcm9uIEdvbmR3YW5hIDxicm9uZ0Bm YXN0bWFpbHRlYW0uY29tPjsgZXh0cmEtY2hhaXJzQGlldGYub3JnOyBkcmFmdC1pZXRmLQ0KPiBl eHRyYS1pbWFwLWZldGNoLXByZXZpZXdAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtFWFRdIFJv YmVydCBXaWx0b24ncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1leHRyYS1pbWFwLQ0KPiBm ZXRjaC1wcmV2aWV3LTEwOiAod2l0aCBDT01NRU5UKQ0KPiANCj4gSSBoYWQgc3VnZ2VzdGVkIHdv cmRpbmcgZm9yIHRoaXM7IGRpZCB5b3Ugc2VlIGl0PyAgTWljaGFlbD8gIFJvYj8NCj4gDQo+IEJh cnJ5DQo+IA0KPiBPbiBXZWQsIE9jdCA3LCAyMDIwIGF0IDEyOjQzIFBNIE1pY2hhZWwgU2x1c2Fy eg0KPiA8bWljaGFlbC5zbHVzYXJ6PTQwb3Blbi14Y2hhbmdlLmNvbUBkbWFyYy5pZXRmLm9yZz4g d3JvdGU6DQo+ID4NCj4gPiA+IE9uIDEwLzA1LzIwMjAgMjo1NCBBTSBSb2JlcnQgV2lsdG9uIHZp YSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4NCj4gd3JvdGU6DQo+ID4gPg0KPiA+ID4g T25lIG1pbm9yIGNvbW1lbnQ6DQo+ID4gPg0KPiA+ID4gICAgVGhpcyBzdGFuZGFyZGl6ZWQgZGlz cGxheSBjYW4gcmVkdWNlIHVzZXIgY29uZnVzaW9uIHdoZW4gdXNpbmcNCj4gPiA+ICAgIG11bHRp cGxlIGNsaWVudHMsIGFzIGFiYnJldmlhdGVkIG1lc3NhZ2UgcmVwcmVzZW50YXRpb25zIGluIGNs aWVudHMNCj4gPiA+ICAgIHdpbGwgc2hvdyBpZGVudGljYWwgbWVzc2FnZSBjb250ZW50cy4NCj4g PiA+DQo+ID4gPiBJIGRpZG4ndCByZWFsbHkgZmluZCB0aGlzIHJlYXNvbmluZyB0byBiZSBjb21w ZWxsaW5nLCBhbmQgcGVyaGFwcyBpdA0KPiBjb3VsZCBiZQ0KPiA+ID4gcmVtb3ZlZC4gIEluIG15 IGV4cGVyaWVuY2UgdGhlIGFtb3VudCBvZiBwcmV2aWV3IGRpc3BsYXllZCBkZXBlbmRzIG9uDQo+ IGNsaWVudA0KPiA+ID4gYmVoYXZpb3VyIG9yIHNldHRpbmdzIChlLmcuLCBob3cgbXVjaCBzcGFj ZSB0byBhbGxvdyBmb3IgcHJldmlld3MpLg0KPiA+DQo+ID4gSHlwb3RoZXRpY2FsOiBhIG1lc3Nh Z2Ugd2l0aCB0d28gYWx0ZXJuYXRpdmUgcGFydHMgLSB0ZXh0IGFuZCBIVE1MLiAgVGhlDQo+IHRl eHQgcGFydCBpcyBhICJ5b3VyIGNsaWVudCBkb2Vzbid0IHN1cHBvcnQgSFRNTCBtZXNzYWdlIiBw bGFjZWhvbGRlciwgdGhlDQo+IEhUTUwgcGFydCBpcyB0aGUgInJlYWwiIGRhdGEuICBPbmUgY2xp ZW50IG1heSB0cnkgdG8gY3JlYXRlIGEgcHJldmlldyBvdXQNCj4gb2YgdGhlIG1vc3QgZmVhdHVy ZS1yaWNoIGFsdGVybmF0aXZlIChIVE1MKTsgYW5vdGhlciB3aWxsIGNyZWF0ZSBhIHByZXZpZXcN Cj4gb3V0IG9mIHRoZSBmaXJzdCBzZXF1ZW50aWFsIHRleHQgcGFydCBpdCBmaW5kcy4gIEFub3Ro ZXIgZXhhbXBsZSB3b3VsZCBiZQ0KPiBjb21wZXRlbmN5IGluIEhUTUwgLT4gcGxhaW50ZXh0IHBh cnNpbmcuDQo+ID4NCj4gPiBJIHdpbGwgYWdyZWUgdGhhdCB1c2VyIGNvbmZ1c2lvbiBpcyBub3Qg YSBtYWpvciBpc3N1ZSBpZiBwcmV2aWV3IGRpc3BsYXkNCj4gZGlmZmVycyBiYXNlZCBvbiBVSSBj b25jZXJuczogQXJlIHRoZSBmaXJzdCA0MCBjaGFyYWN0ZXJzIGRpc3BsYXllZCBvciB0aGUNCj4g Zmlyc3QgMTAwIGNoYXJhY3RlcnM/ICBIb3dldmVyLCBpZiB0aGUgY29udGVudCBpcyB2YXN0bHkg ZGlmZmVyZW50IHRoZW4gSQ0KPiBkbyB0aGluayB0aGVyZSBpcyBjaGFuY2VzIGZvciBjb25mdXNp b24sIGVzcGVjaWFsbHkgZm9yIHVzZXJzIHRoYXQgdXNlDQo+IHByZXZpZXdzIGFzIGEgd2F5IHRv IGNvbnRleHR1YWxseSBzY2FuIHRoZWlyIG1haWxib3hlcy4NCj4gPg0KPiA+ICJDb25zaXN0ZW50 IHByZXZpZXdzIGFjcm9zcyBjbGllbnRzIiB3YXMgYSBwcm9kdWN0IGFzayB3aGVuIHRoaXMgZmVh dHVyZQ0KPiB3YXMgZmlyc3QgYmVpbmcgZGV2ZWxvcGVkLiAgSXMgaXQgdGhlIG1vc3QgaW1wb3J0 YW50IGZlYXR1cmU/ICBNYXliZSBub3QuDQo+IEJ1dCBpdCBzZWVtcyBpbXBvcnRhbnQgZW5vdWdo IHRvIGp1c3RpZnkgYSBtZW50aW9uIHNpbmNlIGl0IGRvZXMgY2xlYW4gdXAsDQo+IGF0IGJlc3Qs IGEgbWlub3IgYW5ub3lhbmNlIGFuZCwgYXQgd29yc3QsIGEgcmVhbCBzb3VyY2Ugb2YgY29uZnVz aW9uIHRoYXQNCj4gZW5kLXVzZXJzIGhhdmUgY29tcGxhaW5lZCBhYm91dCBpbiB0aGUgcGFzdC4N Cj4gPg0KPiA+IG1pY2hhZWwNCj4gPg0K From nobody Tue Oct 13 04:44:08 2020 Return-Path: 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 DEC323A0F43 for ; Tue, 13 Oct 2020 04:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 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, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 e8k8AHrO1GSm for ; Tue, 13 Oct 2020 04:44:04 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id C5E813A0F61 for ; Tue, 13 Oct 2020 04:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1602589443; d=isode.com; s=june2016; i=@isode.com; bh=qjvcT/IiMkUGn3oEncf2OV3jXVVoqVBmi8ucOJV7vFQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Uf5qmHjkkvF9O7LUHSpUSMx3BuMPVDtFGjNxKzaxdgsFAWRTw5u0rtaZB9V0ebwt8AO+8U t6bZpTFPw6eyJeWztoNy1Q+8Df3CW/T9XJ3icilEtfkOP+3Qw9e/zXAPZn71vY3KT2n/l3 NsZ3IXJBzeRXyOIubRFKIj0RZ9xSyhY=; Received: from [192.168.1.79] (109-252-81-41.nat.spd-mgts.ru [109.252.81.41]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 13 Oct 2020 12:44:03 +0100 To: Arnt Gulbrandsen Cc: extra@ietf.org References: <6c7fffa7-ad50-40f0-9b16-e4c34630df81@dogfood.fastmail.com> <68507b4a-00de-44b6-99b6-311644fc276c@gulbrandsen.priv.no> From: Alexey Melnikov Message-ID: <9e1bdf6c-c63a-ae2b-669e-998f955175f3@isode.com> Date: Tue, 13 Oct 2020 12:44:00 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 In-Reply-To: <68507b4a-00de-44b6-99b6-311644fc276c@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Extra] Working group last call for draft-ietf-extra-imap4rev2-18 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 11:44:06 -0000 Hi Arnt, On 18/09/2020 11:47, Arnt Gulbrandsen wrote: > Hi, > > I had another look, starting with the top. In Special Notes to=20 > Implementors, I find: > > =C2=A0 IMAP4rev2 is largely compatible with > =C2=A0 the IMAP4rev1 protocol described in RFC 3501 and the IMAP4 protocol > =C2=A0 described in RFC 1730; the exception being in certain facilities > =C2=A0 added in RFC 1730 that proved problematic and were subsequently > =C2=A0 removed. > > Well, really. Is that it? Well spotted. Yes, this needs to be cleaned as you say below. > I think 1.3 should refer to appendices A-D and add two parapgraphs of=20 > introduction of the changes since 4r1. It should say... let's see... > > That human-readable text can now be unicode, that bigger numbers are=20 > permitted (but no limits have changed), that CHECK, \RECENT, UNSEEN=20 > and LSUB are gone. That clients have to send ENABLE. That mailbox=20 > names are utf8. That the mandatory-to-implement authentication has=20 > been updated. Best Regards, Alexey From nobody Thu Oct 22 07:20:35 2020 Return-Path: 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 7F5563A0E72 for ; Thu, 22 Oct 2020 07:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, SPF_HELO_NONE=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=open-xchange.com 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 i6bbS4Q6ZVA5 for ; Thu, 22 Oct 2020 07:20:29 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D82003A0EDF for ; Thu, 22 Oct 2020 07:20:20 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx4.open-xchange.com (Postfix) with ESMTPS id 421806A28D for ; Thu, 22 Oct 2020 16:20:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1603376414; bh=vn7IleEOqvJAaMctBiDoQIKIj4dakL/Il7fLWg5cdgw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ON6ZfAeLP5tt1xMasrX5ugtLli4r46aGEzPkIB/wiRpJboMohuTbHB7b6hj0Eg8Tn Kf8NLJLNvPFurhB/l+Pn38ENEBX6tJI7ivtXapUhRSTngWmFKK05Ja8X6m2R+l1Fqv ks3WJgAdAZbMU1fKq/5K4x1xwegqZFTz7rMNZ8tzOgNPsWhCjhh7yuagMpHagWzZxy /VBqOmlH+WKc0gpDM5kom7/QB1eXpmi46brz6PhysJ///WDLt+ZZ+j6PuGw9Gmj2OI tT+vNQUjMjrtEMYcXzTvzPEpeI/MeaAko7ifPu1gat9dkVyIK/EGHD1pw2nYVLPZdF th7wY+moGf9PA== Received: from [10.168.3.2] (unknown [10.217.131.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 135D03C0066 for ; Thu, 22 Oct 2020 16:20:14 +0200 (CEST) To: extra@ietf.org References: <159705787314.11834.3190103463887221194@ietfa.amsl.com> From: Stephan Bosch Message-ID: Date: Thu, 22 Oct 2020 16:20:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <159705787314.11834.3190103463887221194@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 14:20:34 -0000 On 10/08/2020 13:11, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. > > Title : Sieve Email Filtering: Snooze Extension > Authors : Kenneth Murchison > Ricardo Signes > Neil Jenkins > Filename : draft-ietf-extra-sieve-snooze-00.txt > Pages : 12 > Date : 2020-08-07 > > Abstract: > This document describes the "snooze" extension to the Sieve email > filtering language. The "snooze" extension gives Sieve the ability > to postpone the filing of an incoming into a target mailbox until a > later point in time. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-snooze/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-extra-sieve-snooze-00 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-snooze-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ I have one question about this: Why does this add a new command? Why can't it just extend both keep and fileinto with new arguments? Regards, Stephan. From nobody Thu Oct 22 09:17:00 2020 Return-Path: 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 B0E923A07E6 for ; Thu, 22 Oct 2020 09:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, 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=fastmail.com header.b=jCD8iq24; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YyG2bfuI 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 CWJJv0QlOE63 for ; Thu, 22 Oct 2020 09:16:55 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66393A07CE for ; Thu, 22 Oct 2020 09:16:47 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id C2F1767F for ; Thu, 22 Oct 2020 12:16:46 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 22 Oct 2020 12:16:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=K CptsargqofVK6OLlRboWc4zgGzqKwfyxd4UDAKBDHw=; b=jCD8iq249OPamKiUW zPPsf3dALa507uFMszlnzmsHWGpXhoI8cZYEO+E77uxHDe14HPXP3hD/wmbYvUt/ yoFkwM5a37HIX9MqpWBvI9JG1A2682JK6hZpVLbmhSKVEQ/H4OkldG6jXf73HTFQ ANVsFhMhSUN28EJHTyo72+BSwBnQ6vGPT+1fBDszt6fpG9/j/pk/s8HKvQe33uBW nJpyOIMbYwShe/eHm7sB62VmUDy60Qx/dJTQjEZ8Pc8DTyfE9xLpqWVr3GhwQJA4 k5UXVGZjhAnt2hka+iWiFsERfBuVw2lksSnySPqrqQYAfK4X6jlZP4C3OsYybhSS G1HIg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=KCptsargqofVK6OLlRboWc4zgGzqKwfyxd4UDAKBD Hw=; b=YyG2bfuINIEolrmL0fFNbVkDEfEY16V1CDs5+LhntCYwlkGht27I+3CHi z5PZbxWwtxslNytIozipyOETLTywu1uE7TXpH4SQXsf63inpFx/l9Z4U01v4M1g5 17pfSiUe94XFR2jv4XQMz8SswEqtCylBs1fLfYdkGtptIolJ6gcFFiWCSgsYdmZt xQr3iINiexXu/UiktjyQLfVWa1l7IPHUjUVZis3EToei7Q+U3Pzeq5/2FlVsXR13 otY306Xfl48iM2noWoe7SFE6ql9CE/TfAoBY+U3S85Aazr3iS7C4pB9VTT6ebg4E QDMCuWzuDyV3fGFpol69F3mfrdN5Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeekgddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekre dttdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehfrghs thhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhepvdeutedugeeiffeitedvhfeiud etvdegjeekkedutedvvddvudetjeevgffhvdeknecuffhomhgrihhnpehivghtfhdrohhr ghenucfkphepjeegrdejjedrkeehrddvhedtnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 2BC1C328005D for ; Thu, 22 Oct 2020 12:16:46 -0400 (EDT) To: extra@ietf.org References: <159705787314.11834.3190103463887221194@ietfa.amsl.com> From: Ken Murchison Message-ID: <9772b986-260e-77da-1dea-4a1ae8010857@fastmail.com> Date: Thu, 22 Oct 2020 12:16:45 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 16:16:58 -0000 On 10/22/20 10:20 AM, Stephan Bosch wrote: > > > On 10/08/2020 13:11, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Email mailstore and eXtensions To >> Revise or Amend WG of the IETF. >> >>          Title           : Sieve Email Filtering: Snooze Extension >>          Authors         : Kenneth Murchison >>                            Ricardo Signes >>                            Neil Jenkins >>     Filename        : draft-ietf-extra-sieve-snooze-00.txt >>     Pages           : 12 >>     Date            : 2020-08-07 >> >> Abstract: >>     This document describes the "snooze" extension to the Sieve email >>     filtering language.  The "snooze" extension gives Sieve the ability >>     to postpone the filing of an incoming into a target mailbox until a >>     later point in time. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-snooze/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-extra-sieve-snooze-00 >> https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-snooze-00 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ > > I have one question about this: > > Why does this add a new command? Why can't it just extend both keep > and fileinto with new arguments? Hi Stephan, I suppose we could extend these commands as we are really just delaying the keep/fileinto until a future (awaken) time. So, it could look something like: fileinto [:snooze [:tzid ] [:weekdays ]] If we don't like having multiple tagged arguments, we could use a single string with some kind of ISO or iCalendar recurrence rule, but that might be more restrictive (I haven't actually sat down and worked out various examples). The only issue would be whether we want/need flags to be set at snooze time and then set/unset again at awaken time, which the current spec allows. How do others feel about extending keep/fileinto vs. a new command? -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Fri Oct 23 14:17:55 2020 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE553A10ED; Fri, 23 Oct 2020 14:15:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: extra@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348774876.5087.712421720776939590@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:15:48 -0700 Archived-At: Subject: [Extra] extra - Requested session has been scheduled for IETF 109 X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 21:15:52 -0000 Dear Bron Gondwana, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. extra Session 1 (1:00 requested) Wednesday, 18 November 2020, Session II 1430-1530 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/extra.ics Request Information: --------------------------------------------------------- Working Group Name: Email mailstore and eXtensions To Revise or Amend Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 15 Conflicts to Avoid: Chair Conflict: jmap calext dispatch Technology Overlap: emailcore dmarc Key Participant Conflict: gendispatch People who must be present: Barry Leiba Alexey Melnikov Jiankang Yao Bron Gondwana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Oct 25 22:23:00 2020 Return-Path: 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 681103A192F for ; Sun, 25 Oct 2020 22:22:58 -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=SoNpAmuD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HjVVWemW 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 3Or_MEHzFJ0x for ; Sun, 25 Oct 2020 22:22:57 -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 381DE3A192E for ; Sun, 25 Oct 2020 22:22:57 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 34A7C5C006F for ; Mon, 26 Oct 2020 01:22:56 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Mon, 26 Oct 2020 01:22:56 -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:subject:content-type; s=fm1; bh=6T0Gakf 2A5wYGv8bvmixy6CIzuZ6EWgvJYYRDAXqYxY=; b=SoNpAmuDTMVRet8l7kIRym1 W6vZom+3YGyEsqG5/+Z8aEkQjdqkTaEmg5Hcr4VnrKuwQkhgOQeekGYAR7f+C2K6 J9s07gwC+K3pI7cVlPaSnlcqCaSCzWHaNVdx1JpJ507wSt4dU7wKRZUIcSp/0fpW 3rhTb2XyT041Lo2CNXH90LKqr9jjmyo/9F604jHAc9NGHrU4Gr92ofDLT1OmNv5F WyVgWpAonD9RrY3cFzDjUJBoXvrLZLRyENvCrn+AF3uqxFe9RWzaKA8hIC4YcSY/ pHeWH3SjP0D6aY0YTDVab4OB7C0XRPCg0W6H2qdqgD3L5HzIT0QKHTSPRw/IsWg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=6T0Gak f2A5wYGv8bvmixy6CIzuZ6EWgvJYYRDAXqYxY=; b=HjVVWemWBdbPq1mz5RbIm4 3bulKBdo5t7M+2c/oVY+WMn73ydI6R/4o/3Gp8z7i8twdQFgUGpQLZWWTxYRhJVZ biDet7kqVnXEHApHjizplCLP+v2TzOZGNc2bhZZAdafza2uynYDuz5WhKMEF9/s3 QiumEzotpxhPpiHCprEfQ9yXcCxzC7L6zKviUS9QRqDMjYP469wlLnou0fqneNtp OcyYMUprJhGFElj6n2o3v/Rss9qBF1+s+yq3g+5dtWWLLokMVlXgn/p/EsxViWv2 SeVrP0rW9rG9uNu9Reh9SJxx9R39WQg/5DAiyoIewrPrUFl9ZljsU50WGT4q955Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrkeehgdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevvdetvdduleekhf eghfetfeettdelhfehfeevffevleekuddtudffieevjeevhfenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E010918009B; Mon, 26 Oct 2020 01:22:54 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-529-g69105b1-fm-20201021.003-g69105b13 Mime-Version: 1.0 Message-Id: In-Reply-To: <9772b986-260e-77da-1dea-4a1ae8010857@fastmail.com> References: <159705787314.11834.3190103463887221194@ietfa.amsl.com> <9772b986-260e-77da-1dea-4a1ae8010857@fastmail.com> Date: Mon, 26 Oct 2020 16:22:54 +1100 From: "Neil Jenkins" To: extra@ietf.org Content-Type: multipart/alternative; boundary=cd7a57c817b64fdea48e71f155027bc6 Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 05:22:58 -0000 --cd7a57c817b64fdea48e71f155027bc6 Content-Type: text/plain On Fri, 23 Oct 2020, at 03:16, Ken Murchison wrote: > The only issue would be whether we want/need flags to be set at snooze > time and then set/unset again at awaken time, which the current spec allows. > > How do others feel about extending keep/fileinto vs. a new command? I have no objection to extending fileinto rather than a new command, but for our use case we need to preserve the ability to set flags separately both on delivery and at awaken time. Neil. --cd7a57c817b64fdea48e71f155027bc6 Content-Type: text/html
On Fri, 23 Oct 2020, at 03:16, Ken Murchison wrote:
The only issue would be whether we want/need flags to be set at snooze 
time and then set/unset again at awaken time, which the current spec allows.

How do others feel about extending keep/fileinto vs. a new command?

I have no objection to extending fileinto rather than a new command, but for our use case we need to preserve the ability to set flags separately both on delivery and at awaken time.

Neil.
--cd7a57c817b64fdea48e71f155027bc6-- From nobody Sun Oct 25 23:56:39 2020 Return-Path: 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 E43A93A1976 for ; Sun, 25 Oct 2020 23:56:37 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.no 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 uzBKbjwHudL5 for ; Sun, 25 Oct 2020 23:56:35 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [144.76.73.169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8613A1977 for ; Sun, 25 Oct 2020 23:56:34 -0700 (PDT) Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 4431FC0114; Mon, 26 Oct 2020 07:02:55 +0000 (GMT) Authentication-Results: stabil.gulbrandsen.priv.no; dmarc=none (p=none dis=none) header.from=gulbrandsen.priv.no Authentication-Results: stabil.gulbrandsen.priv.no; spf=none smtp.mailfrom=arnt@gulbrandsen.priv.no DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1603695775; bh=2ESsuMDb5YrkHoAtT10MYnP+mxtP6C+/HznUoAlcRac=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZAgb7XHDxpnJEWad8QTeC+qd6CTk1mC3v348iCTUAIdX42r7I5BHOMoj3xjY4T0Bj HHGeLCLWdNOmu2430vpvG9i1be98P+YH31yBjMw46HGxAJeLWc7x0WpdniHmXH0gnC nMKI7SApweJn/DgEuiKOS4mPdUN/PIDmZDNRpyQg= Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1603695774-28651-19140/9/40; Mon, 26 Oct 2020 07:02:54 +0000 From: Arnt Gulbrandsen To: extra@ietf.org Date: Mon, 26 Oct 2020 07:58:03 +0100 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <159705787314.11834.3190103463887221194@ietfa.amsl.com> <9772b986-260e-77da-1dea-4a1ae8010857@fastmail.com> User-Agent: Trojita/0.7; Qt/5.11.3; xcb; Linux; Devuan GNU/Linux 3 (beowulf) Content-Type: text/plain; charset=utf-8; format=flowed Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 06:56:38 -0000 On Monday 26 October 2020 06:22:54 CET, Neil Jenkins wrote: > I have no objection to extending fileinto rather than a new > command, but for our use case we need to preserve the ability to > set flags separately both on delivery and at awaken time. Could you elaborate? I'm just curious here. Arnt From nobody Tue Oct 27 03:18:39 2020 Return-Path: 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 85A043A16B9 for ; Tue, 27 Oct 2020 03:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 lHpUihNx_-RH for ; Tue, 27 Oct 2020 03:18:37 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7433A16B0 for ; Tue, 27 Oct 2020 03:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1603793916; d=isode.com; s=june2016; i=@isode.com; bh=dS8asGZaJ5sV0/kjOtnqYwvJs6Mroazvyo+w8VRnZYw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=qcTWSNJSuMliWD8AX8sPRl8iYCgVw3DywUqVS4VcvFmvGEms6iicL63UYmSV9DylucplLO YyfsshsJMq1VsEAqu6VlRXPwuPmJhIjBhWuJpgLaZlcn7SpRX31tKA2oEcjdT7K+svxclB NXIhT7gBWKeDCUlF9xn1f4V2NwndYHw=; Received: from [192.168.0.5] (97e7601a.skybroadband.com [151.231.96.26]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 27 Oct 2020 10:18:36 +0000 To: extra@ietf.org From: Alexey Melnikov Message-ID: <4e10b4fc-d162-eaa0-086b-40585195f296@isode.com> Date: Tue, 27 Oct 2020 10:18:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [Extra] A STARTTLS received after a successful STARTTLS X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 10:18:38 -0000 Hi all, A STARTTLS command received after a successfully executed STARTTLS must fail. Do people send BAD or NO in this case? I think IMAP4rev2 should recommend BAD tagged response, but I would like to know if implementations differ in this respect. Best Regards, Alexey From nobody Tue Oct 27 04:03:47 2020 Return-Path: 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 5E0E33A16D8 for ; Tue, 27 Oct 2020 04:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, 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=fastmail.com header.b=dv8aZ8aW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=W8nW2KWY 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 ZMZAqntfUyC7 for ; Tue, 27 Oct 2020 04:03:44 -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 8F3133A0CDF for ; Tue, 27 Oct 2020 04:03:44 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id F0C8D5C00BD for ; Tue, 27 Oct 2020 07:03:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 27 Oct 2020 07:03:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=u gwZ6qEupuNTNn9xoV9y5D675fDqMchVCnXdNJ3VPt8=; b=dv8aZ8aWk/ztQkqp4 ++T7J8IerofC1TJGHh3xkuGHAuG46N42zXr/m847XBgd5k2kLJjBNTLhLcsfJmiI Knqo2O2ds4w9XaQvaAdhr0L/qV1y5Kpycky8e6unmf4Gu7ilZyUc3+wRYiOrdWR+ 666K5pznT0zTxeI/5ZT8Dhrk+BNu5HtmQkEqL0uv4vcvhMI44Rb/ibGM/qp2hD3g +pInpYqyraeb9qMwAFjlIONS4ahcALXmekIwiOK8WZE6Wkhnwaql8VuHl/GUmZGT FivSw0JNBK+VXGgVrEhuKkhz3de5v8OAxBydm30HQO00gBripl1C1WeVFECF+IFb gL9eA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=ugwZ6qEupuNTNn9xoV9y5D675fDqMchVCnXdNJ3VP t8=; b=W8nW2KWYECZSWaU8kNSrWTKvaEUULL3C4orCeoBFDo2hQ0jybfWhxRxL/ bni5OXyMKmi/kfPCWplgyF/DvLfGkv5ldOJGyaN+uNJfAn0BBEkRN8/cuEbLUfx0 8yhlJvmfTXZVUp4OMXJiCoqTk+qw3Vk/vnRGUsWNGlDuczguJ0pMHfgcQVnJNDFF DKZ1j/DqpkfQCQCqwA7F5KxJH46KrCHJyGCmqUSF1k3JcZb61azJvvV2JwprbJPl FNosn7EcxJcI1botbBc6ZHLLDrLl8nQdQWKH2uaFyD0kqyy8nY9Ne6fDjpGUPEuS HI3yViScN1y6sCnpcnSrcRo5EGs/w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrkeelgddvfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthejre dttdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehfrghs thhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhepiedulefhjefhueehlefgueetve fhtdffheetjeffgfduffetvedutedvueduudetnecuffhomhgrihhnpehivghtfhdrohhr ghenucfkphepjeegrdejjedrkeehrddvhedtnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 9CFF5328005E for ; Tue, 27 Oct 2020 07:03:43 -0400 (EDT) To: extra@ietf.org References: <4e10b4fc-d162-eaa0-086b-40585195f296@isode.com> From: Ken Murchison Message-ID: Date: Tue, 27 Oct 2020 07:03:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <4e10b4fc-d162-eaa0-086b-40585195f296@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Extra] A STARTTLS received after a successful STARTTLS X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 11:03:46 -0000 Alexey, Cyrus IMAP returns BAD. On 10/27/20 6:18 AM, Alexey Melnikov wrote: > Hi all, > > A STARTTLS command received after a successfully executed STARTTLS > must fail. Do people send BAD or NO in this case? I think IMAP4rev2 > should recommend BAD tagged response, but I would like to know if > implementations differ in this respect. > > Best Regards, > > Alexey > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Tue Oct 27 06:05:26 2020 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF803A08F6; Tue, 27 Oct 2020 06:05:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <160380392500.12441.7491817898062269373@ietfa.amsl.com> Date: Tue, 27 Oct 2020 06:05:25 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-19.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 13:05:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : Internet Message Access Protocol (IMAP) - Version 4rev2 Authors : Alexey Melnikov Barry Leiba Filename : draft-ietf-extra-imap4rev2-19.txt Pages : 163 Date : 2020-10-27 Abstract: The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as RFC 6409. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-19 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 27 06:15:49 2020 Return-Path: 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 C04EA3A0A93 for ; Tue, 27 Oct 2020 06:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 Nh07fh9FG66j for ; Tue, 27 Oct 2020 06:15:43 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id BD7BA3A0BA8 for ; Tue, 27 Oct 2020 06:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1603804535; d=isode.com; s=june2016; i=@isode.com; bh=CCQEralluw3xBCkTCsuGEsX7v2KvL/V6wyPOQFYNjNI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=MoqWcG6mosMo7295y0VAF6AVImayJBbM9AkPzV+ZPMtfk2Y9dHySNHJmn0gXy7j0xqocWz 8t9sZkxw74WGSXPBKPuRGyEYkeZCl0TT4m3kFBkXBsbqDYCxJ0hZ/SVBeavIUI6T082I4t g6bs+UXG7RsKkx4JtDYl/a0Hh1y+iSg=; Received: from [192.168.0.5] (97e7601a.skybroadband.com [151.231.96.26]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 27 Oct 2020 13:15:35 +0000 To: extra@ietf.org References: <160380392500.12441.7491817898062269373@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <4959a340-9599-6a9a-60d0-21642c0f306c@isode.com> Date: Tue, 27 Oct 2020 13:15:34 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 In-Reply-To: <160380392500.12441.7491817898062269373@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-imap4rev2-19.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 13:15:45 -0000 Hi all, On 27/10/2020 13:05, internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-19 > https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-19 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-19 This version adds normative reference to TLS 1.3 and updates TLS related text to make it clear that TLS 1.2 and/or TLS 1.3 must be implemented, with TLS 1.3 being the recommended one. I also updated text about changes since RFC 3501 at the beginning of the document by adding missing references to appendices based on Arnt's suggestions. I didn'timplement Arnt's entire suggestion, but this can be improved in the next revision. I also finally added a new appendix with recommended extensions: QRESYNC/CONDSTORE and OBJECTID. If you have an opinion on this section, let's discuss on the mailing list. Best Regards, Alexey From nobody Tue Oct 27 06:40:52 2020 Return-Path: X-Original-To: extra@ietf.org Delivered-To: extra@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0CA3A0A24; Tue, 27 Oct 2020 06:40:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: extra@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: extra@ietf.org Message-ID: <160380605157.27888.5690307410040717244@ietfa.amsl.com> Date: Tue, 27 Oct 2020 06:40:51 -0700 Archived-At: Subject: [Extra] I-D Action: draft-ietf-extra-imap4rev2-20.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 13:40:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Email mailstore and eXtensions To Revise or Amend WG of the IETF. Title : Internet Message Access Protocol (IMAP) - Version 4rev2 Authors : Alexey Melnikov Barry Leiba Filename : draft-ietf-extra-imap4rev2-20.txt Pages : 163 Date : 2020-10-27 Abstract: The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev2 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev2 does not specify a means of posting mail; this function is handled by a mail submission protocol such as the one specified in RFC 6409. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-extra-imap4rev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-extra-imap4rev2-20 https://datatracker.ietf.org/doc/html/draft-ietf-extra-imap4rev2-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-extra-imap4rev2-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 27 07:00:31 2020 Return-Path: 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 118FC3A0E56 for ; Tue, 27 Oct 2020 07:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, 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=fastmail.com header.b=Q9ngZbAZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TxWInNJG 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 9lDxb3D98NXv for ; Tue, 27 Oct 2020 07:00:21 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107373A0E59 for ; Tue, 27 Oct 2020 07:00:07 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EC7E05C012A for ; Tue, 27 Oct 2020 10:00:05 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 27 Oct 2020 10:00:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=g wigHp/yyewDgEu36uUCR6Y/HrMe0CSFzktirdSSFic=; b=Q9ngZbAZa3uCNT3yu x28/C3VGFP/r+KKiA/mM2pdm37LEYZGSQmgrOlMvmtaKOgQcWXvgrmP4fFDjLEkO d+qy3sFi8S7/CkcTJHLeupDkXQYlljDDouD2khACuNbFhaGyfuWBP3no3TJ60NN9 9wFgG5PQiy+1dxPUqijpjqJiNgp+NJI1x/soMnoylEA+Dt0e7aKtzgOjVnhppWqE gNHBvid216r+0qLcaLgZPjdl/PaW9ak5w0S5M3lzTpqTViJ4du2zwEQoqSFO2NHR sgh1fQHgOq8KL0FOOLN58ww9wIEvTx9pJbdDeSLrPTHzOil9imrFJLyn7LjWORMK e67MA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=gwigHp/yyewDgEu36uUCR6Y/HrMe0CSFzktirdSSF ic=; b=TxWInNJGLFCYRwaBllmJywTVcMOb3kyA2yyIWUs4F2XKLzab4dShc7mhc 01urSyw4HuzY8jnklbUXmP2Sns0jL74ukToMjp7qVXU35wnhR9ZofIzgv/gINKfg NDTLQcP6nF/NgKxd8qrhHrY30303wyBgISZVpsFbXA2/e4jtAT3hen4pt85+z4+k zCQB0gjLT0K836I/RH/pwoNhjHyEj30GiJlaB9i6P5aUgkvUADWI4sEiF4a0zmpR pHk8mNX2XxHSrbS1cbIKZzLRX94LhKDn1sbuEk65guFflA2MG04ZGK30hvveWY1O 0vM21ofrjgK2NvNtebVjpZjvNgD/g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrkeelgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekre dttdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehfrghs thhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhepvdeutedugeeiffeitedvhfeiud etvdegjeekkedutedvvddvudetjeevgffhvdeknecuffhomhgrihhnpehivghtfhdrohhr ghenucfkphepjeegrdejjedrkeehrddvhedtnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 1AE51328006C for ; Tue, 27 Oct 2020 10:00:05 -0400 (EDT) To: extra@ietf.org References: <159705787314.11834.3190103463887221194@ietfa.amsl.com> <9772b986-260e-77da-1dea-4a1ae8010857@fastmail.com> From: Ken Murchison Message-ID: <2411a867-d381-984e-fbd9-c6d7309cbab6@fastmail.com> Date: Tue, 27 Oct 2020 10:00:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <9772b986-260e-77da-1dea-4a1ae8010857@fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 14:00:30 -0000 On 10/22/20 12:16 PM, Ken Murchison wrote: > > On 10/22/20 10:20 AM, Stephan Bosch wrote: >> >> >> On 10/08/2020 13:11, internet-drafts@ietf.org wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Email mailstore and eXtensions To >>> Revise or Amend WG of the IETF. >>> >>>          Title           : Sieve Email Filtering: Snooze Extension >>>          Authors         : Kenneth Murchison >>>                            Ricardo Signes >>>                            Neil Jenkins >>>     Filename        : draft-ietf-extra-sieve-snooze-00.txt >>>     Pages           : 12 >>>     Date            : 2020-08-07 >>> >>> Abstract: >>>     This document describes the "snooze" extension to the Sieve email >>>     filtering language.  The "snooze" extension gives Sieve the ability >>>     to postpone the filing of an incoming into a target mailbox until a >>>     later point in time. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-snooze/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-extra-sieve-snooze-00 >>> https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-snooze-00 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >> >> I have one question about this: >> >> Why does this add a new command? Why can't it just extend both keep >> and fileinto with new arguments? > > > Hi Stephan, > > I suppose we could extend these commands as we are really just > delaying the keep/fileinto until a future (awaken) time. > > So, it could look something like: > > fileinto [:snooze [:tzid ] [:weekdays > ]] > > If we don't like having multiple tagged arguments, we could use a > single string with some kind of ISO or iCalendar recurrence rule, but > that might be more restrictive (I haven't actually sat down and worked > out various examples). > > The only issue would be whether we want/need flags to be set at snooze > time and then set/unset again at awaken time, which the current spec > allows. > > How do others feel about extending keep/fileinto vs. a new command? As I think about this more, and look at how :fcc became kind of a mess with a bunch of add-on tagged args, I wonder if using a single structured string for a :snooze option to keep/fileinto might be better.  E.g.: keep :snooze text: {   "until": [ "08:00:00", "12:00:00" ],   "days": [ "1", "3", "5" ],   "tzid": "America/New_York",   "addflags": [ "\\\\Flagged" ],   "removeflags": [ "\\\\Seen" ] } . ; -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Tue Oct 27 10:36:34 2020 Return-Path: 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 A0D8D3A126B for ; Tue, 27 Oct 2020 10:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 f3Zaf3F1RquV for ; Tue, 27 Oct 2020 10:36:31 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id EABDE3A126A for ; Tue, 27 Oct 2020 10:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1603820190; d=isode.com; s=june2016; i=@isode.com; bh=8F3Gp5oQOHBaQfZn9TegTAKKru9COwkevfg1FJj5MSw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=dgHI+EbLjgs4pLvjM3FWk0ChFTDWN4nue+x51TQajIzcSczTQtgVYRVZEIoX9RBocI4UNH a738STD55skyD4yKjUuOYokgPYQNWzOh/wwjn5T/+LFzVNCM5FMWyuO5zFP2UQfTz5Fuqm hRBizOtMfniIaaOoTozxGcmE/KLwdAc=; Received: from [192.168.0.5] (97e7601a.skybroadband.com [151.231.96.26]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 27 Oct 2020 17:36:29 +0000 To: Ken Murchison References: <159705787314.11834.3190103463887221194@ietfa.amsl.com> <9772b986-260e-77da-1dea-4a1ae8010857@fastmail.com> <2411a867-d381-984e-fbd9-c6d7309cbab6@fastmail.com> From: Alexey Melnikov Cc: extra@ietf.org Message-ID: <941ea682-1264-874d-096e-6654f8707ba7@isode.com> Date: Tue, 27 Oct 2020 17:36:29 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 In-Reply-To: <2411a867-d381-984e-fbd9-c6d7309cbab6@fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 17:36:33 -0000 Hi Ken, On 27/10/2020 14:00, Ken Murchison wrote: > > On 10/22/20 12:16 PM, Ken Murchison wrote: >> >> On 10/22/20 10:20 AM, Stephan Bosch wrote: >>> >>> >>> On 10/08/2020 13:11, internet-drafts@ietf.org wrote: >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts=20 >>>> directories. >>>> This draft is a work item of the Email mailstore and eXtensions To=20 >>>> Revise or Amend WG of the IETF. >>>> >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Sieve Email Filtering: Snooz= e Extension >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Kenneth Murchison >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Ricardo Signes >>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Neil Jenkins >>>> =C2=A0=C2=A0=C2=A0=C2=A0Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 : draft-ietf-extra-sieve-snooze-00.txt >>>> =C2=A0=C2=A0=C2=A0=C2=A0Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 : 12 >>>> =C2=A0=C2=A0=C2=A0=C2=A0Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 : 2020-08-07 >>>> >>>> Abstract: >>>> =C2=A0=C2=A0=C2=A0 This document describes the "snooze" extension to th= e Sieve email >>>> =C2=A0=C2=A0=C2=A0 filtering language.=C2=A0 The "snooze" extension giv= es Sieve the=20 >>>> ability >>>> =C2=A0=C2=A0=C2=A0 to postpone the filing of an incoming into a target = mailbox=20 >>>> until a >>>> =C2=A0=C2=A0=C2=A0 later point in time. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-snooze/ >>>> >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-ietf-extra-sieve-snooze-00 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-snooze-00 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of=20 >>>> submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> I have one question about this: >>> >>> Why does this add a new command? Why can't it just extend both keep=20 >>> and fileinto with new arguments? >> >> >> Hi Stephan, >> >> I suppose we could extend these commands as we are really just=20 >> delaying the keep/fileinto until a future (awaken) time. >> >> So, it could look something like: >> >> fileinto [:snooze [:tzid ] [:weekdays=20 >> ]] >> >> If we don't like having multiple tagged arguments, we could use a=20 >> single string with some kind of ISO or iCalendar recurrence rule, but=20 >> that might be more restrictive (I haven't actually sat down and=20 >> worked out various examples). >> >> The only issue would be whether we want/need flags to be set at=20 >> snooze time and then set/unset again at awaken time, which the=20 >> current spec allows. >> >> How do others feel about extending keep/fileinto vs. a new command? From the point of view of making sure that extensions work with each=20 other, not multiplying number of commands is a good thing. But I can=20 also see attraction for [manual] script writers for shorter/different=20 commands. > As I think about this more, and look at how :fcc became kind of a mess=20 > with a bunch of add-on tagged args, I wonder if using a single=20 > structured string for a :snooze option to keep/fileinto might be=20 > better.=C2=A0 E.g.: > > keep :snooze text: > { > =C2=A0 "until": [ "08:00:00", "12:00:00" ], > =C2=A0 "days": [ "1", "3", "5" ], > =C2=A0 "tzid": "America/New_York", > =C2=A0 "addflags": [ "\\\\Flagged" ], > =C2=A0 "removeflags": [ "\\\\Seen" ] > } > . > ; > This would mean that you have 2 levels of parsing: first you use a=20 generic Sieve parser to parse a Sieve script and then you would have to=20 selectively parse certain recognized parameters using a different=20 parser. I think this would unnecessarily increase complexity for both=20 implementors and script writers, because there are now special cases of=20 syntax. Best Regards, Alexey From nobody Tue Oct 27 10:45:52 2020 Return-Path: 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 8E8B63A0D87 for ; Tue, 27 Oct 2020 10:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 nDbyAcKFXKRQ for ; Tue, 27 Oct 2020 10:45:49 -0700 (PDT) Received: from mail-ob3.cityemail.com (mail-ob3.cityemail.com [104.128.152.20]) by ietfa.amsl.com (Postfix) with ESMTP id D355C3A0D64 for ; Tue, 27 Oct 2020 10:45:47 -0700 (PDT) Received: (qmail 4598 invoked from network); 27 Oct 2020 17:45:47 -0000 Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe3.cityemail.com with (DHE-RSA-AES128-SHA encrypted) SMTP (3ebed2ae-187c-11eb-bdf6-b38ff9f407b3); Tue, 27 Oct 2020 10:45:47 -0700 To: extra@ietf.org References: <159705787314.11834.3190103463887221194@ietfa.amsl.com> <9772b986-260e-77da-1dea-4a1ae8010857@fastmail.com> <2411a867-d381-984e-fbd9-c6d7309cbab6@fastmail.com> <941ea682-1264-874d-096e-6654f8707ba7@isode.com> From: Michael Peddemors Organization: LinuxMagic Inc. Message-ID: <21368546-3a7f-548b-3fc7-9a0a76419a96@linuxmagic.com> Date: Tue, 27 Oct 2020 10:45:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <941ea682-1264-874d-096e-6654f8707ba7@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MagicMail-OS: Linux 3.11 and newer X-MagicMail-UUID: 3ebed2ae-187c-11eb-bdf6-b38ff9f407b3 X-MagicMail-Authenticated: michael@wizard.ca X-MagicMail-SourceIP: 104.128.144.8 X-MagicMail-RegexMatch: 0 X-MagicMail-EnvelopeFrom: X-Archive: Yes Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 17:45:52 -0000 If you don't mind a stupid question on this.. The idea of a 'snooze' feature is something lot's of people are working on, and maybe it should be a higher level than in 'sieve'? Maybe it would be helpful to set solicit feedback on other industry implementations of this feature.. possibly this should be in IMAP itself? On 2020-10-27 10:36 a.m., Alexey Melnikov wrote: > Hi Ken, > > On 27/10/2020 14:00, Ken Murchison wrote: >> >> On 10/22/20 12:16 PM, Ken Murchison wrote: >>> >>> On 10/22/20 10:20 AM, Stephan Bosch wrote: >>>> >>>> >>>> On 10/08/2020 13:11, internet-drafts@ietf.org wrote: >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Email mailstore and eXtensions To >>>>> Revise or Amend WG of the IETF. >>>>> >>>>>          Title           : Sieve Email Filtering: Snooze Extension >>>>>          Authors         : Kenneth Murchison >>>>>                            Ricardo Signes >>>>>                            Neil Jenkins >>>>>     Filename        : draft-ietf-extra-sieve-snooze-00.txt >>>>>     Pages           : 12 >>>>>     Date            : 2020-08-07 >>>>> >>>>> Abstract: >>>>>     This document describes the "snooze" extension to the Sieve email >>>>>     filtering language.  The "snooze" extension gives Sieve the >>>>> ability >>>>>     to postpone the filing of an incoming into a target mailbox >>>>> until a >>>>>     later point in time. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-snooze/ >>>>> >>>>> There are also htmlized versions available at: >>>>> https://tools.ietf.org/html/draft-ietf-extra-sieve-snooze-00 >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-snooze-00 >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> I have one question about this: >>>> >>>> Why does this add a new command? Why can't it just extend both keep >>>> and fileinto with new arguments? >>> >>> >>> Hi Stephan, >>> >>> I suppose we could extend these commands as we are really just >>> delaying the keep/fileinto until a future (awaken) time. >>> >>> So, it could look something like: >>> >>> fileinto [:snooze [:tzid ] [:weekdays >>> ]] >>> >>> If we don't like having multiple tagged arguments, we could use a >>> single string with some kind of ISO or iCalendar recurrence rule, but >>> that might be more restrictive (I haven't actually sat down and >>> worked out various examples). >>> >>> The only issue would be whether we want/need flags to be set at >>> snooze time and then set/unset again at awaken time, which the >>> current spec allows. >>> >>> How do others feel about extending keep/fileinto vs. a new command? > From the point of view of making sure that extensions work with each > other, not multiplying number of commands is a good thing. But I can > also see attraction for [manual] script writers for shorter/different > commands. >> As I think about this more, and look at how :fcc became kind of a mess >> with a bunch of add-on tagged args, I wonder if using a single >> structured string for a :snooze option to keep/fileinto might be >> better.  E.g.: >> >> keep :snooze text: >> { >>   "until": [ "08:00:00", "12:00:00" ], >>   "days": [ "1", "3", "5" ], >>   "tzid": "America/New_York", >>   "addflags": [ "\\\\Flagged" ], >>   "removeflags": [ "\\\\Seen" ] >> } >> . >> ; >> > This would mean that you have 2 levels of parsing: first you use a > generic Sieve parser to parse a Sieve script and then you would have to > selectively parse certain recognized parameters using a different > parser. I think this would unnecessarily increase complexity for both > implementors and script writers, because there are now special cases of > syntax. > > Best Regards, > > Alexey > > _______________________________________________ > Extra mailing list > Extra@ietf.org > https://www.ietf.org/mailman/listinfo/extra -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From nobody Tue Oct 27 11:07:16 2020 Return-Path: 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 768AF3A1391 for ; Tue, 27 Oct 2020 11:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-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=fastmail.com header.b=aiIml49T; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bdDoX88h 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 7tU4juzBff3l for ; Tue, 27 Oct 2020 11:07:08 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA5E3A12C8 for ; Tue, 27 Oct 2020 11:07:08 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id C0356149B; Tue, 27 Oct 2020 14:07:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 27 Oct 2020 14:07:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=P 8JKNOEScL4h8Bu0miuy1YhGiz1iozmL++CoQIXyv2U=; b=aiIml49TeT8Jek6sQ KEmDMdt/THlfyoYSlBtJB9R8pIbXIDfnzHGjpU3yZTY+cqJ7Ok10lWcwomXYdhb/ LeE3cecaJeW5zVsrInxIsw9Uxx9biULnoS6ys0b9aydcdHbywSgyaEQcqZDKF33D xQvTZk48YWthbdSOlGwSIQPmERXrtQsjnkkHdU9Zgy73PkAopnzXwsslqxjtlbI/ 8vqwY9Sw/h+1yRjGH1n0LzL+y1RvtSCjcqc1QZvYs8OWVSdQlmpSQghgG0quDjR2 azpuUo7ESXnSowPSaX+a4K9ntdR9zn5VTxcmitXaZJ4r8QSscAd2z3/HKc2+c/hO ziA+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=P8JKNOEScL4h8Bu0miuy1YhGiz1iozmL++CoQIXyv 2U=; b=bdDoX88h3eb9gvggpwvThLwPksO+erghRmAxTKYY3W87KxT+kPLQb0lSy GLnmelQTWpD0VuhwfzIEL9XjI9XLKx9rc87u0gXC9zDO/dHssdeca4Ct/ZbxRbZJ ZWmMM9Jm5BW7lhk+/8dhs3sWE7Wea4tXDdAIIhKdsLRFsgogfJb5vkJVzU66aL3b 1QaWNzFgkTw8G0+6/IhGGK/lTq7olRq2quYUI3zH2dmkR1x7O2bt1hE6XiUW29rG gA8w/KaqnMR7J5wryjR9SYaVjI/kgq5phPWG0yyCGwjhzQPFbx4P+88FlM5BzXar Mf3aDiq2Cq42aLpwYR6timmal/i9g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrkeelgddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomhepmfgvnhcu ofhurhgthhhishhonhcuoehmuhhrtghhsehfrghsthhmrghilhdrtghomheqnecuggftrf grthhtvghrnhepvdeutedugeeiffeitedvhfeiudetvdegjeekkedutedvvddvudetjeev gffhvdeknecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepjeegrdejjedrkeehrd dvhedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep mhhurhgthhesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id B7AAF3280067; Tue, 27 Oct 2020 14:07:06 -0400 (EDT) To: Alexey Melnikov Cc: extra@ietf.org References: <159705787314.11834.3190103463887221194@ietfa.amsl.com> <9772b986-260e-77da-1dea-4a1ae8010857@fastmail.com> <2411a867-d381-984e-fbd9-c6d7309cbab6@fastmail.com> <941ea682-1264-874d-096e-6654f8707ba7@isode.com> From: Ken Murchison Message-ID: <8852c0da-b461-f90f-36cd-13ca268ae4e5@fastmail.com> Date: Tue, 27 Oct 2020 14:07:06 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <941ea682-1264-874d-096e-6654f8707ba7@isode.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 18:07:14 -0000 On 10/27/20 1:36 PM, Alexey Melnikov wrote: > Hi Ken, > > On 27/10/2020 14:00, Ken Murchison wrote: >> >> On 10/22/20 12:16 PM, Ken Murchison wrote: >>> >>> On 10/22/20 10:20 AM, Stephan Bosch wrote: >>>> >>>> >>>> On 10/08/2020 13:11, internet-drafts@ietf.org wrote: >>>>> >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> This draft is a work item of the Email mailstore and eXtensions To >>>>> Revise or Amend WG of the IETF. >>>>> >>>>>          Title           : Sieve Email Filtering: Snooze Extension >>>>>          Authors         : Kenneth Murchison >>>>>                            Ricardo Signes >>>>>                            Neil Jenkins >>>>>     Filename        : draft-ietf-extra-sieve-snooze-00.txt >>>>>     Pages           : 12 >>>>>     Date            : 2020-08-07 >>>>> >>>>> Abstract: >>>>>     This document describes the "snooze" extension to the Sieve email >>>>>     filtering language.  The "snooze" extension gives Sieve the >>>>> ability >>>>>     to postpone the filing of an incoming into a target mailbox >>>>> until a >>>>>     later point in time. >>>>> >>>>> >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-snooze/ >>>>> >>>>> There are also htmlized versions available at: >>>>> https://tools.ietf.org/html/draft-ietf-extra-sieve-snooze-00 >>>>> https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-snooze-00 >>>>> >>>>> >>>>> >>>>> Please note that it may take a couple of minutes from the time of >>>>> submission >>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>> >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> I have one question about this: >>>> >>>> Why does this add a new command? Why can't it just extend both keep >>>> and fileinto with new arguments? >>> >>> >>> Hi Stephan, >>> >>> I suppose we could extend these commands as we are really just >>> delaying the keep/fileinto until a future (awaken) time. >>> >>> So, it could look something like: >>> >>> fileinto [:snooze [:tzid ] [:weekdays >>> ]] >>> >>> If we don't like having multiple tagged arguments, we could use a >>> single string with some kind of ISO or iCalendar recurrence rule, >>> but that might be more restrictive (I haven't actually sat down and >>> worked out various examples). >>> >>> The only issue would be whether we want/need flags to be set at >>> snooze time and then set/unset again at awaken time, which the >>> current spec allows. >>> >>> How do others feel about extending keep/fileinto vs. a new command? > From the point of view of making sure that extensions work with each > other, not multiplying number of commands is a good thing. But I can > also see attraction for [manual] script writers for shorter/different > commands. Agree on both points and I don't have a string preference either way.  Although extending keep/fileinto is a lot less to document than a new snooze command and then having to document how fileinto extensions work with it (which is what the current draft had to do). >> As I think about this more, and look at how :fcc became kind of a >> mess with a bunch of add-on tagged args, I wonder if using a single >> structured string for a :snooze option to keep/fileinto might be >> better.  E.g.: >> >> keep :snooze text: >> { >>   "until": [ "08:00:00", "12:00:00" ], >>   "days": [ "1", "3", "5" ], >>   "tzid": "America/New_York", >>   "addflags": [ "\\\\Flagged" ], >>   "removeflags": [ "\\\\Seen" ] >> } >> . >> ; >> > This would mean that you have 2 levels of parsing: first you use a > generic Sieve parser to parse a Sieve script and then you would have > to selectively parse certain recognized parameters using a different > parser. I think this would unnecessarily increase complexity for both > implementors and script writers, because there are now special cases > of syntax. Sure, but don't we already have that now with existing structured strings that need to be parsed/verified?  We have email addresses, time and date formats, full MIME parts, URIs, and even regex. -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Tue Oct 27 11:37:08 2020 Return-Path: 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 D2E133A145F for ; Tue, 27 Oct 2020 11:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-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=fastmail.com header.b=RDDGcv6g; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Usj24emQ 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 vWvNg-MEg6qm for ; Tue, 27 Oct 2020 11:36:42 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6D73A145B for ; Tue, 27 Oct 2020 11:36:42 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 06F59149B for ; Tue, 27 Oct 2020 14:36:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 27 Oct 2020 14:36:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=6 riT9FZwk/OxqdVl8pyY1JKS+8gaM9d0CcXeGLZ37u8=; b=RDDGcv6gV1+Ouzd5l iGaB6M5zBSJU3bWQ+oxGcJUhTz89vTFe0O5TFTUBKGyC6aZo3QBcqVUKNN+e7gzz YMFnNFBJt/xvhAABQ7JalOucSWXAazmiDduD3DQJ9KW9syzezJDTvbMFZNQczIf3 /xYlv+rTUVrsU6zalGHIAITMN1s45ShdzEXHtEXR9h6iBE7xHKXHLhRrCc4w/IQd Sn9O7q+mKjh8Sz+XrpsBFE4KSA5Ttzdt5BG1LFCkfcbLX4DNEtddLF1sNuN7hRuw 1e2D7KxUD2J7efRtI2LtvNWSe2poKo4AxY3MMUeEcD640S+TQUMKYuavEuzC0nag 4ogJg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=6riT9FZwk/OxqdVl8pyY1JKS+8gaM9d0CcXeGLZ37 u8=; b=Usj24emQGfpojGBOh5NE0C9x4rS9I1iiPDICsXiF+Axik2h4QMVbNv8lb zjG1K1yeOr8sDLsFbcnkK0/7850A9eZcmmtLBIXCzyoTvR0P3HVPQQiLKX5fHCW1 4dhsH3psoDJiuUDrrTBSos6Pt6USdnHhC+dzjLLra0mQh6nVoqEm1USs+MF4nr8y lfYxtQLbCUHg7wLivH6uyFNRkhG6fae8zk9BldaKL70OhUG+VPp4MltfR6tyFAq+ eFaWi9m8BZ9007cMvMWpP+2W9Q7zYuckdjZeEGrdBGYpxXSVVCGdhEV8fy8eKNwL Epa+gBVXZPX8eKvSJU3Hvr0FbHHHw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrkeelgdduudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgr shhtmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpedvueetudegieffieetvdfhie dutedvgeejkeekudetvddvvdduteejvefghfdvkeenucffohhmrghinhepihgvthhfrdho rhhgnecukfhppeejgedrjeejrdekhedrvdehtdenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 4A6DA328005D for ; Tue, 27 Oct 2020 14:36:41 -0400 (EDT) To: extra@ietf.org References: <159705787314.11834.3190103463887221194@ietfa.amsl.com> <9772b986-260e-77da-1dea-4a1ae8010857@fastmail.com> <2411a867-d381-984e-fbd9-c6d7309cbab6@fastmail.com> <941ea682-1264-874d-096e-6654f8707ba7@isode.com> <8852c0da-b461-f90f-36cd-13ca268ae4e5@fastmail.com> From: Ken Murchison Message-ID: Date: Tue, 27 Oct 2020 14:36:40 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <8852c0da-b461-f90f-36cd-13ca268ae4e5@fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 18:36:45 -0000 On 10/27/20 2:07 PM, Ken Murchison wrote: > > On 10/27/20 1:36 PM, Alexey Melnikov wrote: >> Hi Ken, >> >> On 27/10/2020 14:00, Ken Murchison wrote: >>> >>> On 10/22/20 12:16 PM, Ken Murchison wrote: >>>> >>>> On 10/22/20 10:20 AM, Stephan Bosch wrote: >>>>> >>>>> >>>>> On 10/08/2020 13:11, internet-drafts@ietf.org wrote: >>>>>> >>>>>> A New Internet-Draft is available from the on-line >>>>>> Internet-Drafts directories. >>>>>> This draft is a work item of the Email mailstore and eXtensions >>>>>> To Revise or Amend WG of the IETF. >>>>>> >>>>>>          Title           : Sieve Email Filtering: Snooze Extension >>>>>>          Authors         : Kenneth Murchison >>>>>>                            Ricardo Signes >>>>>>                            Neil Jenkins >>>>>>     Filename        : draft-ietf-extra-sieve-snooze-00.txt >>>>>>     Pages           : 12 >>>>>>     Date            : 2020-08-07 >>>>>> >>>>>> Abstract: >>>>>>     This document describes the "snooze" extension to the Sieve >>>>>> email >>>>>>     filtering language.  The "snooze" extension gives Sieve the >>>>>> ability >>>>>>     to postpone the filing of an incoming into a target mailbox >>>>>> until a >>>>>>     later point in time. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-snooze/ >>>>>> >>>>>> There are also htmlized versions available at: >>>>>> https://tools.ietf.org/html/draft-ietf-extra-sieve-snooze-00 >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-snooze-00 >>>>>> >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> I have one question about this: >>>>> >>>>> Why does this add a new command? Why can't it just extend both >>>>> keep and fileinto with new arguments? >>>> >>>> >>>> Hi Stephan, >>>> >>>> I suppose we could extend these commands as we are really just >>>> delaying the keep/fileinto until a future (awaken) time. >>>> >>>> So, it could look something like: >>>> >>>> fileinto [:snooze [:tzid ] [:weekdays >>>> ]] >>>> >>>> If we don't like having multiple tagged arguments, we could use a >>>> single string with some kind of ISO or iCalendar recurrence rule, >>>> but that might be more restrictive (I haven't actually sat down and >>>> worked out various examples). >>>> >>>> The only issue would be whether we want/need flags to be set at >>>> snooze time and then set/unset again at awaken time, which the >>>> current spec allows. >>>> >>>> How do others feel about extending keep/fileinto vs. a new command? >> From the point of view of making sure that extensions work with each >> other, not multiplying number of commands is a good thing. But I can >> also see attraction for [manual] script writers for shorter/different >> commands. > > > Agree on both points and I don't have a string preference either way.  > Although extending keep/fileinto is a lot less to document than a new > snooze command and then having to document how fileinto extensions > work with it (which is what the current draft had to do). > > >>> As I think about this more, and look at how :fcc became kind of a >>> mess with a bunch of add-on tagged args, I wonder if using a single >>> structured string for a :snooze option to keep/fileinto might be >>> better.  E.g.: >>> >>> keep :snooze text: >>> { >>>   "until": [ "08:00:00", "12:00:00" ], >>>   "days":  "3[ "1",", "5" ], >>>   "tzid": "America/New_York", >>>   "addflags": [ "\\\\Flagged" ], >>>   "removeflags": [ "\\\\Seen" ] >>> } >>> . >>> ; >>> >> This would mean that you have 2 levels of parsing: first you use a >> generic Sieve parser to parse a Sieve script and then you would have >> to selectively parse certain recognized parameters using a different >> parser. I think this would unnecessarily increase complexity for both >> implementors and script writers, because there are now special cases >> of syntax. > > > Sure, but don't we already have that now with existing structured > strings that need to be parsed/verified?  We have email addresses, > time and date formats, full MIME parts, URIs, and even regex. FWIW, this looks like it MAY be valid (using a test-list as the final argument): fileinto :create "INBOX.foo" (snooze :removeflags [ "\\Seen" ] :weekdays [ "1", "3", "5" ] :tzid "America/New_York" [ "08:00:00", "12:00:00" ]) -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Wed Oct 28 03:22:20 2020 Return-Path: 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 363143A07C3 for ; Wed, 28 Oct 2020 03:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 kCrBxAv3a-xA for ; Wed, 28 Oct 2020 03:22:16 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 508483A067A for ; Wed, 28 Oct 2020 03:22:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1603880535; d=isode.com; s=june2016; i=@isode.com; bh=fqbM+zac6xEBj2icv99emJHHIGusIej0KT4jju+n2qw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=VAgvPcQYjX1OXOpXqK9OwW6ZrUkfsb4wFFo84fFrvqmsap3a8RMdMPNhpQksWrMeRxSKjg WhUIiatdorZca3bXc1uOeipOkQn+bZb+7apfC4sedfPWEfPmAxmoVL+9eDlUaqhS/tSJJ/ JVb/oz8BEee0FRauBwyQAXvvqZLWnOs=; Received: from [192.168.0.5] (97e7601a.skybroadband.com [151.231.96.26]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 28 Oct 2020 10:22:15 +0000 To: Michael Peddemors References: <159705787314.11834.3190103463887221194@ietfa.amsl.com> <9772b986-260e-77da-1dea-4a1ae8010857@fastmail.com> <2411a867-d381-984e-fbd9-c6d7309cbab6@fastmail.com> <941ea682-1264-874d-096e-6654f8707ba7@isode.com> <21368546-3a7f-548b-3fc7-9a0a76419a96@linuxmagic.com> From: Alexey Melnikov Cc: extra@ietf.org Message-ID: <72cb4558-f983-7eff-7308-dd970052c643@isode.com> Date: Wed, 28 Oct 2020 10:22:13 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 In-Reply-To: <21368546-3a7f-548b-3fc7-9a0a76419a96@linuxmagic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 10:22:18 -0000 Hi Michael, On 27/10/2020 17:45, Michael Peddemors wrote: > If you don't mind a stupid question on this.. > > The idea of a 'snooze' feature is something lot's of people are=20 > working on, and maybe it should be a higher level than in 'sieve'? > > Maybe it would be helpful to set solicit feedback on other industry=20 > implementations of this feature.. possibly this should be in IMAP itself? IMHO, I think it depends on how and where the snooze functionality is=20 invoked: 1) If it is a set of static rules, such as "snooze all messages between=20 7am and 9am till 11am" or "snooze all messages from X till 3pm", then=20 Sieve is absolutely the right place for this. Ken's draft doesn't=20 mandate how this is done, but it has 2 reasonable suggestions (one using=20 SMTP and one using IMAP). 2) if snooze is initiated by a user on ad-hoc basis through IMAP, then a=20 separate mechanism would be needed. Best Regards, Alexey > On 2020-10-27 10:36 a.m., Alexey Melnikov wrote: >> Hi Ken, >> >> On 27/10/2020 14:00, Ken Murchison wrote: >>> >>> On 10/22/20 12:16 PM, Ken Murchison wrote: >>>> >>>> On 10/22/20 10:20 AM, Stephan Bosch wrote: >>>>> >>>>> >>>>> On 10/08/2020 13:11, internet-drafts@ietf.org wrote: >>>>>> >>>>>> A New Internet-Draft is available from the on-line=20 >>>>>> Internet-Drafts directories. >>>>>> This draft is a work item of the Email mailstore and eXtensions=20 >>>>>> To Revise or Amend WG of the IETF. >>>>>> >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Sieve Email Filtering: Snooz= e Extension >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : Kenneth Murchison >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Ricardo Signes >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Neil Jenkins >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 : draft-ietf-extra-sieve-snooze-00.txt >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 : 12 >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0Date=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 : 2020-08-07 >>>>>> >>>>>> Abstract: >>>>>> =C2=A0=C2=A0=C2=A0 This document describes the "snooze" extension to = the Sieve=20 >>>>>> email >>>>>> =C2=A0=C2=A0=C2=A0 filtering language.=C2=A0 The "snooze" extension g= ives Sieve the=20 >>>>>> ability >>>>>> =C2=A0=C2=A0=C2=A0 to postpone the filing of an incoming into a targe= t mailbox=20 >>>>>> until a >>>>>> =C2=A0=C2=A0=C2=A0 later point in time. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-extra-sieve-snooze/ >>>>>> >>>>>> There are also htmlized versions available at: >>>>>> https://tools.ietf.org/html/draft-ietf-extra-sieve-snooze-00 >>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-extra-sieve-snooze-0= 0=20 >>>>>> >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of=20 >>>>>> submission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>> >>>>> I have one question about this: >>>>> >>>>> Why does this add a new command? Why can't it just extend both=20 >>>>> keep and fileinto with new arguments? >>>> >>>> >>>> Hi Stephan, >>>> >>>> I suppose we could extend these commands as we are really just=20 >>>> delaying the keep/fileinto until a future (awaken) time. >>>> >>>> So, it could look something like: >>>> >>>> fileinto [:snooze [:tzid ] [:weekdays=20 >>>> ]] >>>> >>>> If we don't like having multiple tagged arguments, we could use a=20 >>>> single string with some kind of ISO or iCalendar recurrence rule,=20 >>>> but that might be more restrictive (I haven't actually sat down and=20 >>>> worked out various examples). >>>> >>>> The only issue would be whether we want/need flags to be set at=20 >>>> snooze time and then set/unset again at awaken time, which the=20 >>>> current spec allows. >>>> >>>> How do others feel about extending keep/fileinto vs. a new command? >> =C2=A0From the point of view of making sure that extensions work with eac= h=20 >> other, not multiplying number of commands is a good thing. But I can=20 >> also see attraction for [manual] script writers for shorter/different=20 >> commands. >>> As I think about this more, and look at how :fcc became kind of a=20 >>> mess with a bunch of add-on tagged args, I wonder if using a single=20 >>> structured string for a :snooze option to keep/fileinto might be=20 >>> better.=C2=A0 E.g.: >>> >>> keep :snooze text: >>> { >>> =C2=A0 "until": [ "08:00:00", "12:00:00" ], >>> =C2=A0 "days": [ "1", "3", "5" ], >>> =C2=A0 "tzid": "America/New_York", >>> =C2=A0 "addflags": [ "\\\\Flagged" ], >>> =C2=A0 "removeflags": [ "\\\\Seen" ] >>> } >>> . >>> ; >>> >> This would mean that you have 2 levels of parsing: first you use a=20 >> generic Sieve parser to parse a Sieve script and then you would have=20 >> to selectively parse certain recognized parameters using a different=20 >> parser. I think this would unnecessarily increase complexity for both=20 >> implementors and script writers, because there are now special cases=20 >> of syntax. >> >> Best Regards, >> >> Alexey >> >> _______________________________________________ >> Extra mailing list >> Extra@ietf.org >> https://www.ietf.org/mailman/listinfo/extra > > > From nobody Wed Oct 28 08:34:36 2020 Return-Path: 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 E5CBE3A0A99 for ; Wed, 28 Oct 2020 08:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 Rhi7lCYCmX1Z for ; Wed, 28 Oct 2020 08:34:32 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F733A0A92 for ; Wed, 28 Oct 2020 08:34:32 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RRC37NAK8G00C014@mauve.mrochek.com> for extra@ietf.org; Wed, 28 Oct 2020 08:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1603898969; bh=RnpqtQLCofksmArz5d10emifGlH0GYP7eCiiOHYDJcY=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=pammUj9ov6ku/Af3G4H1GOldjE1nJsNWCV+bGUYrEWsdscOvXs2LpyQPO57IxwvsW nXnzkrkg7KaEXubB8IvhAvTNluG6A8ZRqiPZM2xhMK511/deaesX6juF/O8gZqmX6g /0yfckgSyKYTGrY6n8ekr6+o4gkWfK7Is8qTNFwE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RRANBSB6000085YQ@mauve.mrochek.com>; Wed, 28 Oct 2020 08:29:26 -0700 (PDT) Cc: extra@ietf.org Message-id: <01RRC37LA1GM0085YQ@mauve.mrochek.com> Date: Wed, 28 Oct 2020 06:12:03 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 27 Oct 2020 10:45:47 -0700" <21368546-3a7f-548b-3fc7-9a0a76419a96@linuxmagic.com> References: <159705787314.11834.3190103463887221194@ietfa.amsl.com> <9772b986-260e-77da-1dea-4a1ae8010857@fastmail.com> <2411a867-d381-984e-fbd9-c6d7309cbab6@fastmail.com> <941ea682-1264-874d-096e-6654f8707ba7@isode.com> <21368546-3a7f-548b-3fc7-9a0a76419a96@linuxmagic.com> To: Michael Peddemors Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 15:34:34 -0000 > If you don't mind a stupid question on this.. Far from being stupid; it cuts to the heart of the purpose of this extension. > The idea of a 'snooze' feature is something lot's of people are working > on, and maybe it should be a higher level than in 'sieve'? I guess future release in SMTP (RFC 4865) qualifies as a "higher level" mechanism, and as the draft notes, it can be leveraged by the sieve implementation to implement snooze. > Maybe it would be helpful to set solicit feedback on other industry > implementations of this feature.. possibly this should be in IMAP itself? Possibly. But the how very much depends on the why. The draft states that the purpose of this extension is to avoid having messages appear in a mailbox until "a more convenient time for the user to act upon them". This begs the question (yes, I'm using the phrase in the sense it has recently acquired) of why a user would be incapable of simply ignoring or otherwise dealing with the message, without the need for any delay. After all, delaying delivery has potentially serious consequences: Suppose a user sets up a delay, some messages are then delayed, and then then for whatever reason the user urgently needs to access these messages. Depending on the way this is implemented, tney may have no means of determining whether or not there are messages in this state, let alone accessing them. [1] So why would someone be willing to accept these consequences? The draft doesn't say, but I think answer is that some clients fail in the most fundamental way imagineable: They make it difficult, if not impossible, for the user to exercise proper control of how they handle their email. And there are several failure modes a delay can address: The lack of a, "Don't sound an alarm for nonurgent messages delivered between 10PM and 6AM" setting, inadequate and/or inconvenient filtering options for displaying recent arrivals, etc. Add to this the fact that users often make use of multiple clients, which invokes a variant of Einar Stefferud's three body problem: When multiple clients are used you end up with the union of the bugs and the intersection of their features. So how does this relate to an IMAP based alternative? Such an alternative is it requires client support to configure. And if clients are going to have to change to support this wouldn't it be better to address the underlying client issue that makes this extension necessary? In contrast, it only takes support in one client to set up sieve filters. And filter configuration is something you already need for other reasons. Finally, if need be it can be an entirely separate client. Ned {1] This is, at a minumum, a security consideration that needs to be documented. From nobody Thu Oct 29 04:00:59 2020 Return-Path: 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 91E7D3A0BE4 for ; Thu, 29 Oct 2020 04:00:57 -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=UyK8lXPP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hN6lKpYf 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 Ak1WO9xrMIg6 for ; Thu, 29 Oct 2020 04:00:56 -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 1A3203A0BE3 for ; Thu, 29 Oct 2020 04:00:56 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3EF735C005E for ; Thu, 29 Oct 2020 07:00:55 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Thu, 29 Oct 2020 07:00:55 -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:subject:content-type; s=fm1; bh=qM761j2 CsRD/KEaFlhO2+f/SuF8cyarLFIJxdSjo8Yc=; b=UyK8lXPPEHuUnPwp+6W6Hkr bEwot6EBffA1CojLhkaanSu4Ofph6TcbhM9sN2vHm8TxUWcMcpzGx+ga6cM5WX/W qLtXsyUwx9JbhPoFnBI00rmD2HYeJji0Lw2z9/a/P9WJhnvTsFPDESPN7pkLFcnk RvDd21E7xC6kIeOJmfOWa8uEspa92MZ1ombtn98Ey6yuX/s4JBzH6U3g8uvH+1Lc tDNHk2q4rzCE54xpH6f6/tOfKd84h/aauBVwMJ6hpykAO+imxM7efXmPw/ze8b34 zph7XZaIfDdFb1b2PAzmnphWBHQHn32lLCt78EU5TsgJiW36PsypJVKzUG5Zo0A= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=qM761j 2CsRD/KEaFlhO2+f/SuF8cyarLFIJxdSjo8Yc=; b=hN6lKpYfyONUuFQImkESzs DPtTO1e9reeR4nrYc6zYle8R2USz7hjB32mp22PpbbMta+PaHg1OnbSAEhdAXkM+ j+rUfrvVtHwu0GElVyH6zwgcsFnvQarQWxE213ngJ27EmLmSHiKuSAP1WYnqNZUJ n/GhtefSZiyBKMYI5unIykm7cPk7tjcwcRmQORUCmmXlVTox0rphAqURdtq2zcSq eTu00Muj0V6UsHkVm8nsbuQCi2UjLOX1VcJxkJ5sQz50hpAFM/H3kwORCOWIYvJC NdLHLJmd+Q/RXP3vhCbHdk69YX6WG+pHJejSFzmTAV7qAVrB2xnaIySzpCbWMEFg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrleefgddvfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevvdetvdduleekhf eghfetfeettdelhfehfeevffevleekuddtudffieevjeevhfenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A97C31800A3; Thu, 29 Oct 2020 07:00:54 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-530-g8da6958-fm-20201021.003-g69105b13-v35 Mime-Version: 1.0 Message-Id: <730cbb05-a1cc-4274-9aef-553b08289f26@dogfood.fastmail.com> In-Reply-To: <01RRC37LA1GM0085YQ@mauve.mrochek.com> References: <159705787314.11834.3190103463887221194@ietfa.amsl.com> <9772b986-260e-77da-1dea-4a1ae8010857@fastmail.com> <2411a867-d381-984e-fbd9-c6d7309cbab6@fastmail.com> <941ea682-1264-874d-096e-6654f8707ba7@isode.com> <21368546-3a7f-548b-3fc7-9a0a76419a96@linuxmagic.com> <01RRC37LA1GM0085YQ@mauve.mrochek.com> Date: Thu, 29 Oct 2020 22:00:54 +1100 From: "Neil Jenkins" To: extra@ietf.org Content-Type: multipart/alternative; boundary=2e78218e59e042948bc6339ae7519007 Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 11:00:58 -0000 --2e78218e59e042948bc6339ae7519007 Content-Type: text/plain On Thu, 29 Oct 2020, at 00:12, Ned Freed wrote: > This begs the question (yes, I'm using the phrase in the sense it has recently > acquired) of why a user would be incapable of simply ignoring or otherwise > dealing with the message, without the need for any delay. After all, delaying > delivery has potentially serious consequences: Suppose a user sets up a delay, > some messages are then delayed, and then then for whatever reason the user > urgently needs to access these messages. Depending on the way this is > implemented, tney may have no means of determining whether or not there are > messages in this state, let alone accessing them. [1] The draft is intentionally a bit generic to try to allow for different implementations; perhaps that is a mistake. To give more specifics about what *we* implemented and why: * Users can explicitly snooze email using our interface. This moves the message to a Snoozed mailbox, then moves it back to the original mailbox at the time appointed by the user. The API for this is a custom JMAP extension. * We also added the `snooze` sieve command to allow users to set up rules to do this on delivery. This allows you to, for example, batch all marketing email so it only arrives in the inbox once a day but other email comes through immediately. The message is delivered to the Snoozed mailbox, so is immediately available via search or browsing if the user needs it before the snooze time, but it doesn't interrupt their workflow. Since the Snooze action is now fairly widespread, it would be great to standardise an API so different clients can interoperate on this. The difficulty, as always, lies in working out what features and nuances are common enough to be standardised, and what's best left as vendor-specific extensions. Neil. --2e78218e59e042948bc6339ae7519007 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, 29 Oct = 2020, at 00:12, Ned Freed wrote:
This begs the question (yes, I'm using the phrase i= n the sense it has recently
acquired) of why a user would = be incapable of simply ignoring or otherwise
dealing with = the message, without the need for any delay. After all, delaying
delivery has potentially serious consequences: Suppose a user set= s up a delay,
some messages are then delayed, and then the= n for whatever reason the user
urgently needs to access th= ese messages. Depending on the way this is
implemented, tn= ey may have no means of determining whether or not there are
messages in this state, let alone accessing them. [1]

The draft is intentionally a bit generic to t= ry to allow for different implementations; perhaps that is a mistake. To= give more specifics about what we implemented and why:
=
  • Users can explicitly snooze email using our interface. This move= s the message to a Snoozed mailbox, then moves it back to the original m= ailbox at the time appointed by the user. The API for this is a custom J= MAP extension.
  • We also added the snooze sieve command to allow users to set up rules to do this on delivery= . This allows you to, for example, batch all marketing email so it only = arrives in the inbox once a day but other email comes through immediatel= y. The message is delivered to the Snoozed mailbox, so is immediately av= ailable via search or browsing if the user needs it before the snooze ti= me, but it doesn't interrupt their workflow.
Since the= Snooze action is now fairly widespread, it would be great to standardis= e an API so different clients can interoperate on this. The difficulty, = as always, lies in working out what features and nuances are common enou= gh to be standardised, and what's best left as vendor-specific extension= s.

Neil.
--2e78218e59e042948bc6339ae7519007-- From nobody Thu Oct 29 04:02:58 2020 Return-Path: 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 D8CBA3A0BE5 for ; Thu, 29 Oct 2020 04:02:56 -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=BBQoLzsg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fWesjF7z 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 buaLMTNoE4IK for ; Thu, 29 Oct 2020 04:02:55 -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 812DD3A0BE4 for ; Thu, 29 Oct 2020 04:02:55 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id BB4055C00E3 for ; Thu, 29 Oct 2020 07:02:54 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Thu, 29 Oct 2020 07:02:54 -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:subject:content-type; s=fm1; bh=Lb4j9Q9 8hmRxNyMuL0c3FBgvQ+wOyQdCelvTkbgOt5U=; b=BBQoLzsgF9zie/8sdBmT2g7 6mQ61HSxXirf525HdEoDUCVJQOHudUbXzlWCbGKGn/33+NBEwrEF7w9L/PUAxaKL +e0wqe4+MwG3qtl0W3HLYtj7QHk9kYkc4//osrS8WDq95ufp7oFlheDuKX0/HNMH 91U8UwVdmHg5cMqDmSgcNEtwsYISE6OA5dlmtNTsFyo8IH+QeCwaWOBshbVNkEYq T8knEdITt1kvCvkhutwN69DB3lzu6HqLp9y0olXKbAlZpVzzYGLRjMJwyDV4GQj5 XDKSDhu3Bk4e154YIPjKyXNWJGfYaKjRDnD98O4VEBn89jpeM2HEbuIZBVnsAnQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=Lb4j9Q 98hmRxNyMuL0c3FBgvQ+wOyQdCelvTkbgOt5U=; b=fWesjF7zeuc/8ioEfESOyd IAEvASzWvDft5fww5+SfsbF1SsA1R7gViKwkv3Oy6L+mafb3Av3vZQ8brm+epbmz C/2Zkoglc+EHGPQ3+M7JoXV/YXlNtBUTvLfkAVMUwkxBdtscZMy0sIZnzWpaKukj q67DwzyUpPnU/xKJ/EJ4luTWmbuKIG0waZOZnEYLNZJPPE/P/DWlhdjmiliEfti0 ZcwKwjA6ZlnaEv/sF1Kvv1rz3BK2mgJDoqGwz6AfmZjqzeZMxm7bpiM76itM2mFT 7HTwbpNn220GvCWdFSJzW41Vh460Hk8eHXlYFQx+EttlFzOwGAX7oxzpQ9p8AhQQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrleefgddvgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevvdetvdduleekhf eghfetfeettdelhfehfeevffevleekuddtudffieevjeevhfenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3F8451800A9; Thu, 29 Oct 2020 07:02:54 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-530-g8da6958-fm-20201021.003-g69105b13-v35 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <159705787314.11834.3190103463887221194@ietfa.amsl.com> <9772b986-260e-77da-1dea-4a1ae8010857@fastmail.com> Date: Thu, 29 Oct 2020 22:02:53 +1100 From: "Neil Jenkins" To: extra@ietf.org Content-Type: multipart/alternative; boundary=c7fa337cc3744a99be31bf610dcf801d Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 11:02:57 -0000 --c7fa337cc3744a99be31bf610dcf801d Content-Type: text/plain On Mon, 26 Oct 2020, at 17:58, Arnt Gulbrandsen wrote: > On Monday 26 October 2020 06:22:54 CET, Neil Jenkins wrote: > > I have no objection to extending fileinto rather than a new > > command, but for our use case we need to preserve the ability to > > set flags separately both on delivery and at awaken time. > > Could you elaborate? I'm just curious here. Sure. On delivery the users normal rules apply, so they may want to flag the message or mark it as read. When the message is unsnoozed we set a `$new` keyword at the awaken time and use this in our interface to mark it out specially to the user until the message is opened (when we clear the keyword). Neil. --c7fa337cc3744a99be31bf610dcf801d Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, 26 Oct = 2020, at 17:58, Arnt Gulbrandsen wrote:
On Monday 26 October 2020 06:22:54 CET, Nei= l Jenkins wrote:
> I have no objection to extending fil= einto rather than a new 
> command, but for our us= e case we need to preserve the ability to 
> set f= lags separately both on delivery and at awaken time.

<= /div>
Could you elaborate? I'm just curious here.

Sure. On delivery the users normal rules apply, = so they may want to flag the message or mark it as read. When the messag= e is unsnoozed we set a $new keyword at the awa= ken time and use this in our interface to mark it out specially to the u= ser until the message is opened (when we clear the keyword).

Neil.
--c7fa337cc3744a99be31bf610dcf801d-- From nobody Thu Oct 29 04:30:26 2020 Return-Path: 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 F2B653A0B58 for ; Thu, 29 Oct 2020 04:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com 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 K9LA5vMs2MC7 for ; Thu, 29 Oct 2020 04:30:22 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376403A0992 for ; Thu, 29 Oct 2020 04:30:22 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RRD8Z7OBQ800CDL8@mauve.mrochek.com> for extra@ietf.org; Thu, 29 Oct 2020 04:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1603970717; bh=KF0YVaVnHOSvDo6TDVXYIQqaq7Pg+Z8ZT6ldQTOqvsU=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Uco1eJ1fYYj0wIag0wDvtYRu7EcZcucdFv+QW2kbl1kTvamV9W1gTMUuCdjW/+cb3 ngJdHNy1cUNCQgbcKV/xlHtXGGUtnzRxr/eg6iwx97jYaAIWcAW7gPh3+PO2MAG0TQ JchD4xrk4d4ZnY0J9rZ2fEHiAnaeo1eO25Rf+p+8= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RRC448N05C0085YQ@mauve.mrochek.com>; Thu, 29 Oct 2020 04:25:13 -0700 (PDT) Cc: extra@ietf.org Message-id: <01RRD8Z5JJF60085YQ@mauve.mrochek.com> Date: Thu, 29 Oct 2020 04:13:41 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 29 Oct 2020 22:00:54 +1100" <730cbb05-a1cc-4274-9aef-553b08289f26@dogfood.fastmail.com> References: <159705787314.11834.3190103463887221194@ietfa.amsl.com> <9772b986-260e-77da-1dea-4a1ae8010857@fastmail.com> <2411a867-d381-984e-fbd9-c6d7309cbab6@fastmail.com> <941ea682-1264-874d-096e-6654f8707ba7@isode.com> <21368546-3a7f-548b-3fc7-9a0a76419a96@linuxmagic.com> <01RRC37LA1GM0085YQ@mauve.mrochek.com> <730cbb05-a1cc-4274-9aef-553b08289f26@dogfood.fastmail.com> To: Neil Jenkins Archived-At: Subject: Re: [Extra] I-D Action: draft-ietf-extra-sieve-snooze-00.txt X-BeenThere: extra@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Email mailstore and eXtensions To Revise or Amend List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 11:30:24 -0000 > On Thu, 29 Oct 2020, at 00:12, Ned Freed wrote: > > This begs the question (yes, I'm using the phrase in the sense it has recently > > acquired) of why a user would be incapable of simply ignoring or otherwise > > dealing with the message, without the need for any delay. After all, delaying > > delivery has potentially serious consequences: Suppose a user sets up a delay, > > some messages are then delayed, and then then for whatever reason the user > > urgently needs to access these messages. Depending on the way this is > > implemented, tney may have no means of determining whether or not there are > > messages in this state, let alone accessing them. [1] > The draft is intentionally a bit generic to try to allow for different > implementations; perhaps that is a mistake. Perhaps. OTOH, nailing down the mechanism makes widespread implementation far less likely, and as noted below, doesn't really address the issue I raised. > To give more specifics about what *we* implemented and why: > * Users can explicitly snooze email using our interface. This moves the > message to a Snoozed mailbox, then moves it back to the original mailbox at the > time appointed by the user. The API for this is a custom JMAP extension. If you do it this way it's possible for a user to find the snoozed messages and "unsnooze" them, even with an unextended client. Which is good. > * We also added the `snooze` sieve command to allow users to set up rules to > do this on delivery. This allows you to, for example, batch all marketing email > so it only arrives in the inbox once a day but other email comes through > immediately. I have to say I still regard it as something of a client issue that it cannot classify and present messages in the INBOX without having to hide them somewhere else. Heck, the client I'm using right now has this ability, and it was coded in the 1990s. > The message is delivered to the Snoozed mailbox, so is immediately > available via search or browsing if the user needs it before the snooze time, > but it doesn't interrupt their workflow. But there's still an issue: Most users won't know how to do this. So this still has to be called out as a security consideration. > Since the Snooze action is now fairly widespread, it would be great to > standardise an API so different clients can interoperate on this. The > difficulty, as always, lies in working out what features and nuances are common > enough to be standardised, and what's best left as vendor-specific extensions. Implementability also enters into it. Depending on a JMAP extension at tihs point may be... premature. Ned