[Jmap] PROPOSAL: recharter CALEXT and bring contact work and maintenance in charter

Bron Gondwana <brong@fastmailteam.com> Wed, 17 November 2021 10:15 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 0FCCD3A0BC5; Wed, 17 Nov 2021 02:15:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=J3M31rSj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=m3oF9NDi
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 f-0MLGkF9Vwy; Wed, 17 Nov 2021 02:15:08 -0800 (PST)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4935D3A0BB4; Wed, 17 Nov 2021 02:15:08 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 113463201D60; Wed, 17 Nov 2021 05:15:05 -0500 (EST)
Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Wed, 17 Nov 2021 05:15:05 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:cc :subject:content-type; s=fm1; bh=byr0RpNYgl2/QwcFZ83bZgZQtrqKqCI r3uvzVd/YO2k=; b=J3M31rSjTiQrFdcIByLyN9Lce5rsKf5IIy1RPjk4FeI6Szb ouSMeRkpSa4snuNWqh9owy9FDBjViza8WOfu13p9PWnwF7LsyisSGCmwKUu+9sgc 70XbeOmnlrTLMwwcwWQ69VuBAn2547VbWy13himwuWax0ce1PiJsAc2VdR14DrGF lhMudUMQdyTPTv+dbxVmq7deJVHDCzYHSOZOuh/BdQta2UA+NS5RSoRxCe4Cpxic 03o5orX0qqtQqok27GjWyv2Donw85XGFgqg20pWzbQ0HSRw01zdZuhqtBEF7Kr5d H9hlh9QwqWUs4Hr0WimtBJ/GigA1hc41ynT1WUQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=byr0RpNYgl2/QwcFZ83bZgZQtrqKq CIr3uvzVd/YO2k=; b=m3oF9NDilqGcJRocGT0SGXhO/348ZzVa1mMhxAA09jBhe iGgvs/Y73N8oL7l1GKz/ZeFOPIJGKS94iAbmslNYcKnNx01QOPZ03bpr3Bn1VedZ 3fy1DkSThg4ntgiz6kKTjT3Anx0YVVWEBLZBSPTdydJVjmRlyS+eS28K3S9Ga1LK i2vimoY3C5dlrs36uiO9Ue92Fu6joZE53JpMUxj7CiiRWOzvgQx5DKoC6sspXdLn mrcXayxTigNeokV27oKv/p46lLkivlPqRGRWV5KXshQYk1eZ1CIjgyvUwMKkUk0X oDxeZey4zvF/dDWhPowdk4VZ507EYXvZFbl+2gu+Q==
X-ME-Sender: <xms:J9aUYZEONM9oIsx8AZq0YHkYXLjvYslvg0E9Xv64LXQGh2rwraknJg> <xme:J9aUYeWV4nFlni4Bxy7Vh3KsWNcNHlzngyHFrhtiE3CRhuQSHsz9nyiF-0tUNj2Ke r97rJlrr98>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrfeeggddtkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre erjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnheptdelfeegudettefhhe egtdelvefhudduhfeijeeghedtveeitddtuefggedvjeehnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh
X-ME-Proxy: <xmx:J9aUYbLooczc6jFGqOLeUkzitng9vyDHJfMDTFz9WjK29J6KkxF76A> <xmx:J9aUYfFr-7wZDo6bo7ZQGe4YabJLqVC-QpChmZCo__hV_vLK4Wr7PQ> <xmx:J9aUYfU_dxbCKq7uDieRUy__001GWgI3RQQikY7JX_1058MzsEN0mQ> <xmx:J9aUYQeqbEjUCc5SnreBFSCUGh-FUaRQ4eLWl6Eg0GY2EcyYcuYt_Q>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 78B27AC0DD1; Wed, 17 Nov 2021 05:15:03 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1457-g307304a2db-fm-20211109.001-g307304a2
Mime-Version: 1.0
Message-Id: <283e06dd-9bbe-41af-b9bf-9326ed91c131@dogfood.fastmail.com>
Date: Wed, 17 Nov 2021 21:13:48 +1100
From: Bron Gondwana <brong@fastmailteam.com>
To: calsify@ietf.org, jmap@ietf.org
Cc: art-ads@ietf.org
Content-Type: multipart/alternative; boundary="328d2b25234445c49e408cfaf3f733fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/hTRZcXjRKfVpeAXRkRCxxSLlfkI>
Subject: [Jmap] PROPOSAL: recharter CALEXT and bring contact work and maintenance in charter
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, 17 Nov 2021 10:15:14 -0000

