Re: [calsify] PROPOSAL: recharter CALEXT and bring contact work and maintenance in charter
Ken Murchison <murch@fastmail.com> Wed, 17 November 2021 12:15 UTC
Return-Path: <murch@fastmail.com>
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A613A0C77 for <calsify@ietfa.amsl.com>; Wed, 17 Nov 2021 04:15:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.938
X-Spam-Level:
X-Spam-Status: No, score=-3.938 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=-1.852, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, 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=YjP5nZP8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fEynNjI0
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 U8y-dYUEveqZ for <calsify@ietfa.amsl.com>; Wed, 17 Nov 2021 04:15:42 -0800 (PST)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCFF13A0C6E for <calsify@ietf.org>; Wed, 17 Nov 2021 04:15:42 -0800 (PST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 66A845C01D3 for <calsify@ietf.org>; Wed, 17 Nov 2021 07:15:39 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Wed, 17 Nov 2021 07:15:39 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-type:message-id:date:mime-version:subject:to:references :from:in-reply-to; s=fm1; bh=oO8xmpGHktZ9pS2KxNa7LO3GPGknrsv6zwy opLATu7U=; b=YjP5nZP8yNJ/gByFQ77p64jPkuMG16oWdaiXiIcf4aWThbOEI0A +z4xnnN+6yNcQudGrYpcPw7OahC9d2CzdS6vfUkJkIahqCXRDedL2AhAAljs6jtF X1gdEb2ZZobuQajEotqn1tRWn+bH0V+YZ9Y3KwJkhxnDklCXfi34VfuEZBGeHHL7 CrwSkMOKAmeDuhI1Ww67dWxsOShjuEMGLBsywwJ5ZpG5fTWU8TD2DgV4P5+Kfs6w W+Fa7N0pqdH8WKS1KqnxhPkmen8g9ti8Y8SVsJcTsx2A546O16JHVZD7wprp37R3 zTacUg1pSYg+RcoB+pR9kZmz/XOr5Korhpw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=oO8xmp GHktZ9pS2KxNa7LO3GPGknrsv6zwyopLATu7U=; b=fEynNjI0FaiMpG7XONtUqX ZDxV2HfGYuPgdCS/xB3OaW3E9CEk0KKi5KiAjdog4/QBLqDD4v0pNisnc/ncT7ZM GU6i/QykuTwt9VuSKXqLUeBiubeB2EhjIFqjKJWOc1gxQaHsHMZRii2bODiATcY+ 0YSNU3ZvwufVk5XNss2JclQKWifWclwOSv2DLVAQLFik6txFvyaB76xtPrSbt0lX hPp//XYbKwvrKXgVyGCdUso5hycvhEJ8Blh9ZDxdNzvSN817rq4K44PZxVOzM5n+ 0s29zPe/T7rmbKJpMa+apoKRvVLMsDVZ9mG4N4RkJhO5458XRdSNmLds8nNFNIFw ==
X-ME-Sender: <xms:a_KUYbqSxsjd7bXa1DEPYuZZUnZ1MpnO37qTp-Djy0W4dLQAzYdWYg> <xme:a_KUYVqxzbsTx6wuq3X4QeRX8qr8jd2WvjgrSui_dJIKemYgSRZp_KG4NkyYyScg_ bxAdlcmkEvrlA>
X-ME-Received: <xmr:a_KUYYO3Q0bg84-QNXHEDEWHO3w2FHTJ4Dp7kk9kTjQzHK2nilsnh1fZVD2I1sOXz7IGPl970AKFCTIcnw769te0DT2Px3TJK65tVw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrfeeggdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptgfkffggfgfuvfhfhfgjsegrtderre dtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshht mhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeffteekteeguedvveetjedtudfgff ekteduteduheeiheegveffgfelfeejffetudenucffohhmrghinhepihgvthhfrdhorhhg necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhurh gthhesfhgrshhtmhgrihhlrdgtohhm
X-ME-Proxy: <xmx:a_KUYe5AXM1tNZc3vJRYfvaX-8l5XfNadZgt_mdvCV1ULjRYl_-Msw> <xmx:a_KUYa49Sc7LaEikvNAOofLp8dYS0Q5HYxoIoyiqqUGqD35yx-oI5Q> <xmx:a_KUYWgz6OMyBEg3DkapYbQrAfueTm94t_Kq2VSim37MAR1D9W-GVg> <xmx:a_KUYXX1cO6Xfo9xZF7dz2HRnxYa_auE4OEosRUR4W5CMtPOK8L_BA>
Received: by mail.messagingengine.com (Postfix) with ESMTPA for <calsify@ietf.org>; Wed, 17 Nov 2021 07:15:39 -0500 (EST)
Content-Type: multipart/alternative; boundary="------------RqPXIajhiZKdZMpJ2wxvup5s"
Message-ID: <08f866b3-904f-c27f-3610-10e1692c4152@fastmail.com>
Date: Wed, 17 Nov 2021 07:15:38 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0
Content-Language: en-US
To: calsify@ietf.org
References: <283e06dd-9bbe-41af-b9bf-9326ed91c131@dogfood.fastmail.com>
From: Ken Murchison <murch@fastmail.com>
In-Reply-To: <283e06dd-9bbe-41af-b9bf-9326ed91c131@dogfood.fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/l9nZxHZzO2ppwHXERejyofsRhqk>
Subject: Re: [calsify] PROPOSAL: recharter CALEXT and bring contact work and maintenance in charter
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Calendaring and Scheduling Standards Simplification <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Nov 2021 12:15:48 -0000
The charter text looks sensible and clear to me. Do we want to add iMIP (RFC 6047) to the list of basis specs? On 11/17/21 5:13 AM, Bron Gondwana wrote: > 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 > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Kenneth Murchison Senior Software Developer Fastmail US LLC
- [calsify] PROPOSAL: recharter CALEXT and bring co… Bron Gondwana
- Re: [calsify] PROPOSAL: recharter CALEXT and brin… Alexey Melnikov
- Re: [calsify] PROPOSAL: recharter CALEXT and brin… Alexey Melnikov
- Re: [calsify] PROPOSAL: recharter CALEXT and brin… Ken Murchison
- Re: [calsify] PROPOSAL: recharter CALEXT and brin… Daniel Migault
- Re: [calsify] PROPOSAL: recharter CALEXT and brin… Bron Gondwana
- Re: [calsify] PROPOSAL: recharter CALEXT and brin… Michael Douglass
- Re: [calsify] PROPOSAL: recharter CALEXT and brin… Ronald Tse
- Re: [calsify] PROPOSAL: recharter CALEXT and brin… Bron Gondwana