From nobody Sun Nov 1 19:17:01 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F823A0CB8 for ; Sun, 1 Nov 2020 19:16:59 -0800 (PST) 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=j8kE+3s2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SsMYI79f 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 xxT--_ZVV-V2 for ; Sun, 1 Nov 2020 19:16:58 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082863A0CB5 for ; Sun, 1 Nov 2020 19:16:58 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 498AF5C0056 for ; Sun, 1 Nov 2020 22:16:57 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Sun, 01 Nov 2020 22:16:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm1; bh=pBDdaqR5k83i2D1ST30Sj2jvwO17OWf6H4ltbPx Y+ak=; b=j8kE+3s2V+8J4jejRtuKDA41nYFrIBaDfA6CLnCNmI+3tOlXQJMi4pW DDqyX1A9xRy1bDjRSY2z0c/czIuJI3TxXqlmdL3Mn/4R8jHd41B/3v3JNben5AyR /ML8E7SPCRMBVSkjYmlDW/tq0mCTxVPIqIr0QOHmDdpnDWvRW7GUNAgjzyKnT6OT hRx627K1fbmMX+XE501A6lczxL8pbHBgnuN9nCA0WncVVohxSThUFVuKH2wa0dIX KV2r0sWL4IvWhiiDTobiITiTGaOMdnS3uI8HtfTFoD3zT0wEEpQwctG/OxyTdpQJ ToVoNodEZ4RoOn1psMmkcCHYA/zjfIQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=pBDdaqR5k83i2D1ST30Sj2jvwO17O Wf6H4ltbPxY+ak=; b=SsMYI79frYrAoiD37HeUJyzStK8kJKLCvzA0+b7E1SE/+ 4Kjxhbr12xrRLg5KGovQmahg4XvrYVgI2AIn9RK25gv8v59tkkDZu1YUptxNhh25 KkVllUBG0Fkebk2q3iEV1mvCghSZWqfFEsi1/dYJfFNr3MXajwHehTwIx8zo3Fd0 5Y6Q2TU/i+q705NNJq+yVNON4PJbGyBfedgJLGO/DWyewitA8yGOJa20HDdd4dF7 +NhVM4lwlioEV/rzdqiUqEWOB/lwJny1DiqmuWR0NDhwK5zpEPtfr4Li/5vpSYdr /WukFZ/AgoI54L7GHbL+d4XgGbWQ+KvRorinbgJHw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddttddgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpefhjeehkeejkeehve eutdejteeihffffeduiedttdejhfelteevueehudeltdeuffenucffohhmrghinhepihgv thhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0DB60180093; Sun, 1 Nov 2020 22:16:56 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-530-g8da6958-fm-20201021.003-g69105b13-v35 Mime-Version: 1.0 x-forwarded-message-id: <160428648942.7062.7826596556949036083@ietfa.amsl.com> Message-Id: Date: Mon, 02 Nov 2020 14:16:35 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=05742cfccebf49349841d6adc0b4f8a6 Archived-At: Subject: [Jmap] Fwd: New Version Notification for draft-gondwana-jmap-blob-00.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 03:17:00 -0000 --05742cfccebf49349841d6adc0b4f8a6 Content-Type: text/plain As promised a very rough first draft to show the shape of things. In particular, it's probably worth looking at whether the 'catenate' logic makes sense to include directly in 'set' or whether it should be a separate item. Also need to work out how to report which blob is missing for a catenate error! Finally, I'm not totally happy with the "lookup" logic. Right now Cyrus has "Blob/get" doing what I'm creating with lookup, but of course that's kinda non-standard usage of 'get' and I'd like to change it. Bron. ----- Original message ----- From: internet-drafts@ietf.org To: Bron Gondwana Subject: New Version Notification for draft-gondwana-jmap-blob-00.txt Date: Monday, November 02, 2020 14:08 A new version of I-D, draft-gondwana-jmap-blob-00.txt has been successfully submitted by Bron Gondwana and posted to the IETF repository. Name: draft-gondwana-jmap-blob Revision: 00 Title: JMAP Blob management extension Document date: 2020-11-02 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-gondwana-jmap-blob-00.txt Status: https://datatracker.ietf.org/doc/draft-gondwana-jmap-blob/ Html: https://www.ietf.org/archive/id/draft-gondwana-jmap-blob-00.html Htmlized: https://tools.ietf.org/html/draft-gondwana-jmap-blob-00 Abstract: The JMAP base protocol (RFC8620) provides the ability to upload and download arbitrary binary data via HTTP PUT and GET on defined endpoint. This binary data is called a "Blob". This extension adds additional ways to handle Blobs, by making inline method calls within a standard JMAP request. 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. The IETF Secretariat -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --05742cfccebf49349841d6adc0b4f8a6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
As promised a very rough first draft to show the shape of = things.

In particular, it's probably worth looking at wheth= er the 'catenate' logic makes sense to include directly in 'set' or whet= her it should be a separate item.

Also need to work out h= ow to report which blob is missing for a catenate error!

= Finally, I'm not totally happy with the "lookup" logic.  Right now = Cyrus has "Blob/get" doing what I'm creating with lookup, but of course = that's kinda non-standard usage of 'get' and I'd like to change it.
<= /div>

Bron.

----- Original message -----
= To: Bron Gondwana <brong@fa= stmailteam.com>
Subject: New Version Notification f= or draft-gondwana-jmap-blob-00.txt
Date: Monday, November = 02, 2020 14:08


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

Name: draft-gondwana-jmap-blob
<= /div>
Revision: 00
Title: JMAP Blob management extension
Document date: 2020-11-02
Group: Individual Submission
Pages: 7


Abstract:
   The J= MAP base protocol (RFC8620) provides the ability to upload and
=
   download arbitrary binary= data via HTTP PUT and GET on defined
   endpoint.  This binary data is called a "Blob= ".

   This extension adds additional ways to ha= ndle Blobs, by making inline
=    method calls within a standard JMAP request.

            = ;            = ;            = ;            = ;            = ;            = ;          
<= div style=3D"font-family:Arial;">

Please note that it may= take a couple of minutes from the time of submission
until the htmlized version and diff are availab= le at tools.ietf.org.

The IETF Secretariat




--
  Bron Gondwana, CEO, = Fastmail Pty Ltd
  brong@fastmail= team.com


--05742cfccebf49349841d6adc0b4f8a6-- From nobody Mon Nov 2 03:35:08 2020 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 667E93A0E41; Mon, 2 Nov 2020 03:35:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <160431690732.22434.10293492942158194310@ietfa.amsl.com> Date: Mon, 02 Nov 2020 03:35:07 -0800 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-sieve-02.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 11:35:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the JSON Mail Access Protocol WG of the IETF. Title : JMAP for Sieve Scripts Author : Kenneth Murchison Filename : draft-ietf-jmap-sieve-02.txt Pages : 25 Date : 2020-11-02 Abstract: This document specifies a data model for managing Sieve scripts on a server using JMAP. Open Issues o Should we introduce an "isIncluded" or "isInUse" filter/sort condition for the /query method to locate scripts which are included by others? o Do we need any (rate) limits for /test? o Should ":fcc" and associated arguments (e.g., ":flags", ":create":, etc) reported in the /test response be in their own "fcc" sub-object rather than listed inline with the rest of the arguments for the action? The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-sieve/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-sieve-02 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-sieve-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-sieve-02 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 Mon Nov 2 04:15:53 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5563A0E99 for ; Mon, 2 Nov 2020 04:15:52 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=uOFBQtFU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bM+DDSYI 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 mApxpJqqGXv5 for ; Mon, 2 Nov 2020 04:15:47 -0800 (PST) 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 145F83A0E75 for ; Mon, 2 Nov 2020 04:15:47 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 0B89E1030 for ; Mon, 2 Nov 2020 07:15:45 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 02 Nov 2020 07:15:46 -0500 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; s=fm1; bh=qSDuKiq3jN1qUNGgJrEunmCH9vr G5zY0OxaY2qdTn1g=; b=uOFBQtFUChsL1GjE0RqG3n0wO8YUXsAVGtF3FJ2+BH0 V1/8qLHvhHowlsNPLglzwp+ijZ2rkElIe5GnPk5HugtmMQtVFZvwnYv4I4nIook0 IMchymBLH6xyjs5U6j4mG3Wnc8Rq35uJIraHEY82F6UtCbRI3wVLJ4j7euSVmHC3 I6lpXpwfIBb5NaviFFHxh9e9RZJ7ksnzWJ25uO4Y44ji2BgUHTHrsWndLqVSxTJn wdZHw4u2+BW6cyqLTdFym45YjjOvcf8S2023zpTzs/Z8Obal4dVk8yo2xDmQEGwc 49KkoiIvkSdhamRDQTV4auP5w6k31L+eLzXtU/DXU8Q== 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=qSDuKi q3jN1qUNGgJrEunmCH9vrG5zY0OxaY2qdTn1g=; b=bM+DDSYIFCica9h2F3G5wP vHI3OrB8x0ez+kp2wur3KoP9IkpDmUuA4RDHQjK/Bfmf59opnCdWL0T9TgXC/2yb 4QN5+mBi5EthkPcCizKyunsEEcx7V/9PYEHrnkZ4w3y/iupnNS5rQ+bX+YTwjR3B SHVjHRwpLFw/ysL3/C4uw3upcgYSj6vfrDOYv880DtvMi2Y5Skt0YGOeUxwOMIYF psTWN9aPTjogBVgc/S8I09+c2ENW0eX9KRfE80jP3m6Npx7c0hA1x2+0w7j3lqzg Shq+KrWda8jyEO5NakAt8PfZSiuz5kuJOZ/bJVjO6ORPIFsgKG84yUc91N8hujGg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddtuddgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehfrghs thhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhepffeuhfevgffgvdduuedvteeije euvddvkedugeegvdffvefgudffueeileeggeegnecuffhomhgrihhnpehivghtfhdrohhr 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 695C23064680 for ; Mon, 2 Nov 2020 07:15:45 -0500 (EST) To: jmap@ietf.org References: From: Ken Murchison Message-ID: Date: Mon, 2 Nov 2020 07:15:43 -0500 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: multipart/alternative; boundary="------------05811DEAFC4B13E49830DC48" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Fwd: New Version Notification for draft-gondwana-jmap-blob-00.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2020 12:15:53 -0000 This is a multi-part message in MIME format. --------------05811DEAFC4B13E49830DC48 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit FYI, you have this updating RFC 5228, which is obviously an artifact of reusing an existing draft as a template. On 11/1/20 10:16 PM, Bron Gondwana wrote: > As promised a very rough first draft to show the shape of things. > > In particular, it's probably worth looking at whether the 'catenate' > logic makes sense to include directly in 'set' or whether it should be > a separate item. > > Also need to work out how to report which blob is missing for a > catenate error! > > Finally, I'm not totally happy with the "lookup" logic.  Right now > Cyrus has "Blob/get" doing what I'm creating with lookup, but of > course that's kinda non-standard usage of 'get' and I'd like to change it. > > Bron. > > ----- Original message ----- > From: internet-drafts@ietf.org > To: Bron Gondwana > > Subject: New Version Notification for draft-gondwana-jmap-blob-00.txt > Date: Monday, November 02, 2020 14:08 > > > A new version of I-D, draft-gondwana-jmap-blob-00.txt > has been successfully submitted by Bron Gondwana and posted to the > IETF repository. > > Name: draft-gondwana-jmap-blob > Revision: 00 > Title: JMAP Blob management extension > Document date: 2020-11-02 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/archive/id/draft-gondwana-jmap-blob-00.txt > > Status: https://datatracker.ietf.org/doc/draft-gondwana-jmap-blob/ > > Html: https://www.ietf.org/archive/id/draft-gondwana-jmap-blob-00.html > > Htmlized: https://tools.ietf.org/html/draft-gondwana-jmap-blob-00 > > > > Abstract: >    The JMAP base protocol (RFC8620) provides the ability to upload and >    download arbitrary binary data via HTTP PUT and GET on defined >    endpoint.  This binary data is called a "Blob". > >    This extension adds additional ways to handle Blobs, by making inline >    method calls within a standard JMAP request. > > > > > 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. > > The IETF Secretariat > > > > > -- >   Bron Gondwana, CEO, Fastmail Pty Ltd >   brong@fastmailteam.com > > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Kenneth Murchison Senior Software Developer Fastmail US LLC --------------05811DEAFC4B13E49830DC48 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

FYI, you have this updating RFC 5228, which is obviously an artifact of reusing an existing draft as a template.


On 11/1/20 10:16 PM, Bron Gondwana wrote:

As promised a very rough first draft to show the shape of things.

In particular, it's probably worth looking at whether the 'catenate' logic makes sense to include directly in 'set' or whether it should be a separate item.

Also need to work out how to report which blob is missing for a catenate error!

Finally, I'm not totally happy with the "lookup" logic.  Right now Cyrus has "Blob/get" doing what I'm creating with lookup, but of course that's kinda non-standard usage of 'get' and I'd like to change it.

Bron.

----- Original message -----
To: Bron Gondwana <brong@fastmailteam.com>
Subject: New Version Notification for draft-gondwana-jmap-blob-00.txt
Date: Monday, November 02, 2020 14:08


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

Name: draft-gondwana-jmap-blob
Revision: 00
Title: JMAP Blob management extension
Document date: 2020-11-02
Group: Individual Submission
Pages: 7


Abstract:
   The JMAP base protocol (RFC8620) provides the ability to upload and
   download arbitrary binary data via HTTP PUT and GET on defined
   endpoint.  This binary data is called a "Blob".

   This extension adds additional ways to handle Blobs, by making inline
   method calls within a standard JMAP request.

                                                                                  


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.

The IETF Secretariat




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



