From nobody Thu Jul 2 05:22:37 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 794163A0C34; Thu, 2 Jul 2020 05:22:35 -0700 (PDT) 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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <159369255543.20019.13598179598227152273@ietfa.amsl.com> Date: Thu, 02 Jul 2020 05:22:35 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-smime-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: Thu, 02 Jul 2020 12:22:36 -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 : S/MIME signature verification extension to JMAP Author : Alexey Melnikov Filename : draft-ietf-jmap-smime-02.txt Pages : 8 Date : 2020-07-02 Abstract: This document specifies an extension to JMAP for returning S/MIME signature verification status. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-smime-02 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-smime-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-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 Thu Jul 2 05:25:05 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 50D1D3A0C38 for ; Thu, 2 Jul 2020 05:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UH_hNQAuXUEs for ; Thu, 2 Jul 2020 05:25:03 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id F2EBF3A0C37 for ; Thu, 2 Jul 2020 05:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1593692702; d=isode.com; s=june2016; i=@isode.com; bh=52BiFAewfjhDCQz+4VeSXWjuFc0Tws08TTWkVGFbOHA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ZhqcFH42D4t4q8UiY22bHpWnYsC67byxT/fUYgBlAtLIzgOcnHOL4Aqlyb9+h3eeD6RzZ1 HoD7sjrjke7yP2ZdqjXgSKGMpcjlKluKgpkWzl0fcdj9Mdbi2YEl90eEQ/R4nPFsJaoOqm kZVRCeP+IxYM+N+xcYrGw5b8XC1Poc0=; Received: from [172.27.253.137] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 2 Jul 2020 13:25:01 +0100 To: jmap@ietf.org References: <159369255543.20019.13598179598227152273@ietfa.amsl.com> From: Alexey Melnikov Message-ID: <013c8917-7ed3-4c07-504f-70fba7903e44@isode.com> Date: Thu, 2 Jul 2020 13:24:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: <159369255543.20019.13598179598227152273@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-smime-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, 02 Jul 2020 12:25:04 -0000 On 02/07/2020 13:22, internet-drafts@ietf.org wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-jmap-smime/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-jmap-smime-02 > https://datatracker.ietf.org/doc/html/draft-ietf-jmap-smime-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-smime-02 This version adds smimeVerifiedAd property and also clarifies interaction of smimeErrors values with with Content-Language header field. From nobody Thu Jul 2 12:31:52 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 C2F9B3A083F; Thu, 2 Jul 2020 12:31:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <159371830065.20833.14382177227696098288@ietfa.amsl.com> Date: Thu, 02 Jul 2020 12:31:40 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mdn-13.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: Thu, 02 Jul 2020 19:31:41 -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 : Handling Message Disposition Notification with JMAP Author : Raphaël Ouazana Filename : draft-ietf-jmap-mdn-13.txt Pages : 13 Date : 2020-07-02 Abstract: JMAP (RFC8620 - JSON Meta Application Protocol) is a generic protocol for synchronising data, such as mail, calendars or contacts, between a client and a server. It is optimised for mobile and web environments, and aims to provide a consistent interface to different data types. JMAP for Mail (RFC8621 - The JSON Meta Application Protocol (JMAP) for Mail) specifies a data model for synchronising email data with a server using JMAP. Clients can use this to efficiently search, access, organise, and send messages. MDN are defined in RFC8098 and are used as "read receipts", "acknowledgements", or "receipt notifications". MDN have a specific format that must be parsed or generated. The goal of this document is to specify a data model for handling MDN messages with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mdn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mdn-13 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mdn-13 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 Thu Jul 2 17:21:57 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 CFF4A3A0941; Thu, 2 Jul 2020 17:20:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: jmap@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373563283.30173.12575842018533844958@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:20:32 -0700 Archived-At: Subject: [Jmap] jmap - Requested session has been scheduled for IETF 108 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: Fri, 03 Jul 2020 00:20:42 -0000 Dear Bron Gondwana, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. jmap Session 1 (1:40 requested) Thursday, 30 July 2020, Session I 1100-1240 Room Name: Room 2 size: 2 --------------------------------------------- Special Note: Joint with EXTRA iCalendar: https://datatracker.ietf.org/meeting/108/sessions/jmap.ics Request Information: --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 15 Conflicts to Avoid: Chair Conflict: calext Technology Overlap: uta httpbis txauth People who must be present: Jiankang Yao Jim Fenton Alexey Melnikov Barry Leiba Neil Jenkins Bron Gondwana Resources Requested: Special Requests: Not at the very end of the day please, that's very late for our Australians. We plan to use this session as a combined session with EXTRA depending how much work comes up at our interim meetings. --------------------------------------------------------- From nobody Fri Jul 3 02:44:12 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 AD44F3A0B7B; Fri, 3 Jul 2020 02:44:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Bron Gondwana via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Bron Gondwana , jmap@ietf.org, iesg-secretary@ietf.org, jmap-chairs@ietf.org, brong@fastmailteam.com Message-ID: <159376944968.24109.13131755536212584007@ietfa.amsl.com> Date: Fri, 03 Jul 2020 02:44:09 -0700 Archived-At: Subject: [Jmap] Publication has been requested for draft-ietf-jmap-mdn-13 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: Fri, 03 Jul 2020 09:44:10 -0000 Bron Gondwana has requested publication of draft-ietf-jmap-mdn-13 as Proposed Standard on behalf of the JMAP working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-jmap-mdn/ From nobody Wed Jul 8 05:23:15 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 26DC43A0962 for ; Wed, 8 Jul 2020 05:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=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=EhZf4JTQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Yysz3vr7 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 I4Ja6VQACw2M for ; Wed, 8 Jul 2020 05:23:12 -0700 (PDT) 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 306663A0959 for ; Wed, 8 Jul 2020 05:23:12 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 4CA8EB6F for ; Wed, 8 Jul 2020 08:23:11 -0400 (EDT) Received: from imap38 ([10.202.2.88]) by compute1.internal (MEProxy); Wed, 08 Jul 2020 08:23:11 -0400 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=fm3; bh=Q7PAFSQux3oOOiTPAxfGH/5CneLgbXMlsUkeg/c 6xKg=; b=EhZf4JTQtVZG1skmHe806e6ClsKl0NFboy1atJrFru4fpgrk5xlXVJR bOTFiOKxTi0lqyRnLFoT8ii30iibdIusjipNu8A5y/55oR4iOIemngCYC5EJZjvt cJQPxZfPD2pYdUvXOT4SKfPsiAcZWJkCR7X1F71r/fztTii3muDbNfCowCOXDaEL XWJqeg6bdZIitQkz5YZ1FGaW/m1Mm3n5fJ3iL8uRRiR/gh3x9ezcxHOxcsIKMI2J HiUfm46zPjR2XbCvYksUydyYiJTFblBHZif/RwbxERCfoHPJnlzvKdUMeK98yaXz vIcrtTz3CizlqePBa02YCmfd1fCb1Kg== 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=fm3; bh=Q7PAFSQux3oOOiTPAxfGH/5CneLgb XMlsUkeg/c6xKg=; b=Yysz3vr71p3/zQP5NOwhRF9H/Y6bZ8F12Jefjc4TKMWiA GQy4t8OZ1VC2Iji4Rl2bSXqq25U/M2IMEuVXAzQRcIwB9mV5Ka1lZga+rI2fVfMC nOo7UgJTnlUM7pjJDwktFF30QgqHCi6d56bnOMqjbG/PIvMKdQ4sZ9btAFYSXS43 dQbrQjzLivzJ8/RjFbX44NF178k5yLHOkpVzpYuffCmHX7CPCo9PKs2pWT+GFuZY 4RAnEO9zd7O4WsgwiH5rEiLJKW1u5qt64WcZ9OYrZKxIZ+tpNfamzMAIO3XrFg4l NjBGeVeIwV1k/Ouo8m7QXVgsSUQiQ31SwcM3OeQ2w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudejgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvdetteeiveeihfegie dtgeeigfduveelhefgffelgeelueehhfeitdelgedtffegnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlth gvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 81DAA4AA005D; Wed, 8 Jul 2020 08:23:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-623-g16e0e99-fm-idx2020-20200708.001-g16e0e99e Mime-Version: 1.0 Message-Id: <1a099401-bbb6-496f-836f-033a0274b74f@dogfood.fastmail.com> Date: Wed, 08 Jul 2020 22:22:50 +1000 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=4d7ecc2d72114cdc941d9859164aafbc Archived-At: Subject: [Jmap] Review: draft-murchison-jmap-sieve-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: Wed, 08 Jul 2020 12:23:14 -0000 --4d7ecc2d72114cdc941d9859164aafbc Content-Type: text/plain Hi Ken, Figured I'd do this here so it's all public :) * * *Open issues:* /set#create should fail if there's already a script with the same name. The JMAP request can include a "destroy" for the ID of the old script, or it can issue an "update" on the Id of the script with the same name to replace the content. I like the fail with "another script is active" as the JMAP way - otherwise you have action at a distance on another object. Again, the client can issue an isActive: false for the other Id as part of the same request. I don't think we need a SieveScript/copy method. There's nothing like it in MANAGESIEVE and the amount of data is so small that it seems pointless. Likewise, I don't think we need quotas if we have size limits and count limits on the number of scripts. We can still return an error to the client if we hit quota limits, but I don't see a client presenting quota information to the user about their sieve storage space as being a realistic use case. *Specific sections: * o *sieveExtensions*: "String[]" A list of Sieve extensions (as listed in Sieve "require" action [RFC5228], Section 3.2) supported by the Sieve engine. It was unclear from me reading RFC5228 whether extension names are case significant, but for the avoidance of doubt we should clarify this here. o *content*: "String" The Sieve code in the script. Note that any double (") quote or backslash (\) characters appearing in the script content MUST be escaped by prefixing them with a backslash (\). This needs clarity around what quoting is required on top of any quoting required by JSON. Is the backslash because of JSON, or is there an additional level of backslashery required as well, and if so why? It should be that passing the same octets to a MANAGESIEVE client for its quoting or a JSON encoded for JMAP encoding works the same. 2.1. SieveScript/get This is a standard "/get" method as described in [RFC8620], Section 5.1. The _ids_ argument may be "null" to fetch all at once. There probably should be an example of using that with "properties": ["name", "isActive"] in order to work out which script is active without needing to pull all the contents. 2.2. SieveScript/set The discussion should cover whether updating the content is legal (per my earlier comments about replacing a script). 2.3. SieveScript/validate o *errorDescription*: "String" A description of the error to show to the user, or an empty string if the Sieve code is valid. Is there a reason why this is empty string rather than NULL? 3. Security Considerations This needs to refer to the security considerations of RFC5228 as well! *General overall comments:** * There's a couple of things I'd love. One is being able to reference sieve scripts as blobs with a blobId. This would allow them to be attached directly to emails, uploaded and downloaded without encoding troubles, etc. I have a draft that I should write up for Blob/set and Blob/info which allow for both setting blobs as part of a request to avoid a separate upload, and getting reverse index information about where blobs are referenced. Another thing is a SieveScript/test endpoint which takes a sieveScriptId (or blobId of a sieve script to avoid uploading it every time without needing to name it!) and an emailId and returns a set of actions that would be taken if that email was processed with that sieve script. This is different enough that it might merit a separate capability called 'sievetest' or something, and will definitely want rate limiting! Is it worth having a SieveScript/query? It probably on needs "name" and "isActive" filters. I mean, sorts as well if you wanted to get fancy and allow a client to manage thousands of these things. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --4d7ecc2d72114cdc941d9859164aafbc Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Ken,

Figured I'd do this here so it's al= l public :)

=
Open issues:

/set#create should fail if there's alread= y a script with the same name.  The JMAP request can include a "des= troy" for the ID of the old script, or it can issue an "update" on the I= d of the script with the same name to replace the content.

I like the fail = with "another script is active" as the JMAP way - otherwise you have act= ion at a distance on another object.  Again, the client can issue a= n isActive: false for the other Id as part of the same request.

I don't think we need a SieveScript/copy method.  There's no= thing like it in MANAGESIEVE and the amount of data is so small that it = seems pointless.

Likewise, I don't think we need quotas i= f we have size limits and count limits on the number of scripts.  W= e can still return an error to the client if we hit quota limits, but I = don't see a client presenting quota information to the user about their = sieve storage space as being a realistic use case.

Spec= ific sections:

= 
   o  *sieveExtensions*: "String[]" A list of Sieve extension=
s (as
      listed in Sieve "require" action [RFC5228], Section 3.2) supported=

      by the Sieve engine.

It was unclear from me reading RFC5228 whether extension names are c= ase significant, but for the avoidance of doubt we should clarify this h= ere.

   =
