Re: [Jmap] new JMAP server for prototyping

Bron Gondwana <brong@fastmailteam.com> Wed, 19 May 2021 03:56 UTC

Return-Path: <brong@fastmailteam.com>
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 386B33A1C50 for <jmap@ietfa.amsl.com>; Tue, 18 May 2021 20:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=F2U2wcwh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kyC96urJ
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 7CHL2oCYRbvy for <jmap@ietfa.amsl.com>; Tue, 18 May 2021 20:56:41 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E891B3A1C3F for <jmap@ietf.org>; Tue, 18 May 2021 20:56:40 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2882C5C0194 for <jmap@ietf.org>; Tue, 18 May 2021 23:56:40 -0400 (EDT)
Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Tue, 18 May 2021 23:56:40 -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=fm2; bh=ji5RuvN sVv3W/Wlm1rcokUVWGOzuf18weSM1Zh2JJ34=; b=F2U2wcwhhcUCJNc2br/2bCY Q/Sk0whjMoL1rmpj5zrsIl6XBV6ILQK2Ux/QagPPlNt+AXWLCdyTJ6gH2UBxhFy4 iWxcY4F5I2rLPWB4bSglvSU38Bcu365q9h9r4B6/YtAfmHilFMzV/T5lDnE6m/tm qUkFWH1CwK7mMu5u45vEEkNdbSlSkccKFxZEpp/JMuI5HD6wkAzwmKvBJThidUoF y5rME5DpBn8pZAeZzPu23HFQ+4aIJwvz9x8bUPIzMwn4ZkXFe+pNAFkboQGT5dbU hstgsDhEl9yIi56JDrXKECXi+Wl/+TO3gc3rlA5YqwLv7o4emMl2khF6quNLgug= =
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=fm2; bh=ji5Ruv NsVv3W/Wlm1rcokUVWGOzuf18weSM1Zh2JJ34=; b=kyC96urJaEFmPkzkvU6AEi Uuj/JeS2B0wd66X9m4NRHLslS+M2hj8tFBJGL+BegqllsiNLT1cPnmnGFYqOpgeQ Wm2U57qeVuPuHQiBDw+LA3pru6ma02rm1cRMaFWqHCJ9D3KVceVS0md7VpJ5KG/K UFapWeJvdlZpEd5AbdrN4QS0YIW3oiMpUCSXDo/n4/P9EbptELzkMArhnNRljAok odIrIhaz5vi6hGbgz7kXaTxuJLOEuh8K3zvvCr3W38vkKgl7bSP+lsjimmuWhNRl nHhtx2c4I8vIa9Nrcfy9mz5dpQNmcmmr1UzvUsfET/b7V3Ew8h4PaCtVDaAlK14g ==
X-ME-Sender: <xms:d4ykYPUw7k4gebNrHDDJySk1LVt2UvGlslFFXHvzTEwWfnMboSAZ3A> <xme:d4ykYHkSOXtG9cjpzvB0VyeAk1e1kJ5fEvQ8DwbVRIxKwJX9a87snaNV92s--oi7c JX0RGxhiS8>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeikedgjeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeelkefhvedvfe euieeilefftddtieefjefhfeektdeuuefftdekudetheeivdetgeenucffohhmrghinhep rhgvlhgrthhiohhnshhhihhprdhfohhonecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy: <xmx:d4ykYLbr0arEbf-ucardclz2I0naAnSPXOlU0EV-24WoEAcLkDkymg> <xmx:d4ykYKVM0rnsUJ5ut3WidgssDr8ZhCAAE26JT3EgIjqpSctQVtXMTQ> <xmx:d4ykYJmkxglMZYyK8JnyBeJnBOr0Rv3sub5j9Fx0uWh6YTpicecHdg> <xmx:eIykYFzl1edtPeHgYqVQAni_7_DE6rODtiEIWMe5-YoovI06a-tJRA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7219D18005D; Tue, 18 May 2021 23:56:39 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-701-g78bd539edf-fm-ubox-20210517.001-g78bd539e
Mime-Version: 1.0
Message-Id: <2d6ede2e-152d-4ed6-9498-d87ecfcad9e0@dogfood.fastmail.com>
In-Reply-To: <978706aa-c660-451f-a119-807ec9cc1bce@beta.fastmail.com>
References: <CAJi=jaeZ7uC+CoXLhSekvO-pOJnHgSOFNzZ_WBCv1Sf9HfqK2A@mail.gmail.com> <978706aa-c660-451f-a119-807ec9cc1bce@beta.fastmail.com>
Date: Wed, 19 May 2021 13:56:19 +1000
From: "Bron Gondwana" <brong@fastmailteam.com>
To: jmap@ietf.org
Content-Type: multipart/alternative; boundary=ac47d1102b7e4224a7f27c14f509066f
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/9a__ZDiWpDK9UaBmUTlzjWdQsZM>
Subject: Re: [Jmap] new JMAP server for prototyping
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 May 2021 03:56:46 -0000

On Wed, May 19, 2021, at 13:05, Neil Jenkins wrote:
> I don't think we actually considered a data type that supported circular references, but the way the current spec is written I would say that if the circular reference is valid for that data type and the final state is valid, then yes you would be allowed to do that in a single /set. But I agree that's a bit ambiguous, and I think you could probably forbid it in the /set description for the particular data type. Do you have an example in mind?

I can think of one - anything double-linked - for example calendar events that have a rel=next and rel=prev relationship.

[ "Foo/set", {
  "a" : { next: "#b" }
  "b" : { prev: "#a" }
}, "x" ]

>> - If the client uses the same creation ID in two method calls, despite the "SHOULD" cautioning against it, and the second create fails, should the first one's ID continue to be used? Is "the most recently created item with that id" the most recent attempt, or the most recent success?
> 
> Most recent success was the intention, but looking at it again I can see how you could interpret it both ways.

If you break it, you get to keep both pieces!

>> But overall I've found the spec pretty clear and solid so far.
> 
> Great! This was really good feedback. I don't think any of it requires an errata (although if someone on the list disagrees, please pipe up!), but if we publish an updated RFC at some point in the future we know which points to clarify.

We should track these somewhere specific, because I for sure won't know which points to clarify in 5 years' time, and I'm unlikely to read every mail thread!  Maybe as open issues on the git repo, or even in a text file in the repo?

Cheers,

Bron.

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