[Jmap] Tasks (draft-ietf-jmap-tasks-04) and recurrence

Ricardo Signes <rjbs@semiotic.systems> Mon, 13 June 2022 12:46 UTC

Return-Path: <rjbs@semiotic.systems>
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 39558C14F733 for <jmap@ietfa.amsl.com>; Mon, 13 Jun 2022 05:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.705
X-Spam-Level:
X-Spam-Status: No, score=-0.705 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=semiotic.systems header.b=SEuUjfto; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xKAy5ICT
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V614y8heBJEG for <jmap@ietfa.amsl.com>; Mon, 13 Jun 2022 05:46:35 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4A56C159827 for <jmap@ietf.org>; Mon, 13 Jun 2022 05:46:35 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 1EB8C320047A for <jmap@ietf.org>; Mon, 13 Jun 2022 08:46:33 -0400 (EDT)
Received: from imap43 ([10.202.2.93]) by compute4.internal (MEProxy); Mon, 13 Jun 2022 08:46:33 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= semiotic.systems; h=cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm2; t=1655124392; x=1655210792; bh=npIgsThroK /7GBkS4jPMuHewVaBoYX1MZlbpZD0jCe4=; b=SEuUjftowEBdoLFpbxk1vd6nch mDgYeBSWgNVKRMBTti6+PKBvQm4ndxcEEwYJDbsYNDr7X81aZNy9LzTW3Egyr8S6 bptajNRuiISIrjvPV9QKvGlZ9DICDUttLkjdoOxo2io6yvxhhV/wxoeA8StOtVpZ e3bUocm2VuVMN8wnT9OGk+ZHkMMKqKWFWj4q0xat0X2hYgkau625qfYLiZ1DUiN+ 8ECFnqYe2ztyxIohE93QzLrgOWGqu+GcmjJ4iQHWJ+tllhIEnOHGu02cCaR0K5SY gQdp6i4RKvfiuSYZHOXykrCKxuQfoqsyhzA95U74T5Wa4BiNfr5i9YmOUfbQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1655124392; x= 1655210792; bh=npIgsThroK/7GBkS4jPMuHewVaBoYX1MZlbpZD0jCe4=; b=x KAy5ICTRt0hvwhA5zOkTSXaqgM02gAFBDnKr0GDeWvF94L4UNsznze2n54MhMBBz A32LNTT7kHZv/v4wXWIrX2SOriKsfvxDPcH/ePNW7K2IDTQn42AUYBiRB5ZQQeEI GNPK9qw57CaB2pqVWLtFH9wJ0ghVuXnDpl3cnR00d7VX3d6poZsInb/eWQzlQFJe 43r0whbT8jCXRfvlMazvH4fy/hD9hCK1dnWU0QTlMKwmcCRbWyoHrybkFepnbmK2 n6x9uhec3TqnG3Yntt29SyzpfOC247hob4tUhEkxcfeRT2dSacMLgatmxyhoGneS NXjSGkAICY8kzUmgs42TA==
X-ME-Sender: <xms:qDGnYgE8-pFqLoFFHk_8E9IiiBjWTEpYM_TDZl5r55Xc5QzSziOgPA> <xme:qDGnYpWOVnC6jWXXHsk5scN4tCVc0azTuq_1_M5vvHJKWRn_Acm6I4e31ZzM-BAFA 3z4VNUskHp8C3xoJFU>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedruddujedgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedftfhitggrrhguohcuufhighhnvghsfdcuoehrjhgsshesshgv mhhiohhtihgtrdhshihsthgvmhhsqeenucggtffrrghtthgvrhhnpeeuheejgfehffeuhf efudfgkeeiteeivdelteefueeggedtfeegffffgefgkeelgfenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrjhgsshesshgvmhhiohhtihgtrd hshihsthgvmhhs
X-ME-Proxy: <xmx:qDGnYqLrsDeJVQTSxvaQW_X3tcXXUroE8Ul3vEJ3RvlqDU8EUqIUZg> <xmx:qDGnYiFMQ6QosrR9Ij-mbauznmjb_6qxVCXsbTUijaf8wtwZlrblAQ> <xmx:qDGnYmXUvG9ujHt_1ulsh0dUJ1dkdJ1dUyJYd5uqU4UfPA7tkg_M1A> <xmx:qDGnYujF-xMGWDyesmbvcDZWWgTkKQASX8Obg1hOEkP6fR5qp2iSEQ>
Feedback-ID: idc49479b:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 43F0D2D40070; Mon, 13 Jun 2022 08:46:32 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-692-gb287c361f5-fm-20220603.003-gb287c361
Mime-Version: 1.0
Message-Id: <cf696f96-bd96-4a23-b375-a4b52ea47685@www.fastmail.com>
Date: Mon, 13 Jun 2022 08:46:12 -0400
From: Ricardo Signes <rjbs@semiotic.systems>
To: jmap@ietf.org
Content-Type: multipart/alternative; boundary="c0723e2586814d93981826e3408a438c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/cMPyheylMKRLX_xzjyGbeVKbjvk>
Subject: [Jmap] Tasks (draft-ietf-jmap-tasks-04) and recurrence
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 13 Jun 2022 12:46:40 -0000

Hi all,

I'm a bit late to the game here, but have tried to find and read past discussion before posting.  I hope I'm not rehashing anything, here.

Last night, I was giving a read to draft-ietf-jmap-tasks-04 and thinking about the way that it divides its features up into a larger number of capabilities than JMAP for Calendars.  The splitting off of "recurrence" gave me pause.

I know that not all todo systems have every feature, specified in the draft, but I'm not sure I see what this one is meant to fix.  It's either meant for the server or the client, right?  If it's to allow a server to say "I do not support recurrence," then I think it will work fine.  But by existing, it also allows the client to omit the recurrence capability from requests.  I think that means this scenario is possible:
 * the server supports recurrence
 * client A connects to the server, puts recurrence in its request's "using", and makes Tasks with recurrence rules
 * client B connects to the server and looks at the Tasks available
What do they see?  They can't see the recurrence rules.  They also (presumably) can't use expandRecurrences, so they can't treat the recurrences more or less like many individual events.  I think in this scenario, client B is likely to be impossible to use well.

I don't have a clearly ideal solution to suggest at the moment.  But is this even a problem, as I think it is?

-- 
rjbs