o  *content*: "String" The Sieve code in the script.  Note that any
      double (") quote or backslash (\) characters appearing in the
      script content MUST be escaped by prefixing them with a backslash
      (\).

This needs clarity around what quoting is requ= ired on top of any quoting required by JSON.  Is the backslash beca= use of JSON, or is there an additional level of backslashery required as= well, and if so why?  It should be that passing the same octets to= a MANAGESIEVE client for its quoting or a JSON encoded for JMAP encodin= g works the same.

<= pre>2.1. SieveScript/get This is a standard "/get" method as described in [RFC8620], Section 5.1. The _ids_ argument may be "null" to fetch all at once.<= br>

There probably should b= e an example of using that with "properties": ["name", "isActive"] in or= der to work out which script is active without needing to pull all the c= ontents.

2.2. SieveScript/set

The discussion should cover whethe= r updating the content is legal (per my earlier comments about replacing= a script).

2.3.  SieveScript/validate
   = o  *errorDescription*: "String" A description of the error to show = to
 &n= bsp;    the user, or an empty string if the Sieve code is= valid.

Is there a reason why this is empty string= rather than NULL?

= 
3.  Security Considerations

This needs to refer to t= he security considerations of RFC5228 as well!


=
General overall comments:

There's a couple of things I'd love.  One is being= able to reference sieve scripts as blobs with a blobId.  This woul= d allow them to be attached directly to emails, uploaded and downloaded = without encoding troubles, etc.  I have a draft that I should write= up for Blob/set and Blob/info which allow for both setting blobs as par= t of a request to avoid a separate upload, and getting reverse index inf= ormation about where blobs are referenced.

Another thing = is a SieveScript/test endpoint which takes a sieveScriptId (or blobId of= a sieve script to avoid uploading it every time without needing to name= it!) and an emailId and returns a set of actions that would be taken if= that email was processed with that sieve script.  This is differen= t enough that it might merit a separate capability called 'sievetest' or= something, and will definitely want rate limiting!

Is it w= orth having a SieveScript/query?  It probably on needs "name" and "= isActive" filters.  I mean, sorts as well if you wanted to get fanc= y and allow a client to manage thousands of these things.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pt= y Ltd
  brong@fastmailteam.com


--4d7ecc2d72114cdc941d9859164aafbc-- From nobody Wed Jul 8 05:41: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 CBE2F3A0ACB for ; Wed, 8 Jul 2020 05:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=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=X92RGRrz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gtUL9i3W 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 ZIC5RRpRgvee for ; Wed, 8 Jul 2020 05:41:39 -0700 (PDT) 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 C3A753A0ACE for ; Wed, 8 Jul 2020 05:41:38 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 9E5532CF for ; Wed, 8 Jul 2020 08:41:37 -0400 (EDT) Received: from imap38 ([10.202.2.88]) by compute1.internal (MEProxy); Wed, 08 Jul 2020 08:41:37 -0400 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=fm3; bh=rPjk7nxVZswGvzFyANqPx7MIjCWfY7RbC8gr0b2 qwRc=; b=X92RGRrzoqE42KQvAJTq/IZvu3Akr9TwQa4RVvA3lv6jgZT4MpXm1HM 26SaGnkOGMpBVmTsfzCsWBxH4tg5BOpjg87wM3yJgo+wfF8bKke2xHP3cXJomwpe HX3CVn7dl44NEDaztOCvStLI8ZrzT4gurt+yQhFhhAFVNsmij3DngeFGta+RPJbf Onk53E5Mw0CHDf/sqfbqrDyUIg0GgzcI7PsET8tIBEv9ySMGFQbrrwRSfoUyFp7G JDV/yCpDh20Zg3lJDAgqwMBfrGhAZfJOtZMhA2eszL0riUKzGnz01tLJ9tuTF3gK ZO8YXvSMxpDquFDXmAyisJcvSxodeeg== 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=fm3; bh=rPjk7nxVZswGvzFyANqPx7MIjCWfY 7RbC8gr0b2qwRc=; b=gtUL9i3W6/Jno0Cwutkc2aar7Muz84jGpuuWEQxxMSG9W 9+qv3D7MR7khvFsMJRGTi2TFoTRBmgc2y6opJDrqyKHQXjym2+ZIe6FuxY735igx 7l4sUSKYdAhBeJnfkLPKhxSwexJk4EaAhUFCSswPa4vumb/W31Eyc8ZKP2dM/9nW 3dgJlOH9Dck6WBd86Fyt1KSFdaMxRjNzW+Fhf+/KFniWVGbIXt3+gdN9aMKcPmu0 QeH2xuAkG+kaDZs/lAISvPZvnB+Qy19fq97BjpeBhSLxmIYz1zPXYuthTxCTGrBv 5z7mLA/CXkWGv6fTQKeevBgX0MjSVq+kjjV/stUpw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudejgdehhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvdetteeiveeihfegie dtgeeigfduveelhefgffelgeelueehhfeitdelgedtffegnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlth gvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EA26C4AA005E; Wed, 8 Jul 2020 08:41:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-623-g16e0e99-fm-idx2020-20200708.001-g16e0e99e Mime-Version: 1.0 Message-Id: <56e51eaa-7f72-4ded-adda-61962fa4a7bb@dogfood.fastmail.com> Date: Wed, 08 Jul 2020 22:41:15 +1000 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=53d4441319484b93ab3dc498ac812bee Archived-At: Subject: [Jmap] Review: draft-ietf-jmap-smime-02 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, 08 Jul 2020 12:41:41 -0000 --53d4441319484b93ab3dc498ac812bee Content-Type: text/plain Hi Alexey, Here's a review of the latest smime document. *Specific Sections:** * 3. Addition to the capabilities object Are you happy to use the 'smime' name for just this part rather than "urn:ietf:params:jmap:smimeverify" or something? 4. Extension to Email/get for S/MIME signature verification smimeStatus: "String|null". Servers MAY return other values not defined below. Client MUST treat unrecognized values as "unknown" or "signed/failed". Note that the value of this property might change over time. Does this need a registry of possible values? In all other cases it is set to the date and time of when S/MIME signature was verified the last time. I would phrase this as "was most recently verified". I had to re-parse it because of the two different uses of "time" in the sentence. As recalculating these values is expensive for the server they MAY be cached for up to 10 minutes from the moment when they were calculated. Do we need a way to tell the server that a fresh calculation is required and it must not use its cache? Examples: Some of the JSON keys are missing quotes around them. 5. Open Issues >From my memory, the issue here is allowing a query "did you verify this message as being correctly signed in the past, and if so when?". That's really useful when looking back at old emails! I would like to see that feature, but I'm also not likely to be a heavy user of this feature, so I think feedback from people who use S/MIME is best on that. I think I would just want a single value smimeLastSuccessfulVerification: "UTCDate|null". Which raises another issue, and I'm not sure if this is an issue with the language in the other specs referenced or specific to this one. The word "VERIFIED" is used with two different meanings in this document. IT's used in 'smimeVerifiedAt' to mention a time when a check was done, and it's used in 'signed/verified' to refer to a SUCCESSFUL verification. These are not the same thing, and I'd be keen to see a different word used for one of them. "signed/valid" for example. *General comments:** * Should we also extend Email/query to have a couple more filters - `hasSmime` and `hasVerifiedSmime` are the two I can think of. - where hasSmime is any status other than NULL, while hasVerifiedSmime is only the value "signed/verified". Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --53d4441319484b93ab3dc498ac812bee Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Alexey,

=
Here's a review of the latest sm= ime document.

Specific Sections:
<= div style=3D"font-family:Arial;">
3.  Addition to the capa=
bilities object

Are you happy to use the 'smime' name for= just this part rather than "urn:ietf:params:jmap:smimeverify" or someth= ing?

4.  Exten=
sion to Email/get for S/MIME signature verification
 smime=
Status: "String|null".
   Servers MAY return other values =
not defined below.  Client
   MUST treat unrecognized values as "unknown" or "signed/failed".  Note=

   that the value of this property might change over time.

Does this need a registry of possible values?

In all other cases
   it is set to the date and time of when S/MIME signature was verified
   the last time.

<= div style=3D"font-family:Arial;">I would phrase this as "was most recent= ly verified".  I had to re-parse it because of the two different us= es of "time" in the sentence.

   As recalculating
   these values is expensive for the server they MAY be cached for up to=

   10 minutes from the moment when they were calculated.

= Do we need a way to tell the server that a fresh calculation is required= and it must not use its cache?

Examples:

= Some of the JSON keys are missing quotes around them.

5.  Open Issues

F= rom my memory, the issue here is allowing a query "did you verify this m= essage as being correctly signed in the past, and if so when?".  Th= at's really useful when looking back at old emails!  I would like t= o see that feature, but I'm also not likely to be a heavy user of this f= eature, so I think feedback from people who use S/MIME is best on that.<= br>

I think I would just want a single value smimeLastSuccess= fulVerification: "UTCDate|null".  Which raises another issue, and I= 'm not sure if this is an issue with the language in the other specs ref= erenced or specific to this one.

The word "VERIFIED" is u= sed with two different meanings in this document.  IT's used in 'sm= imeVerifiedAt' to mention a time when a check was done, and it's used in= 'signed/verified' to refer to a SUCCESSFUL verification.  These ar= e not the same thing, and I'd be keen to see a different word used for o= ne of them.  "signed/valid" for example.

General = comments:

Should we also extend Email/query to= have a couple more filters - `hasSmime` and `hasVerifiedSmime` are the = two I can think of. - where hasSmime is any status other than NULL, whil= e hasVerifiedSmime is only the value "signed/verified".

C= heers,

Bron.
--
  Bron Gondwa= na, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


= --53d4441319484b93ab3dc498ac812bee-- From nobody Mon Jul 13 06:23:07 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 6354A3A11C3 for ; Mon, 13 Jul 2020 06:23:05 -0700 (PDT) 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=QAyO8bve; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OHopiDHV 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 bTfU5kh8ed-f for ; Mon, 13 Jul 2020 06:23:03 -0700 (PDT) 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 5E1583A11BC for ; Mon, 13 Jul 2020 06:23:03 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 8DBBC5C0102 for ; Mon, 13 Jul 2020 09:23:02 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Mon, 13 Jul 2020 09:23:02 -0400 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=fm3; bh=ern45x6bnTeufI0lzwVQW4E7D5oaX2GHf0xYeH+ ng3k=; b=QAyO8bve5jtAX/wkdjTNooU7/aVsQnMy6uftdbAMzw1psk3Vh7ULqLA eG7sKY2qXiIXH7VXrgKqevLxKHTaMsGmFX3w3UtsERWsNwPY1sf9BNNQZ9UiXrG+ VJ4NU8Z3lkxq/7DG+2Lt2l36zydwGdoChDqmQCNjoG1MVvbLOeb9rM1L08TZZJVz ODBTLNVmgImuxRd0zLgCHbq4D+LhYxR/AE4VUkXqioJ6K8ZRZ+dSpds9DeeF3RsC 5ntPHSswd8f3pnJx8shJ1vtwi/n4+kqAfehDIrfRGVmuyDFSVV3lfMK5iheFmhqP weYvtGttELWxnqzfJpsn8PkpWCJkywA== 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=fm3; bh=ern45x6bnTeufI0lzwVQW4E7D5oaX 2GHf0xYeH+ng3k=; b=OHopiDHVCulh0H3CShaiCvz2+YEMDuTeI/wA6yb00LVDg GVajtge63KZk/5ZHXyU9X+ClKjI9ZM6a/oh9uPDw83i3/XXO7hd+csGJBnVIAUge /+Q8Z3mv/szNk8SmmEnyJaMJJOBUPrXZYOUH4FSZvWMIrnpQo9vMlKeSdhe6UQ2u /y3MMNDFlHe8Ebo66Pg/4hJi1mt6NJQgekH5VX5j3VXlaTHg6QvmtPgXRCCNQbQD OFHFAhlBtyjrWBDXC17DoZZ4vAqeNre5aUwxCEKPCIpXyWUhwv38ushuGUywrwU1 28q1xOMQlq00xAq+q035hxztvsekQUpyCXvczZu0A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvdekgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvdetteeiveeihfegie dtgeeigfduveelhefgffelgeelueehhfeitdelgedtffegnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlth gvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1CF54180109; Mon, 13 Jul 2020 09:23:02 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-637-g57f734b-fm-idx2020-20200709.002-g57f734bf Mime-Version: 1.0 Message-Id: <100ecc03-66db-4ee0-b56c-be20f605ff8b@dogfood.fastmail.com> Date: Mon, 13 Jul 2020 23:22:40 +1000 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=82d409702d944c0080f8438c428fd861 Archived-At: Subject: [Jmap] Review: draft-ietf-jmap-calendars-03 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, 13 Jul 2020 13:23:05 -0000 --82d409702d944c0080f8438c428fd861 Content-Type: text/plain Ok, so I haven't read this thing yet! Figured I'd have a read through and note down things as they come up. This'll just be all the clarifications or things that I don't like because otherwise it would be a long email! *1.1: Data Model * A CalendarPrincipal has a 1:1 correspondence with an Account (see [RFC8620], Section 1.6.2) that supports the "urn:ietf:params:jmap:calendars" capability. And then later CalendarPrincipal/query is defined as a way to scan through CalendarPrincipals efficiently. *Why do this rather than defining properties on the Account object directly and then adding an Account/query mechanism *which allows you to filter to accounts which support "urn:ietf:params:jmap:calendars" as part of the query parameters? This would be easier to extend for other data types that may be available from many accounts in the future. *2. Calendar Principals* All the object properties appear to be required with no default value. Should they have default values given (generaly null) in the spec? Particularly where null is a valid value, it appears that would be a sensible default. *3. Calendars** * Likewise, should color be optional (default #000000 or whatever). Speaking of color - I believe that the CSS color specs should be normative references, since you can't build a compliant implementation without them. Likewise isSubscribed should probably default to true if not specified, since a server which doesn't care about subscriptions would just return the calendars that you can see. And probably ditto for everything else that doesn't have a default. o *timeZone*: "String|null" The time zone to use for events without a time zone when the server needs to resolve them into absolute time, e.g., for reminders, queries, or availability calculation. The value MUST be a time zone id from the IANA Time Zone Database. If "null", the timeZone of the account's associated CalendarPrincipal will be used. Clients SHOULD use this as the default for new events in this calendar if set. The IANA Time Zone Database should be in the references at the end of the document. *3.1. Per-user properties** * We should address read-only accounts here, where users may not be able to store anything on the server. * * *4.5. CalendarShareNotification/set* This is a standard "/changes" method as described in [RFC8620], Section 5.3. This looks like a copy-paste error from above. It looks from the lack of create/update that "undo" will not work when dismissing notifications! *5. Calendar Events* You know my opinion on this! I think events should be able to be present in mutliple Calendars, so calendarIds becomes a map of { "id" : true, "id2": true } instead of a single value. Of course that doesn't map well with copying stuff out of the "defaults" fields of the calendar into the event when it's created, but I also don't like that compared to the client reading the defaults off the calendar and applying them itself - good old "be explicit in what you ask of the server" which is a continual tradeoff, but which I really like as a pattern because it reduces magicalness and action at a distance. *5.8. CalendarEvent/set* o *sendSchedulingMessages*: "Boolean" (default: true) If true then any changes to scheduled events will be sent to all the participants (if the user is an owner of the event) or back to the owners (otherwise). If false, the changes only affect this calendar and no scheduling messages will be sent. Speaking of which - I believe the default should be false here. Clients can easily be built to automatically add it, and the wording needs to say that it's not an error to set this even if none of the events are scheduling events... but things should default to less impactful and the client should ask for impacts - and sending scheduling messages is an impact. The ICALENDAR default is the wrong one, and we should fix that here. *5.8.1. Patching** * Yeah, I guess that's the only way to do it! I'm unhappy about the patching story here in general and would like to discuss the "patch the model" vs "patch the representation" a bit more, but there's definitely edge cases to review either way. It's not so bad with recurrences because you can treat them as fully expanded for patching purposes, but it does get very messy with localisation! *9. IANA Considerations* There are a few fields which have been specified as an enumeration, e.g. Calendar/role, and "Per User Properties" in JSEvent. Should there be registries created for these? ... This may not be everything yet, but these are the main points I found reading through! Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --82d409702d944c0080f8438c428fd861 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Ok, so I haven't read this thing yet!  Figured I'd ha= ve a read through and note down things as they come up.  This'll ju= st be all the clarifications or things that I don't like because otherwi= se it would be a long email!
=
1.1: Data Mode= l

A=
 CalendarPrincipal has a 1:1
   correspondence with an Account (see [RFC8620], Section 1.6.2) that
   supports the "urn:ietf:params:jmap:calendars" capability.

And then later CalendarPrincipal/query is defined as a way to scan t= hrough CalendarPrincipals efficiently.  Why do this rather than = defining properties on the Account object directly and then adding an Ac= count/query mechanism which allows you to filter to accounts which s= upport "urn:ietf:params:jmap:calendars" as part of the query parameters?=   This would be easier to extend for other data types that may be a= vailable from many accounts in the future.

2. Calendar Principals

All the object properties appear to be required with no default value.=   Should they have default values given (generaly null) in the spec= ?  Particularly where null is a valid value, it appears that would = be a sensible default.

3. Calendars

Likewise, should colo= r be optional (default #000000 or whatever).

Speaking of color - I believe that the CSS color sp= ecs should be normative references, since you can't build a compliant im= plementation without them.
Likewise isSubscribed should p= robably default to true if not specified, since a server which doesn't c= are about subscriptions would just return the calendars that you can see= .  And probably ditto for everything else that doesn't have a defau= lt.

   o=
  *timeZone*: "String|null" The time zone to use for events without
      a time zone when the server needs to resolve them into absolute
      time, e.g., for reminders, queries, or availability calculation.
      The value MUST be a time zone id from the IANA Time Zone Database.=

      If "null", the timeZone of the account's associated
      CalendarPrincipal will be used.  Clients SHOULD use this as the
      default for new events in this calendar if set.

The IANA Time Zone Database should be in = the references at the end of the document.

3.1. Per-user properties

We should address read-only accounts here, where users = may not be able to store anything on the server.

4.5.  CalendarShareNotifica=
tion/set

   This is a standard "/changes" method as described in [RFC8620],
   Section 5.3.

Th= is looks like a copy-paste error from above.

It looks fro= m the lack of create/update that "undo" will not work when dismissing no= tifications!

= 
5. Calendar Events

You know my opinion on t= his!  I think events should be able to be present in mutliple Calen= dars, so calendarIds becomes a map of { "id" : true, "id2": true } inste= ad of a single value.

Of course that doesn't map well wit= h copying stuff out of the "defaults" fields of the calendar into the ev= ent when it's created, but I also don't like that compared to the client= reading the defaults off the calendar and applying them itself - good o= ld "be explicit in what you ask of the server" which is a continual trad= eoff, but which I really like as a pattern because it reduces magicalnes= s and action at a distance.
<= br>
5.8.  CalendarEvent/set

   o  *sendScheduling=
Messages*: "Boolean" (default: true) If true then
      any changes to scheduled events will be sent to all the
      participants (if the user is an owner of the event) or back to the=

      owners (otherwise).  If false, the changes only affect this
      calendar and no scheduling messages will be sent.

S= peaking of which - I believe the default should be false here.  Cli= ents can easily be built to automatically add it, and the wording needs = to say that it's not an error to set this even if none of the events are= scheduling events... but things should default to less impactful and th= e client should ask for impacts - and sending scheduling messages is an = impact.  The ICALENDAR default is the wrong one, and we should fix = that here.

= 
5.8.1.  Patching

Yeah, I guess that's the = only way to do it!  I'm unhappy about the patching story here in ge= neral and would like to discuss the "patch the model" vs "patch the repr= esentation" a bit more, but there's definitely edge cases to review eith= er way.  It's not so bad with recurrences because you can treat the= m as fully expanded for patching purposes, but it does get very messy wi= th localisation!

9. IANA Considerations

There are a few = fields which have been specified as an enumeration, e.g. Calendar/role, = and "Per User Properties" in JSEvent.  Should there be registries c= reated for these?

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

This may not be ever= ything yet, but these are the main points I found reading through!

Cheers,

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

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  b= rong@fastmailteam.com


--82d409702d944c0080f8438c428fd861-- From nobody Mon Jul 13 06:59:58 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 53D4A3A121E; Mon, 13 Jul 2020 06:59:56 -0700 (PDT) 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.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <159464879630.29708.12215143774183545428@ietfa.amsl.com> Date: Mon, 13 Jul 2020 06:59:56 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-jscontact-vcard-00.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, 13 Jul 2020 13:59:56 -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 : JSContact: Converting from and to vCard Authors : Mario Loffredo Robert Stepanek Filename : draft-ietf-jmap-jscontact-vcard-00.txt Pages : 38 Date : 2020-07-13 Abstract: This document provides informational guidance for converting the contact card defined by JSContact specification, namely JSCard, from and to vCard. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact-vcard/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-jscontact-vcard-00 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-vcard-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 13 13:10:02 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 6E9EA3A0805 for ; Mon, 13 Jul 2020 13:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=manxome.org header.b=XaNgGID5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DanEfoOB 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 7jyF_2yHmaOf for ; Mon, 13 Jul 2020 13:09:58 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334343A081F for ; Mon, 13 Jul 2020 13:09:27 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 3D17B5C019D for ; Mon, 13 Jul 2020 16:09:27 -0400 (EDT) Received: from imap35 ([10.202.2.85]) by compute2.internal (MEProxy); Mon, 13 Jul 2020 16:09:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manxome.org; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=WFxo6G8wOzm8gMKLPISThZZez1myoUH VAb11H1exR7I=; b=XaNgGID56B/1m9zSmG5wUtzVZjN0GgtRAlj9M0WZKH8bWk0 eoZIs+voYgWqPA+oMYwaR1M4UYqupFbGDagc4uJU4r6gs/zJATDguxRIgDSL7Hfa kXWxw3tsAI98pKj8jICf53m4BUwMjCH+wwMep3LIkqhttrk5su1ByqE8BtMb3t4t GmLmIsYxWrkLPk7UOEf258srzJBWERbBZ+OS1nwNvaYt+1jIRzSFzg6F2c821JoL BmLqINVIcvKC2Y/ZZsmdcRdeOiRWqLi3XSWQUMyMYnZ3it2B0eV7dKbdZ3xP1Yoo M3cBAuJVqkdvMcueQ5e0FnzyBbaiMhf99sBUU1A== 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=fm3; bh=WFxo6G 8wOzm8gMKLPISThZZez1myoUHVAb11H1exR7I=; b=DanEfoOBriVcID+TfjwpTe 3BN2dIUsyayF97RORvQSIDwejL7072pKdP5T8TGVZOqhvzblvbcRpLFUfT6Uwo/9 loeSoSlKanLcRZ5sKbg+b1kneJdxCKvSBPLbrx+OPuYueAiGl08LJAZ2O8OH8bai vC/xdp7xayaNc5vEvAH8cOLkOAaNxlePUaxctiUk1Equ3w7wit9J6fYsi28q7x6T LIJtjZda+UUguBQYsUlfZDsKbDmpk0U6M5NSmGftUn+UavptueQuZArE9VSwmMVN 6VDVjZQwgHY7t3zDjwhC1dzaltuYRAsMynwbnjwCTUAlLsENtpiLBFwskTEQmhCg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvdekgddugeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedftfhitggrrhguohcuufhighhnvghsfdcuoehjmhgrphdr ihgvthhfsehrjhgsshdrmhgrnhigohhmvgdrohhrgheqnecuggftrfgrthhtvghrnhepgf eggeegjeevffethfegveegtdelffeuieeijeetieeuteehffehffevvdeufeegnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjhhmrghprdhivg htfhesrhhjsghsrdhmrghngihomhgvrdhorhhg X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D193114C013D; Mon, 13 Jul 2020 16:09:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e Mime-Version: 1.0 Message-Id: In-Reply-To: <1a099401-bbb6-496f-836f-033a0274b74f@dogfood.fastmail.com> References: <1a099401-bbb6-496f-836f-033a0274b74f@dogfood.fastmail.com> Date: Mon, 13 Jul 2020 16:08:28 -0400 From: "Ricardo Signes" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=109b55091dcb4be3abf8235c830aaa07 Archived-At: Subject: Re: [Jmap] Review: draft-murchison-jmap-sieve-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: Mon, 13 Jul 2020 20:10:00 -0000 --109b55091dcb4be3abf8235c830aaa07 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Jul 8, 2020, at 8:22 AM, Bron Gondwana wrote: > *Open issues:* >=20 > /set#create should fail if there's already a script with the same name= . The JMAP request can include a "destroy" for the ID of the old script,= or it can issue an "update" on the Id of the script with the same name = to replace the content. Well, you already know this doesn't get me what I want, but I have a sug= gestion. :-) First, my complaints: This leads to more HTTP transactions than is otherwise necessary. Say that from a position of ignorance of the remote state, I want to set= my active Sieve script to the document S. This requires this set of int= eractions: =E2=80=A2 HTTP request 1: SieveScript/get =E2=80=A2 locally extract the id of the active script =E2=80=A2 HTTP request 2: SieveScript/set { update: { activeId: { script= : $NEW, isActive: true } } } This is an extra round trip. (So the re-set of isActive at the end is to= avoid a race. An ifInState would also do the trick.) This would not be required in managesieve, where by convention the clien= t could control the script name and know that a PUTSCRIPT for the conven= tional name would update the active script. The shift from client-contro= lled keys (script names) to server-controlled keys (JMAP ids) eliminates= the possibility for this kind of convention.=20 You suggest that the client can perform either a destroy-and-create or a= n update but I think that *only the update-based operation is safe*. Con= sider: =E2=80=A2 client does a SieveScript/get and determines the active id scr= ipt is "123" =E2=80=A2 client issues SieveScript/set { destroy =3D> [ "123" ], create= =3D> { newScript =3D> { =E2=80=A6something invalid=E2=80=A6 } } } Because the create and destroy may be applied independently, the user co= uld end up with no active script at all. This is too bad, because otherw= ise you could provide SieveScript/query (which would need to be invented= ), backreference the results for (filter:{isActive:true} OR name:NameWeW= ant) in a destroy, and create the replacement in the same breath, which = would be safe.=20 *I suggest instead*: 1. We drop isActive as a property from SieveScript. 2. We create a new type, SieveConfig 3. SieveConfig has exactly one instance per account, with the fixed id "= singleton" 4. The SieveScriptConfig object has one property, activeScriptId, which = is either a script id or null 5. If no "name" is provided, the server will provide a guaranteed unique= name. To replace the active Sieve script in the blind, you do this: SieveScript/set { create: { newScript: { content: "..." } } } SieveConfig/set { update: { "singleton": { activeScriptId: "#newScript" = } } } This is guaranteed safe. The worst case is that you end up with a unique= ly-named script that is not, in fact, active. We probably also need: 6. If the active script is deleted, the SieveScriptActive activeScriptId= becomes null. Alternatively, it could be illegal to destroy the active script. *As for everything else=E2=80=A6* I agreed with all the rest of your points. If we add SieveScript/query as you suggest, then this pair of methods wo= uld get tacked onto my couplet above: SieveScript/query { filter: { isActive: false } }, A SieveScript/set { "#destroy": { backreference-to-A-list } } --=20 rjbs --109b55091dcb4be3abf8235c830aaa07 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Wed, Ju= l 8, 2020, at 8:22 AM, Bron Gondwana wrote:
Open is= sues:

/set#create s= hould fail if there's already a script with the same name.  The JMA= P request can include a "destroy" for the ID of the old script, or it ca= n issue an "update" on the Id of the script with the same name to replac= e the content.

Well, you= already know this doesn't get me what I want, but I have a suggestion.&= nbsp; :-)  First, my complaints:

This = leads to more HTTP transactions than is otherwise necessary.

Say that from a position of ignorance of the remote st= ate, I want to set my active Sieve script to the document S.  This = requires this set of interactions:

=E2=80=A2= HTTP request 1:  SieveScript/get
=E2=80=A2 locally e= xtract the id of the active script
=E2=80=A2 HTTP request = 2: SieveScript/set { update: { activeId: { script: $NEW, isActive: true = } } }

This is an extra round trip.  (S= o the re-set of isActive at the end is to avoid a race.  An ifInSta= te would also do the trick.)

This would not= be required in managesieve, where by convention the client could contro= l the script name and know that a PUTSCRIPT for the conventional name wo= uld update the active script.  The shift from client-controlled key= s (script names) to server-controlled keys (JMAP ids) eliminates the pos= sibility for this kind of convention.  

You suggest that the client can perform either a destroy-and-crea= te or an update but I think that only the update-based operation= is safe.  Consider:

=E2=80=A2 cli= ent does a SieveScript/get and determines the active id script is "123"<= br>
=E2=80=A2 client issues SieveScript/set { destroy =3D> = [ "123" ], create =3D> { newScript =3D> { =E2=80=A6something inval= id=E2=80=A6 } } }

Because the create and de= stroy may be applied independently, the user could end up with no active= script at all.  This is too bad, because otherwise you could provi= de SieveScript/query (which would need to be invented), backreference th= e results for (filter:{isActive:true} OR name:NameWeWant) in a destroy, = and create the replacement in the same breath, which would be safe. = ;

I suggest instead:
<= br>
1. We drop isActive as a property from SieveScript.
2. We create a new type, SieveConfig
3. SieveConfi= g has exactly one instance per account, with the fixed id "singleton"
4. The SieveScriptConfig object has one property, activeScri= ptId, which is either a script id or null
5. If no "name" = is provided, the server will provide a guaranteed unique name.
=

To replace the active Sieve script in the blind, you= do this:

SieveScript/set { create: { newSc= ript: { content: "..." } } }
SieveConfig/set { update: { "= singleton": { activeScriptId: "#newScript" } } }

This is guaranteed safe.  The worst case is that you end up w= ith a uniquely-named script that is not, in fact, active.
=
We probably also need:

= 6.  If the active script is deleted, the SieveScriptActive activeSc= riptId becomes null.

Alternative= ly, it could be illegal to destroy the active script.

As for everything else=E2=80=A6
I agreed with all the rest of your points.

If we add SieveScript/query as you suggest, then= this pair of methods would get tacked onto my couplet above:
<= div>
SieveScript/query { filter: { isActive: false } }, A<= br>
SieveScript/set { "#destroy": { backreference-to-A-list } = }

-- 
rjbs
--109b55091dcb4be3abf8235c830aaa07-- From nobody Sun Jul 19 21:19: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 CA4633A0A0C for ; Sun, 19 Jul 2020 21:18:55 -0700 (PDT) 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_H4=-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=ZeTql+cN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NurrSQlr 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 lxT2I406AZzh for ; Sun, 19 Jul 2020 21:18:53 -0700 (PDT) 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 BF7C03A0A3F for ; Sun, 19 Jul 2020 21:18:50 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 12D9A882 for ; Mon, 20 Jul 2020 00:18:50 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 20 Jul 2020 00:18:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=DkDgYg1 +cdRqgg+G9reKWZuI/7CjnLye/O84S/2X10w=; b=ZeTql+cN0kUwxsDbs1e1jUR 9f4QIT5Ovqn7tyuDioSaD0KRGh7bOBl/ye9ldUktZEDkWj4cDdkWoQDXPiOHLk4L 1dtYaSbzDxqnR2MonlvLaVk1gz6+dM+nGFt/w2NVYC8dIVdrD3hCdQ/rLsTqgdEk C7TQVzwmuD2x/aBdyVDD9C5/r9I2yirK/l9zdqUTqerBZ+UbhUGd08cMGhj8c+Hb Uk9G51/WIL9qmU9bjd9K3M37fLvRH2hXUcZeJAk1YxEq3jE2MJ+9w8rtLyqUYwrU TeT6M4GvAFZOxg5lPL3IThnVcEi/6XHkVpPmc4s/0oy74aOUc5CNQBYV5qda+JA= = 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=fm3; bh=DkDgYg 1+cdRqgg+G9reKWZuI/7CjnLye/O84S/2X10w=; b=NurrSQlrQtaOAj527nAcIo 6SVclW6w/jvsM6xog0oqSJkU9plB8ylzlyGAmxGzXQcA+zRDZUo9t7VeSk7qhv4w YvWlIydZkWBTUNyfTlatUnlgx/h7iY83brHSl1SqYRZ9nxgLWMQV7BTijmrWFdYA LY078VeuUlXIDPgT5Fq2UDPLEIrSxzJ1PcgSqpMoDStlGpdlcyhK8yBkszeEhHQw Z1rJJAhDTBs/y+nHNiCwM9ytrXFMbrK2V5z6VlPP3wXD42Lo7k+VLBOkFYcRnuFB f6sqT/eYVljimZwIULLp5TA74OHVfomq98O97evunlixvXoPsyspS9/KvuW1bHLA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrgedvgdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepvedvtedvudelkefhgefhteeftedtlefhheefveffveelkedu tdduffeiveejvefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6A775180269; Mon, 20 Jul 2020 00:18:49 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-77-g15cf182-fm-20200720.002-g15cf182a Mime-Version: 1.0 Message-Id: <044b2bbb-9f69-486a-841d-1cc9bad4356d@dogfood.fastmail.com> In-Reply-To: <100ecc03-66db-4ee0-b56c-be20f605ff8b@dogfood.fastmail.com> References: <100ecc03-66db-4ee0-b56c-be20f605ff8b@dogfood.fastmail.com> Date: Mon, 20 Jul 2020 14:18:47 +1000 From: "Neil Jenkins" To: "IETF JMAP Mailing List" Content-Type: multipart/alternative; boundary=74585330248344cdb33db52ee8cb7e2e Archived-At: Subject: Re: [Jmap] Review: draft-ietf-jmap-calendars-03 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, 20 Jul 2020 04:18:59 -0000 --74585330248344cdb33db52ee8cb7e2e Content-Type: text/plain On Mon, 13 Jul 2020, at 23:22, Bron Gondwana wrote: > *Why do this rather than defining properties on the Account object directly and then adding an Account/query mechanism *which allows you to filter to accounts which support "urn:ietf:params:jmap:calendars" as part of the query parameters? For several reasons, including: 1. You may have access to more than one account containing calendar principals. These are separate namespaces and need to remain so. Making it all part of one thing would break this, making it much harder to transparently proxy different backends via a single JMAP endpoint. 2. You may not have access to the account (you are only allowed to call getAvailability); so you can't represent the principal as an account. 3. The standard get/changes etc. methods have consistency guarantees tied to an account. This would be undefined, or require redefining if you needed to do it for querying accounts, which makes the spec more complex. These guarantees may not be possible to make when the set of accounts actually comes from multiple different backends. > *2. Calendar Principals* > > All the object properties appear to be required with no default value. Should they have default values given (generaly null) in the spec? Particularly where null is a valid value, it appears that would be a sensible default. Since you can't create a principal via this spec, it's unclear to me what a default would mean for these properties. > *3. Calendars*** > > Likewise, should color be optional (default #000000 or whatever). I'll make it nullable and that can be the default. > Speaking of color - I believe that the CSS color specs should be normative references, since you can't build a compliant implementation without them. I'm not sure I can do this in the markdown source; this will probably need fixing up at the end when I do final edits in the XML. I'll make sure we do this though. > Likewise isSubscribed should probably default to true if not specified, since a server which doesn't care about subscriptions would just return the calendars that you can see.. It's a bit more nuanced than that. The spec says: *This SHOULD default to false for Calendars in shared accounts the user has access to and true for any new Calendars created by the user themself.* > And probably ditto for everything else that doesn't have a default. I've added in defaults for all other calendar properties where it makes sense. > o *timeZone*: "String|null" The time zone to use for events without a time zone when the server needs to resolve them into absolute time, e.g., for reminders, queries, or availability calculation. The value MUST be a time zone id from the IANA Time Zone Database. If "null", the timeZone of the account's associated CalendarPrincipal will be used. Clients SHOULD use this as the default for new events in this calendar if set. > > The IANA Time Zone Database should be in the references at the end of the document. Same as with the CSS ref; I've put a link in and will make sure it's a normative reference in the final edit. > *3.1. Per-user properties*** > > We should address read-only accounts here, where users may not be able to store anything on the server. I've taken out this section because it's covered in more detail in the Calendar/set description (the user must be subscribed to the calendar in order to change any of these properties for themself, and the server may reject them subscribing themself even if they can otherwise see and access it, thus enforcing a read-only mode). > *4.5. CalendarShareNotification/set* This is a standard "/changes" method as described in [RFC8620], Section 5.3. > > This looks like a copy-paste error from above. Thanks, fixed. > It looks from the lack of create/update that "undo" will not work when dismissing notifications! Correct. I considered this when defining it and I think it's OK; I've yet to see a client that has undo for dismissing a notification like this, and it makes server implementation considerably easier (you don't want clients being able to create bogus notifications; if they can create anything it would have to be something identical to the one they dismissed and that gets icky). > *5. Calendar Events* > > You know my opinion on this! I think events should be able to be present in mutliple Calendars, so calendarIds becomes a map of { "id" : true, "id2": true } instead of a single value. > > Of course that doesn't map well with copying stuff out of the "defaults" fields of the calendar into the event when it's created Nothing is copied on create. Inheritance from the calendar is live. e.g. If you set the event to useDefaultAlerts then change the default alerts on the calendar it's in, the new defaults now apply to the event. Inheriting this from multiple calendars would just be a mess (same for time zone for floating events etc.) > *5.8. CalendarEvent/set* > > o *sendSchedulingMessages*: "Boolean" (default: true) If true then any changes to scheduled events will be sent to all the participants (if the user is an owner of the event) or back to the owners (otherwise). If false, the changes only affect this calendar and no scheduling messages will be sent. > > Speaking of which - I believe the default should be false here. Clients can easily be built to automatically add it, and the wording needs to say that it's not an error to set this even if none of the events are scheduling events... but things should default to less impactful and the client should ask for impacts - and sending scheduling messages is an impact. The ICALENDAR default is the wrong one, and we should fix that here. Sure, fine by me. > *9. IANA Considerations* > > There are a few fields which have been specified as an enumeration, e.g. Calendar/role, and "Per User Properties" in JSEvent. Should there be registries created for these? Yes, I think there should. Neil. --74585330248344cdb33db52ee8cb7e2e Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, 13= Jul 2020, at 23:22, Bron Gondwana wrote:
Why do th= is rather than defining properties on the Account object directly and th= en adding an Account/query mechanism which allows you to filter to a= ccounts which support "urn:ietf:params:jmap:calendars" as part of the qu= ery parameters?

For several re= asons, including:
  1. You may have access to more than one = account containing calendar principals. These are separate namespaces an= d need to remain so. Making it all part of one thing would break this, m= aking it much harder to transparently proxy different backends via a sin= gle JMAP endpoint.
  2. You may not have access to the account (y= ou are only allowed to call getAvailability); so you can't represent the= principal as an account.
  3. The standard get/changes etc. meth= ods have consistency guarantees tied to an account. This would be undefi= ned, or require redefining if you needed to do it for querying accounts,= which makes the spec more complex. These guarantees may not be possible= to make when the set of accounts actually comes from multiple different= backends.

2. Calendar Principals

All the = object properties appear to be required with no default value.  Sho= uld they have default values given (generaly null) in the spec?  Pa= rticularly where null is a valid value, it appears that would be a sensi= ble default.

Since you can't c= reate a principal via this spec, it's unclear to me what a default would= mean for these properties.

3. Calendars

Likewise, should color be optional (default #000000 or whatever).
<= /div>

I'll make it nullable and that can= be the default.

Speaking of color - I believe that the CSS color specs shoul= d be normative references, since you can't build a compliant implementat= ion without them.

I'm no= t sure I can do this in the markdown source; this will probably need fix= ing up at the end when I do final edits in the XML. I'll make sure we do= this though.

Likewise isSubscribed should probably default to true if not sp= ecified, since a server which doesn't care about subscriptions would jus= t return the calendars that you can see.. 

It's a bit more nuanced than that. The spec say= s:

This SHOULD default to false for Cale= ndars in shared accounts the user has access to and true for any new Cal= endars created by the user themself.

And probably ditto for everything el= se that doesn't have a default.

I've added in defaults for all other calendar properties where i= t makes sense.

   o  *timeZone*: "String|null" The time zone to use =
for events without
      a time zone when the server needs to resolve them into absolute
      time, e.g., for reminders, queries, or availability calculation.
      The value MUST be a time zone id from the IANA Time Zone Database.=

      If "null", the timeZone of the account's associated
      CalendarPrincipal will be used.  Clients SHOULD use this as the
      default for new events in this calendar if set.

The IANA Time Zone Database should be in = the references at the end of the document.
<= div>
Same as with the CSS ref; I've put a link in and will= make sure it's a normative reference in the final edit.
<= br>
3.1. Per=
-user properties
<= br>
We should address read-only a= ccounts here, where users may not be able to store anything on the serve= r.

I've taken out this section= because it's covered in more detail in the Calendar/set description (th= e user must be subscribed to the calendar in order to change any of thes= e properties for themself, and the server may reject them subscribing th= emself even if they can otherwise see and access it, thus enforcing a re= ad-only mode).

4.5.  CalendarShareNotification/set

   This is a standard "/changes" method as described in [RFC8620],
   Section 5.3.

Th= is looks like a copy-paste error from above.

Thanks, fixed.

<= /div>
It looks from the lack of create/update that "undo" will not w= ork when dismissing notifications!

Correct. I considered this when defining it and I think= it's OK; I've yet to see a client that has undo for dismissing a notifi= cation like this, and it makes server implementation considerably easier= (you don't want clients being able to create bogus notifications; if th= ey can create anything it would have to be something identical to the on= e they dismissed and that gets icky).

5. Calendar Events
<=
/pre>

You know my opinion on this!  I think events should be able =
to be present in mutliple Calendars, so calendarIds becomes a map of { "=
id" : true, "id2": true } instead of a single value.

Of c=
ourse that doesn't map well with copying stuff out of the "defaults" fie=
lds of the calendar into the event when it's created

Nothing is copied on create. Inherita= nce from the calendar is live. e.g. If you set the event to useDefaultAl= erts then change the default alerts on the calendar it's in, the new def= aults now apply to the event. Inheriting this from multiple calendars wo= uld just be a mess (same for time zone for floating events etc.)

=
5.8.  CalendarEvent/set
<= div style=3D"font-family:Arial;">

<= /div>
   o  *sendSchedulingMessages*: "Boolean" (default=
: true) If true then
      any changes to scheduled events will be sent to all the
      participants (if the user is an owner of the event) or back to the=

      owners (otherwise).  If false, the changes only affect this
      calendar and no scheduling messages will be sent.

S= peaking of which - I believe the default should be false here.  Cli= ents can easily be built to automatically add it, and the wording needs = to say that it's not an error to set this even if none of the events are= scheduling events... but things should default to less impactful and th= e client should ask for impacts - and sending scheduling messages is an = impact.  The ICALENDAR default is the wrong one, and we should fix = that here.

Sure, fine by me.

9. IANA Considerations
=
There are a few fields which= have been specified as an enumeration, e.g. Calendar/role, and "Per Use= r Properties" in JSEvent.  Should there be registries created for t= hese?

Yes, I think= there should.

Neil.
--74585330248344cdb33db52ee8cb7e2e-- From nobody Thu Jul 23 21:34: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 E38423A0B22; Thu, 23 Jul 2020 21:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 CxLvm5BTa_72; Thu, 23 Jul 2020 21:34:39 -0700 (PDT) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (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 2C11C3A0B2A; Thu, 23 Jul 2020 21:34:36 -0700 (PDT) Received: by mail-io1-f48.google.com with SMTP id d18so8597426ion.0; Thu, 23 Jul 2020 21:34:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=MZ/RTyTgzg4tXTiuTCXAwqzl12UNOz6aliVvO7z0as8=; b=quEi0hj6SZG5awNVOwc7xuD3keAqU5Z06y9eJq0GAFI8gf5wxu/ppfI0co+njDwHhO EnpSqEMJsLVwC0by0EDjgf+vuHTVNKiNMeJkP1+JjwD+AXDrtsOVoT21gzLHnwbvRKnw tlHrz1oqODpp2Y6stvhTdt4azUugaAMkgCfIl0//glRg4Np6PCz10jtEcw5dJ8WDowZI tsB9/5QXc8DZaDeIa6pfwKhDaLWUi+jeyP5wsi+f/iT3LO7TbTVbqLLetZ5lzCV8obXe YtGl94V1PH8pn/F/UJP5PA32UxRyEN/LsSnCkAukejiDgmX5z9W0f+MTGc7EfUbgv/9V jt5w== X-Gm-Message-State: AOAM533KmW2eNjy2YGdVAxbefiN/MMbOojrAYNa8GpvBE28KdsLZe3ga TrSMfjDOZKqHUv89tKu/qL9+QnQlBM/kPIu7gddcsw== X-Google-Smtp-Source: ABdhPJy2+hep84Um1Xv2GaonGnuA8sKlLw664PxifSdMMdNNLEVJdgI9jAwg+d8GSGoAhBsImju53WmsN6k/v6PrOU0= X-Received: by 2002:a6b:1885:: with SMTP id 127mr1994014ioy.17.1595565274485; Thu, 23 Jul 2020 21:34:34 -0700 (PDT) MIME-Version: 1.0 From: Barry Leiba Date: Fri, 24 Jul 2020 00:34:23 -0400 Message-ID: To: "draft-ietf-jmap-mdn.all@ietf.org" Cc: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary="00000000000066dc0405ab287d8b" Archived-At: Subject: [Jmap] AD review of draft-ietf-jmap-mdn-13 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, 24 Jul 2020 04:34:41 -0000 --00000000000066dc0405ab287d8b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the good work on this document, and I=E2=80=99m sorry I couldn= =E2=80=99t get to reviewing it more quickly. Here=E2=80=99s my AD review; please let me know= if you have questions or disagreements with any of it. I=E2=80=99ll set the state= to =E2=80=9Crevised I-D needed=E2=80=9D, and will request last call after a su= itable revision is posted. =E2=80=94 Abstract =E2=80=94 It=E2=80=99s a small thing, and if you want to leave it as is, it=E2=80=99s= OK, but I think the Abstract is unnecessarily long, and doesn=E2=80=99t need to include bac= kground that you might reasonably want in the Introduction. I would just make the entire Abstract this: NEW This document specifies a data model for handling Message Disposition Notifications (MDNs, RFC 8098) in the JSON Meta Application Protocol (JMAP, RFCs 8620 and 8621). END =E2=80=94 Section 1 =E2=80=94 and aims to provide a consistent interface to different data types. It doesn=E2=80=99t aim: it does. Make it, =E2=80=9Cand provides...=E2=80= =9D. Please expand =E2=80=9CMDN=E2=80=9D on its first use in the Introduction. Throughout, when you use =E2=80=9CMDN=E2=80=9D as a plural, please make it = =E2=80=9CMDNs=E2=80=9D, reserving =E2=80=9CMDN=E2=80=9D for the singular. Throughout, when you use =E2=80=9Can email=E2=80=9D to mean =E2=80=9Can ema= il message=E2=80=9D, please use the longer version instead. Also look for things such as =E2=80=9Can exist= ing sent mail=E2=80=9D, which should be =E2=80=9Can existing sent message=E2=80=9D, = and so on. Client might want to display detailed information about a received MDN. You need an article here: =E2=80=9CA client=E2=80=9D or =E2=80=9CThe client= =E2=80=9D. =E2=80=94 Section 1.2 =E2=80=94 Keywords being case insensitive in IMAP but JSON being case sensitive, the "$mdnsent" keyword MUST always be used in lowercase. I find this awkward; would you mind changing it thus?: NEW Because keywords are case-insensitive in IMAP but case-sensitive in JMAP, the "$mdnsent" keyword MUST always be used in lowercase. END =E2=80=94 Section 1.3 =E2=80=94 You never say explicitly that you=E2=80=99re defining a new capability, and= you probably should. I would append to the first paragraph, =E2=80=98This defi= nes a new capability, "urn:ietf:params:jmap:mdn".=E2=80=99 =E2=80=94 Section 2 =E2=80=94 What are the asterisks in =E2=80=9C*MDN*=E2=80=9D and =E2=80=9C*Disposition= *=E2=80=9D for? =E2=80=94 Section 2.1 =E2=80=94 always be a backreference to the creation id What=E2=80=99s a =E2=80=9Cbackreference=E2=80=9D? Do you mean =E2=80=9Ca b= ackward reference=E2=80=9D? =E2=80=94 Section 2.2 =E2=80=94 The "forEmailId" property can be null or missing if the "originalMessageId" property is missing, not referencing an existing email or if the server cannot efficiently calculate the related email (for example if several emails get the same "Message-Id" header). This list isn=E2=80=99t parallel in structure. Please try this (which also corrects the =E2=80=9Cemail message=E2=80=9D issue): NEW The "forEmailId" property can be null or missing if the "originalMessageId" property is missing or does not refer to an existing message, or if the server cannot efficiently calculate the related message (for example, if several messages get the same "Message-Id" header). END =E2=80=94 Section 3.1 =E2=80=94 "reportingUA": "linagora.com; OpenPaaS", "originalMessageId": "<1521557867.2614.0.camel@apache.org>" Please make sure your examples all use example domain names, and not actual, valid names. =E2=80=94 Section 4.2 =E2=80=94 The following subsection register one new error code Make it =E2=80=9Cregisters=E2=80=9D. And, really, why have this one senten= ce and a subsection? Why not just put the subsection right here? =E2=80=94 Section 4.2.1 =E2=80=94 Description: The message has the "$mdnsent" keyword already set. The client MUST NOT try again to send an MDN for this message. This contradicts Section 2.1, which says this: The client SHOULD NOT issue an MDN/send request if the message has the "$mdnsent" keyword set. =E2=80=94 Section 6.2 =E2=80=94 8174 has to be normative, just as 2119 does. Barry --00000000000066dc0405ab287d8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the good work on this document, and I=E2=80=99= m sorry I couldn=E2=80=99t get to reviewing it more quickly.=C2=A0 Here=E2= =80=99s my AD review; please let me know if you have questions or disagreem= ents with any of it.=C2=A0 I=E2=80=99ll set the state to =E2=80=9Crevised I= -D needed=E2=80=9D, and will request last call after a suitable revision is= posted.

=E2=80=94 Abstract =E2=80=94
It=E2=80=99s a small thing,= and if you want to leave it as is, it=E2=80=99s OK, but I think the Abstra= ct is unnecessarily long, and doesn=E2=80=99t need to include background th= at you might reasonably want in the Introduction.=C2=A0 I would just make t= he entire Abstract this:

NEW
This document specif= ies a data model for handling Message Disposition Notifications (MDNs, RFC = 8098) in the JSON Meta Application Protocol (JMAP, RFCs 8620 and 8621).
END

=E2=80=94 Section 1 =E2=80=94

=C2=A0 =C2=A0and aims to provide a consistent = interface to different
=C2=A0 =C2=A0data types.

I= t doesn=E2=80=99t aim: it does.=C2=A0 Make it, =E2=80=9Cand provides...=E2= =80=9D.

=
Please expand =E2=80=9C= MDN=E2=80=9D on its first use in the Introduction.

Throughout, when you use =E2=80=9CMDN=E2=80=9D as a plu= ral, please make it =E2=80=9CMDNs=E2=80=9D, reserving =E2=80=9CMDN=E2=80=9D= for the singular.

Throughout, = when you use =E2=80=9Can email=E2=80=9D to mean =E2=80=9Can email message= =E2=80=9D, please use the longer version instead.=C2=A0 Also look for thing= s such as =E2=80=9Can existing sent mail=E2=80=9D, which should be =E2=80= =9Can existing sent message=E2=80=9D, and so on.

=C2=A0 =C2=A0 =C2=A0 Client might want to display detaile= d
=C2=A0 =C2=A0 = =C2=A0 =C2=A0information about a received MDN.

You need an article here: =E2=80=9CA client=E2=80=9D or =E2= =80=9CThe client=E2=80=9D.

=E2= =80=94 Section 1.2 =E2=80=94

= =C2=A0 =C2=A0Keywords being case insensitive in IMAP but JSON being case
=C2=A0 =C2=A0sensiti= ve, the "$mdnsent" keyword MUST always be used in lowercase.

I find this awkward; would you mind= changing it thus?:

NEW
=C2=A0 =C2=A0Because keyw= ords are case-insensitive in IMAP but case-sensitive
=C2=A0 =C2=A0in JMAP, the "$mdnsent= " keyword MUST always be used in lowercase.
END

=E2=80=94 Section 1.3 =E2=80=94
You never say explicitly that you=E2=80=99re defining a n= ew capability, and you probably should.=C2=A0 I would append to the first p= aragraph, =E2=80=98This defines a new capability, "urn:ietf:params:jma= p:mdn".=E2=80=99

=E2=80=94= Section 2 =E2=80=94
What are the asterisks in =E2=80=9C*MDN*=E2=80=9D and =E2=80=9C*Disposit= ion*=E2=80=9D for?

=E2=80=94 Se= ction 2.1 =E2=80=94

=C2=A0 =C2= =A0 =C2=A0 always be a backreference to the creation id

What=E2=80=99s a =E2=80=9Cbackreference=E2=80=9D?= =C2=A0 Do you mean =E2=80=9Ca backward reference=E2=80=9D?

=E2=80=94 Section 2.2 =E2=80=94

=C2=A0 =C2=A0The "forEmailId" prop= erty can be null or missing if the
=C2=A0 =C2=A0"originalMessageId" property is mis= sing, not referencing an existing
=C2=A0 =C2=A0email or if the server cannot efficiently calc= ulate the related email
=C2=A0 =C2=A0(for example if several emails get the same "Messag= e-Id" header).

This list i= sn=E2=80=99t parallel in structure.=C2=A0 Please try this (which also corre= cts the =E2=80=9Cemail message=E2=80=9D issue):

NEW
=C2=A0 =C2=A0The "forEmailId" property can be null or missing = if the
=C2=A0 =C2= =A0"originalMessageId" property is missing or does not refer to a= n
=C2=A0 =C2=A0exi= sting message, or if the server cannot efficiently calculate the
=C2=A0 =C2=A0related message= (for example, if several messages get the same
=C2=A0 =C2=A0"Message-Id" header).<= /div>
END

=E2=80=94 Section 3.1 =E2=80=94

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"reportingUA": "linago= ra.com; OpenPaaS",

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"originalMessageId": "= <1521557867.2614.0= .camel@apache.org>"

Please make sure your examples all use example domain names, and not actua= l, valid names.
=E2=80=94 Secti= on 4.2 =E2=80=94
<= br>
=C2=A0 =C2=A0T= he following subsection register one new error code

Make it =E2=80=9Cregisters=E2=80=9D.=C2=A0 And, really= , why have this one sentence and a subsection?=C2=A0 Why not just put the s= ubsection right here?

=E2=80=94= Section 4.2.1 =E2=80=94

=C2=A0= =C2=A0Description: The message has the "$mdnsent" keyword alread= y set.=C2=A0 The
= =C2=A0 =C2=A0client MUST NOT try again to send an MDN for this message.

This contradicts Section 2.1, whic= h says this:

<= /div>
=C2=A0 =C2=A0The c= lient SHOULD NOT issue an MDN/send request if the message has
=C2=A0 =C2=A0the "$mdnsent= " keyword set.

=E2=80=94 S= ection 6.2 =E2=80=94
8174 has to be normative, just as 2119 does.

Barry
--00000000000066dc0405ab287d8b-- From nobody Thu Jul 23 21:42:50 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 0BC163A0B49 for ; Thu, 23 Jul 2020 21:42:49 -0700 (PDT) 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=TTwgz2YD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QwnX8Kgy 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 8YwQR7q_LnbX for ; Thu, 23 Jul 2020 21:42:47 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A863A0B48 for ; Thu, 23 Jul 2020 21:42:47 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1358C475 for ; Fri, 24 Jul 2020 00:42:47 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Fri, 24 Jul 2020 00:42:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=Mfvf+LL m8sNseH1xglv098yz261DTanWJ1QkAkyWvkk=; b=TTwgz2YDMxQ90+vrPjSs6VM mNARu6A593AxVhGrqiaNaY5RwNlxKP3a4VUdOBeddiEbIutcQHT2qYDtqzWE+0O6 82kNmb8pzMte2PrgKRChrI3iq8Rg27w1IbzfAvCHMmQucWX1UjysMKJ0R9i738yv gUcgNT/fE4TVU3oCRJoYKjvLMqO6prZ0o4WTrnNjJppPp8SkzcWeMDJW9Y5ci4ho rRDUeljXzk9ABVFeS+H/HKPHB4wrS6q/Sf3O2ohQG++55SWCmQqCaewNGGfAP2nM fK0crL/8hfTfuEZSyiYkekkgOSr3VjHA47ST76EGCKc2LxxVYl/ZCWreRqg1wZQ= = 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=fm3; bh=Mfvf+L Lm8sNseH1xglv098yz261DTanWJ1QkAkyWvkk=; b=QwnX8KgyA0TEh+t5jTjleM wsjNYC4HtmYbTnmcYarjWKWoDfidhFTuXV0zqBnqKbskqEfJeNES2gcpHT9PE6Le VkqR3llEGc09LB3c6B+Qkt7gChikAb72kXexLFjZdiB3Kvglh5Ehc6SMihtGtrRN RVl8geKRRZYKRRbknnjdSmg0Y/eQy4v1CZiEr3DjmR4y3oJV4+91uZWxuSRIU+Wa Ny7hKbYGNIlZ5B3U/X9dzX5omIdZL9Fp0nxseC+uOH2g4Jb9vjH6f9aI857vaKj3 1d3XFVnIcOEwdX1KzxB8yNLwhQxNBsjLab+9cdUEbDyiKcebcWY/TyRArEcEbXzA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrhedvgdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnheptdehteegfeevte duffevteehfffghefhvdevkeeuhfehueetudehgfegieekjeetnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 71EF71803EE; Fri, 24 Jul 2020 00:42:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-92-g11c785d-fm-20200721.004-g11c785d5 Mime-Version: 1.0 Message-Id: <468b125b-083a-4198-8106-430e7873121c@dogfood.fastmail.com> In-Reply-To: References: Date: Fri, 24 Jul 2020 14:42:26 +1000 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=541da18e357443f89d5eb6771ebe6b1d Archived-At: Subject: Re: [Jmap] AD review of draft-ietf-jmap-mdn-13 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, 24 Jul 2020 04:42:49 -0000 --541da18e357443f89d5eb6771ebe6b1d Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Jul 24, 2020, at 14:34, Barry Leiba wrote: >=20 > =E2=80=94 Section 4.2.1 =E2=80=94 >=20 > Description: The message has the "$mdnsent" keyword already set. T= he > client MUST NOT try again to send an MDN for this message. >=20 > This contradicts Section 2.1, which says this: >=20 > The client SHOULD NOT issue an MDN/send request if the message has > the "$mdnsent" keyword set. The way I read this is "there's a race condition here and your client ma= y not have done an immediate fetch to know if it's already happened, but= if it's told that there was a $mdnsent flag then it MUST not keep tryin= g". So it SHOULD check the keywords in advance (ideally with a recent refres= h) but that's not as important as not retrying infinitely. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --541da18e357443f89d5eb6771ebe6b1d Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 24, 2020, at 14:34, Barry Leiba wrote:

<= /div>
=E2=80=94 Section 4.2.1 =E2=80=94
<= /div>

   Description: The messa= ge has the "$mdnsent" keyword already set.  The
=    client MUST NOT try again to send an MDN for this message.<= br>

This contradicts Section 2.1, w= hich says this:

   Th= e client SHOULD NOT issue an MDN/send request if the message has
   the "$mdnsent" keyword set.

The way I read this is "there's a race condition here an= d your client may not have done an immediate fetch to know if it's alrea= dy happened, but if it's told that there was a $mdnsent flag then it MUS= T not keep trying".

So it SHOULD check the keywords in ad= vance (ideally with a recent refresh) but that's not as important as not= retrying infinitely.

Bron.

--
&n= bsp; Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fas= tmailteam.com


--541da18e357443f89d5eb6771ebe6b1d-- From nobody Fri Jul 24 06:51:18 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 7E6043A0529; Fri, 24 Jul 2020 06:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 c1iv7Q6qvFoi; Fri, 24 Jul 2020 06:51:14 -0700 (PDT) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (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 067C93A048D; Fri, 24 Jul 2020 06:51:13 -0700 (PDT) Received: by mail-io1-f47.google.com with SMTP id k23so9797823iom.10; Fri, 24 Jul 2020 06:51:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bb6ZfDqsb3svj82HSHsySFNeW7EVIKaXMri18hxKtQw=; b=g1kXuPkpTgwIdInFCe9zi1FYQti7vwZNlEgYKgg8IGonOXTEjTCIyEfksdp5e9VfzH emnkt0VibVbhr4lMDcQps1IB01IHLpb0FTk22KFmLoXI9ACXOjqkxz35++SeSkqiQT8w 1rcLXUjCcnSel+BrpZ3NypKqLgTYVxaNAsLQwSQOHDB8u3RxawAhivoPwnljc6PSID7j kaVXbVWfczcAWDoivzYiKBTsUkFgEqkUGarlDNp4EkCA9wA9bKKCLSCd4+aTdKQgdiG9 76J7Ew3c3Vrmq5iL1Dx24+Zb40qOoWdn9llXkSY2gLmSjiQK414NQChSqXYPcZJsWN/m N2BQ== X-Gm-Message-State: AOAM531JaA9buBVxbQzkpDayD1AM79k25Mpx7L68xQKLJ1HL8xPMcO8A bh0q86kohe57pk4KJjGMDrR4jXrlNm8/kSGATjEM+Q== X-Google-Smtp-Source: ABdhPJx9L+ui0Z8LqTp7xeeM7CzhFJnS+1lPJw1Z4EwoYOLQ1iJWQ2KeAkPrdNLm9AIwaUEoKe6HLkwH1DbFPDh67js= X-Received: by 2002:a02:3b10:: with SMTP id c16mr2781742jaa.128.1595598673157; Fri, 24 Jul 2020 06:51:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Fri, 24 Jul 2020 09:51:02 -0400 Message-ID: To: Raphael OUAZANA Cc: draft-ietf-jmap-mdn.all@ietf.org, IETF JMAP Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] AD review of draft-ietf-jmap-mdn-13 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, 24 Jul 2020 13:51:16 -0000 Thanks for the quick response, Raphael. > > =E2=80=94 Section 2 =E2=80=94 > > What are the asterisks in =E2=80=9C*MDN*=E2=80=9D and =E2=80=9C*Disposi= tion*=E2=80=9D for? > > They were also in RFC8620 and RFC8621 when defining objects. I kept them > for consistency. Should I change that? No; if it's consistent with the other docs, leave it there, and we'll see if anyone else (including the RFC Editor) brings it up. > > =E2=80=94 Section 4.2.1 =E2=80=94 > > > > Description: The message has the "$mdnsent" keyword already set. > > The > > client MUST NOT try again to send an MDN for this message. > > > > This contradicts Section 2.1, which says this: > > > > The client SHOULD NOT issue an MDN/send request if the message has > > the "$mdnsent" keyword set. > > I agree with Bron on this point. If the client is not aware of the > keyword, it may issue a new request. When it is aware the keyword is > set, it must not try to. I didn't see a response from Bron; perhaps he dropped me off the distribution list. I think this is an important inconsistency that needs to be fixed, as these, as worded, are directly in conflict. If there's a nuance here, the nuance needs to be made clearer by rewording one or the other, or both. Barry From nobody Sun Jul 26 20:21:25 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 8F9923A1645; Sun, 26 Jul 2020 20:21:22 -0700 (PDT) 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.10.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <159582008253.22225.7002838387178657271@ietfa.amsl.com> Date: Sun, 26 Jul 2020 20:21:22 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-calendars-04.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, 27 Jul 2020 03:21:23 -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 Calendars Authors : Neil Jenkins Michael Douglass Filename : draft-ietf-jmap-calendars-04.txt Pages : 45 Date : 2020-07-26 Abstract: This document specifies a data model for synchronizing calendar data with a server using JMAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-calendars-04 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-calendars-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-calendars-04 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 Jul 27 00:16:10 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 5A13B3A1321; Mon, 27 Jul 2020 00:16:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.10.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <159583416131.28258.1261490541184669325@ietfa.amsl.com> Date: Mon, 27 Jul 2020 00:16:01 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mdn-14.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, 27 Jul 2020 07:16:02 -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 : Handling Message Disposition Notification with JMAP Author : Raphaël Ouazana Filename : draft-ietf-jmap-mdn-14.txt Pages : 13 Date : 2020-07-27 Abstract: This document specifies a data model for handling Message Disposition Notifications (MDNs, RFC 8098) in the JSON Meta Application Protocol (JMAP, RFCs 8620 and 8621). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mdn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mdn-14 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mdn-14 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 Jul 27 08:20: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 6FE243A0F0A; Mon, 27 Jul 2020 08:20:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: jmap@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.10.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: jmap@ietf.org Message-ID: <159586322539.22896.12466827634919520792@ietfa.amsl.com> Date: Mon, 27 Jul 2020 08:20:25 -0700 Archived-At: Subject: [Jmap] I-D Action: draft-ietf-jmap-mdn-15.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, 27 Jul 2020 15:20:26 -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 : Handling Message Disposition Notification with JMAP Author : Raphaël Ouazana Filename : draft-ietf-jmap-mdn-15.txt Pages : 13 Date : 2020-07-27 Abstract: This document specifies a data model for handling Message Disposition Notifications (MDNs, RFC 8098) in the JSON Meta Application Protocol (JMAP, RFCs 8620 and 8621). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jmap-mdn/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-jmap-mdn-15 https://datatracker.ietf.org/doc/html/draft-ietf-jmap-mdn-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-mdn-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 28 04:03:02 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 D51B43A0ADD for ; Tue, 28 Jul 2020 04:03:00 -0700 (PDT) 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=D/tMtxkR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KxM3eoO8 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 8YquBYWi6N6j for ; Tue, 28 Jul 2020 04:02:58 -0700 (PDT) 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 4EFE23A0ADA for ; Tue, 28 Jul 2020 04:02:58 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 6F0B315A3 for ; Tue, 28 Jul 2020 07:02:57 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 28 Jul 2020 07:02:57 -0400 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=fm3; bh=rkQGQMWpaKiRehe3Bdj8ZzwmQmEh7ArzsHaIAFa 9A8c=; b=D/tMtxkRiIB2hCH+VDBVbd+0UYsMlpbzhFXpZtjOUCmiAgvB3g0Nbny mRXGcqwUe77Uethr/QBy7axIxfp/CiZ0CjzYjVK+CvS3QjaO7UcWuKlWVqL3d/qk y1udltCvotj+TiTDNDe7I7/Stx/8x4pIcl8J4K64GE9qGFIR4cCN7Rta7qlpuV1z ZaXu6BgCWYfa/UyLrIbj9JppCRfex3n0nynO/HUZIvaHmZnD84OOqDTewk/j2i+G Ud6OZpfXsGSqaAS6YhYNS6Av1toFx/RdniDfH1XvfzzL3NYJzYJyf140nuLvyO1Z G1H3r3aRvgp8qfi3U0CoH+zVZrqerkA== 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=fm3; bh=rkQGQMWpaKiRehe3Bdj8ZzwmQmEh7 ArzsHaIAFa9A8c=; b=KxM3eoO8tJW1OBhWuD1fE+riVzf0Yncug+LH8BnolIcTN BdJftdx/8JjlgLbl/C+BvJpzeERxrI9m8dWTVhd7wu0Xg50PSaRff6BTGKm1jO9E f6gIUxzwkYKpou5nfOHoUP23qv52/is7ji6CBNZ1mAlVwVS1CtXz6ptWFin9CJ4x IlbtXyPQX9VuaNMb6OubY8MbflRSA1vBuxh/v868jZh4isqY4INeNz0Ym7XKp7oc llEB0UABSgVsG9MYcwdZCdJjlgqvcu3rKQ/eXTg8PLiF5hpnTGwRB3goX4Uq2Dl6 rgsni2vpSvEVLcGNdPNtYPseESEzxSEhH0BUCOMjg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedriedvgdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvdetteeiveeihfegie dtgeeigfduveelhefgffelgeelueehhfeitdelgedtffegnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlth gvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C92A71802D2; Tue, 28 Jul 2020 07:02:56 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: <57e54630-4dc8-441b-8d56-b4990c93c4e7@beta.fastmail.com> Date: Tue, 28 Jul 2020 21:02:36 +1000 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=a22113532e8947b3b82a958acd2ee4ad Archived-At: Subject: [Jmap] Please send slides if you're presenting at IETF108 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, 28 Jul 2020 11:03:01 -0000 --a22113532e8947b3b82a958acd2ee4ad Content-Type: text/plain Hi all, If you're presenting in the session on Thursday and you want to use slides, can you please send them to me by tomorrow so I can upload them and prepare the chair slides. Thanks, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --a22113532e8947b3b82a958acd2ee4ad Content-Type: text/html
Hi all,

If you're presenting in the session on Thursday and you want to use slides, can you please send them to me by tomorrow so I can upload them and prepare the chair slides.

Thanks,

Bron.

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


--a22113532e8947b3b82a958acd2ee4ad-- From nobody Wed Jul 29 06:49:17 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 DAA893A0B33 for ; Wed, 29 Jul 2020 06:49:15 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-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=fastmail.com header.b=CX8oWCZL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nquaezX5 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 cnOwt7u8IT_V for ; Wed, 29 Jul 2020 06:49:14 -0700 (PDT) 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 2ABC23A0B2F for ; Wed, 29 Jul 2020 06:49:14 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8240B5C0176 for ; Wed, 29 Jul 2020 09:49:13 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 29 Jul 2020 09:49:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm3; bh=90X6B99E5Dj9qNRRL9P4oTj5csg g1+1Srywx6l21dPk=; b=CX8oWCZLOa+Fo5IeGZbIFQo49AiTgB8C2b46E/FMroP BogOcAfdFDO+dnenY9xUisdBYd068NRln9WuBVa3tkvMBked3h5m2kKY9nYaGrZb 16s6vuKR001S45L4V6qBfVVfW05n2oTUHDFxyQIUoywMpiUwUr87h8vux7rbf/UD nWhq+Qz19UlbkwTTQMq5yAxsmiiJ3JqbzBivuxIYjrRWlZUiBMc5guPFPFiTTV+9 skLNPVVoDySbSzgxADHFRNobH9p1S502GIHbDysK98ksYLFJTiDERLh6sNQpyHUo ws25EbM0XoxEszSkRu3KWyJpkV3SJpxbPG1wiuzmRNg== 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=fm3; bh=90X6B9 9E5Dj9qNRRL9P4oTj5csgg1+1Srywx6l21dPk=; b=nquaezX5SDSa+Y2v2WHIIO r1y7rhFtijN+tOVmTB2otDmFGHlixc2d5nXM1Q+z0OiOWy37Y9sxNaEjyIuhZJ7W rXI6EOkra6/pVlpLE13zmOlCeyAps7JxouPv2oLfv5pZvmeCFt6ab9DlCW0aAzdB OBoFYDazgJDHwyMnK+4AloQAevcU+R2QvB88f8lDghVUP0p2K4vOxtcVpD/4j4aL 5oCicZoV/yI8TM5l5ckJVYGBJ2JgtwY5EiMSh9haGC9xhFUuhFMmxHH4znkrXV3P 7r+T8dRR3YGIcudu8FD5D/ES+bL3al/6tMuW2Pg9oA3N7RBzTx7wLcLrxfMqGZ6A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieeggdeilecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtderre dtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshht mhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeekheevhfduleeufeduhfellefffe eigeeguddvveekiefhvdeujeeffeejtdegfeenucfkphepjeegrdejjedrkeehrddvhedt 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 627B1328005D for ; Wed, 29 Jul 2020 09:49:12 -0400 (EDT) To: jmap@ietf.org References: <1a099401-bbb6-496f-836f-033a0274b74f@dogfood.fastmail.com> From: Ken Murchison Message-ID: <9048b94a-8927-5915-b280-af5e1d7d0cfa@fastmail.com> Date: Wed, 29 Jul 2020 09:49:11 -0400 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: multipart/alternative; boundary="------------68FE4B8117BD57BD637D3318" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Review: draft-murchison-jmap-sieve-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: Wed, 29 Jul 2020 13:49:16 -0000 This is a multi-part message in MIME format. --------------68FE4B8117BD57BD637D3318 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/13/20 4:08 PM, Ricardo Signes wrote: > *I suggest instead*: > > 1. We drop isActive as a property from SieveScript. > 2. We create a new type, SieveConfig > 3. SieveConfig has exactly one instance per account, with the fixed id > "singleton" > 4. The SieveScriptConfig object has one property, activeScriptId, > which is either a script id or null > 5. If no "name" is provided, the server will provide a guaranteed > unique name. > > To replace the active Sieve script in the blind, you do this: > > SieveScript/set { create: { newScript: { content: "..." } } } > SieveConfig/set { update: { "singleton": { activeScriptId: > "#newScript" } } } > > This is guaranteed safe.  The worst case is that you end up with a > uniquely-named script that is not, in fact, active. > > We probably also need: > > 6.  If the active script is deleted, the SieveScriptActive > activeScriptId becomes null. > > Alternatively, it could be illegal to destroy the active script. As an alternative to using a new data type for setting the active script, we could make isActive a server-set property (not directly set by the client within the SieveScript/set{create|update} method) and add a new onSuccessActivateScript argument to the SieveScript/set method which only gets processed if ALL create|update|delete are successful. -- Kenneth Murchison Senior Software Developer Fastmail US LLC --------------68FE4B8117BD57BD637D3318 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 7/13/20 4:08 PM, Ricardo Signes wrote:
I suggest instead:

1. We drop isActive as a property from SieveScript.
2. We create a new type, SieveConfig
3. SieveConfig has exactly one instance per account, with the fixed id "singleton"
4. The SieveScriptConfig object has one property, activeScriptId, which is either a script id or null
5. If no "name" is provided, the server will provide a guaranteed unique name.

To replace the active Sieve script in the blind, you do this:

SieveScript/set { create: { newScript: { content: "..." } } }
SieveConfig/set { update: { "singleton": { activeScriptId: "#newScript" } } }

This is guaranteed safe.  The worst case is that you end up with a uniquely-named script that is not, in fact, active.

We probably also need:

6.  If the active script is deleted, the SieveScriptActive activeScriptId becomes null.

Alternatively, it could be illegal to destroy the active script.


As an alternative to using a new data type for setting the active script, we could make isActive a server-set property (not directly set by the client within the SieveScript/set{create|update} method) and add a new onSuccessActivateScript argument to the SieveScript/set method which only gets processed if ALL create|update|delete are successful.

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
--------------68FE4B8117BD57BD637D3318-- From nobody Fri Jul 31 07:42:11 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 D86313A1380 for ; Fri, 31 Jul 2020 07:42:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159620652887.7968.17155838601358726318@ietfa.amsl.com> Date: Fri, 31 Jul 2020 07:42:08 -0700 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: Fri, 31 Jul 2020 14:42:09 -0000 Changed milestone "Submit Message Disposition Notification document to the IESG", resolved as "Done". Changed milestone "Adopt a document defining mappings between VCARD and JSContact", resolved as "Done". Changed milestone "Submit JMAP S/MIME signature validation document to the IESG", set due date to August 2020 from July 2020. Changed milestone "Adopt a document defining JMAP access to addressbooks", set due date to October 2020 from August 2020. Changed milestone "Adopt a document for S/MIME key management and server side signing/encryption", set due date to October 2020 from August 2020. URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Fri Jul 31 07:44:57 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 C01043A0ECA for ; Fri, 31 Jul 2020 07:44:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159620669577.32687.5559843878398944566@ietfa.amsl.com> Date: Fri, 31 Jul 2020 07:44:55 -0700 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: Fri, 31 Jul 2020 14:44:56 -0000 Changed milestone "Adopt a document for creating Blobs via JMAP method call", set state to active from review, accepting new milestone. Changed milestone "Adopt a document for managing Sieve via JMAP", set state to active from review, accepting new milestone. Changed milestone "Submit document for Blobs via JMAP to the IESG", set state to active from review, accepting new milestone. Changed milestone "Submit Sieve document to the IESG", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/jmap/about/ From nobody Fri Jul 31 07:45: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 9D10D3A0C74 for ; Fri, 31 Jul 2020 07:45:20 -0700 (PDT) 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=CZ6t5q0S; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=T3Sl0ylQ 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 wTKys6jsNMwE for ; Fri, 31 Jul 2020 07:45:19 -0700 (PDT) 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 F050A3A0BDD for ; Fri, 31 Jul 2020 07:45:18 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 6E38BEA0 for ; Fri, 31 Jul 2020 10:45:18 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Fri, 31 Jul 2020 10:45:18 -0400 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=fm3; bh=oZ/1nJvuUzEyfItWdtJaLJ/Xibdx2KKiEbAVxhf Ooa4=; b=CZ6t5q0SEASCiRJQubVyEFyIcjrpr+z707AHa9uN+NitE7KDjngUOce v3Lk/ekHlHtIaX46RPPrqsbnPFXlsQJJ7JCg90ef9cluhODe9DZXLGzYZxA/zN2L CuaUJoWSQ5mNUVfw3pbvySGwLIesX2d8BILm6FLEcn6G59aubeLnDviS7jEGhp3u rQlN23HqH/Q1gXm9pypmAnExhxFsZMbh8BFVCY08cRqyJVJJWkzYD+ZKchklVvEO xN+5sGqB1Dx327XpwDD6VSegWmL28havnt5anlHhYVqp7C4Zq8xQcdreKycJteOu wr32jMEXOgEKdWWgGbKjsH6trpHlL3w== 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=fm3; bh=oZ/1nJvuUzEyfItWdtJaLJ/Xibdx2 KKiEbAVxhfOoa4=; b=T3Sl0ylQ10vuCEvzZMASbb4+zp8OLkGCekV0kANbzDq51 pVhBCotz8JBJfHmmvDZb4DhUqc72ftfVmVkT5oVS/5LotpDRSgimanqWC9YXYi35 8kFcOGJmoR1cEftTIZo2a2f9nt4CbHXRUGavx5ogs7ErUvIc03ii9w1cvYjShckD wnqI+7m3dYlVwU4QfrmcEjbX8tKt27TiskaC03pa8IN+srtGv9U95qj/TQUqENg7 AwPobsFP7IB8xB2AROii1XzvOYpZoSCUiZ9ULOmf/56M3v4KvOracGm3rGV7qHAQ fOw9vKCMs/a1GKRDor25hZ5V0fgjTJRJJJstzPQnw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieekgdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhephfejheekjeekheevue dtjeetiefhffefudeitddtjefhleetveeuheduledtueffnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CB842180573; Fri, 31 Jul 2020 10:45:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: <4b219ec8-cd7e-496a-b81f-ae08e7837ad2@beta.fastmail.com> Date: Sat, 01 Aug 2020 00:44:57 +1000 From: "Bron Gondwana" To: jmap@ietf.org Content-Type: multipart/alternative; boundary=612da75e60d04971a7b20d0b84ce8499 Archived-At: Subject: [Jmap] Call for adoption draft-murchison-jmap-sieve-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, 31 Jul 2020 14:45:21 -0000 --612da75e60d04971a7b20d0b84ce8499 Content-Type: text/plain Hi All, As discussed in the meeting at IETF108, this is a formal call for adoption for a document for managing sieve scripts via JMAP. Please send any comments on the adoption by August 14th (2 weeks from now). https://datatracker.ietf.org/doc/draft-murchison-jmap-sieve/ Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --612da75e60d04971a7b20d0b84ce8499 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,

As discussed in the meeting at IETF= 108, this is a formal call for adoption for a document for managing siev= e scripts via JMAP.  Please send any comments on the adoption by Au= gust 14th (2 weeks from now).


Cheers,
<= div style=3D"font-family:Arial;">
Bron.

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


--612da75e60d04971a7b20d0b84ce8499-- From nobody Fri Jul 31 08:49:05 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 6070A3A0786 for ; Fri, 31 Jul 2020 08:48:30 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-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=fastmail.com header.b=kAjG/SPz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jAUDosGA 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 WSHcnkBbc2nu for ; Fri, 31 Jul 2020 08:48:28 -0700 (PDT) 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 371D43A0903 for ; Fri, 31 Jul 2020 08:47:35 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 5DE6CE89 for ; Fri, 31 Jul 2020 11:47:34 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 31 Jul 2020 11:47:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm3; bh=5H0u2nDnMtiZz3dPNPKiN4yjZxT EdpTNAxAMf5oAuaE=; b=kAjG/SPzv+L8GQ9kKBowjZwXKyqCX2yAJqx+PfwQut6 dYM8c+8cjMtvQU9Gl3+/wcFykudI4h7AShu6yDe2REjUbn1pHQYp0WluReK+CCWQ h1eBJM9088wk4CZe59lsLvPwWvIY4rmiBHMVbirfpmnc7/3E0+kHLk3d9dKz0q9x 0loFiQYwoPF0KE6m/OHlmJkBW6N4VHjlaIUwG7hbaYje3kx74Np48uQttWEt1DRC ml+OParaNB5WzW2xlTOlt9N7R4DL5ey8wPm2/LvjlxESdF6xwMJ/0q9IsWFuLa4I hTqR8TAfHD33j4Q28h4ydoqecriHurA/ftSIcDQfYwA== 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=fm3; bh=5H0u2n DnMtiZz3dPNPKiN4yjZxTEdpTNAxAMf5oAuaE=; b=jAUDosGACfdO5LujqZUumX sDWrVnfmo3YiqUFehZB4B3xeMI2jj24j4wJCVHcXpvAPm6KwbvKAX4A7munlVAEw WZjp9jbmw6quQoQueP3k2OrRjnZYKyUcORH0b0PpVRkhDDX1cBIRA3Y33Q9j///7 hm13lLNCyx8SEMqHwoxIjoQCuRDTgJx6AzdArltxuglwPM9GpNjGxDsd2GTKCvGi CDID+jtpqq4Me1XHPF0tOTSOWpDUv498syc5pbAZORo8DvaIa//4bqmRx401XD8E zA/AIHYXzl2ti9KHeVUL358LH9x1qE/AlfTDRoY/PSaxvJ2Nqb5SuXTo4oHEOWBw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieekgdelgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtderre dtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshht mhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeffuefhvefggfdvudeuvdetieejue dvvdekudeggedvffevgfduffeuieelgeeggeenucffohhmrghinhepihgvthhfrdhorhhg necukfhppeejgedrjeejrdekhedrvdehtdenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtghomh 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 A6A0E328005E for ; Fri, 31 Jul 2020 11:47:33 -0400 (EDT) To: jmap@ietf.org References: <4b219ec8-cd7e-496a-b81f-ae08e7837ad2@beta.fastmail.com> From: Ken Murchison Message-ID: Date: Fri, 31 Jul 2020 11:47:32 -0400 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: <4b219ec8-cd7e-496a-b81f-ae08e7837ad2@beta.fastmail.com> Content-Type: multipart/alternative; boundary="------------9522D2DDC938896DD2E643E8" Content-Language: en-US Archived-At: Subject: Re: [Jmap] Call for adoption draft-murchison-jmap-sieve-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, 31 Jul 2020 15:48:31 -0000 This is a multi-part message in MIME format. --------------9522D2DDC938896DD2E643E8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I'm obviously in favor of adopting. On 7/31/20 10:44 AM, Bron Gondwana wrote: > Hi All, > > As discussed in the meeting at IETF108, this is a formal call for > adoption for a document for managing sieve scripts via JMAP.  Please > send any comments on the adoption by August 14th (2 weeks from now). > > https://datatracker.ietf.org/doc/draft-murchison-jmap-sieve/ > > Cheers, > > Bron. > > -- >   Bron Gondwana, CEO, Fastmail Pty Ltd >   brong@fastmailteam.com > > --------------9522D2DDC938896DD2E643E8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I'm obviously in favor of adopting.


On 7/31/20 10:44 AM, Bron Gondwana wrote:
Hi All,

As discussed in the meeting at IETF108, this is a formal call for adoption for a document for managing sieve scripts via JMAP.  Please send any comments on the adoption by August 14th (2 weeks from now).


Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd


--------------9522D2DDC938896DD2E643E8-- From nobody Fri Jul 31 10:17:03 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 EA61B3A0B96 for ; Fri, 31 Jul 2020 10:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HPipfmUbyeJ for ; Fri, 31 Jul 2020 10:16:59 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id B06C43A0B90 for ; Fri, 31 Jul 2020 10:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1596215818; d=isode.com; s=june2016; i=@isode.com; bh=KFuor/4JRQJrA/Lk5Pww9gaF0Z0VNWo6KiF6LdgoA8w=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=K+wjZYucawBsoyCirP5Bul92sfyPBMbIQoxM2D/fe0uZjrRa5as1lcH4FAVkklrMRTvBQA I4K2n2DCr8Aq+uGIQEthFxdMgBPmh0fMwW7fD66wMEmH7ix8enAXjHcGzwrns3Q3gUapqH sUKo9W2t/p/D8OaJEtOZq1fMq42crM0=; Received: from [192.168.0.5] (97e1f4dd.skybroadband.com [151.225.244.221]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 31 Jul 2020 18:16:58 +0100 To: Ken Murchison , jmap@ietf.org References: <4b219ec8-cd7e-496a-b81f-ae08e7837ad2@beta.fastmail.com> From: Alexey Melnikov Message-ID: Date: Fri, 31 Jul 2020 18:16:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <4b219ec8-cd7e-496a-b81f-ae08e7837ad2@beta.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------CF163D6905E97D24ABE2AE87" Content-Language: en-GB Archived-At: Subject: Re: [Jmap] Call for adoption draft-murchison-jmap-sieve-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, 31 Jul 2020 17:17:02 -0000 --------------CF163D6905E97D24ABE2AE87 Content-Type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: quoted-printable Hi, On 31/07/2020 15:44, Bron Gondwana wrote: > Hi All, > > As discussed in the meeting at IETF108, this is a formal call for=20 > adoption for a document for managing sieve scripts via JMAP.=C2=A0 Please= =20 > send any comments on the adoption by August 14th (2 weeks from now). > > https://datatracker.ietf.org/doc/draft-murchison-jmap-sieve/ I support adopting this document and will work on it. Some specific comments: > Open Issues > > =C2=A0=C2=A0 o=C2=A0 How should doing /set{create} with an existing script= name be > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 handled?=C2=A0 Should it fail or overwrite = the existing script?=C2=A0 Should > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the /set request include an 'overwrite' boo= lean argument? RFC 5804 overwrites scripts by default, as long as they are valid. I=20 would do the same here. So maybe add boolean "nooverwrite" instead? > > =C2=A0=C2=A0 o=C2=A0 Should setting isActive=3D=3Dtrue on a script automat= ically deactivate > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 any other existing active script, or should= the client have to do > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 so itself (as is currently documented)? I think being able to activate the uploaded script in one operation=20 would be handy. So yes, I agree with diactivating other scripts. > > =C2=A0=C2=A0 o=C2=A0 Do we want/need a SieveScript/copy method? I am not sure this is needed. It is not like we support CATENATE for=20 Sieve scripts ;-). > =C2=A0=C2=A0 o=C2=A0 Do we want to leverage draft-ietf-jmap-quotas to quer= y Sieve > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 script storage quotas? Yes. > 2.=C2=A0 Sieve Scripts > > =C2=A0=C2=A0 o=C2=A0 *content*: "String" The Sieve code in the script.=C2= =A0 Note that any > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 double (") quote or backslash (\) character= s appearing in the > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 script content MUST be escaped by prefixing= them with a backslash > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (\). If this text is staying, it should explain that escaping is due to JSON=20 rules. (Similar text when setting script) Also, RFC 5804 has the following text: =C2=A0"A script of zero length SHOULD be disallowed." So it is probably good to mention this in 2.2 and 2.3? > 2.3.=C2=A0 SieveScript/validate > > =C2=A0=C2=A0 o=C2=A0 *errorDescription*: "String" A description of the err= or to show to > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the user, or an empty string if the Sieve c= ode is valid. No strong preference, but should this be null when not set? Best Regards, Alexey --------------CF163D6905E97D24ABE2AE87 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

Hi,

On 31/07/2020 15:44, Bron Gondwana wrote:

Hi All,

As discussed in the meeting at IETF108, this is a formal call for adoption for a document for managing sieve scripts via JMAP.=C2=A0 Please send any comments on the adoption by August 14th (2 weeks from now).

I support adopting this document and will work on it.


Some specific comments:

Open Issues

=C2=A0=C2=A0 o=C2=A0 How should doing /set{create} with an existing = script name be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 handled?=C2=A0 Should it fail or over= write the existing script?=C2=A0 Should
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the /set request include an 'overwrit= e' boolean argument?
RFC 5804 overwrites scripts by default, as long as they are valid. I would do the same here.

So maybe add boolean "nooverwrite" instead?


=C2=A0=C2=A0 o=C2=A0 Should setting isActive=3D=3Dtrue on a script a= utomatically deactivate
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 any other existing active script, or = should the client have to do
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 so itself (as is currently documented= )?
I think being able to activate the uploaded script in one operation would be handy. So yes, I agree with diactivating other scripts.

=C2=A0=C2=A0 o=C2=A0 Do we want/need a SieveScript/copy method?
I am not sure this is needed. It is not like we support CATENATE for Sieve scripts ;-).
=C2=A0=C2=A0 o=C2=A0 Do we want to leverage draft-ietf-jmap-quotas to query Sieve
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 script storage quotas?
Yes.
2.=C2=A0 Sieve Scripts

=C2=A0=C2=A0 o=C2=A0 *content*: "String" The Sieve code in the scrip= t.=C2=A0 Note that any
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 double (") quote or backslash (\) cha= racters appearing in the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 script content MUST be escaped by pre= fixing them with a backslash
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (\).
If this text is staying, it should explain that escaping is due to JSON rules. (Similar text when setting script)

Also, RFC 5804 has the following text:
=C2=A0"A script of zero length SHOULD be disallowed."

So it is probably good to mention this in 2.2 and 2.3?

2.3.=C2=A0 SieveScript/validate

=C2=A0=C2=A0 o=C2=A0 *errorDescription*: "String" A description of t= he error to show to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the user, or an empty string if the S= ieve code is valid.
No strong preference, but should this be null when not set?

Best Regards,

Alexey


--------------CF163D6905E97D24ABE2AE87--