Hi - both JMAP and CALEXT working groups,

I'm emailing both groups, because this proposal includes taking the current jscontact work and moving it from JMAP to CALEXT where it will be maintained on an ongoing basis - along with the icalendar, vcard and jscalendar specs as well as the caldav and carddav protocols.  This new charter anticipates a long lived maintenance working group for all the contacts, calendars, and related data formats.  The reasons for taking on the VCARD and CardDAV work are pretty obvious:
 * Both have *DAV protocols.
 * Both have similar syntax model (VOBJECT)
 * Could move maintenance of JSContact over from JMAP where it doesn’t really fit either.
 * Frequently implemented together.
 * Both handled by CalConnect as well, maintain the relationship.
 * Better than starting another group for contacts! We already have enough groups.
We also propose to close the 'calsify' mailing list and move all the subscribers to a list called 'calext@ietf.org' so that the mailing list name matches the working group name, because this is an ongoing source of confusion to new people.

We have deliberately left the "out of scope" a little loose so that things like tasks or even file synchronization (which is needed for managed attachments in calendars among other things) might come into scope - so long as it's related to the documents that this group currently maintains and isn't better suited to another existing group, then it's a candidate to be worked on in CALEXT.  That's hopefully a good balance between too much charter lawyering for things we should be working on, while not opening the door to do arbitrary stuff here.

The CALEXT chairs and our two ADs (Francesca and Murray) would love any feedback you have on this charter text over the next couple of weeks before we formally propose this charter to the IESG.  *Please send feedback by December 1st (earlier is better so we can iterate)*

Thanks,

Bron.

https://notes.ietf.org/calext-proposed-charter-2021 - pasted below
Charter Text:

The CALEXT working group is chartered to maintain and extend the specifications for formats and protocols related to calendaring and contacts within the IETF, starting from the basis of:

 * CalDAV (RFC 4791)
 * iCalendar (RFC 5545)
 * iTIP (RFC 5546)
 * VCARD (RFC 6350)
 * CardDAV (RFC 6352)
 * JSCalendar (RFC 8984)
 * JSContact (draft-ietf-jmap-jscontact)
and the many existing extensions and companion documents to these.

This working group is envisaged to be long-running, and deal with a steady slow flow of changes. Experience has shown that these specifications are still seeing significant need for updates, as new use-cases are identified and user requirements change.

This working group will do the following:

 * maintain existing standards and proposed standards, processing errata and refreshing them as required
 * evaluate and develop extensions to the existing standards to provide for new use-cases where there is demand
 * publish informative documents describing existing implementations of non-standard extensions, where vendors have already shipped an implementation and with which our protocols will need to interoperate
The working group will work under the following parameters:

 * The extensions developed are expected to be backwards-compatible with the existing standards. Incompatibilities must be identified, minimized, and justified.
 * Any extensions to icalendar or jscalendar must include a representation in both formats, and define a robust mapping between them.
 * Any extensions to vcard or jscontact must include a representation in both formats, and define a robust mapping between them.
 * All calendar extensions must examine their impact on the iTIP protocol (RFC 5546), and define any necessary extensions to iTIP to accommodate such impact.
The working group will maintain relationships with other working groups:

 * HTTPBIS and HTTPAPI: when extending the CalDAV or CardDAV protocols to ensure that changes are consistent with good http practices.
 * JMAP: when making updates to JSCalendar and JSContact to ensure that the changes are compatible with the JMAP methods for managing data in these formats.
 * EXTRA, DMARC and EMAILCORE: for changes related to iTIP delivery via email.
 * Other working groups as appropriate, when their work interacts with ours.
The following are out of scope for the working group:

 * Any attempt to develop non-Gregorian calendar systems/calculations.
 * Work which is in scope for any other ART area working group, and better suited to that group.
 * Work which is unrelated to anything that this group is currently maintaining.

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