_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
--------------05811DEAFC4B13E49830DC48-- From nobody Wed Nov 4 01:13:34 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295763A0DE6 for ; Wed, 4 Nov 2020 01:13:33 -0800 (PST) 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=Ww1Xmc5B; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BWqSk82T 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 OK_h0va9xylo for ; Wed, 4 Nov 2020 01:13:31 -0800 (PST) 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 011913A0DE4 for ; Wed, 4 Nov 2020 01:13:30 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1D19E5C00CB for ; Wed, 4 Nov 2020 04:13:30 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 04 Nov 2020 04:13:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=IVX2Bx2 g6srY7RehzS4HkQe8aWWJzNK+T1qRvij9pgg=; b=Ww1Xmc5B9TWazLmy0Sm7MEb jUHd/Wks0Zeah8nLOzu47ZzejzQ45KaDAUc56Qggm0IJQ1weiAVeX+8LNZfgT9Ee tC3CaVXh8pBIRuzr6padOO4f4RbquXmW1oxK9yT1oeSMGZ/5R4bWiKSp2yNAfpWD 0nZTAszQa/lB8Ew4QUG7Dw/w27Q71w6nKBX6EfPppuf9sy+P9vvX7hj1ZhvxaGEc pR81XYK19zYtM2OUiYFIDhmok1fxhNdM69TX1dCcym26rkTso4OeXhHkcHXOE2ad +OAWB5BYaP7NqC9EmznLvL7Ro5rLmhrxoNpt4bjkGl+jw+Vf6vxlyz91nn8QtCQ= = 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=IVX2Bx 2g6srY7RehzS4HkQe8aWWJzNK+T1qRvij9pgg=; b=BWqSk82TBpWdQDDHTh66ro PC/cWRuDadumea3ixnJKGHlSRhG0U0kbQ1MxZTTX7WAkIqLisdupDNIA8JkyeIpF +ylArdPP1nrYd2qeTNMpX+neMrbhjLX0xdPwbUW3gZ11u6iFl0JBYHrKTOMJu+2u b0wVB4LNaHPMKIm9cVOIGAh6KBYa5mqw+X9VTwr7mq5V0lN9Fs1BBt3BMUn8VkTq PCHNh2pGuI9WTPGMIgupCtrZHc0+xoe8rTWo1+iI4YwE89yg+u10Neixvv1LCeeI t2XbTPjV1MLdg5g6yJh/r53PW/IkX1Y34VISsewaMt15P64I0VTUvdX/KX9xt7PA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddthedgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffvdekfeegle eiueettddtffehveevffefkeduvddttdekiefgjeduvdfhvdduleenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 882FA1800B3; Wed, 4 Nov 2020 04:13:29 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-565-g5179928-fm-20201104.001-g5179928e Mime-Version: 1.0 Message-Id: <4b3060b8-fc5c-47c2-bb7f-329073d1786b@dogfood.fastmail.com> In-Reply-To: References: Date: Wed, 04 Nov 2020 20:13:08 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=b29a97bdd21944ba93064ac53c285015 Archived-At: Subject: Re: [Jmap] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draft-gondw?= =?utf-8?q?ana-jmap-blob-00=2Etxt?= X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2020 09:13:33 -0000 --b29a97bdd21944ba93064ac53c285015 Content-Type: text/plain Dammit! Thanks, will fix when allowed. On Mon, Nov 2, 2020, at 23:15, Ken Murchison wrote: > FYI, you have this updating RFC 5228, which is obviously an artifact of reusing an existing draft as a template. > > On 11/1/20 10:16 PM, Bron Gondwana wrote: >> As promised a very rough first draft to show the shape of things. >> >> In particular, it's probably worth looking at whether the 'catenate' logic makes sense to include directly in 'set' or whether it should be a separate item. >> >> Also need to work out how to report which blob is missing for a catenate error! >> >> Finally, I'm not totally happy with the "lookup" logic. Right now Cyrus has "Blob/get" doing what I'm creating with lookup, but of course that's kinda non-standard usage of 'get' and I'd like to change it. >> >> Bron. >> >> ----- Original message ----- >> From: internet-drafts@ietf.org >> To: Bron Gondwana >> Subject: New Version Notification for draft-gondwana-jmap-blob-00.txt >> Date: Monday, November 02, 2020 14:08 >> >> >> A new version of I-D, draft-gondwana-jmap-blob-00.txt >> has been successfully submitted by Bron Gondwana and posted to the >> IETF repository. >> >> Name: draft-gondwana-jmap-blob >> Revision: 00 >> Title: JMAP Blob management extension >> Document date: 2020-11-02 >> Group: Individual Submission >> Pages: 7 >> URL: https://www.ietf.org/archive/id/draft-gondwana-jmap-blob-00.txt >> Status: https://datatracker.ietf.org/doc/draft-gondwana-jmap-blob/ >> Html: https://www.ietf.org/archive/id/draft-gondwana-jmap-blob-00.html >> Htmlized: https://tools.ietf.org/html/draft-gondwana-jmap-blob-00 >> >> >> Abstract: >> The JMAP base protocol (RFC8620) provides the ability to upload and >> download arbitrary binary data via HTTP PUT and GET on defined >> endpoint. This binary data is called a "Blob". >> >> This extension adds additional ways to handle Blobs, by making inline >> method calls within a standard JMAP request. >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> >> >> >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >> >> >> >> _______________________________________________ Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap >> > -- Kenneth Murchison Senior Software Developer Fastmail US LLC > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --b29a97bdd21944ba93064ac53c285015 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Dammit!  Thanks, will fix when allowed.

On Mon, Nov 2, 2020, a= t 23:15, Ken Murchison wrote:

FYI, you have this updating RFC 5228, which is obviousl= y an artifact of reusing an existing draft as a template.

On 11/1/20 10:16 PM, Bron Gondwana wrote:

As promised a very rough first draft to show the shape of things.

In particular,= it's probably worth looking at whether the 'catenate' logic makes sense to include directly in 'set' or whether it should be a separate item.

Also need to work out how to report which blob is missing for a catenate error!

Finally, I'm not totally happy with the "lookup" logic.  Right now Cyrus has "Blob/get" do= ing what I'm creating with lookup, but of course that's kinda non-standard usage of 'get' and I'd like to change it.
=

Bron.

--= --- Original message -----
To: B= ron Gondwana <brong@fastmai= lteam.com>
Subject: New Version Notification for draft-gondwana-jmap-blob-00.txt
Date: Monday, Nove= mber 02, 2020 14:08


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

Name: draft-gondwana-jma= p-blob
Revision: 00
=
Title: JMAP Blob management extension
Document = date: 2020-11-02
Group: Indiv= idual Submission
Pages: 7
=
   The JMAP base protocol (RFC8620) provides the ability to upload and
   download arbitrary binary data via HTTP PUT and GET on defined
   endpoint.  This binary data is called a "Blob".

   This extension= adds additional ways to handle Blobs, by making inline
   method calls within a standard JMAP request.

    =             =             =             =             =             =             =       


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.

The IETF = Secretariat


<= br>

--
  Bron Gondwana, CEO, Fastmail Pty Ltd



_____________=
__________________________________
Jmap mailing list
J=
map@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

--=20=

Kenneth Murchison
Senior Software Developer
Fastmail US LLC
__________________________________________= _____
Jmap mailing list



--b29a97bdd21944ba93064ac53c285015-- From nobody Sun Nov 15 17:48:38 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79353A0E46 for ; Sun, 15 Nov 2020 17:48:36 -0800 (PST) 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=HJwP5jwG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Lwz1aHBs 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 Z3Mw-m6qrc1R for ; Sun, 15 Nov 2020 17:48:34 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F343A0E48 for ; Sun, 15 Nov 2020 17:48:34 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 99BACB58 for ; Sun, 15 Nov 2020 20:48:33 -0500 (EST) Received: from imap38 ([10.202.2.88]) by compute2.internal (MEProxy); Sun, 15 Nov 2020 20:48:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=yKPQQFt EZPPgefe8pPbc+Lbz0/V35Xz7J/SYG6SGclE=; b=HJwP5jwGdFijKd4s1iGzopx OpQr3dcTVnpFH3t0hwARizjhChLkJDkjraOxn6D43dVj4mJgjUVHa5MlRJVxeixl En2WOl9wK/RLTcO4Ntng4DDthNPyiMQuQSBI3kULioWutjQ8EmLHkCUfjBH4FtXP qU7J81weOH8r87zUs+MhwuaFVlWi67VPhmLdLgK2Ofks5I7GsXL5MLi3d526nobN gFeWSJePJTH7tihrp6cCnMRMtAtWC6RxAYHH9uCiQwZVIeXQYcNlf58CpBDl6Ysn epIoX1nLJ+7sSEyKGVy4JB/cXOX2apJgJkbQHuZGaM1moKE9CBcClktMvMjRfkg= = 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=yKPQQF tEZPPgefe8pPbc+Lbz0/V35Xz7J/SYG6SGclE=; b=Lwz1aHBskfktQctv6wL2Wn WM22TxAaS1iO9pX1pZhzI49RvVn3H72zlXdfoGxBwuy0kjW2iGcep8DCe6gQZld+ xdZzLwSi2ujdHn1XK1IYUBFNUinsB/lf2G/UHjf/F239XTH9F3z6n1VcK1E0hC+P +Oy5Vh7NXcbT6ogGmMGC/pKOwuLvX8RgkW/eUdSj50DUlV7T86ciGYaZIWVBBUuP orG642NW62VtLBc3Z3zNvOhQrUS8/EuwxNcbDJ3ED6rr5f3di5shdnem1Gixg5MI B8FYwKyiAmesDfBI8n9oNCfLbsyPh4cWgBF2HF7A0tW9JTsy99+enjCymocn8N5w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeftddggedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffvdekfeegle eiueettddtffehveevffefkeduvddttdekiefgjeduvdfhvdduleenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DCEBE4AA0069; Sun, 15 Nov 2020 20:48:32 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <0b058abb-2d2e-4691-bcec-eeffe0f4d89e@dogfood.fastmail.com> In-Reply-To: <4b3060b8-fc5c-47c2-bb7f-329073d1786b@dogfood.fastmail.com> References: <4b3060b8-fc5c-47c2-bb7f-329073d1786b@dogfood.fastmail.com> Date: Mon, 16 Nov 2020 12:48:11 +1100 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=43121b8c5aee4d15aac8ec39238588d5 Archived-At: Subject: Re: [Jmap] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draft-gondw?= =?utf-8?q?ana-jmap-blob-00=2Etxt?= X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2020 01:48:37 -0000 --43121b8c5aee4d15aac8ec39238588d5 Content-Type: text/plain As promised, v01 is now uploaded with the updating fixed, and also the working group name fixed, and also an example for Blob/set. Bron. On Wed, Nov 4, 2020, at 20:13, Bron Gondwana wrote: > Dammit! Thanks, will fix when allowed. > > On Mon, Nov 2, 2020, at 23:15, Ken Murchison wrote: >> FYI, you have this updating RFC 5228, which is obviously an artifact of reusing an existing draft as a template. >> >> On 11/1/20 10:16 PM, Bron Gondwana wrote: >>> As promised a very rough first draft to show the shape of things. >>> >>> In particular, it's probably worth looking at whether the 'catenate' logic makes sense to include directly in 'set' or whether it should be a separate item. >>> >>> Also need to work out how to report which blob is missing for a catenate error! >>> >>> Finally, I'm not totally happy with the "lookup" logic. Right now Cyrus has "Blob/get" doing what I'm creating with lookup, but of course that's kinda non-standard usage of 'get' and I'd like to change it. >>> >>> Bron. >>> >>> ----- Original message ----- >>> From: internet-drafts@ietf.org >>> To: Bron Gondwana >>> Subject: New Version Notification for draft-gondwana-jmap-blob-00.txt >>> Date: Monday, November 02, 2020 14:08 >>> >>> >>> A new version of I-D, draft-gondwana-jmap-blob-00.txt >>> has been successfully submitted by Bron Gondwana and posted to the >>> IETF repository. >>> >>> Name: draft-gondwana-jmap-blob >>> Revision: 00 >>> Title: JMAP Blob management extension >>> Document date: 2020-11-02 >>> Group: Individual Submission >>> Pages: 7 >>> URL: https://www.ietf.org/archive/id/draft-gondwana-jmap-blob-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-gondwana-jmap-blob/ >>> Html: https://www.ietf.org/archive/id/draft-gondwana-jmap-blob-00.html >>> Htmlized: https://tools.ietf.org/html/draft-gondwana-jmap-blob-00 >>> >>> >>> Abstract: >>> The JMAP base protocol (RFC8620) provides the ability to upload and >>> download arbitrary binary data via HTTP PUT and GET on defined >>> endpoint. This binary data is called a "Blob". >>> >>> This extension adds additional ways to handle Blobs, by making inline >>> method calls within a standard JMAP request. >>> >>> >>> >>> >>> 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. >>> >>> The IETF Secretariat >>> >>> >>> >>> >>> -- >>> Bron Gondwana, CEO, Fastmail Pty Ltd >>> brong@fastmailteam.com >>> >>> >>> >>> _______________________________________________ Jmap mailing list >>> Jmap@ietf.org >>> https://www.ietf.org/mailman/listinfo/jmap >>> >> -- Kenneth Murchison Senior Software Developer Fastmail US LLC >> _______________________________________________ >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap >> > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --43121b8c5aee4d15aac8ec39238588d5 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
As promised, v01 is now uploaded with the updating fi= xed, and also the working group name fixed, and also an example for Blob= /set.

Bron.
On Wed, Nov 4, 2020, at 20:13, Bron Gondwana wrote:
Dammit!  Thanks, will fix when allowed.

On Mon, Nov 2, 2020, at 23:15,= Ken Murchison wrote:

FYI, you have this updating RFC 5228, which is obviously an artifact of reusing an existing draft as a template.

On 11/1/20 10:16 PM, Bron Gondwana wrote:

As promised a very rough first draft to show the shape of things.

In particular,= it's probably worth looking at whether the 'catenate' logic makes sense to include directly in 'set' or whether it should be a separate item.

Also need to work out how to report which blob is missing for a catenate error!

Finally, I'm not totally happy with the "lookup" logic.  Right now Cyrus has "Blob/get" do= ing what I'm creating with lookup, but of course that's kinda non-standard usage of 'get' and I'd like to change it.
=

Bron.

--= --- Original message -----
To: B= ron Gondwana <brong@fastmai= lteam.com>
Subject: New Version Notification for draft-gondwana-jmap-blob-00.txt
Date: Monday, Nove= mber 02, 2020 14:08


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

Name: draft-gondwana-jma= p-blob
Revision: 00
=
Title: JMAP Blob management extension
Document = date: 2020-11-02
Group: Indiv= idual Submission
Pages: 7
=
   The JMAP base protocol (RFC8620) provides the ability to upload and
   download arbitrary binary data via HTTP PUT and GET on defined
   endpoint.  This binary data is called a "Blob".

   This extension= adds additional ways to handle Blobs, by making inline
   method calls within a standard JMAP request.

    =             =             =             =             =             =             =       


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.

The IETF = Secretariat


<= br>

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
<= div class=3D"qt-qt-signature">  brong@fastmailteam.com



_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

--=
=20
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
__________________________________________= _____
Jmap mailing list





--
  Bron Gondwana, CEO, Fastmail Pty Ltd<= br>
  brong@fastmailteam.com


--43121b8c5aee4d15aac8ec39238588d5-- From nobody Wed Nov 18 18:28:31 2020 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4423A09AC for ; Wed, 18 Nov 2020 18:28:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160575290956.7306.728896426141328655@ietfa.amsl.com> Date: Wed, 18 Nov 2020 18:28:29 -0800 From: IETF Secretariat Archived-At: Subject: [Jmap] Milestones changed for jmap WG X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 02:28:30 -0000 Changed milestone "Adopt a document for managing Sieve via JMAP", resolved as "Done". Changed milestone "Adopt a document for creating Blobs via JMAP method call", set due date to December 2020 from August 2020. Changed milestone "Adopt a document defining JMAP access to addressbooks", set due date to January 2021 from October 2020. Changed milestone "Submit JMAP Calendars document to the IESG", set due date to January 2021 from November 2020. Changed milestone "Submit document for Blobs via JMAP to the IESG", set due date to January 2021 from November 2020. Changed milestone "Submit JMAP Quotas document to the IESG", set due date to March 2021 from August 2020. Changed milestone "Submit JMAP S/MIME signature validation document to the IESG", set due date to March 2021 from August 2020. Changed milestone "Adopt a document for S/MIME key management and server side signing/encryption", set due date to March 2021 from October 2020. Changed milestone "Submit JSON Contact document to IESG", set due date to May 2021 from December 2020. Changed milestone "Submit document with guidance for implementation of IMAP servers and proxies (Informational)", set due date to July 2021 from December 2020. URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Wed Nov 18 18:35:08 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B573A09F4 for ; Wed, 18 Nov 2020 18:35:07 -0800 (PST) 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=KdjeMB+s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rDwfq2UB 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 JzgXU9OAJKsv for ; Wed, 18 Nov 2020 18:35:05 -0800 (PST) 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 CFC9E3A09F0 for ; Wed, 18 Nov 2020 18:35:04 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 001825C01A8; Wed, 18 Nov 2020 21:35:02 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 18 Nov 2020 21:35:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm1; bh=qUcI hDyExfDDE5J8dEooHxFtjCgrObIMFB9o/ZNwmx8=; b=KdjeMB+sM1x6ZxlOw5jb IKh4GLNYc6+fWVXy9GLVmGUoDYy/pdo7ZPRlP0SBOsm56nbA4wW5OvV83z/5mJeu Bt48wD05IvCgRoN/YD39YOzDD/KS68tsEgL8b6+cGpz7KpG7L9bn11GhIr7LTBaE 7CF8pmYw/xcYcXPbLAHf4esvPWsItmRUdl97ciTPHxEeKLcd0dvJiRLherOryWCF BzVRj3eQHZPS+YSanRGN529Nc6pVEwhzBA/6a7xIAhLOsuI2cWm4tnxdY8PcdvHn xXY2IG78aIQQsd3qRnMQMpIKazX3/sssMmIxrkQPvp219X1q2lx44qHjKwnm/nAF XQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qUcIhD yExfDDE5J8dEooHxFtjCgrObIMFB9o/ZNwmx8=; b=rDwfq2UBexjYtsCZH9hwf7 sen1HUbeXlqSmIEphLHOJxlTkPvuWM1wao3HsOLy+VLN9mgnavPkEdumPBYeUZ0A x3NjxRbP+cOfYP9klUE2mCiJn16i2oV0QckfIpJpI6/M4DuNjf48vWreXU18PL4P fcogE3mzUVte4Mcm0GBJixaDcN9y4oJIWfuwZ6MKuKPT2lO7zunBVL7VtqmNa/oG XUPLRYAiB8dRCRIjBCL/h2WDCpOxkG+o3HwETnSRnU1iMuDqKoFWJuUqWB+nSVPy nDvztEBptDmESU84oEmkCR2ZacWXgQo2Yg5fx1pctxbGp6tGsMY2wTYgkf/eF7TQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefiedggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepffdvkeefgeelieeutedttdffheevvefffeekuddvtddt keeigfejuddvhfdvudelnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhm rghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D73EE1802D3; Wed, 18 Nov 2020 21:35:01 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <522c72f3-a4d3-46ae-b62b-bc87302d64a3@dogfood.fastmail.com> In-Reply-To: <160193187289.4946.17482930539468511819@ietfa.amsl.com> References: <160193187289.4946.17482930539468511819@ietfa.amsl.com> Date: Thu, 19 Nov 2020 13:34:40 +1100 From: "Bron Gondwana" To: jmap@ietf.org Cc: "Raphael OUAZANA" , "Benjamin Kaduk" Content-Type: multipart/alternative; boundary=c62d93845e7b4d5c9f5115eeb3e96d7c Archived-At: Subject: Re: [Jmap] =?utf-8?q?Benjamin_Kaduk=27s_Discuss_on_draft-ietf-jmap-m?= =?utf-8?q?dn-15=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 02:35:07 -0000 --c62d93845e7b4d5c9f5115eeb3e96d7c Content-Type: text/plain Hi Raphael, This discuss is blocking MDN progress. Can you please look at providing clarifying text here, or discuss with Ben what he wants. Ben - the intent is that the client can override the value if it needs to. Generally it won't need to, but sometimes there will be preferred canonical versions of addresses. For example: Fastmail tries to hide the user's username entirely from the sender if they sent to an external alias, so that their username can remain secret from those who contact them on that alias - so we would override finalRecipient to be the alias name at our boundary, even though the actual final recipient inside our system was their primary address. The text does require that the server validate that the client is allowed to use the value it sets as finalRecipient. Cheers, Bron. On Tue, Oct 6, 2020, at 08:04, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-jmap-mdn-15: Discuss > > 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-jmap-mdn/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This should be quite easy to resolve; I'm just not sure yet which > direction the resolution will be. > > I think we should be a little more clear about whether the client can > override the finalRecipient calculation (or just provide a suggestion to > do so, or not give any input at all, etc.): the description of the > finalRecipient property of an MDN object says that "if set, it > overrides the value that would be calculated by the server from the > Identity", which to me suggests that the client could set something to > override the server (if the server sua sponte did something different > that would typically be an "exception", not an "override"), but later on > in Section 2.1 we say that "[w]hen sending the MDN, the server is in > charge of generating the "originalRecipient", "finalRecipient" and > "originalMessageId" fields according to the [RFC8098] specification. I > do not see discussion in RFC 8098 of client intput into the server's > populating of this field, so I'm unsure whether/where the client has > input. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for noting the `jq` validation in the sheperd writeup! > > Section 1 > > A client can have to deal with MDNs in different ways: > > (editorial) "have to deal with" seems like it can be read as implying > obligation to do so (even though the majuscule "MUST" is not used); it > seems like this is just attempting to enumerate the cases in which an > MDN might be encountered or need to be interacted with. > > 2. When sending an email message, an MDN can be requested. This > must be done with the help of a header, and is already specified > by [RFC8098] and can already be handled by [RFC8621] this way. > > (nit?) "header" or "header field"? (We get this a lot for HTTP and I've > forgotten if SMTP uses the same rule...) > > 3. When receiving an MDN, the MDN could be related to an existing > sent message. This is already covered by [RFC8621] in the > EmailSubmission object. [...] > > (The "DeliveryStatus" member, in particular, right?) > > Section 1.3 > > The value of this "urn:ietf:params:jmap:mdn" property is an empty > object in the account's "accountCapabilities" property. > > I presume it's also an empty object in the server's "capabilities" > property as well (and we should probably say so). > > Section 2 > > It's a little interesting to me that RFC 8261 did not define or mention > specific access to the User-Agent string but we need to have a specific > reportingUA here. I do recognize that it's (an optional) part of the > RFC 8098 ABNF, and that RFC 8098 mentions the relevant security > considerations already. Perhaps a subtle nudge in this section that the > "null" option may have better privacy properties would be appropriate. > (We may also revisit whether/what to include in the examples for > reportingUA.) > > o finalRecipient: "String|null" Recipient for which the MDN is being > issued. if set, it overrides the value that would be calculated > by the server from the Identity. > > Could we get a couple more words to support the definite article? (I am > not sure which Identity is "the" Identity just from this context; it is > only later on that we discover that there is an identityId in the > MDN/send arguments.) > > o extensionFields: "String[String]|null" Object where keys are > extension-field names and values are extension-field values. > > I used process of elimination to conclude that these are RFC 8098 > extension-field ABNF names/values; I don't know if there's a good way to > hint the reader of that fact. > > o actionMode: "String" This MUST be one of the following strings: > "manual-action" / "automatic-action" > > o sendingMode: "String" This MUST be one of the following strings: > "mdn-sent-manually" / "mdn-sent-automatically" > > I recognize that this is entirely the responsibility of RFC 8098 and not > this document, but is it valid to combine "automatic-action" with > "mdn-sent-manually"? I am not 100% I understand the semantics. > > Section 2.1 > > The latter because of the implicit call > to Email/set and the use of Identities, described below. [...] > > nit: does this sentence have a verb? > > The following already registered SetError would mean: > > nit: these are the SetError types, right? > > Section 3.x > > It might be helpful to use a different creation ID for the different > classes of example (though not required by the protocol). > > Section 3.1 > > "extension": { > "X-EXTENSION-EXAMPLE": "example.com" > } > > nit(?): somehow I thought X- extensions were generally thought to not be > needed/useful anymore. > > Section 5 > > In order to enforce trust regarding the relation between the user > sending an email message and the identity of this user, the server > SHOULD validate in conformance to the provided Identity that the user > is permitted to use the finalRecipient value and return a > forbiddenFrom error if not. > > "enforce" and "SHOULD" are not words I usually see in combination. > > > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --c62d93845e7b4d5c9f5115eeb3e96d7c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Raphael,
This discuss is blocking MDN pr= ogress.  Can you please look at providing clarifying text here, or = discuss with Ben what he wants.

Ben - the intent is that = the client can override the value if it needs to.  Generally it won= 't need to, but sometimes there will be preferred canonical versions of = addresses.  For example: Fastmail tries to hide the user's username= entirely from the sender if they sent to an external alias, so that the= ir username can remain secret from those who contact them on that alias = - so we would override finalRecipient to be the alias name at our bounda= ry, even though the actual final recipient inside our system was their p= rimary address.

The text does require that the server val= idate that the client is allowed to use the value it sets as finalRecipi= ent.

Cheers,
<= br>Bron.

On Tu= e, Oct 6, 2020, at 08:04, Benjamin Kaduk via Datatracker wrote:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-jmap-mdn-15: Discus= s

When responding, please keep the subject line intact an= d reply to all
email addresse= s included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
=


Please refer to <= a href=3D"https://www.ietf.org/iesg/statement/discuss-criteria.html">htt= ps://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS an= d COMMENT positions.


The document, along with other ballot positions, can be found he= re:


--------------= --------------------------------------------------------
DISCUSS:
----------------------------------------------------------------= ------

This should be quite easy to resolve; I'm just not = sure yet which
direction the = resolution will be.

I think we should be a little more cl= ear about whether the client can
override the finalRecipient calculation (or just provide a suggestio= n to
do so, or not give any i= nput at all, etc.): the description of the
finalRecipient property of an MDN object says that "if set= , it
overrides the value that= would be calculated by the server from the
Identity", which to me suggests that the client could set= something to
override the se= rver (if the server sua sponte did something different
that would typically be an "exception", not an= "override"), but later on
in= Section 2.1 we say that "[w]hen sending the MDN, the server is in
charge of generating the "original= Recipient", "finalRecipient" and
"originalMessageId" fields according to the [RFC8098] specification.=   I
do not see discussio= n in RFC 8098 of client intput into the server's
populating of this field, so I'm unsure whether/wher= e the client has
input.


------------------= ----------------------------------------------------
COMMENT:
--------------------------------------------------------------------= --

Thank you for noting the `jq` validation in the sheper= d writeup!

Section 1

   A client= can have to deal with MDNs in different ways:

(editorial= ) "have to deal with" seems like it can be read as implying
obligation to do so (even though the maju= scule "MUST" is not used); it
seems like this is just attempting to enumerate the cases in which an
MDN might be encountered or ne= ed to be interacted with.
   2.  When send= ing an email message, an MDN can be requested.  This
       must b= e done with the help of a header, and is already specified
       by [R= FC8098] and can already be handled by [RFC8621] this way.

(nit?) "header" or "header field"?  (We get this a lot for HTTP an= d I've
forgotten if SMTP uses= the same rule...)

=
   3.  When receiving a= n MDN, the MDN could be related to an existing
       sent message.&nbs= p; This is already covered by [RFC8621] in the
       EmailSubmission o= bject.  [...]

=
(The "DeliveryStatus" member, in parti= cular, right?)

Section 1.3

   Th= e value of this "urn:ietf:params:jmap:mdn" property is an empty
   object in the account's = "accountCapabilities" property.

I presume it's also an em= pty object in the server's "capabilities"
property as well (and we should probably say so).
=

Section 2

It's a little interesting to me that RFC = 8261 did not define or mention
specific access to the User-Agent string but we need to have a specifi= c
reportingUA here.  I d= o recognize that it's (an optional) part of the
RFC 8098 ABNF, and that RFC 8098 mentions the relevan= t security
considerations alr= eady.  Perhaps a subtle nudge in this section that the
"null" option may have better privacy pro= perties would be appropriate.
(We may also revisit whether/what to include in the examples for
reportingUA.)

 &= nbsp; o  finalRecipient: "String|null" Recipient for which the MDN = is being
   &n= bsp;  issued.  if set, it overrides the value that would be ca= lculated
   &n= bsp;  by the server from the Identity.

Could we get = a couple more words to support the definite article?  (I am
not sure which Identity is "the" Ide= ntity just from this context; it is
only later on that we discover that there is an identityId in the=
MDN/send arguments.)

   o  extensionFields: "String[String]|null" Obje= ct where keys are
  = ;    extension-field names and values are extension-field= values.

I used process of elimination to conclude that t= hese are RFC 8098
extension-f= ield ABNF names/values; I don't know if there's a good way to
<= div style=3D"font-family:Arial;">hint the reader of that fact.
=

   o  actionMode: "String" This MUST be one of the = following strings:
 &nbs= p;    "manual-action" / "automatic-action"

   o  sendingMode: "String" This MUST be one of the foll= owing strings:
  &n= bsp;   "mdn-sent-manually" / "mdn-sent-automatically"

I recognize that this is entirely the responsibility of RFC 8098 = and not
this document, but is= it valid to combine "automatic-action" with
"mdn-sent-manually"?  I am not 100% I understand th= e semantics.

Section 2.1

   = ;            = ;            = ;      The latter because of the implicit call<= br>
   to Email/set and= the use of Identities, described below.  [...]

nit:= does this sentence have a verb?

   The followi= ng already registered SetError would mean:

nit: these are= the SetError types, right?
<= br>
Section 3.x

It= might be helpful to use a different creation ID for the different
classes of example (though not req= uired by the protocol).

<= /div>
Section 3.1

 &= nbsp;           "exten= sion": {
   &n= bsp;           "X-EXTE= NSION-EXAMPLE": "example.com"
            = ; }

nit(?): somehow I thought X- extensions were generall= y thought to not be
needed/us= eful anymore.

Section 5

   In or= der to enforce trust regarding the relation between the user
   sending an email message an= d the identity of this user, the server
   SHOULD validate in conformance to the provided I= dentity that the user
 &= nbsp; is permitted to use the finalRecipient value and return a
   forbiddenFrom error if n= ot.

"enforce" and "SHOULD" are not words I usually see in= combination.



___________________________= ____________________
Jmap mai= ling list


<= div id=3D"sig56629417">
--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--c62d93845e7b4d5c9f5115eeb3e96d7c-- From nobody Wed Nov 18 22:18:12 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07943A0FB3; Wed, 18 Nov 2020 22:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, 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 fSKAM03RAZKo; Wed, 18 Nov 2020 22:17:57 -0800 (PST) Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) (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 286103A0FF8; Wed, 18 Nov 2020 22:17:47 -0800 (PST) Received: by mail-vs1-f45.google.com with SMTP id y73so2434828vsc.5; Wed, 18 Nov 2020 22:17:47 -0800 (PST) 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=5f3oYkLfE5VE9n1OImjdqyHEdcbgWhM8GFsUNG47Nx0=; b=E70pLKu6bD11r91kEhsyJfYcKdMJSrKqXQEo2HqQklQG+66zpLbFFnOXiww29oa7rn jlihu58ysfHxw0wqkmdtxbI9RTq2zFT8gT8dMJ+C610VaxCJ7DxJ4pEA58pOXqgxO1QM kD2XbubLZd2nMODjBEm1R9BaVxQEDxYj5cmH756OMu4fmeQHNRdUEpdlLcVceL9u6v4w QTYzNqyUgYNqaSC55m73It+W7JFoLN4mk9Zr0geLfCszyPgyTm9lj+J4faYZtCf2jcjO PIyNM179afyoyYH5U6DRr8q5T5wNBbWV18L4fZQ5bia5MFhTVMq5mOpxG/2LAlo+FJQK tCww== X-Gm-Message-State: AOAM530Agg7+F2D+s5vEclJOWbrXHYr2H3lGSXnnbEnNwBudUZWCLPIO AdJcMAK/pD9EppRC38MXM4EVUYTQnOuqXEd33kJOwUBH3FJ2gw== X-Google-Smtp-Source: ABdhPJxJ9s5Awy6WViux82TOennWDtqMVGT+059jAG683Ym5wMFuzUWasSDhyxSQ5Iea7BR1a5RIkmYIeWs2a19YBkA= X-Received: by 2002:a67:f05:: with SMTP id 5mr7085290vsp.39.1605766665834; Wed, 18 Nov 2020 22:17:45 -0800 (PST) MIME-Version: 1.0 References: <160193187289.4946.17482930539468511819@ietfa.amsl.com> In-Reply-To: <160193187289.4946.17482930539468511819@ietfa.amsl.com> From: Barry Leiba Date: Thu, 19 Nov 2020 01:17:34 -0500 Message-ID: To: Benjamin Kaduk Cc: The IESG , IETF JMAP Mailing List , Bron Gondwana , draft-ietf-jmap-mdn@ietf.org, jmap-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-mdn-15: (with DISCUSS and COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 06:18:06 -0000 Rapha=C3=ABl, I've seen no response from you on this, and it's been around six weeks. Will you please address Ben's comments so we can move ahead? Thanks, Barry On Mon, Oct 5, 2020 at 5:04 PM Benjamin Kaduk via Datatracker wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-jmap-mdn-15: Discuss > > 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-jmap-mdn/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This should be quite easy to resolve; I'm just not sure yet which > direction the resolution will be. > > I think we should be a little more clear about whether the client can > override the finalRecipient calculation (or just provide a suggestion to > do so, or not give any input at all, etc.): the description of the > finalRecipient property of an MDN object says that "if set, it > overrides the value that would be calculated by the server from the > Identity", which to me suggests that the client could set something to > override the server (if the server sua sponte did something different > that would typically be an "exception", not an "override"), but later on > in Section 2.1 we say that "[w]hen sending the MDN, the server is in > charge of generating the "originalRecipient", "finalRecipient" and > "originalMessageId" fields according to the [RFC8098] specification. I > do not see discussion in RFC 8098 of client intput into the server's > populating of this field, so I'm unsure whether/where the client has > input. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for noting the `jq` validation in the sheperd writeup! > > Section 1 > > A client can have to deal with MDNs in different ways: > > (editorial) "have to deal with" seems like it can be read as implying > obligation to do so (even though the majuscule "MUST" is not used); it > seems like this is just attempting to enumerate the cases in which an > MDN might be encountered or need to be interacted with. > > 2. When sending an email message, an MDN can be requested. This > must be done with the help of a header, and is already specified > by [RFC8098] and can already be handled by [RFC8621] this way. > > (nit?) "header" or "header field"? (We get this a lot for HTTP and I've > forgotten if SMTP uses the same rule...) > > 3. When receiving an MDN, the MDN could be related to an existing > sent message. This is already covered by [RFC8621] in the > EmailSubmission object. [...] > > (The "DeliveryStatus" member, in particular, right?) > > Section 1.3 > > The value of this "urn:ietf:params:jmap:mdn" property is an empty > object in the account's "accountCapabilities" property. > > I presume it's also an empty object in the server's "capabilities" > property as well (and we should probably say so). > > Section 2 > > It's a little interesting to me that RFC 8261 did not define or mention > specific access to the User-Agent string but we need to have a specific > reportingUA here. I do recognize that it's (an optional) part of the > RFC 8098 ABNF, and that RFC 8098 mentions the relevant security > considerations already. Perhaps a subtle nudge in this section that the > "null" option may have better privacy properties would be appropriate. > (We may also revisit whether/what to include in the examples for > reportingUA.) > > o finalRecipient: "String|null" Recipient for which the MDN is being > issued. if set, it overrides the value that would be calculated > by the server from the Identity. > > Could we get a couple more words to support the definite article? (I am > not sure which Identity is "the" Identity just from this context; it is > only later on that we discover that there is an identityId in the > MDN/send arguments.) > > o extensionFields: "String[String]|null" Object where keys are > extension-field names and values are extension-field values. > > I used process of elimination to conclude that these are RFC 8098 > extension-field ABNF names/values; I don't know if there's a good way to > hint the reader of that fact. > > o actionMode: "String" This MUST be one of the following strings: > "manual-action" / "automatic-action" > > o sendingMode: "String" This MUST be one of the following strings: > "mdn-sent-manually" / "mdn-sent-automatically" > > I recognize that this is entirely the responsibility of RFC 8098 and not > this document, but is it valid to combine "automatic-action" with > "mdn-sent-manually"? I am not 100% I understand the semantics. > > Section 2.1 > > The latter because of the implicit call > to Email/set and the use of Identities, described below. [...] > > nit: does this sentence have a verb? > > The following already registered SetError would mean: > > nit: these are the SetError types, right? > > Section 3.x > > It might be helpful to use a different creation ID for the different > classes of example (though not required by the protocol). > > Section 3.1 > > "extension": { > "X-EXTENSION-EXAMPLE": "example.com" > } > > nit(?): somehow I thought X- extensions were generally thought to not be > needed/useful anymore. > > Section 5 > > In order to enforce trust regarding the relation between the user > sending an email message and the identity of this user, the server > SHOULD validate in conformance to the provided Identity that the user > is permitted to use the finalRecipient value and return a > forbiddenFrom error if not. > > "enforce" and "SHOULD" are not words I usually see in combination. > > > From nobody Thu Nov 19 05:01:57 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC4D3A102D for ; Thu, 19 Nov 2020 05:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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.001, 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 Ocz-HuUfpVGi for ; Thu, 19 Nov 2020 05:01:47 -0800 (PST) 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 641553A0EED for ; Thu, 19 Nov 2020 05:01:40 -0800 (PST) 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 D199F6A2CF for ; Thu, 19 Nov 2020 14:01:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1605790896; bh=lIi0HFNKWiFMwbM4ELsofWfyGI4hEqEdONHVu0aYIUY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=eps9/1ZMw6kSVYNDg/axjBLvSTlRVyB2ptfIXLkKxtLbSuhqkVJfX7bdVqcHxrl0g iTjJoszjHAjDGNR57n37r5htbUgMAXHGbRQ5bDQcm6AX3JuHwdVuokmX5MzMEfocdM JeG+zjDueYEX5+WRfH6um85Lo7kqvSTdlShKSwlR8WkpEmNv9QUQa/O8NyMXP/NvM2 bq1dPhQF6iVKBAAaX91rp68Y1oblsB3g2l5Lpo+kQNJslS3F0iuEvq2EGiWCaiH4uB 8tRsD6Oc/ek2X+0YMg+3RKJhaAMhA2Zi048a7uzvn9LKYRhB/oh2600hoxvpChzQCJ kniCu/vSFEeuQ== Received: from [10.168.3.2] (unknown [10.217.131.10]) (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 A05603C0369 for ; Thu, 19 Nov 2020 14:01:36 +0100 (CET) To: jmap@ietf.org References: <160431690732.22434.10293492942158194310@ietfa.amsl.com> From: Stephan Bosch Message-ID: <36838c43-aefb-c7f9-d973-2e6f8df5e78f@open-xchange.com> Date: Thu, 19 Nov 2020 14:01:34 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <160431690732.22434.10293492942158194310@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-sieve-02.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 13:01:56 -0000 On 02/11/2020 12:35, 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 JSON Mail Access Protocol WG of the IETF. > > Title : JMAP for Sieve Scripts > Author : Kenneth Murchison > Filename : draft-ietf-jmap-sieve-02.txt > Pages : 25 > Date : 2020-11-02 > > Abstract: > This document specifies a data model for managing Sieve scripts on a > server using JMAP. > > Open Issues > > o Should we introduce an "isIncluded" or "isInUse" filter/sort > condition for the /query method to locate scripts which are > included by others? > > o Do we need any (rate) limits for /test? > > o Should ":fcc" and associated arguments (e.g., ":flags", > ":create":, etc) reported in the /test response be in their own > "fcc" sub-object rather than listed inline with the rest of the > arguments for the action? > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jmap-sieve/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-jmap-sieve-02 > https://datatracker.ietf.org/doc/html/draft-ietf-jmap-sieve-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-sieve-02 > First, I think this now misses a nice way to upload/download raw Sieve scripts (i.e. without JSON string escaping). As said earlier in this mailing list, using the blob upload/download facility would be better and it is more consistent with jmap:mail in my opinion. Second, I remember RFC 5784 (https://tools.ietf.org/html/rfc5784). That is an effort to map the Sieve language grammar to XML. We could (optionally of course) do the same in this extension using JSON rather than XML and make it easier for clients to evaluate, display, and manipulate Sieve scripts without the need to write a Sieve parser/generator. This could be a "content:as(json)" field, or something like that. Or is that just too complex? Regards, Stephan. From nobody Thu Nov 19 05:40:25 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF503A136C for ; Thu, 19 Nov 2020 05:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_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 vT5Xqpfq0nyg for ; Thu, 19 Nov 2020 05:40:16 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 795723A1115 for ; Thu, 19 Nov 2020 05:39:39 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS6NIEABA800AXMJ@mauve.mrochek.com> for jmap@ietf.org; Thu, 19 Nov 2020 05:34:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1605792874; bh=Ixhjkv+vDGeUhFz7X5DlIGhVEosCRQQQELfouPkvs9g=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=AmB0rripS4+6yiTVmDEsj0Nvr6iO5f4AEFif942N2cklGkgPP0dcWSOavLHc1pK+D NIFCnBZgbIktRNeJF8GIpMEa6YoIGxmHEHD2e6stGvVYzhUZJPAIpxqbELEs05sn3z 07t2sdczN+HgBKorxTH+g98UKjMRHp4DT9rdA2Us= 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 <01RS4XGHZZF4005PTU@mauve.mrochek.com>; Thu, 19 Nov 2020 05:34:32 -0800 (PST) Cc: jmap@ietf.org Message-id: <01RS6NIC0KZC005PTU@mauve.mrochek.com> Date: Thu, 19 Nov 2020 05:17:01 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 19 Nov 2020 14:01:34 +0100" <36838c43-aefb-c7f9-d973-2e6f8df5e78f@open-xchange.com> References: <160431690732.22434.10293492942158194310@ietfa.amsl.com> <36838c43-aefb-c7f9-d973-2e6f8df5e78f@open-xchange.com> To: Stephan Bosch Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-sieve-02.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 13:40:24 -0000 I think there's a more fundamental question we need to ask here: Is the managesieve model the right one for handling sieves in JMAP? By "managesieve model" I'm referring to the underlying data model where there are multiple named sieves and one active sieve. My specific concern is interoperability between clients that fully support this model and clients that don't. A client that doesn't want to offer the ability to have multiple sieves is likely going to just present the active script and let you mess with it. Things can get interesting if another client that does support multiple scripts comes along and switches to another script. Of course there are ways of handling this, some requiring protocol/server changes and others requiring extra vigilance on the part of clients. But before we start exploring those - and given the ratio of single script to multiscript clients I've seen I don't really think we have a choice - I think we need to ask if multiscript facilities are something we want. Ned P.S. I speak as someone who has implemented managesieve server side without any real difficulty, and forsee no difficulty doing the same in JMAP. This is all about client needs. From nobody Thu Nov 19 06:16:33 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3AE53A105B for ; Thu, 19 Nov 2020 06:16:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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.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=fastmail.com header.b=IElSQA0Q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RvBrkgxu 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 Fy69aI1iehB0 for ; Thu, 19 Nov 2020 06:16:25 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602143A107F for ; Thu, 19 Nov 2020 06:15:58 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id DD5C1424 for ; Thu, 19 Nov 2020 09:15:56 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 19 Nov 2020 09:15:57 -0500 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=a +QSpYISlXXI2jwYpwG/2b6QeO7iKO8t3db4iPRaTag=; b=IElSQA0QRM8Xy8USc yMhbMXWd5+0wabO2wa2bTTFeKn2YqE84joRbMtfY9UjCW4JSEIf1uaNGW6OOc6WL AXguCi86Cc8/wV4+jCOh7XsjoXzWDVtWoerfuslJzoKw+qu9RtQv5ixxIwbUwAt9 qO8gV9FzsAgkmUVKYg4sqZbDcFR9KBVuhTx/kl6Bpw4faltnnVFgwefl7hEL4TK9 Qr+X4N4XH7iDtKtr4tEFRCKvp8C77fe/mUpgwyCcTBCAqKtw7p7rvZ1GEpxf7T5O oOR9iNrEfZ2iaaOMMl3bHoqjfPjF9zRoifw1idfs3Yia3owtC2L6rDxGnxirc8jY QhfpQ== 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=a+QSpYISlXXI2jwYpwG/2b6QeO7iKO8t3db4iPRaT ag=; b=RvBrkgxu6Ft50/Oi4mJWJW6ynVkgs7kcT7OjEbPcbp/PuUOwsU8Lw5mCB YbSoQA2XzN9GWKO7JBKtcgabHFYyezJYI7/mLNJ17fuzsbIe58ybW9Avt1Zw0KLS 2T3EnAYs4mp/PDllHMED5yc3ZMYJA5OADRcLJom81tXAHgYgMsgQ1eMZEqNlIAJJ u0G6Y/drhlDpj7ctlMV89wAxkdgY4qW+ojhanSw/8s6xM/soOHuEr5osfgEStv7G Y9eddYutIomJc4FxPumiKG4v04vA4NgS98EbGGGPXOckIUpbaptMBu87uW0aj0sd P5ljSoZyxFdZM737qT3UEa78c8ZAQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefjedgieduucetufdoteggodetrfdotf 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 241823280063 for ; Thu, 19 Nov 2020 09:15:56 -0500 (EST) To: jmap@ietf.org References: <160431690732.22434.10293492942158194310@ietfa.amsl.com> <36838c43-aefb-c7f9-d973-2e6f8df5e78f@open-xchange.com> From: Ken Murchison Message-ID: Date: Thu, 19 Nov 2020 09:15:55 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <36838c43-aefb-c7f9-d973-2e6f8df5e78f@open-xchange.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-sieve-02.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 14:16:32 -0000 Hi Stephan, On 11/19/20 8:01 AM, Stephan Bosch wrote: > > First, I think this now misses a nice way to upload/download raw Sieve > scripts (i.e. without JSON string escaping). As said earlier in this > mailing list, using the blob upload/download facility would be better > and it is more consistent with jmap:mail in my opinion. The reason that we chose to provide the content as an argument to /set, /validate, and /test (unless using scriptId) is to avoid the extra roundtrip of having to first upload the script in a separate request. That said, a client could leverage https://tools.ietf.org/html/draft-gondwana-jmap-blob-01 to avoid the extra roundtrip, but I will note that in order to avoid JSON string escaping, the script would have to be base64-encoded. I have no strong opinion either way on how the script content gets supplied for the /set method.  I'll leave that up to others to hash out. What do you envision would be returned by /get?  The script content, or a blobId that would have to be subsequently fetched? > > Second, I remember RFC 5784 (https://tools.ietf.org/html/rfc5784). > That is an effort to map the Sieve language grammar to XML. We could > (optionally of course) do the same in this extension using JSON rather > than XML and make it easier for clients to evaluate, display, and > manipulate Sieve scripts without the need to write a Sieve > parser/generator. This could be a "content:as(json)" field, or > something like that. Or is that just too complex? If someone wants come up with a design for a JSON object to represent Sieve, we could certainly consider it.  Again, I have no strong opinion. -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Thu Nov 19 06:26:43 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313BA3A005C for ; Thu, 19 Nov 2020 06:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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.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=fastmail.com header.b=csAKojrF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VoOE8s/8 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 liFvd0KlNk-t for ; Thu, 19 Nov 2020 06:26:40 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725CD3A003E for ; Thu, 19 Nov 2020 06:26:40 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 3B431A18 for ; Thu, 19 Nov 2020 09:26:39 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 19 Nov 2020 09:26:39 -0500 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=v UU2WSniGSjucoLzks2JHhXNN0YpqjgDNDCnaFvoVOI=; b=csAKojrFqCO6hn5XQ jdtLxrt+1rZUpvk87YSlGf3myEWYG2ovyucfKTLi3mpyJ+shUQAgUsQjOXLj+3q2 PN7URTh+doV9JAew3oYjPd4YsN3crTY8AtlrhEkHfbogOiMBV8gNPWTlf3ulvGaG nzI13qJlfpXRZC8P5o07JpwvXKn407f9NjV525KUF9/lUbOkzLIeCaOithloMsmh N6lgH0rVHKQBEJizKh6BWMtIQS7L/Q25Z2xJjzfSe2eodg9zKwCf8ruG60JSqcsY hAhhh9XSu1GWWK25eRtDzGBeiJLfgpbLmqKXkNMQH6Q+hwgV59B1r1RGcAE7xK+k euvfw== 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=vUU2WSniGSjucoLzks2JHhXNN0YpqjgDNDCnaFvoV OI=; b=VoOE8s/8KFX920VB4oyuEHcwX6jlGYzqPZlHK56SMM07mYuPOrJz+3n8v 55g0blFUWJGg+4lewxq+ukKgSWsaH5U6OnKCM2ojgHRKXfdZZ4/Rc0AIrDsEF7gU nm5uVQL3t6bRoHxtYsyFk6fMcArh3jCa2lfhPi5sjUONUhD1X6IIQiFy4BlEW2Xu ySOZKBnPROix1p012CMfH9mz3ucTJFLjFt9U2Ii3f+v/msylYjbNPWHLmtedemJa YFrpAu0JI3jFmDQqV1STNVSLi1AG2jnnUKumc9wM6s3bBw2IYr8xZ96HKK82SMgo 52pRRIOtO3yNen2V79W8zBMa5inUA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefjedgieegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgr shhtmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeehhffgteelueevuedthfefue dvueekgfekjeeuuefhtdelheetfffgvdetueeujeenucfkphepjeegrdejjedrkeehrddv hedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmh hurhgthhesfhgrshhtmhgrihhlrdgtohhm 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 A82B3328006A for ; Thu, 19 Nov 2020 09:26:37 -0500 (EST) To: jmap@ietf.org References: <160431690732.22434.10293492942158194310@ietfa.amsl.com> <36838c43-aefb-c7f9-d973-2e6f8df5e78f@open-xchange.com> <01RS6NIC0KZC005PTU@mauve.mrochek.com> From: Ken Murchison Message-ID: Date: Thu, 19 Nov 2020 09:26:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <01RS6NIC0KZC005PTU@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-sieve-02.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 14:26:42 -0000 Hi Ned, On 11/19/20 8:17 AM, Ned Freed wrote: > I think there's a more fundamental question we need to ask here: Is the > managesieve model the right one for handling sieves in JMAP? > > By "managesieve model" I'm referring to the underlying data model where > there are multiple named sieves and one active sieve. > > My specific concern is interoperability between clients that fully > support this > model and clients that don't. A client that doesn't want to offer the > ability > to have multiple sieves is likely going to just present the active > script and > let you mess with it. Things can get interesting if another client > that does > support multiple scripts comes along and switches to another script. > > Of course there are ways of handling this, some requiring protocol/server > changes and others requiring extra vigilance on the part of clients. > But before > we start exploring those - and given the ratio of single script to > multiscript > clients I've seen I don't really think we have a choice - I think we > need to > ask if multiscript facilities are something we want. Don't we have the same single-script/multi-script client issue with managesieve? Or perhaps I'm not fully understanding your concern. A separate question that comes to mind, is do we want JMAP Sieve servers to be able to only support a single script?  I guess in this case, the server could simply have a single script with id "singleton" which can only be updated and (de)activated.  Any attempt to create another script or destroy the existing one would fail with a "singleton" error. -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Thu Nov 19 07:02:56 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73ACE3A0989 for ; Thu, 19 Nov 2020 07:02:55 -0800 (PST) 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 nrFgz3hhS-TK for ; Thu, 19 Nov 2020 07:02:54 -0800 (PST) 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 784883A09A4 for ; Thu, 19 Nov 2020 07:02:54 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS6QFMDAPS009FEM@mauve.mrochek.com> for jmap@ietf.org; Thu, 19 Nov 2020 06:57:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1605797871; bh=W+YTH8xd5GePrASSARaUjLmRKvyQOGFY78Rfp22aNgE=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=DnpEQ0+MQDvmjHw4cbBcyZqYGGOzI9m+yDYJNRho59CyQuMxygymqQ00i1tVjgIyS 7LI1mFoLJPWcMhZdXL3s4/3l37k0ro3/xnhM6suE81s2BsJp+eT/Pts1t/lxPdg/3M 6av8hV0UwNaqmmAbfe3fmykpSqXzrUcjKt2Fd5vY= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS6Q9IGBAO0085YQ@mauve.mrochek.com>; Thu, 19 Nov 2020 06:57:49 -0800 (PST) Cc: jmap@ietf.org Message-id: <01RS6QFKSX1U0085YQ@mauve.mrochek.com> Date: Thu, 19 Nov 2020 06:54:42 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 19 Nov 2020 09:26:37 -0500" References: <160431690732.22434.10293492942158194310@ietfa.amsl.com> <36838c43-aefb-c7f9-d973-2e6f8df5e78f@open-xchange.com> <01RS6NIC0KZC005PTU@mauve.mrochek.com> To: Ken Murchison Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-sieve-02.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:02:55 -0000 > Don't we have the same single-script/multi-script client issue with > managesieve? Yes. That's kind of the point. > Or perhaps I'm not fully understanding your concern. > A separate question that comes to mind, is do we want JMAP Sieve servers > to be able to only support a single script?  I guess in this case, the > server could simply have a single script with id "singleton" which can > only be updated and (de)activated.  Any attempt to create another script > or destroy the existing one would fail with a "singleton" error. Indeed. It seems like we're asking a lot of clients here. And if the past is any indication, we're likely to be disappointed by what we get. Ned From nobody Thu Nov 19 07:02:59 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56243A098E for ; Thu, 19 Nov 2020 07:02:55 -0800 (PST) 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 B53rrAgnVUjB for ; Thu, 19 Nov 2020 07:02:55 -0800 (PST) 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 B09213A09AD for ; Thu, 19 Nov 2020 07:02:54 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS6QHHOF4W009FEM@mauve.mrochek.com> for jmap@ietf.org; Thu, 19 Nov 2020 06:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1605797961; bh=hRoNXue2mKjyL4JAsJnb8u9hGAlkmNcK9QEMlo6h8cQ=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=cYbweBonTdixuueNHmWyjYWCCC1IWdD9eWZ44v8XIalR66Z84DvfZSBLDrjlw3Rir vd32NwUBv8QrOjBzdVSyC18DzgB7PfIyvin2q8KNlI1Icdh8yXbv3Zs/shZEWUy+l7 Y0YQJINEC0LCCQIRpDhO6A5eOcTAetP4sQ8/wFH4= 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 <01RS6Q9IGBAO0085YQ@mauve.mrochek.com>; Thu, 19 Nov 2020 06:59:19 -0800 (PST) Cc: jmap@ietf.org Message-id: <01RS6QHGH2I80085YQ@mauve.mrochek.com> Date: Thu, 19 Nov 2020 06:58:29 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 19 Nov 2020 09:15:55 -0500" References: <160431690732.22434.10293492942158194310@ietfa.amsl.com> <36838c43-aefb-c7f9-d973-2e6f8df5e78f@open-xchange.com> To: Ken Murchison Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-sieve-02.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:02:56 -0000 > Hi Stephan, > On 11/19/20 8:01 AM, Stephan Bosch wrote: > > > > First, I think this now misses a nice way to upload/download raw Sieve > > scripts (i.e. without JSON string escaping). As said earlier in this > > mailing list, using the blob upload/download facility would be better > > and it is more consistent with jmap:mail in my opinion. > The reason that we chose to provide the content as an argument to /set, > /validate, and /test (unless using scriptId) is to avoid the extra > roundtrip of having to first upload the script in a separate request. Is sieve updating something clients do often enough that it warrants roundtrip optimization? Ned From nobody Thu Nov 19 07:06:49 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112453A0A26 for ; Thu, 19 Nov 2020 07:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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.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=fastmail.com header.b=GTUNRzpM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iApwq2yU 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 xw4_p6CxqRdc for ; Thu, 19 Nov 2020 07:06:46 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D153A09F1 for ; Thu, 19 Nov 2020 07:06:46 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 2D1C3803; Thu, 19 Nov 2020 10:06:46 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 19 Nov 2020 10:06:46 -0500 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=S 1OetyZNOHc8DnTUKU4i8r6cJ23U32tNXuaPDva1mGY=; b=GTUNRzpMGoR5sD5oS Rz4fXGK3lkQrdWtiPWCDY/2kreWvCBK7WC7zgNz1ehEzcNz95qxmoPJvnwC0ZpdJ mbM9BdEsNrxEGmADVV6eP+JTlKJK0aeyWXOCiY+finTT3Ie53kAX7mG1LrJxa3jy 7hZ0OUBAk4xK1QXek4U3nyFFxzs5Wiq/bmrvUJHVcMy3oMnhiyyw411pgT3xQj7p 7BiI01jqTqFOdOHFmBdfAxfYjAj4NfVvyzexgoXaErlSzZrEO8DUOWr4y6Iu4Ekl 43zSLeWDpZIIRrQDHuRutde7fsoYVyOeauOpMvpUnFb7oaw5u3z3ddz0rDcBioY7 nxGeQ== 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=S1OetyZNOHc8DnTUKU4i8r6cJ23U32tNXuaPDva1m GY=; b=iApwq2yUfGYdaAGoO8POWH+1WB9sXJqGWj5mVFiVFDFLYV7xbsehfBhTE GLzaVy8MktXxZXuZAb2OyLeaxVTBZatU1e11ajJ6ISYVh+RH3gBZ0Upoq/S3aePQ CGWLzWglGsmhthBFgJIgrREC5TlZRzDGbf49VYolSkY+NkhZvK2qLq6CEOS5tggk GtdtcR4vvkJt4033EkBouGrU+/YtarGM3kObus/yLY/oEYkcc5hw7OOirdm4/LwW lcJIQVjPjT2YdVAcWZYHukoJuSdBoAeLyoPlWVZLNCNxrAFQe4qoh7B5p9iejMWl I8r3RWu88bH/3OkuCS2WaQucc2oFQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefjedgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomhepmfgvnhcu ofhurhgthhhishhonhcuoehmuhhrtghhsehfrghsthhmrghilhdrtghomheqnecuggftrf grthhtvghrnhephefhgfetleeuveeutdfhfeeuvdeukefgkeejueeuhfdtleehteffgfdv teeuueejnecukfhppeejgedrjeejrdekhedrvdehtdenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtgho mh 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 0F93E3280060; Thu, 19 Nov 2020 10:06:45 -0500 (EST) To: Ned Freed Cc: jmap@ietf.org References: <160431690732.22434.10293492942158194310@ietfa.amsl.com> <36838c43-aefb-c7f9-d973-2e6f8df5e78f@open-xchange.com> <01RS6NIC0KZC005PTU@mauve.mrochek.com> <01RS6QFKSX1U0085YQ@mauve.mrochek.com> From: Ken Murchison Message-ID: <26b87332-75b7-9c98-7eab-482e4c4c427d@fastmail.com> Date: Thu, 19 Nov 2020 10:06:44 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <01RS6QFKSX1U0085YQ@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-sieve-02.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:06:48 -0000 On 11/19/20 9:54 AM, Ned Freed wrote: >> Don't we have the same single-script/multi-script client issue with >> managesieve? > > Yes. That's kind of the point. > >> Or perhaps I'm not fully understanding your concern. > >> A separate question that comes to mind, is do we want JMAP Sieve servers >> to be able to only support a single script?  I guess in this case, the >> server could simply have a single script with id "singleton" which can >> only be updated and (de)activated.  Any attempt to create another script >> or destroy the existing one would fail with a "singleton" error. > > Indeed. It seems like we're asking a lot of clients here. And if the > past is > any indication, we're likely to be disappointed by what we get. So, its sounds like you're making an argument that JMAP Sieve should always operate on a singleton.  Am I correct? Obviously, this takes the Sieve "include" extension of the table. -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Thu Nov 19 07:07:48 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D07E3A0AB7 for ; Thu, 19 Nov 2020 07:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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.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=fastmail.com header.b=oSdQHHVw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RYixq5Am 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 nQblQAvWYGrA for ; Thu, 19 Nov 2020 07:07:45 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8943A0A4A for ; Thu, 19 Nov 2020 07:07:45 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id AB4ABC36; Thu, 19 Nov 2020 10:07:44 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 19 Nov 2020 10:07:44 -0500 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=3 xPYtxqMCuNPf2OzhBimardeI42VtQgbDWAANwMPlp8=; b=oSdQHHVw/QDpJvADR Rjd7dsbRmxa9zMJRErR2hs+bbKydW4JRIOWySyrlFTFJNbmYUWyDE4d+Hgn1o5Eu +C9klOPkwUa/A1iKz9PmOd9OxM2Vxx81APcMo6fpDE7PEIpbe0LnEkb+7gd0r8eK hmehgf4h50arvF/FDkGxr7tJwdBHcU60BQ/a7XBcucLwS+n5TML48638LDOxuCxz gIqCEXvLD+D4q5rE+aefWNNiT8jae1+3OwaTPt0qFe4o5qBIrT9P/FYSVAojn1Ge ZLDyrjjxW7il3Fst3DAxvoUV4mk4wVcGKRIUBo0bhfQAXor+1YD4nkLO4vsd30y0 HnX9g== 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=3xPYtxqMCuNPf2OzhBimardeI42VtQgbDWAANwMPl p8=; b=RYixq5AmMxDoAJmdqiVlT/mBTZe2ynOMLmsfe5PWo5dbBSlmT5AfoMAfY 6qAZdw7YHekORfd0YfivGi8e1xifQJUAk7VCuI7DDupVg83vvfUP2ldLUnCCF1vS AlEDthZ6fzTJHZNTPgzXJqnc/uQaMNtNUTRXwuoz5Z/uv5U2Ki9yjDteL0hJY0eW hsNkm3xo5CaiwcXcMncOw2u9fN6fbVvW8z4polUv2IuI6WZ35g8PEle9jvSc5FvX SHREE8yZttdJDnFa7cwAGrXcmfTWqUlGYTam2Xi8hieHqo/tk5HwmDkzuu/WOCMh QUNjQHn/l/APWVpIga54C8XAZRi2Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefjedgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomhepmfgvnhcu ofhurhgthhhishhonhcuoehmuhhrtghhsehfrghsthhmrghilhdrtghomheqnecuggftrf grthhtvghrnheptdeitedvtdduffetlefhvdffhfdvjeehudelveffhfdvjeegleejuedt hfefffegnecukfhppeejgedrjeejrdekhedrvdehtdenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtgho mh 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 C743A3280063; Thu, 19 Nov 2020 10:07:43 -0500 (EST) To: Ned Freed Cc: jmap@ietf.org References: <160431690732.22434.10293492942158194310@ietfa.amsl.com> <36838c43-aefb-c7f9-d973-2e6f8df5e78f@open-xchange.com> <01RS6QHGH2I80085YQ@mauve.mrochek.com> From: Ken Murchison Message-ID: Date: Thu, 19 Nov 2020 10:07:43 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <01RS6QHGH2I80085YQ@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-sieve-02.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:07:47 -0000 On 11/19/20 9:58 AM, Ned Freed wrote: >> Hi Stephan, > > >> On 11/19/20 8:01 AM, Stephan Bosch wrote: >> > >> > First, I think this now misses a nice way to upload/download raw Sieve >> > scripts (i.e. without JSON string escaping). As said earlier in this >> > mailing list, using the blob upload/download facility would be better >> > and it is more consistent with jmap:mail in my opinion. > > >> The reason that we chose to provide the content as an argument to /set, >> /validate, and /test (unless using scriptId) is to avoid the extra >> roundtrip of having to first upload the script in a separate request. > > Is sieve updating something clients do often enough that it warrants > roundtrip optimization? Perhaps not, but Blob/set provides a way around it anyways. -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Thu Nov 19 07:43:58 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4323A0ABB for ; Thu, 19 Nov 2020 07:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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.001, 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 1TWLb_wW67Bo for ; Thu, 19 Nov 2020 07:43:55 -0800 (PST) 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 524083A0A9A for ; Thu, 19 Nov 2020 07:43:54 -0800 (PST) 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 C22586A26A; Thu, 19 Nov 2020 16:43:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1605800632; bh=xxuCX+A163fYnHBG6sJz4fL1m1uaZc5Kabi/dKcfp14=; h=Subject:To:References:From:Date:In-Reply-To:From; b=mQPnNsOzQhMFs4Ie0fn4xxaFo9YMYSi934Xb8vyHNrW3jUujMUqnzWe9FHvZWcr/A v6HIsUJ/06k9tvlwmF36xJ7aW875Pf+DxbM+6yJNiCpiLczLX//K34lLpP77UfNpzr A2N4+JseDnAdo60zTAvjqfgk5EDs1h5xz4zkryGWze2XjaSTL+f8dfQU1V1jAkWlrj xFb4zeqqy/Ttv9w9FGuem9yBICNQn3+tCW4EX2KSiWXbH23qbImCauIQn9lg0lCDvb tmSf4Di3jZBfrPVnjJi224up+g7mieGo/hABdVPBDwCyHsZAhCKPiDgE8XPBA7mYEL mckpg+xCVEYtQ== Received: from [10.168.3.2] (unknown [10.217.131.10]) (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 85C123C002F; Thu, 19 Nov 2020 16:43:52 +0100 (CET) To: Ken Murchison , jmap@ietf.org References: <160431690732.22434.10293492942158194310@ietfa.amsl.com> <36838c43-aefb-c7f9-d973-2e6f8df5e78f@open-xchange.com> From: Stephan Bosch Message-ID: Date: Thu, 19 Nov 2020 16:43:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-sieve-02.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:43:57 -0000 On 19/11/2020 15:15, Ken Murchison wrote: > Hi Stephan, > > > On 11/19/20 8:01 AM, Stephan Bosch wrote: >> >> First, I think this now misses a nice way to upload/download raw Sieve >> scripts (i.e. without JSON string escaping). As said earlier in this >> mailing list, using the blob upload/download facility would be better >> and it is more consistent with jmap:mail in my opinion. > > > The reason that we chose to provide the content as an argument to /set, > /validate, and /test (unless using scriptId) is to avoid the extra > roundtrip of having to first upload the script in a separate request. > > That said, a client could leverage > https://tools.ietf.org/html/draft-gondwana-jmap-blob-01 > to avoid the > extra roundtrip, but I will note that in order to avoid JSON string > escaping, the script would have to be base64-encoded. > > I have no strong opinion either way on how the script content gets > supplied for the /set method.  I'll leave that up to others to hash out. Well, I don't like piping potentially large data things through JSON very much. First, for JSON implementations that don't support streaming JSON string values, this means allocating large memory buffers to deal with uploading/downloading those. And yes, Sieve scripts can be quite large (e.g. vacation action with inline email with image attachment etc.). Second, the additional base64 or JSON-string-escape encoding effort does not sound too appealing for large data either. > > What do you envision would be returned by /get?  The script content, or > a blobId that would have to be subsequently fetched? > I'd say both should be supported, as requested by client using the "properties" method field. This is similar to how Email object is structured. Regards, Stephan. From nobody Thu Nov 19 07:47:23 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC143A0C5F for ; Thu, 19 Nov 2020 07:47:17 -0800 (PST) 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 06EV-O8VEySe for ; Thu, 19 Nov 2020 07:47:15 -0800 (PST) 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 A27C93A0C99 for ; Thu, 19 Nov 2020 07:47:15 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS6RYMED1C00CVZ7@mauve.mrochek.com> for jmap@ietf.org; Thu, 19 Nov 2020 07:42:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1605800531; bh=LGbbsIRKWn2BU3ku1zlSxJeYLO8IRQ/K4WbgT/j3F6c=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=I0HYzPWISKavpcWwTqY0DaMl5Mt9B2d4ufvbLL2o1TAROFkpsO1DG0sDo/qc5YhHv R8ENzXF+qqwIJ+sQ0LPjU1vfvUmo2PlmpUmy7zCSj8E8F12ldVrIrVdY456sNajeXm +9ZEM5GqZMdUKz/oLOFuBStTmS9oya0fTP03k04w= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS6Q9IGBAO0085YQ@mauve.mrochek.com>; Thu, 19 Nov 2020 07:42:08 -0800 (PST) Cc: Ned Freed , jmap@ietf.org Message-id: <01RS6RYJNF060085YQ@mauve.mrochek.com> Date: Thu, 19 Nov 2020 07:34:32 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 19 Nov 2020 10:06:44 -0500" <26b87332-75b7-9c98-7eab-482e4c4c427d@fastmail.com> References: <160431690732.22434.10293492942158194310@ietfa.amsl.com> <36838c43-aefb-c7f9-d973-2e6f8df5e78f@open-xchange.com> <01RS6NIC0KZC005PTU@mauve.mrochek.com> <01RS6QFKSX1U0085YQ@mauve.mrochek.com> <26b87332-75b7-9c98-7eab-482e4c4c427d@fastmail.com> To: Ken Murchison Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-sieve-02.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:47:22 -0000 > On 11/19/20 9:54 AM, Ned Freed wrote: > >> Don't we have the same single-script/multi-script client issue with > >> managesieve? > > > > Yes. That's kind of the point. > > > >> Or perhaps I'm not fully understanding your concern. > > > >> A separate question that comes to mind, is do we want JMAP Sieve servers > >> to be able to only support a single script?  I guess in this case, the > >> server could simply have a single script with id "singleton" which can > >> only be updated and (de)activated.  Any attempt to create another script > >> or destroy the existing one would fail with a "singleton" error. > > > > Indeed. It seems like we're asking a lot of clients here. And if the > > past is > > any indication, we're likely to be disappointed by what we get. > So, its sounds like you're making an argument that JMAP Sieve should > always operate on a singleton.  Am I correct? No, not really. I'm saying that the managesieve model has issues that warrant serious consideration before we adopt it in a different context. The single sieve model is the obvious alternative, but it may not be the only one. Since none of this is especially difficult server-side, I would like to hear from client devleopers what sort of model they would prefer. Or if the multisieve model is what they really want, have them say that. > Obviously, this takes the Sieve "include" extension of the table. No, not really. It just means you'd have to use some other means of resolving the includes. (Not that I'd mind. I think include is a botch.) Ned From nobody Thu Nov 19 07:49:57 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40323A0C0A for ; Thu, 19 Nov 2020 07:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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.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=fastmail.com header.b=NSEO11bP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HZTCtLuX 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 nKC04yQX7WQD for ; Thu, 19 Nov 2020 07:49:53 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 902CB3A0C03 for ; Thu, 19 Nov 2020 07:49:53 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id EEBB1E26; Thu, 19 Nov 2020 10:49:51 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 19 Nov 2020 10:49:52 -0500 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=z H7wDfWSOBc1cWt59ymBH69uwgzEF+0WStRxlVwRDs4=; b=NSEO11bP2nXT0uHPE IZbjIu9f+sQGz0D+Bdq7Zr79G9XyCmhGDUdsFg+rGdkmBB9EY4B/aHcKxT/q2FCf oAngZHHFR0kKvRm24XLI/0gS26tsj6a6OXrxt9e53uheThUwTHy+NMcDva+sqSLQ T72NaRJWhqSh0P6AHbpZT6UFzwEGsp6lMnaUvXGhJwuSmzQsIIuhUALjd1s9Muxw b1cXUbevc8Cse1Jkx/xWAjY0rjgSbTIhO9fbYHt1rlpGfnq0s4p/YhCy/jPxL+pa KGyO6uN+VWFJ3XBjDdOQj5dA3rPzLTTrVFQ4x9+CsDkEGWYnAth2X4rV9ilt78rb gj3cw== 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=zH7wDfWSOBc1cWt59ymBH69uwgzEF+0WStRxlVwRD s4=; b=HZTCtLuXeyAdy8ffY82S5T36iod/71a5KdYSRSBud4kMBIyjKX6JpORHP AZ41OMDsfd02pho/HuoEdQshA1C8hSKVa2zaMNnisme4CHB5XixZtmqZk2Dluyqi kOBj2Nrs5SnntkDJBLLK/L+4h8RTuDu9cc8xEddq09TWFNQfPrLTIiaPM1vzgzFS bvTnd/9+RBctXqiEuXdRmmoGBBS3kTWSap0rbTFrd8RKFZDVMRXaAn5MCuA+9Jxo MS1P8/j9pGtgz3pZ1/Sn1ZPHaHLLpVAwIicNjGPIuM9P+CC+bt2Qy584bAHMJnm8 5zzx9aOedBd1z7WLSNJG0FrkeZ4ng== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefjedgkedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomhepmfgvnhcu ofhurhgthhhishhonhcuoehmuhhrtghhsehfrghsthhmrghilhdrtghomheqnecuggftrf grthhtvghrnhephefhgfetleeuveeutdfhfeeuvdeukefgkeejueeuhfdtleehteffgfdv teeuueejnecukfhppeejgedrjeejrdekhedrvdehtdenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtgho mh 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 43D8A3280066; Thu, 19 Nov 2020 10:49:51 -0500 (EST) To: Ned Freed Cc: jmap@ietf.org References: <160431690732.22434.10293492942158194310@ietfa.amsl.com> <36838c43-aefb-c7f9-d973-2e6f8df5e78f@open-xchange.com> <01RS6NIC0KZC005PTU@mauve.mrochek.com> <01RS6QFKSX1U0085YQ@mauve.mrochek.com> <26b87332-75b7-9c98-7eab-482e4c4c427d@fastmail.com> <01RS6RYJNF060085YQ@mauve.mrochek.com> From: Ken Murchison Message-ID: <7d0a23d6-7bf0-684a-5c4b-f5350c5e2da2@fastmail.com> Date: Thu, 19 Nov 2020 10:49:50 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <01RS6RYJNF060085YQ@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-sieve-02.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 15:49:55 -0000 On 11/19/20 10:34 AM, Ned Freed wrote: > >> On 11/19/20 9:54 AM, Ned Freed wrote: >> >> Don't we have the same single-script/multi-script client issue with >> >> managesieve? >> > >> > Yes. That's kind of the point. >> > >> >> Or perhaps I'm not fully understanding your concern. >> > >> >> A separate question that comes to mind, is do we want JMAP Sieve >> servers >> >> to be able to only support a single script?  I guess in this case, >> the >> >> server could simply have a single script with id "singleton" which >> can >> >> only be updated and (de)activated.  Any attempt to create another >> script >> >> or destroy the existing one would fail with a "singleton" error. >> > >> > Indeed. It seems like we're asking a lot of clients here. And if the >> > past is >> > any indication, we're likely to be disappointed by what we get. > > >> So, its sounds like you're making an argument that JMAP Sieve should >> always operate on a singleton.  Am I correct? > > No, not really. I'm saying that the managesieve model has issues that > warrant serious consideration before we adopt it in a different context. > > The single sieve model is the obvious alternative, but it may not be > the only > one. Since none of this is especially difficult server-side, I would > like to > hear from client devleopers what sort of model they would prefer. Or if > the multisieve model is what they really want, have them say that. > >> Obviously, this takes the Sieve "include" extension of the table. > > No, not really. It just means you'd have to use some other means of > resolving > the includes. A user would have no way of managing their own included scripts, but they could still include system-wide global scripts in their own single script if desired. > > (Not that I'd mind. I think include is a botch.) -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Thu Nov 19 09:27:56 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6343A103A for ; Thu, 19 Nov 2020 09:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_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 bk91b7gGQ3b2 for ; Thu, 19 Nov 2020 09:27:50 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (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 2DC673A0FC0 for ; Thu, 19 Nov 2020 09:27:48 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS6VH832CW00CNGZ@mauve.mrochek.com> for jmap@ietf.org; Thu, 19 Nov 2020 09:22:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1605806562; bh=zXFvK3IpQ2fzuzzbXP9xckMH0DufmXucwrthBIQdoHw=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=P6lUWnpYnyOFyWYlAFgF6tQGDMk3Tuov6iJPgAmyWdEiqZNKYfmevweat3iH/9uiN ptMK+hBteawFg1pUEKYL03+SuYyTZUqo1YWKEaM7qQtT99GB+CH6HzxwZf7THQn1WU GBxrRP7mwJnu9UDy6jmVdW6HMFnqw7jNN/DrSbDE= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RS4XGHZZF4005PTU@mauve.mrochek.com>; Thu, 19 Nov 2020 09:22:38 -0800 (PST) Cc: Ned Freed , jmap@ietf.org Message-id: <01RS6VH5IRJM005PTU@mauve.mrochek.com> Date: Thu, 19 Nov 2020 09:19:28 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 19 Nov 2020 10:49:50 -0500" <7d0a23d6-7bf0-684a-5c4b-f5350c5e2da2@fastmail.com> References: <160431690732.22434.10293492942158194310@ietfa.amsl.com> <36838c43-aefb-c7f9-d973-2e6f8df5e78f@open-xchange.com> <01RS6NIC0KZC005PTU@mauve.mrochek.com> <01RS6QFKSX1U0085YQ@mauve.mrochek.com> <26b87332-75b7-9c98-7eab-482e4c4c427d@fastmail.com> <01RS6RYJNF060085YQ@mauve.mrochek.com> <7d0a23d6-7bf0-684a-5c4b-f5350c5e2da2@fastmail.com> To: Ken Murchison Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-sieve-02.txt X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2020 17:27:55 -0000 > On 11/19/20 10:34 AM, Ned Freed wrote: > > > >> On 11/19/20 9:54 AM, Ned Freed wrote: > >> >> Don't we have the same single-script/multi-script client issue with > >> >> managesieve? > >> > > >> > Yes. That's kind of the point. > >> > > >> >> Or perhaps I'm not fully understanding your concern. > >> > > >> >> A separate question that comes to mind, is do we want JMAP Sieve > >> servers > >> >> to be able to only support a single script?  I guess in this case, > >> the > >> >> server could simply have a single script with id "singleton" which > >> can > >> >> only be updated and (de)activated.  Any attempt to create another > >> script > >> >> or destroy the existing one would fail with a "singleton" error. > >> > > >> > Indeed. It seems like we're asking a lot of clients here. And if the > >> > past is > >> > any indication, we're likely to be disappointed by what we get. > > > > > >> So, its sounds like you're making an argument that JMAP Sieve should > >> always operate on a singleton.  Am I correct? > > > > No, not really. I'm saying that the managesieve model has issues that > > warrant serious consideration before we adopt it in a different context. > > > > The single sieve model is the obvious alternative, but it may not be > > the only > > one. Since none of this is especially difficult server-side, I would > > like to > > hear from client devleopers what sort of model they would prefer. Or if > > the multisieve model is what they really want, have them say that. > > > >> Obviously, this takes the Sieve "include" extension of the table. > > > > No, not really. It just means you'd have to use some other means of > > resolving > > the includes. > A user would have no way of managing their own included scripts, but > they could still include system-wide global scripts in their own single > script if desired. Or you could include the ability to have (and manage) named scripts strictly for use with include, and have one fixed script that's always the active one. At first blush I actually like this model a lot. Enough that I may have to revise my opinion of include. Ned From nobody Fri Nov 20 06:00:42 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E898C3A09C0 for ; Fri, 20 Nov 2020 06:00:40 -0800 (PST) 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, FREEMAIL_FROM=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=fastmail.com header.b=kjgPDPRI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=C8VzLCSp 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 DiMAsVNAjnQU for ; Fri, 20 Nov 2020 06:00:39 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC473A0978 for ; Fri, 20 Nov 2020 06:00:39 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 02E88FB0 for ; Fri, 20 Nov 2020 09:00:38 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Fri, 20 Nov 2020 09:00:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= to:from:subject:message-id:date:mime-version:content-type :content-transfer-encoding; s=fm1; bh=oERH+biChzMTc6ep04rcN18lmz 9eXTtq4sr7UUzWFI4=; b=kjgPDPRIJsN5spnD9mY5tU1Gd++nhewneyl+JJbRy4 4pkWwBpMC5PquQUiNd35u2JYhe94T+49w42xCic5bydMSXQCqmzeXkrcAR7z6KVe w596vEVidCWpDTAg9mCrZN9ItK/r2af/yIuwbztFVCZCoPYv9Yb3pa3ogLjN7wKd vbytCL6ttvylDuTl5dHs3j6VUSmrhZFL0afuspDFMQ8MDOl1ywLToZLCihenY/+s JQIqlidMj8+IFwghBeY7IrqZf4TU/RQrXeSGwgyWh7l64QhyHAVJabf6Jny7l8cg Zpw8boHaD17mtIMREOmdT3WVGQZSDCXrt/WdepqUFbrg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=oERH+b iChzMTc6ep04rcN18lmz9eXTtq4sr7UUzWFI4=; b=C8VzLCSpXtxqht4JPfgc1w 1QpRxPvzgwBIaBV3obOnSzA1LG/1EhyYKsFvrhgqOo04rjnqHxfmWMQLkVUUjHLK /VoFGU9UNGdVqFnW/QUp0OaG4/rU/9t/ByQVrq82N4coYM0Et/2liNRs95XwkdgJ x9RpI3ydFdhyWbPJNulKVciyPWr0p/9sZnYkt1HAOx0OKjuY9QiU5yLA8hIBzogE QtkQ8KTPOkKEcfVdOqXlVrSDmauEAGebeM6YqLcQizo/JKiMgzG4WN8S4Z84exzS DpnvbdHzC78uZcNCilkuTOKiGo+oN1I/t/YeZtiPemuBPSj2dTIIkbRnxUuxm/5Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegtddgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefvhffukffffgggtgfgsehtkeertd dtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshht mhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeetkeeutdffledukedvuedtfeehge ekfeelteeljedvgffgheelhfeileekhefhjeenucfkphepjeegrdejjedrkeehrddvhedt necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhurh gthhesfhgrshhtmhgrihhlrdgtohhm 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 7B4D13280069 for ; Fri, 20 Nov 2020 09:00:37 -0500 (EST) To: jmap@ietf.org From: Ken Murchison Message-ID: <35825bfb-864a-6d06-21bc-75c0f0ddbe04@fastmail.com> Date: Fri, 20 Nov 2020 09:00:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Jmap] draft-gondwana-jmap-blob-01 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2020 14:00:41 -0000 Quick nit in the Abstract: Binary data is uploaded via HTTP POST, not PUT.  And they use separate endpoints. -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Wed Nov 25 19:03:27 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78C03A0DD9 for ; Wed, 25 Nov 2020 19:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 6Xl0Z6yS3u6t for ; Wed, 25 Nov 2020 19:03:23 -0800 (PST) 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 9B9CE3A0DD8 for ; Wed, 25 Nov 2020 19:03:23 -0800 (PST) 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 0AQ33EGg023405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Nov 2020 22:03:19 -0500 Date: Wed, 25 Nov 2020 19:03:14 -0800 From: Benjamin Kaduk To: Bron Gondwana Cc: jmap@ietf.org, Raphael OUAZANA Message-ID: <20201126030314.GV39170@kduck.mit.edu> References: <160193187289.4946.17482930539468511819@ietfa.amsl.com> <522c72f3-a4d3-46ae-b62b-bc87302d64a3@dogfood.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <522c72f3-a4d3-46ae-b62b-bc87302d64a3@dogfood.fastmail.com> Archived-At: Subject: Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-mdn-15: (with DISCUSS and COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2020 03:03:26 -0000 Hi Bron, Thanks for clarifying the intent. It looks like we'd then be looking at something like: OLD: When sending the MDN, the server is in charge of generating the "originalRecipient", "finalRecipient" and "originalMessageId" fields according to the [RFC8098] specification. NEW: When sending the MDN, the server is in charge of generating the "originalRecipient", "finalRecipient" and "originalMessageId" fields according to the [RFC8098] specification, subject to potential client override of finalRecipient. ? Thanks, Ben On Thu, Nov 19, 2020 at 01:34:40PM +1100, Bron Gondwana wrote: > Hi Raphael, > > This discuss is blocking MDN progress. Can you please look at providing clarifying text here, or discuss with Ben what he wants. > > Ben - the intent is that the client can override the value if it needs to. Generally it won't need to, but sometimes there will be preferred canonical versions of addresses. For example: Fastmail tries to hide the user's username entirely from the sender if they sent to an external alias, so that their username can remain secret from those who contact them on that alias - so we would override finalRecipient to be the alias name at our boundary, even though the actual final recipient inside our system was their primary address. > > The text does require that the server validate that the client is allowed to use the value it sets as finalRecipient. > > Cheers, > > Bron. > > On Tue, Oct 6, 2020, at 08:04, Benjamin Kaduk via Datatracker wrote: > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-jmap-mdn-15: Discuss > > > > 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-jmap-mdn/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This should be quite easy to resolve; I'm just not sure yet which > > direction the resolution will be. > > > > I think we should be a little more clear about whether the client can > > override the finalRecipient calculation (or just provide a suggestion to > > do so, or not give any input at all, etc.): the description of the > > finalRecipient property of an MDN object says that "if set, it > > overrides the value that would be calculated by the server from the > > Identity", which to me suggests that the client could set something to > > override the server (if the server sua sponte did something different > > that would typically be an "exception", not an "override"), but later on > > in Section 2.1 we say that "[w]hen sending the MDN, the server is in > > charge of generating the "originalRecipient", "finalRecipient" and > > "originalMessageId" fields according to the [RFC8098] specification. I > > do not see discussion in RFC 8098 of client intput into the server's > > populating of this field, so I'm unsure whether/where the client has > > input. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you for noting the `jq` validation in the sheperd writeup! > > > > Section 1 > > > > A client can have to deal with MDNs in different ways: > > > > (editorial) "have to deal with" seems like it can be read as implying > > obligation to do so (even though the majuscule "MUST" is not used); it > > seems like this is just attempting to enumerate the cases in which an > > MDN might be encountered or need to be interacted with. > > > > 2. When sending an email message, an MDN can be requested. This > > must be done with the help of a header, and is already specified > > by [RFC8098] and can already be handled by [RFC8621] this way. > > > > (nit?) "header" or "header field"? (We get this a lot for HTTP and I've > > forgotten if SMTP uses the same rule...) > > > > 3. When receiving an MDN, the MDN could be related to an existing > > sent message. This is already covered by [RFC8621] in the > > EmailSubmission object. [...] > > > > (The "DeliveryStatus" member, in particular, right?) > > > > Section 1.3 > > > > The value of this "urn:ietf:params:jmap:mdn" property is an empty > > object in the account's "accountCapabilities" property. > > > > I presume it's also an empty object in the server's "capabilities" > > property as well (and we should probably say so). > > > > Section 2 > > > > It's a little interesting to me that RFC 8261 did not define or mention > > specific access to the User-Agent string but we need to have a specific > > reportingUA here. I do recognize that it's (an optional) part of the > > RFC 8098 ABNF, and that RFC 8098 mentions the relevant security > > considerations already. Perhaps a subtle nudge in this section that the > > "null" option may have better privacy properties would be appropriate. > > (We may also revisit whether/what to include in the examples for > > reportingUA.) > > > > o finalRecipient: "String|null" Recipient for which the MDN is being > > issued. if set, it overrides the value that would be calculated > > by the server from the Identity. > > > > Could we get a couple more words to support the definite article? (I am > > not sure which Identity is "the" Identity just from this context; it is > > only later on that we discover that there is an identityId in the > > MDN/send arguments.) > > > > o extensionFields: "String[String]|null" Object where keys are > > extension-field names and values are extension-field values. > > > > I used process of elimination to conclude that these are RFC 8098 > > extension-field ABNF names/values; I don't know if there's a good way to > > hint the reader of that fact. > > > > o actionMode: "String" This MUST be one of the following strings: > > "manual-action" / "automatic-action" > > > > o sendingMode: "String" This MUST be one of the following strings: > > "mdn-sent-manually" / "mdn-sent-automatically" > > > > I recognize that this is entirely the responsibility of RFC 8098 and not > > this document, but is it valid to combine "automatic-action" with > > "mdn-sent-manually"? I am not 100% I understand the semantics. > > > > Section 2.1 > > > > The latter because of the implicit call > > to Email/set and the use of Identities, described below. [...] > > > > nit: does this sentence have a verb? > > > > The following already registered SetError would mean: > > > > nit: these are the SetError types, right? > > > > Section 3.x > > > > It might be helpful to use a different creation ID for the different > > classes of example (though not required by the protocol). > > > > Section 3.1 > > > > "extension": { > > "X-EXTENSION-EXAMPLE": "example.com" > > } > > > > nit(?): somehow I thought X- extensions were generally thought to not be > > needed/useful anymore. > > > > Section 5 > > > > In order to enforce trust regarding the relation between the user > > sending an email message and the identity of this user, the server > > SHOULD validate in conformance to the provided Identity that the user > > is permitted to use the finalRecipient value and return a > > forbiddenFrom error if not. > > > > "enforce" and "SHOULD" are not words I usually see in combination. > > > > > > > > _______________________________________________ > > Jmap mailing list > > Jmap@ietf.org > > https://www.ietf.org/mailman/listinfo/jmap > > > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > From nobody Fri Nov 27 00:48:14 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A49F3A1501 for ; Fri, 27 Nov 2020 00:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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 Kn0gj3dGUxmh for ; Fri, 27 Nov 2020 00:48:11 -0800 (PST) Received: from smtp.linagora.com (smtp.linagora.com [54.36.8.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D070C3A14F8 for ; Fri, 27 Nov 2020 00:48:10 -0800 (PST) Received: from [192.168.0.37] (91-168-246-100.subs.proxad.net [91.168.246.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id B67BD3F06F for ; Fri, 27 Nov 2020 09:48:07 +0100 (CET) X-LINAGORA-Copy-Delivery-Done: 1 From: =?UTF-8?Q?Rapha=c3=abl_Ouazana?= To: jmap@ietf.org References: <160193187289.4946.17482930539468511819@ietfa.amsl.com> Message-ID: Date: Fri, 27 Nov 2020 09:48:03 +0100 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-mdn-15: (with DISCUSS and COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 08:48:13 -0000 I think Bron's explanation is right. Would it clarify the issue if in section 2.1 I add "unless explicitly set by the client" to the sentence "The server will use this identity to define the sender of the MDNs and to set the finalRecipient field"? Maybe it can help also if I replace:    When sending the MDN, the server is in charge of generating the    "originalRecipient", "finalRecipient" and "originalMessageId" fields    according to the [RFC8098] specification. By something like:    When sending the MDN, the server is in charge of generating the    "originalRecipient" and "originalMessageId" fields    according to the [RFC8098] specification. "finalRecipient" will also    generally be generated by the server based on the provided identity,    but if specified by the client and allowed (see Security Considerations) the server will use the client provided value. Regards, Raphaël. Le 19/11/2020 à 07:17, Barry Leiba a écrit : > Raphaël, I've seen no response from you on this, and it's been around > six weeks. Will you please address Ben's comments so we can move > ahead? > > Thanks, > Barry > > On Mon, Oct 5, 2020 at 5:04 PM Benjamin Kaduk via Datatracker > wrote: >> Benjamin Kaduk has entered the following ballot position for >> draft-ietf-jmap-mdn-15: Discuss >> >> 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-jmap-mdn/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This should be quite easy to resolve; I'm just not sure yet which >> direction the resolution will be. >> >> I think we should be a little more clear about whether the client can >> override the finalRecipient calculation (or just provide a suggestion to >> do so, or not give any input at all, etc.): the description of the >> finalRecipient property of an MDN object says that "if set, it >> overrides the value that would be calculated by the server from the >> Identity", which to me suggests that the client could set something to >> override the server (if the server sua sponte did something different >> that would typically be an "exception", not an "override"), but later on >> in Section 2.1 we say that "[w]hen sending the MDN, the server is in >> charge of generating the "originalRecipient", "finalRecipient" and >> "originalMessageId" fields according to the [RFC8098] specification. I >> do not see discussion in RFC 8098 of client intput into the server's >> populating of this field, so I'm unsure whether/where the client has >> input. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Thank you for noting the `jq` validation in the sheperd writeup! >> >> Section 1 >> >> A client can have to deal with MDNs in different ways: >> >> (editorial) "have to deal with" seems like it can be read as implying >> obligation to do so (even though the majuscule "MUST" is not used); it >> seems like this is just attempting to enumerate the cases in which an >> MDN might be encountered or need to be interacted with. >> >> 2. When sending an email message, an MDN can be requested. This >> must be done with the help of a header, and is already specified >> by [RFC8098] and can already be handled by [RFC8621] this way. >> >> (nit?) "header" or "header field"? (We get this a lot for HTTP and I've >> forgotten if SMTP uses the same rule...) >> >> 3. When receiving an MDN, the MDN could be related to an existing >> sent message. This is already covered by [RFC8621] in the >> EmailSubmission object. [...] >> >> (The "DeliveryStatus" member, in particular, right?) >> >> Section 1.3 >> >> The value of this "urn:ietf:params:jmap:mdn" property is an empty >> object in the account's "accountCapabilities" property. >> >> I presume it's also an empty object in the server's "capabilities" >> property as well (and we should probably say so). >> >> Section 2 >> >> It's a little interesting to me that RFC 8261 did not define or mention >> specific access to the User-Agent string but we need to have a specific >> reportingUA here. I do recognize that it's (an optional) part of the >> RFC 8098 ABNF, and that RFC 8098 mentions the relevant security >> considerations already. Perhaps a subtle nudge in this section that the >> "null" option may have better privacy properties would be appropriate. >> (We may also revisit whether/what to include in the examples for >> reportingUA.) >> >> o finalRecipient: "String|null" Recipient for which the MDN is being >> issued. if set, it overrides the value that would be calculated >> by the server from the Identity. >> >> Could we get a couple more words to support the definite article? (I am >> not sure which Identity is "the" Identity just from this context; it is >> only later on that we discover that there is an identityId in the >> MDN/send arguments.) >> >> o extensionFields: "String[String]|null" Object where keys are >> extension-field names and values are extension-field values. >> >> I used process of elimination to conclude that these are RFC 8098 >> extension-field ABNF names/values; I don't know if there's a good way to >> hint the reader of that fact. >> >> o actionMode: "String" This MUST be one of the following strings: >> "manual-action" / "automatic-action" >> >> o sendingMode: "String" This MUST be one of the following strings: >> "mdn-sent-manually" / "mdn-sent-automatically" >> >> I recognize that this is entirely the responsibility of RFC 8098 and not >> this document, but is it valid to combine "automatic-action" with >> "mdn-sent-manually"? I am not 100% I understand the semantics. >> >> Section 2.1 >> >> The latter because of the implicit call >> to Email/set and the use of Identities, described below. [...] >> >> nit: does this sentence have a verb? >> >> The following already registered SetError would mean: >> >> nit: these are the SetError types, right? >> >> Section 3.x >> >> It might be helpful to use a different creation ID for the different >> classes of example (though not required by the protocol). >> >> Section 3.1 >> >> "extension": { >> "X-EXTENSION-EXAMPLE": "example.com" >> } >> >> nit(?): somehow I thought X- extensions were generally thought to not be >> needed/useful anymore. >> >> Section 5 >> >> In order to enforce trust regarding the relation between the user >> sending an email message and the identity of this user, the server >> SHOULD validate in conformance to the provided Identity that the user >> is permitted to use the finalRecipient value and return a >> forbiddenFrom error if not. >> >> "enforce" and "SHOULD" are not words I usually see in combination. >> >> >> > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap From nobody Fri Nov 27 03:34:59 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A3E3A095F for ; Fri, 27 Nov 2020 03:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=linagora.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 zBpjwEL9zGTI for ; Fri, 27 Nov 2020 03:34:56 -0800 (PST) Received: from smtp.linagora.com (smtp.linagora.com [54.36.8.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4D63A0957 for ; Fri, 27 Nov 2020 03:34:56 -0800 (PST) Received: from ?Open?PaaS?SMTP?server?for?Linagora? (incoming.linagora.com [51.83.109.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id A00D63F0A4 for ; Fri, 27 Nov 2020 12:34:52 +0100 (CET) MIME-Version: 1.0 DKIM-Signature: a=rsa-sha256; b=Gn4Lm3VSp/CWfiFHPFoXyvceM9ahSWmvnY+cmrCfF259bAAxuA+8sfWOzECg/dMxiDR91KK1i3TlgOfWRsBYT7J95sBbs0MtImVNYu9C93z7vECwJC//SaAb0amfqpeGzfwZd2uxoiH5K4YLG3yN85QNH4S6WW4KtT+1J4PpUN72Ent+9tGXdqsujY8JzCev5LAMSNZBI+rvv9k/gmJH6nHyO9hzu7pwI00Im1YjouagENIWY8Hg7IVFZFi93NbGpGLLrEPEnsAlEUDn04bYvfrIfCSyQgKFoDrC0t+KYFUsHam6OtWVt/5QzW7KI5RABJfcDC/NpqzaCv4BEtr6+g==; s=smtpoutjames; d=linagora.com; v=1; bh=q1rGW+DrXFDN/Lwd6jca7gLmiRczwZYNVY2kF69+A+k=; h=from : reply-to : subject : date : to : cc : resent-date : resent-from : resent-sender : resent-to : resent-cc : in-reply-to : references : list-id : list-help : list-unsubscribe : list-subscribe : list-post : list-owner : list-archive; Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-LINAGORA-Copy-Delivery-Done: 1 From: =?ISO-8859-1?Q?Beno=EEt_TELLIER?= Sender: =?ISO-8859-1?Q?Beno=EEt_TELLIER?= Reply-To: btellier@linagora.com To: "jmap@ietf.org" Message-ID: Date: Fri, 27 Nov 2020 11:34:51 +0000 Archived-At: Subject: [Jmap] Question: Mandate core capability on each API call? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 11:34:58 -0000

Hello!

First I'm very happy to report I have been successfully us= ing https://github=2Ecom/iNPUTmice/lttrs-android on top to (a slightly modi= fied James server)=2E This leads to the following code changes: https://git= hub=2Ecom/linagora/james-project/pull/4089

An incompatibility was fo= und: In James we so far mandate the core capability on every API calls, in = addition to extra capabilities (mail, submission for instance)=2E For my ex= periments, I relaxed this requirements=2E I also think that in doubt client= s can always position this capability to avoid issues=2E

However my = question is: as a server, should I reject api requests not using `urn:ietf:= params:jmap:core` in the using field?

Thanks for answer ;-)

B= enoit

From nobody Fri Nov 27 04:03:47 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9013A0A0B for ; Fri, 27 Nov 2020 04:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 pFAhoPuTN-Ou for ; Fri, 27 Nov 2020 04:03:45 -0800 (PST) Received: from smtp.linagora.com (smtp.linagora.com [54.36.8.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037623A09F9 for ; Fri, 27 Nov 2020 04:03:44 -0800 (PST) Received: from [10.75.246.15] (reverse.completel.net [92.103.166.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id 0F7C03F0A6 for ; Fri, 27 Nov 2020 13:03:39 +0100 (CET) To: jmap@ietf.org X-LINAGORA-Copy-Delivery-Done: 1 From: Benoit Tellier Message-ID: Date: Fri, 27 Nov 2020 13:03:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Jmap] Question: Mandate core capability on each API call? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 12:03:47 -0000 Hello! First I'm very happy to report I have been successfully using https://github.com/iNPUTmice/lttrs-android on top to (a slightly modified james server). This leads to the following code changes: https://github.com/linagora/james-project/pull/4089 An incompatibility was found: In James we so far mandate the core capability on every API calls, in addition to extra capabilities (mail, submission for instance). For my experiments, I relaxed this requirements. I also think that in doubt clients can always position this capability to avoid issues. However my question is: as a server, should I reject api requests not using `urn:ietf:params:jmap:core` in the using field? Thanks for answer ;-) From stephan@wissel.net Fri Nov 27 08:22:38 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713053A0809 for ; Fri, 27 Nov 2020 08:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wissel.net 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 354HSiw-1kLE for ; Fri, 27 Nov 2020 08:22:36 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 C345E3A0803 for ; Fri, 27 Nov 2020 08:22:36 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id b10so3592341pfo.4 for ; Fri, 27 Nov 2020 08:22:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wissel.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=LxlN+2Ikgb9TI9+qaKiRf6eG32KfmLL22YtwiBtUdg4=; b=AH8vV6cbCeV2ZmqC0ZzMBgJMt2UZ+e+aRsWUz0As84QyBscw2L82RjUMvijyBxwUWC FvpGRXVEgX1k6iqw5OUc181vBpto7JbJpMSQL0ZanK7DZ+RktqRX/MyFnM3yso1P3hNt 99KzanT3U+D7iErCoxjA+TJVmk8oEJBsg2ZRA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LxlN+2Ikgb9TI9+qaKiRf6eG32KfmLL22YtwiBtUdg4=; b=oWHGcEd8OpMtQuSswUqInMBY4jbqe8kcOMvk5vlnWi3uPYjpNPDP0YoXSkfN5qFA7s qZ0rOWVfg80jwC3SzGOoVJUtRSdApYobt8pf5i5+uJyRiHADBKQro1038+SlMQGX7UbD Z6WSUpkBYFRM6VJH+n8pq4PC+63Pp6ST6Sd3XEDE0Ghtdr0T4mz2rLlwPlj/SsnQyriv H4Owk8IvNCrI11v7shSB5LpvdEHlcATf/lkDpu8ACWuN9UcO4zOJ+z2wMsRyItaVOXq1 RdMmUyVL/eLiWpywKfI3NKMhrtI6EsYx3ay1lu+LZuwaEI6VfV49eH8Jg1Qq96QdQVD9 zkbg== X-Gm-Message-State: AOAM533j9zHU922CKVztqbpqewHiaYc7UtqPki4QNPotsaBUBonYioRa RPLOEw7/octNMK6E/DGNgeH37RvILgxjjDOyyTKAhCT7CW3alq4S2+8= X-Google-Smtp-Source: ABdhPJw2ehW3RXTfQLjiM34vz7H3YiASCMUkdcbKEwGLP/7LX34R7juD+pOsHQuyMMeTO4MJYl3ktY38M6B3DyfKge4= X-Received: by 2002:a63:6e88:: with SMTP id j130mr3880304pgc.268.1606494155467; Fri, 27 Nov 2020 08:22:35 -0800 (PST) MIME-Version: 1.0 From: Stephan Wissel Date: Sat, 28 Nov 2020 00:22:24 +0800 Message-ID: To: jmap@ietf.org Content-Type: multipart/alternative; boundary="0000000000007887ab05b519113d" Archived-At: Subject: [Jmap] Which spec to use for Calendar? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2020 03:34:43 -0000 --0000000000007887ab05b519113d Content-Type: text/plain; charset="UTF-8" Hi there, we started to create a JSON schema (using OpenAPI 3) for jsCalendar. (which we will contribute back once it is polished) I see 2 documents describing it: https://jmap.io/spec-calendars.html https://tools.ietf.org/html/draft-ietf-calext-jscalendar-32 the former describes objects like CalendarPrincipals, Calendar, CalendarShareNotification, while the later mainly JSEvent, JSTask, JSCalendar. We seen attributes "type" and "@type". Question: Which document should we follow here and how does JSCalendar relate to Calendar? Create a nice day! Stephan H. Wissel Phone: +65 96673269 Blog Twitter LinkedIn Xing --0000000000007887ab05b519113d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi there,

we started to create a JSON s= chema (using OpenAPI 3) for jsCalendar.
(which we will contribute= back once it is polished)

I see 2 documents descr= ibing it:

the former describes= =C2=A0objects like CalendarPrincipals, Calendar, CalendarShareNotification,= =C2=A0
while the later mainly JSEvent, JSTask, JSCalendar.
<= div>
We seen attributes "type" and "@type"= ;.

Question: Which document should we follow here = and how does JSCalendar relate to Calendar?

Cr= eate a nice day!
Stephan H. Wissel

Phone: +65 96673269=
Blog=C2= =A0Twitter= =C2=A0L= inkedIn=C2=A0Xing
--0000000000007887ab05b519113d-- From nobody Mon Nov 30 00:32:39 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632643A1121 for ; Mon, 30 Nov 2020 00:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=MNrHM06U; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Uu9l0ZLh 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 4ofMtSGVCcWq for ; Mon, 30 Nov 2020 00:32:36 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E1F3A1120 for ; Mon, 30 Nov 2020 00:32:36 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C697E5C0052 for ; Mon, 30 Nov 2020 03:32:35 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 30 Nov 2020 03:32:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=R3bEvZL 8MG4AuDQxzYKtFbeJI9wAEfZq11AUKc4zPWE=; b=MNrHM06UG4S4dJiQNikTV6W HDYe1gP97sw/5c2guYzD96OvXp/v64d+93pwKdhkCADqHq9hZMluCSLWLLwh/fmJ dG1g5ZmiUN7UdUezN0S0XEAMVjMAoSF2CNp+fV74P3gYVFZcxDOvyZG4EwkJfqmJ wxExCAyJfpLc9qk3Qv6OzgsTQP7ymSsQ29vNCjCbjfiimU6O/F0h4/cMh/LlSANP l8epi2mE6DP91AHZvfwDrM6ezaf3l3wgmZNngWe5pLbe496E1yXwdJxnc8KOQB25 6idU/MZ5FKZ4Bw9USBwePt1pkHHeX2vB5H6AlYe6gWtVeGeP+qXdg+TcaTBRWtw= = 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=R3bEvZ L8MG4AuDQxzYKtFbeJI9wAEfZq11AUKc4zPWE=; b=Uu9l0ZLh0ZDbSE/HElUYr5 4nlCnk2grxYuXrWjiGx+9pfniIKUPANK784Gaz7Ki5Jw4IHYdj2ZKsw5MGhhdaQJ XOTuOpAaiUXWijCu90NeCE7MBRcoiO898puNK1OnzTaILQ1eDLV5Dg7QjaeWLlvW yEzjVL+O3mAkZy75Sa1yUMymkWE5bCuCQClc16dtVjzPpoQC30ZdbjXYPIh/LkPh +2Z7Kj9JmO05Jz4A115jsFyRdsn9mZ4XFTgmnKPMl4775OPyMg5S78vUsqwHylfv Z8LVP59Zh9A4SdDvlshTbdYZ47/v97haW0v2JqJiDi55BGIhhhur88+po9jISIWw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudehledguddvtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshht ohesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeeggfefud ekfefglefgteekgefhgfehvefhtdevveevvdefheduieffieeigfetieenucffohhmrghi nhepjhhmrghprdhiohdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrghilhhtvggrmhdrtgho mh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7A0AF180093; Mon, 30 Nov 2020 03:32:35 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <483b9167-df7d-4191-a751-416a502e17b0@www.fastmail.com> In-Reply-To: References: Date: Mon, 30 Nov 2020 09:32:15 +0100 From: "Robert Stepanek" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=e558b31d27394fde9de529b31974e6f9 Archived-At: Subject: Re: [Jmap] Which spec to use for Calendar? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2020 08:32:38 -0000 --e558b31d27394fde9de529b31974e6f9 Content-Type: text/plain Hi Stephan, On Fri, Nov 27, 2020, at 5:22 PM, Stephan Wissel wrote: > we started to create a JSON schema (using OpenAPI 3) for jsCalendar. Great! > I see 2 documents describing it: > https://jmap.io/spec-calendars.html > https://tools.ietf.org/html/draft-ietf-calext-jscalendar-32 > [...] > Question: Which document should we follow here and how does JSCalendar relate to Calendar? The jscalendar document in the IETF calext group describes the data model for calendar entries. The document at jmap.io is a proposed internet draft for a calendaring API that uses this data model. The internet draft for the latter is worked on in the IETF jmap working group: https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/ > We seen attributes "type" and "@type". They are unrelated, the @type property is metadata. I assume you mean having both "type" and "@type" can be confusing, and I agree. However, I am not aware of any "type" property in JSCalendar. I do know there is a "type" property defined for CalendarEventNotification in the JMAP Calendars draft. That should probably be renamed. Cheers, Robert --e558b31d27394fde9de529b31974e6f9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Stephan,
=

On Fri, Nov 27, 2020, at 5:22 PM, Stephan Wiss= el wrote:
we started to create a JSON schema (using OpenAPI 3) for= jsCalendar.

Great!
<= /div>

I see 2 documents describing it:
[...]
Question: Which document s= hould we follow here and how does JSCalendar relate to Calendar?

The jscalendar document in the = IETF calext group describes the data model for calendar entries. The doc= ument at jmap.io is a proposed internet draft for a calendaring API that= uses this data model. The internet draft for the latter is worked on in= the IETF jmap working group: https://datatracker.ietf.org/doc/draft-iet= f-jmap-calendars/

We seen attributes = "type" and "@type".

They are unrelated, the @type property is metadata. I assume you= mean having both "type" and "@type" can be confusing, and I agree. Howe= ver, I am not aware of any "type" property in JSCalendar. I do know ther= e is a "type" property defined for CalendarEventNotification in the JMAP= Calendars draft. That should probably be renamed.

Cheers,
Robert


--e558b31d27394fde9de529b31974e6f9-- From nobody Mon Nov 30 20:18:47 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACC13A02C1 for ; Mon, 30 Nov 2020 20:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=TfMXlsR5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aYEB5dza 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 lMZCcxNt0kNg for ; Mon, 30 Nov 2020 20:18:44 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859F13A0147 for ; Mon, 30 Nov 2020 20:18:44 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id AC4395C0166 for ; Mon, 30 Nov 2020 23:18:43 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Mon, 30 Nov 2020 23:18:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=mVYijR5 AJ+JotGXa5rR08TRNABEoD5tWfHEZj9S7IQA=; b=TfMXlsR5vJLy3xtzmLrtQWw BA5cvA2F3pNuBv6TUvbVYC4Q29jqtzYJCHbKrvrDv2gVu+WRmfEfDtAPXj3U+LnT Z4vw66cH8apv9oPfjeSc64h2VYg7QQoFV0FSnuSFw1c7xAncfsHiXoQORahCLrjR i+TDDBfG86XzqVIkLuNUw7FIhsEUQrp3DQ0dhaIRV2tSYcHCVe9YIfGrS9B++T5Q x22V4fSWDPd1mwl6801qs6J6PbVKi/kK/IKv8XABfKUSXgGgVM53MhgPz0ZvGueb 3DcBM7rMv54jU2G7awvffqfukyy9IxAP4Ad9cM/5R5YH7QdvDC0Pyj0KBw0/H0w= = 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=mVYijR 5AJ+JotGXa5rR08TRNABEoD5tWfHEZj9S7IQA=; b=aYEB5dzanc9FvezKhDqnkY gJTiRmFfmZgTnbaEEacp9RaoOAZpKbkkqrlGCr4oSdqij+Fj4U5CHW99/pxAfWHw T9vtZ8AP6yrFn7JOk0F62xN2MtD1t0xzagIsXbtGB9v43bLBuDRxGoBNGu08rmal 8CgjizjcOp/Wv1ATxnR+JNjFXw2Pa615rLtbqSvjhjGoZ8xTwAwP2BXE+jr/Wnx9 htyssaWnmK/vvzwDqBK7DWhD52xNNw2Hlg1E8/Hts2l9GleJj9urTeIJA2a0Mg4A SHBUnFQhSuKTrAf/oNLErNqfjs1VRuZLVhNp/SnpGT77lhVIFssMUtm9IqZoBHtw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeiuddgieekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeevvdetvdduleekhfeghfetfeettdelhfehfeevffevleek uddtudffieevjeevhfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1D4CB180093; Mon, 30 Nov 2020 23:18:43 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <8df9abc8-4c5d-47da-9966-b9646561e286@dogfood.fastmail.com> In-Reply-To: References: Date: Tue, 01 Dec 2020 15:18:42 +1100 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=0145808c111e44cead3ee6efd57af1c6 Archived-At: Subject: Re: [Jmap] Question: Mandate core capability on each API call? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2020 04:18:46 -0000 --0145808c111e44cead3ee6efd57af1c6 Content-Type: text/plain Hi Benoit, Good question! I thought we had specified this, but I can't see it in the final draft. I don't see any particular downside to making it optional, but perhaps someone else has an argument as to why it should be mandatory? Whatever we decide, it is probably worth an erratum for the benefit of future implementors. Neil. --0145808c111e44cead3ee6efd57af1c6 Content-Type: text/html
Hi Benoit,

Good question! I thought we had specified this, but I can't see it in the final draft. I don't see any particular downside to making it optional, but perhaps someone else has an argument as to why it should be mandatory? Whatever we decide, it is probably worth an erratum for the benefit of future implementors.

Neil.
--0145808c111e44cead3ee6efd57af1c6-- From nobody Mon Nov 30 22:33:22 2020 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07D43A0B5A for ; Mon, 30 Nov 2020 22:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=linagora.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 lGPGz_phi_oA for ; Mon, 30 Nov 2020 22:33:19 -0800 (PST) Received: from smtp.linagora.com (smtp.linagora.com [54.36.8.78]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011203A0B54 for ; Mon, 30 Nov 2020 22:33:18 -0800 (PST) Received: from ?Open?PaaS?SMTP?server?for?Linagora? (incoming.linagora.com [51.83.109.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.linagora.com (Postfix) with ESMTPSA id 8877D3F39E for ; Tue, 1 Dec 2020 07:33:15 +0100 (CET) MIME-Version: 1.0 DKIM-Signature: a=rsa-sha256; b=qKNaPhobzXVen4Ha9XBjxPu3VziwrDlM7VoLfA73kVGnnUBW0Ljf0Uyr3p7yFcHvt9y1urtQyTt8czxz7fJI2/VVDOEpZAJwZwqrFPQF0kMZ1qvuVI9s8/RdaPys24T47runr9xqxfU+H9dP0Oa/z+BSbzM0glkr9RRhDjWNdff3ZEgOHrscnMPdEWA8e+mj4IBzKHHKo4Y6rdGJ1XChp7PXK+Zay6BbE7YnmyOTGJOasjC8zTzgexuswcecOcfOJm24kPzSB2K9q9K/hlpJmcWQKuzJHYnJRRVhGPwnl+psqQUHqqTSSFqSWpgwhtWuEchRkZIstYey3LMwpUWduQ==; s=smtpoutjames; d=linagora.com; v=1; bh=sMgT+C93uSv+wQVAiQ/zAx9OIDmEu6qIhMIklsBpISQ=; h=from : reply-to : subject : date : to : cc : resent-date : resent-from : resent-sender : resent-to : resent-cc : in-reply-to : references : list-id : list-help : list-unsubscribe : list-subscribe : list-post : list-owner : list-archive; Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-LINAGORA-Copy-Delivery-Done: 1 From: =?ISO-8859-1?Q?Beno=EEt_TELLIER?= Sender: =?ISO-8859-1?Q?Beno=EEt_TELLIER?= Reply-To: btellier@linagora.com To: IETF JMAP Mailing List Message-ID: Date: Tue, 1 Dec 2020 06:33:14 +0000 References: Archived-At: Subject: Re: [Jmap] Question: Mandate core capability on each API call? X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2020 06:33:21 -0000

Hi Neil,

Thanks for the answer=2E

It is not explicitly ask= ed in the RFC so there is no reasons for server implementations to enforce = it then=2E

I will likely relax the James expectations regarding this= =2E

The explanation behind it would be that the session provides you= an API endpoint compatible with the core capability, thus the redundant ca= pability can be ignored=2E

Maybe we should warn in the client guide = that including the core capability is advised, while waiting for the erratu= m?

Cheers,

Benoit

On December 1, 2020 11:18 AM, = from neilj@fastmailteam=2Ecom
Hi Benoi= t,

Good question! I thought we had specified t= his, but I can't see it in the final draft=2E I don't see any particular do= wnside to making it optional, but perhaps someone else has an argument as t= o why it should be mandatory? Whatever we decide, it is probably worth an e= rratum for the benefit of future implementors=2E

Neil=2E