From nobody Wed Mar 2 06:14:41 2022 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F653A040B; Wed, 2 Mar 2022 06:14:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , calext-chairs@ietf.org, calsify@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <164623047380.18070.325303714068082558@ietfa.amsl.com> Date: Wed, 02 Mar 2022 06:14:33 -0800 Archived-At: Subject: [calsify] WG Action: Rechartered Calendaring Extensions (calext) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2022 14:14:34 -0000 The Calendaring Extensions (calext) WG in the Applications and Real-Time Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Calendaring Extensions (calext) ----------------------------------------------------------------------- Current status: Active WG Chairs: Daniel Migault Bron Gondwana Assigned Area Director: Francesca Palombini Applications and Real-Time Area Directors: Murray Kucherawy Francesca Palombini Mailing list: Address: calsify@ietf.org To subscribe: http://www.ietf.org/mailman/listinfo/calsify Archive: https://mailarchive.ietf.org/arch/browse/calsify/ Group page: https://datatracker.ietf.org/group/calext/ Charter: https://datatracker.ietf.org/doc/charter-ietf-calext/ 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) - iMIP (RFC 6047) - 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 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 - generate documents describing existing vendor extensions which are in common usage, and likely to be encountered in the wild. 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. - TZDIST and SEDATE for date, time, and timezone related issues. - Other IETF working groups as appropriate, when their work interacts with ours. - Other standards organisations like CalConnect and M3AAWG that are doing work in the same fields. 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. Milestones: Jan 2022 - Submit Subscription Upgrade document to IESG for publication Jan 2022 - Submit task draft to IESG Apr 2022 - Submit JSCalendar mapping document to IESG for publication Apr 2022 - Submit JSON Contact document to IESG Jun 2022 - Submit vpoll document to IESG for publication Jun 2022 - Submit Serverside Subscription draft to IESG for publication Jul 2022 - Submit calendar series document to IESG for publication From nobody Fri Mar 4 16:08:04 2022 Return-Path: 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 C917C3A0ABB; Fri, 4 Mar 2022 16:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 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, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=fastmailteam.com header.b=e+u//jTs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=inaiPvjc 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 jxglc3z1X43y; Fri, 4 Mar 2022 16:07:56 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA623A0AA6; Fri, 4 Mar 2022 16:07:55 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 091635C010B; Fri, 4 Mar 2022 19:07:55 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Fri, 04 Mar 2022 19:07:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm2; bh=9RyYLCaHBdf12dvM04rYqKc0riPgIy/yJKayLl SeH0I=; b=e+u//jTsLvtzEZRfmWujbhYavJpMxbQkAHMfYpGG2l7aYbyvzFNgAu jmSX0tdmBgOSWi+3HOuqcqntd4ayRVAjbTr0j+oPcmUkBORCusX17Fq586DtuXFg 0cFRsXy8Lv5DLLDQ5vITqOjCnVfhHnDh3CPpXkbI6VW+VGdJRj9VR0lzTSMgcjDF v1hE8bxRGcVYT23CSBPfTmRnWsNproxqt72ah+JnQyNV4ptXanKAIIvJRfUASb/m U/Fvo6Oxx3hZgu0jPZyYAi8mATgWDGK6974oPZHgxfWgM3PXVq8xod87UiWjsURx Tn0U3liYyDXmpNQOPgocCLobUiuqRJsA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date: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; bh=9RyYLCaHBdf12dvM04rYqKc0riPgIy/yJKayLlSeH 0I=; b=inaiPvjcDUZQze4NaeJqqH+Mkv2mkOh8NEJlkr7jS8dK7k7LKIgmrcsVd jn+W+dcT1a6G5ymQiPP3W/sQGIEueWyvGpq49MQXjt7paCvdzC8JrMPy8kEUMpG3 MWXX+npCzTAUiFJUwV0xhl/7jh3+Hhu2ytO5TKiba+dgFiizzqg4F/+Wf13XupBw bxsXVyFa+ASHmAgr83Q8coG1XoR5fXO8GsiFj4rsKgMjNi7kQM0jMuiUqq5Ddokh pP7vU2BCsgQOxcX4ZSoYV5qqYFLKV2mIHROaWy3rxwJSUHl1KmJOfTPPF29vdTdz gk1uGDdk1JrVKnRba/eXOlx0YyhSg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddtledgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhhonhcu ifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepvdetteeiveeihfegiedtgeeigfduveelhefgffelgeelueeh hfeitdelgedtffegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A460EAC0E9C; Fri, 4 Mar 2022 19:07:54 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4849-gd25ea29a5a-fm-20220301.001-gd25ea29a Mime-Version: 1.0 Message-Id: Date: Fri, 04 Mar 2022 16:07:24 -0800 From: "Bron Gondwana" To: jmap@ietf.org, calsify@ietf.org Cc: "Mario Loffredo" , "Robert Stepanek" , art-ads@ietf.org Content-Type: multipart/alternative; boundary=d5320097c4e245c89a1d9629ea51374d Archived-At: Subject: [calsify] Transfer of draft-ietf-jmap-jscontact to calext X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2022 00:08:02 -0000 --d5320097c4e245c89a1d9629ea51374d Content-Type: text/plain Hi JMAP and CALEXT members, The CALEXT recharter has just gone through, and it brings the JSContact format firmly within the scope of CALEXT, so we're going to move the remaining work over to the other working group. Sorry for the late notice, the charter only just went through! Mario/Robert - if you could upload a new draft with the name `draft-ietf-calext-jscontact`, ideally before the draft cutoff this Sunday! that would be great. Ditto the mapping document. Further discussion will happen on the calsify@ietf.org list. Either way, we'll put the work on the CALEXT agenda regardless of what the drafts are called, so please come to that session if you're interested. It's at 10am on Tuesday morning, Vienna time. Thanks in advance for your flexibility as we fiddle around where work happens :) Cheers, Bron (on behalf of the JMAP and CALEXT chairs) -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --d5320097c4e245c89a1d9629ea51374d Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi JMAP and CALEXT members,

The CALEXT rech= arter has just gone through, and it brings the JSContact format firmly w= ithin the scope of CALEXT, so we're going to move the remaining work ove= r to the other working group.

Sorry for the late notice, the charter only just went through!

Mario/Robe= rt - if you could upload a new draft with the name dra= ft-ietf-calext-jscontact, ideally before the draft cutoff this Su= nday! that would be great.  Ditto the mapping document.  Furth= er discussion will happen on the cal= sify@ietf.org list.

<= /div>
Either way, we'll put the work on= the CALEXT agenda regardless of what the drafts are called, so please c= ome to that session if you're interested. It's at 10am on Tuesday mornin= g, Vienna time.

Thanks in advance for your flexibility as= we fiddle around where work happens :)

Cheers,
=

Bron (on behalf of the JMAP and CALEXT chairs)

--
  Bron Gondwana, CE= O, Fastmail Pty Ltd
  brong@fastm= ailteam.com


--d5320097c4e245c89a1d9629ea51374d-- From nobody Sat Mar 5 15:31:07 2022 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 789813A0E22; Sat, 5 Mar 2022 15:30:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <164652304241.6684.3030907058042507875@ietfa.amsl.com> Date: Sat, 05 Mar 2022 15:30:42 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-subscription-upgrade-05.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2022 23:30:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : Calendar subscription upgrades Author : Michael Douglass Filename : draft-ietf-calext-subscription-upgrade-05.txt Pages : 14 Date : 2022-03-05 Abstract: This specification updates RFC5545 to add the value DELETED to the STATUS property. This specification also updates RFC7240 to add the subscribe- enhanced-get and limit preferences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-subscription-upgrade/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-calext-subscription-upgrade-05.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-subscription-upgrade-05 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sat Mar 5 20:32:37 2022 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEA13A0BA2; Sat, 5 Mar 2022 20:31:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <164654111763.20276.3189696925358407643@ietfa.amsl.com> Date: Sat, 05 Mar 2022 20:31:57 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-vpoll-03.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2022 04:31:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : VPOLL: Consensus Scheduling Component for iCalendar Authors : Eric York Michael Douglass Filename : draft-ietf-calext-vpoll-03.txt Pages : 61 Date : 2022-03-05 Abstract: This specification introduces a new RFC5545 iCalendar component which allows for consensus scheduling, that is, voting on a number of alternative meeting or task alternatives. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-vpoll/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-calext-vpoll-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-vpoll-03 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sat Mar 5 21:08:57 2022 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD323A07DB; Sat, 5 Mar 2022 21:08:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <164654333483.14470.9766035566809850955@ietfa.amsl.com> Date: Sat, 05 Mar 2022 21:08:54 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-ical-tasks-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2022 05:08:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : Task Extensions to iCalendar Authors : Adrian Apthorp Michael Douglass Filename : draft-ietf-calext-ical-tasks-01.txt Pages : 30 Date : 2022-03-05 Abstract: This document defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC5545) to provide improved status tracking, scheduling and specification of tasks. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers can be extended to support certain automated task management behaviours. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-ical-tasks/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-calext-ical-tasks-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-ical-tasks-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Mar 7 07:11:52 2022 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 732973A0964; Mon, 7 Mar 2022 07:11:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164666590745.12091.15431338991874163408@ietfa.amsl.com> Date: Mon, 07 Mar 2022 07:11:47 -0800 Archived-At: Subject: [calsify] The CALEXT WG has placed draft-ietf-jmap-jscontact in state "Adopted by a WG" X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 15:11:48 -0000 The CALEXT WG has placed draft-ietf-jmap-jscontact in state Adopted by a WG (entered by Bron Gondwana) The document was previously in state WG Document The document is available at https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact/ Comment: This work is now in scope for CALEXT so we're moving it over there. From nobody Mon Mar 7 07:12:34 2022 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D21A3A0959; Mon, 7 Mar 2022 07:12:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <164666594824.9081.6887754399635344594@ietfa.amsl.com> Date: Mon, 07 Mar 2022 07:12:28 -0800 Archived-At: Subject: [calsify] The CALEXT WG has placed draft-ietf-jmap-jscontact-vcard in state "Adopted by a WG" X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 15:12:29 -0000 The CALEXT WG has placed draft-ietf-jmap-jscontact-vcard in state Adopted by a WG (entered by Bron Gondwana) The document was previously in state WG Document The document is available at https://datatracker.ietf.org/doc/draft-ietf-jmap-jscontact-vcard/ Comment: This work is now in scope for CALEXT so we're moving it over there. From nobody Mon Mar 7 08:33:00 2022 Return-Path: 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 C5B853A11A7 for ; Mon, 7 Mar 2022 08:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 u8IvqWgfjMC8 for ; Mon, 7 Mar 2022 08:32:44 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9473B3A1318 for ; Mon, 7 Mar 2022 08:32:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 499) id 73B6AE52D9; Mon, 7 Mar 2022 08:32:10 -0800 (PST) To: neilj@fastmailteam.com, rsto@fastmailteam.com, superuser@gmail.com, francesca.palombini@ericsson.com, brong@fastmailteam.com, daniel.migault@ericsson.com From: RFC Errata System Cc: rsto@fastmailteam.com, calsify@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20220307163210.73B6AE52D9@rfc-editor.org> Date: Mon, 7 Mar 2022 08:32:10 -0800 (PST) Archived-At: Subject: [calsify] [Technical Errata Reported] RFC8984 (6872) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 16:32:58 -0000 The following errata report has been submitted for RFC8984, "JSCalendar: A JSON Representation of Calendar Data". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6872 -------------------------------------- Type: Technical Reported by: Robert Stepanek Section: 4.4.3. Original Text ------------- "private": The details of the object are hidden; only the basic time and metadata are shared. The following properties MAY be shared; any other properties MUST NOT be shared: * @type * created * due * duration * estimatedDuration * freeBusyStatus * privacy * recurrenceOverrides (Only patches that apply to another permissible property are allowed to be shared.) * sequence * showWithoutTime * start * timeZone * timeZones * uid * updated Corrected Text -------------- "private": The details of the object are hidden; only the basic time and metadata are shared. The following properties MAY be shared; any other properties MUST NOT be shared: * @type * created * due * duration * estimatedDuration * excludedRecurrenceRules * freeBusyStatus * privacy * recurrenceOverrides (Only patches that apply to another permissible property are allowed to be shared.) * recurrenceRules * sequence * showWithoutTime * start * timeZone * timeZones * uid * updated Notes ----- Adds the recurrenceRules and excludedRecurrenceRules properties to the list of allowed properties of private events. Only the combination of recurrence rules, excluded recurrence rules and recurrence overrides allows to generate the full recurrence set for this event. Omitting the properties was an oversight during the initial publication of this RFC. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8984 (draft-ietf-calext-jscalendar-32) -------------------------------------- Title : JSCalendar: A JSON Representation of Calendar Data Publication Date : July 2021 Author(s) : N. Jenkins, R. Stepanek Category : PROPOSED STANDARD Source : Calendaring Extensions Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Mon Mar 7 08:42:18 2022 Return-Path: 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 46DAA3A0D1D for ; Mon, 7 Mar 2022 08:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 Bh20IhSDGTLg for ; Mon, 7 Mar 2022 08:42:10 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573923A0D07 for ; Mon, 7 Mar 2022 08:42:10 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 499) id 7A5C4E43B4; Mon, 7 Mar 2022 08:42:09 -0800 (PST) To: neilj@fastmailteam.com, rsto@fastmailteam.com, superuser@gmail.com, francesca.palombini@ericsson.com, brong@fastmailteam.com, daniel.migault@ericsson.com From: RFC Errata System Cc: rsto@fastmailteam.com, calsify@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20220307164209.7A5C4E43B4@rfc-editor.org> Date: Mon, 7 Mar 2022 08:42:09 -0800 (PST) Archived-At: Subject: [calsify] [Technical Errata Reported] RFC8984 (6873) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 16:42:16 -0000 The following errata report has been submitted for RFC8984, "JSCalendar: A JSON Representation of Calendar Data". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6873 -------------------------------------- Type: Technical Reported by: Robert Stepanek Section: 4.3.2. Original Text ------------- Identifies the time zone of the main JSCalendar object, of which this JSCalendar object is a recurrence instance. This property MUST be set if the "recurrenceId" property is set. It MUST NOT be set if the "recurrenceId" property is not set. Corrected Text -------------- Identifies the time zone of the main JSCalendar object, of which this JSCalendar object is a recurrence instance. It MUST NOT be set if the "recurrenceId" property is not set. Notes ----- A recurrence instance may be in floating time, in which case the value of the "recurrenceIdTimeZone" property is null. As null is the default value of the "recurrenceIdTimeZone" property, it is NOT required to be set if "recurrenceId" is set. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8984 (draft-ietf-calext-jscalendar-32) -------------------------------------- Title : JSCalendar: A JSON Representation of Calendar Data Publication Date : July 2021 Author(s) : N. Jenkins, R. Stepanek Category : PROPOSED STANDARD Source : Calendaring Extensions Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Mon Mar 7 11:07:24 2022 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5593A11CD; Mon, 7 Mar 2022 11:07:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <164668002890.9143.9991669447505299578@ietfa.amsl.com> Date: Mon, 07 Mar 2022 11:07:08 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscontact-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 19:07:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : JSContact: A JSON representation of contact data Authors : Robert Stepanek Mario Loffredo Filename : draft-ietf-calext-jscontact-01.txt Pages : 26 Date : 2022-03-07 Abstract: This specification defines a data model and JSON representation of contact card information that can be used for data storage and exchange in address book or directory applications. It aims to be an alternative to the vCard data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCard format, it is not a direct mapping from the vCard data model and expands semantics where appropriate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscontact/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscontact-01 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Mar 7 11:23:11 2022 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3275F3A12E6; Mon, 7 Mar 2022 11:22:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <164668093918.9645.7682855794392438410@ietfa.amsl.com> Date: Mon, 07 Mar 2022 11:22:19 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscontact-vcard-00.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 19:22:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : JSContact: Converting from and to vCard Authors : Mario Loffredo Robert Stepanek Filename : draft-ietf-calext-jscontact-vcard-00.txt Pages : 41 Date : 2022-03-07 Abstract: This document defines how to convert contact information as defined in the JSContact [draft-ietf-calext-jscontact] specification from and to vCard. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscontact-vcard/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscontact-vcard-00 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Mar 7 11:40:17 2022 Return-Path: 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 8082E3A0902; Mon, 7 Mar 2022 11:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.186, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no 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 DS3jFC5OXy6q; Mon, 7 Mar 2022 11:39:54 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E68643A0948; Mon, 7 Mar 2022 11:38:50 -0800 (PST) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 227Jce4L001120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 7 Mar 2022 14:38:46 -0500 Date: Mon, 7 Mar 2022 11:38:40 -0800 From: Benjamin Kaduk To: Michael Douglass Cc: The IESG , draft-ietf-calext-ical-relations@ietf.org, calsify@ietf.org, calext-chairs@ietf.org Message-ID: <20220307193840.GP22457@mit.edu> References: <164496396877.21317.914662615752443156@ietfa.amsl.com> <6643da72-0508-3d45-1ba7-604557df2a01@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6643da72-0508-3d45-1ba7-604557df2a01@gmail.com> Archived-At: Subject: Re: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-ical-relations-09: (with DISCUSS and COMMENT) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 19:39:59 -0000 Hi Michael, Most of this looks really good, and I'll go lift my Discuss shortly. Just a handful of notes scattered inline... On Sun, Feb 27, 2022 at 06:10:37PM -0500, Michael Douglass wrote: > Thank you for your detailed response - please see below ... > > On 2/15/22 17:26, Benjamin Kaduk via Datatracker wrote: > > > ... > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > The ABNF for linkparam (§8.2) incorporates a "langparam" production, but > > that is not defined in any of this document, RFC 5455, RFC 8288, or RFC > > 7986. We need to define it somehow, whether by reference or directly. > > RFC 5545 does define a LANGUAGE parameter (our prose references a "LANG" > > parameter) and languageparam ABNF production, which is perhaps the > > simplest explanation for what was intended. > Yes - it should have been languageparam - corrected Excellent, I'm glad it was the easy fix. > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > A couple broad comments before getting into the section-by-section > > details: > > > > I'm a little unclear on the value gained by having RELTYPE=REFID and > > RELTYPE=CONCEPT. If the semantics were just supposed to be "is a member > > of the indicated group", then why do we need a relation type to say so. > > But if there's some other semantics associated, where do we define those > > semantics? > The idea is to associate one entity with others without that entity > necessarily having the associated attribute. The semantics are more like > - this is an aggregator for those things with the designated REFID or > CONCEPT Ah, thanks for the extra explanation. Perhaps I was just being a bit dense when I first read it; I don't really have any suggestions for how we might add more text that would have prevented my confusion. > > There are a number of places (e.g., §1.4) where this document uses the > > term "collection" in a context that suggests that it should be a defined > > term of iCalendar, corresponding roughly to a "site" or administrative > > domain, but I didn't find any usage in RFC 5545 that would correspond to > > what's being described here. Can we say more about what level of grouping > > this is intended to refer to? > > More of a CalDAV thing. I'll precede the first occurrence with some text > > ------ OLD ------- > > It is also often necessary to reference calendar components in other > > collections.  For example, a VEVENT might refer to a VTODO from which > > ------ NEW ------- > > Calendar components are often grouped into collections to represent a > calendar or a series of tasks, for example [RFC4791] (CalDAV) calendar > collections. > > It is often necessary for calendar components in one such collection > to reference components in other collections.  For example, a VEVENT > might refer to a VTODO from which... > > ------------------ > > > Section 1.1 > > > > The iCalendar [RFC5545] RELATED-TO property has no support for > > temporal relationships as used by standard project management tools. > > > > I am admittedly not really the target audience of this specification, but > > I have no idea what the "standard project management tools" are that are > > being referred to. Would (informative) references to a handful be > > appropriate? > > I guess I should drop 'standard' and just write > > temporal relationships as used by project management tools. > > > It's really the relationships which are 'standard' in the sense they are > apparently used by all/most project management tools.There is also the > Project Management Institute which has /A Guide to the Project > Management Body of Knowledge /which apparently defines these terms also. > I'm not sure if we want a reference to that - I think it's as close as > we get to a standard > // > > > Section 1.2 > > > > REFID is used to identify a key allowing the association of > > components that are related to the same object and retrieval of a > > component based on this key. [...] > > > > This says "related to the same *object*" (emphasis mine), but the rest of > > the section just talks about an unstructured grouping. It seems like we > > could give some hint of the nature of the "object" to which all the > > elements of the group are related, prior to the RELTYPE=REFID definition > > in §5. > > Not sure how to reword this. The examples were an attempt to define > that. I should probably at least stick with component instead of object. > > I've tried a bit of rewording... > > ------ OLD ------- > > REFID is used to identify a key allowing the association of > components that are related to the same object and retrieval of a > component based on this key. Two examples of how this may be used > are to identify the tasks associated with a given project without > having to communicate the task structure of the project, and to group > all tasks associated to a specific package in a package delivery > system. > > ------ NEW ------- > > REFID is used to identify a key allowing the association of > components that are all related to the referring, aggregating component and > the retrieval of components based on this key. For example, this may be used > to identify the tasks associated with a given project without > having to communicate the task structure of the project. A further example > is the grouping of all sub-tasks associated with the delivery of a specific > package in a package delivery system. > ------------------ > > > > > Section 1.3 > > > > The current [RFC5545] CATEGORY property is used as a free form > > 'tagging' field. [...] > > > > In light of the discussion in the previous section about grouping without > > semantics, we might consider mentioning here that this is "tagging with > > semantics", just vaguely defined ones, as opposed to the REFID-type > > "tagging without semantics". > Added some text. > > > > Section 1.4 > > > > server-side management and stripping of inline data. Clients may > > choose to handle attachments differently from the LINK property as > > they are often an integral part of the message - for example, the > > agenda. > > > > (See the NITS entries as well, but) is it particularly noteworthy that > > clients might handle LINKs different from ATTACHments? They are different > > properties after all -- why would someone assume equivalent treatment? > > I'm not sure why - but it seems worth pointing out just in case. There's > some degree of similarity between a LINK and an ATTACHMENT - especially > if the attachment value is a uri. > > Also I think when I wrote this managed attachments wasn't an RFC. I have > the ref but the text is vague. > > ------------ OLD ---------- > > The LINK property MUST NOT be treated as just another attachment. > The ATTACH property defined in [RFC5545] is being extended to handle > server-side management and stripping of inline data. Clients may > choose to handle attachments differently from the LINK property as > they are often an integral part of the message - for example, the > agenda. > > For more information on managed attachments see [RFC8607] > > ------------ NEW ---------- > > The LINK property MUST NOT be treated as just another attachment. > The ATTACH property defined in [RFC5545] has been extended by [RFC8607] > to handle server-side management and stripping of inline data and to > provide additional data about the attachment (size, filename etc). > > Additionally clients may choose to handle attachments differently > from the LINK property as attachments are often an integral part > of the message - for example, the agenda. > --------------------------- > > > > > > Section 1.5 > > > > To facilitate offline display the link type may identify important > > pieces of data which should be downloaded in advance. > > > > In general, the calendar entity should be self explanatory without > > the need to download referenced meta-data such as a web page. > > > > I'm not sure how to relate these two statements. It sounds like a " > > may happen, but in general don't do " scenario, in which case it might > > flow better to give the general advice first, followed by the specific > > scenario in which there is an exception to the general guidance. > It does read better - changed > > > > Section 2 > > > > The actual reference value can take three forms specified by the type > > parameter > > > > Is this list fixed for eternity or do we want to give some guidance that > > implementations need to prepare for future extensibility? > > > > REFERENCE: In an XML environment it may be necessary to refer to a > > > > This qualification in the description ("XML environment") suggests that > > perhaps the name being used for these semantics is an overly generic name. > > Having reread the text section has a number of problems, e.g - it's not > "type" - it's the VALUE parameter. I think the title is wrong - this is > really about LINK property references so I'll change the title. Also > LINK has no default type and - to get ahead a little - in the LINK > definition VALUE-TEXT should be VALUE=UID. > > Your point about REFERENCE stands - I'll change it to XML-REFERENCE > elsewhere. > > I'll update the text and get a new version out. > > I've added some text to point out that UID references may need updating > on import and export. > > > > > Section 4 > > > > We do have some text here about the GAP parameter that specifies the lead > > or lag time here, but then we go on to describe the various RELTYPE values > > in language like "cannot start until", "can only be completed after", > > etc., that is very absolute and does not acknowledge the potential for a > > GAP. I think it would be helpful to reframe as that we are making a > > comparison between the indicated pair of events, and that the relationship > > between when the events occur is affected by the GAP interval. > > (Also, the text in this section on the GAP parameter doesn't give a great > > sense that the lead time would be a negative gap.) > Rather than reframe I'll add a note and a couple of examples of the > relationships with a GAP parameter. > > > > Section 5 > > > > RELTYPE=FIRST: Indicates that the referenced calendar component is > > the first in a series the referenced calendar component is part > > of. > > > > I wonder if we want to explicitly contrast this with PARENT and provide an > > example of them being different. > > I added this to allow jscalendar and icalendar events to be mapped. > Unfortunately I omitted to add RELTYPE=NEXT. > > I'll add the NEXT relation, > > The difference is that PARENT, CHILD and SIBLING relationships are about > hierarchy and FIRST, NEXT about order. I can add some text. > > > > > Section 6.1 > > > > In addition to the values defined here any value defined in > > [RFC8288] may be used. However these uses SHOULD be documented in > > an RFC updating both [RFC5545] and [RFC8288] > > > > In some sense this feels a little like saying "the current document SHOULD > > have documented this stuff, but we didn't". Is there anything useful to > > say about why this documenting can't be done now? (Oh, I guess there are > > rather more values in the registry than I remembered, though the number of > > them actually defined in RFC 8288 might be zero?) > > In response to other comments I cut this back to > > In addition to the value defined here any link relation > in the link registry established by [RFC8288], > or new link relations, may be used. > > but I'm a little uneasy about that. Maybe add the text ", but should be > documented in an RFC" at the end? > > It seems to me that we should at least document how these are to be used > in a calendaring environment. Maybe something like "It is expected that link relation types seeing significant usage in calendaring will have the calendaring usage described in an RFC"? There are probably a lot of different approaches here, and I have no strong sense of which would be "best". > > > > Section 8.1 > > > > Conformance: This property can be specified zero or more times in > > any iCalendar component. > > [...] > > Within the "VEVENT", "VTODO", or "VJOURNAL" calendar components, > > more than one formal category can be specified by using multiple > > CONCEPT properties. > > > > Are these two statements fully compatible? The former seems to give > > leeway to put multiple CONCEPT properties in any iCalendar component, but > > the latter seems to limit to the "more than one" ability to just the three > > named components. > I suspect that's something that remained after a copy/paste exercise. > The paragraph naming components should go - it just repeats what was > written before it. > > > > Section 8.2 > > > > I am not entirely sure when the TEXT value type would be used. If it's > > just there to allow for certain types of extensibility, that might be > > worth stating specifically. > That should have been VALUE=UID. > > > > There is no mapping for [RFC8288] "title*", "anchor", "rev" or > > "media". > > > > Maybe "there is currently no mapping"? Or is the definition of such > > mapping prevented for some technical reason(s)? > They don't work or have meaning in the calendar context > > > > Section 9 > > > > This specification updates the RELATED-TO property defined in > > Section 3.8.4.5 of [RFC5545]. > > > > I'd consider adding a note that "the contents of Section 9.1 below replace > > Section 3.8.4.5 of [RFC5545]" to clarify the relationship between the two > > sections. > Done > > > > Section 9.1 > > > > By default, the property value points to another calendar > > component that has a PARENT relationship to the referencing > > object. The "RELTYPE" property parameter is used to either > > explicitly state the default PARENT relationship type to the > > referenced calendar component or to override the default PARENT > > relationship type and specify either a CHILD or SIBLING > > relationship or a temporal relationship. > > > > We allow some new relationship types that are neither CHILD/SIBLING nor > > temporal (e.g., CONCEPT, REFID). Should those get some text in the > > description too? (I am not sure if DEPENDS-ON and FIRST should get lumped > > in as "temporal", either -- we don't do so in §5.) > > I'll change that to > > relationship type and specify some other relationship. > > I'll add some text for the other types. > > > > The FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTART > > relationships define temporal relationships as specified in the > > reltype parameter definition. > > > > Likewise here, it seems some more discussion is in order for the other > > relationship types. > > > > Changes to a calendar component referenced by this property can > > have an implicit impact on the related calendar component. For > > > > Do we want to say anything about changes to a component referenced by this > > property using any of the new relationship types? > I've added a paragraph to explicitly mention the possibility of broken > links. > > > > Section 10 > > > > Many thanks for referencing the URI security considerations and calling > > out "reliability and consistency"! > > > > We might say that the security considerations of RFC 5545 continue to > > apply. > > > > There are perhaps some privacy considerations if a user uses the new > > CATEGORY or REFID functionality to expose information about a related > > group of events, but it's a little hard to concoct a scenario where this > > information gets to an attacker other than the calendar server, which is > > already in something of a trusted position with respect to the user. > > > > Are there any considerations about the new linking and relation operators > > exposing information to other users about calendar components that they're > > not authorized to access? > > > > Very large "gap" parameters seem likely to lead to unexpected behavior. > > > > NITS > > > > Section 1.4 > > > > iCalendar component. This new LINK property is closely aligned to > > the LINK header defined in [RFC8288] > > > > There are probably some pedantic distinctions that could be made here > > relating to how RFC 8288 defines the generic concept of Web Linking (which > > is not intrinsically tied to HTTP), as well as its expression in an HTTP > > header *field*. > > How about: > > component. This new LINK property is closely aligned to > RFC8288 which defines the generic concept > of Web Linking as well as its expression in the HTTP LINK header > field. Looks good, thanks. > > Also, please put a full stop at the end of the sentence. > Done > > > > The ATTACH property defined in [RFC5545] is being extended to handle > > server-side management and stripping of inline data. [...] > > > > It's hard (at least on first read) to tell if this sentence is referring > > to the RFC 8607 work or something being done by this document. > ...is being extended in other specifications to handle > > > > Clients may > > choose to handle attachments differently from the LINK property as > > they are often an integral part of the message - for example, the > > agenda. > > > > Please clarify whether "they" refers to attachments of the LINK property. > > The singular/plural signal implies it's "attachments" but we could > > probably be more clear to the reader. > > > > Also, two hyphens for an em dash. > replaced "they" with "attachments" > > > > Section 4 > > > > This section defines the usual temporal relationships for use with > > > > What's the context behind "usual"? I don't remember (but may have missed) > > a previous reference giving context for temporal relationships. > > Maybe I should remove "the usual". Looking at things liek > > https://project-management.info/pdm-precedence-diagramming-method/ > > these relationships are almost universal - but I don't know what could > be considered a standard. That organization does appear to create > standards but I don't know I can go much beyond saying "widely used". > > > > > RELTYPE=FINISHTOFINISH: Task-B can only be completed after Task-A is > > finished. The related tasks may run in parallel before > > completion. > > > > For example, if the goal is to prepare a meal, we start the > > potatoes, then the meat then the peas but they should all be > > cooked at the same time. > > > > This doesn't look like a great example for "finish-to-finish", as we > > prefer all things to finish at the same time, rather than with a strict > > ordering between end times. > > In finish-to-finish we're trying to express that one task cannot be > completed until another task has completed. Both may run concurrently > but it's the end of both that matters. Perhaps this is a better example? > > ------------ New -------------- > > For example, in the development of two related pieces of software, e.g. > the api and the implementation, the design of the implementation (B) > cannot be completed until the design of the api (A) has been completed. > > ------------------------------- I like it better, at least. > > > > Section 6.1 > > > > Registration: These relation types are registered in [RFC8288] > > > > I think we mean '''registered in the "Link Relation Types" registry > > established by [RFC8288]'''. > Yes > > > > Section 8.2 > > > > Property Parameters: The VALUE parameter is required. Non-standard, > > reference type or format type parameters can also be specified on > > this property. The LABEL parameter is defined in [RFC7986] > > > > I'm not sure I see what in the ABNF would correspond to the "reference > > type" parameters. The closest seems to be the linkrelparam, but that's a > > relation type, not a reference type. > > I think it should be > > Property Parameters: The VALUE parameter is required. > Non-standard, link relation type, > format type, label and language parameters can also be > specified on this property. The LABEL parameter > is defined in [RFC7986] Ok, that does seem easier for me to make sense of. Thanks again for all the good stuff here, Ben > > > > Section 9.1 > > > > Looking at the diff from RFC 5545, we should title case "Property Name" > > and "Value Type". We also have changed the order in which we list the > > options for property parameters but that seems unimportant. > OK > > > > Section 11.1 > > > > The following iCalendar property names have been added to the > > iCalendar Properties Registry defined in Section 8.3.2 of [RFC5545] > > > > Pedantically, RELATED-TO is not "added" but is rather covered by the "has > > added a reference to this document where ... have been updated by this > > document". So if we were to keep this phrasing we might make two tables, > > or we could try to fudge the wording here a bit. > > > > > > > > _______________________________________________ > > calsify mailing list > > calsify@ietf.org > > https://www.ietf.org/mailman/listinfo/calsify From nobody Mon Mar 7 12:47:34 2022 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 842EC3A0A8D; Mon, 7 Mar 2022 12:47:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <164668603849.23491.17498187189179804603@ietfa.amsl.com> Date: Mon, 07 Mar 2022 12:47:18 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-serverside-subscriptions-02.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 20:47:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : Serverside Subscriptions Author : Michael Douglass Filename : draft-ietf-calext-serverside-subscriptions-02.txt Pages : 11 Date : 2022-03-07 Abstract: This specification provides a mechanism whereby subscriptions to external resources can be handled by the server. This specification updates RFC4791 to add new properties for the MKCOL request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-serverside-subscriptions/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-calext-serverside-subscriptions-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-serverside-subscriptions-02 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Mar 7 13:16:25 2022 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A87723A0C1F; Mon, 7 Mar 2022 13:16:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <164668777864.9645.17931017317615930772@ietfa.amsl.com> Date: Mon, 07 Mar 2022 13:16:18 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-ical-tasks-02.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 21:16:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : Task Extensions to iCalendar Authors : Adrian Apthorp Michael Douglass Filename : draft-ietf-calext-ical-tasks-02.txt Pages : 31 Date : 2022-03-07 Abstract: This document defines extensions to the Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC5545) to provide improved status tracking, scheduling and specification of tasks. It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC 4791) servers can be extended to support certain automated task management behaviours. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-ical-tasks/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-calext-ical-tasks-02.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-ical-tasks-02 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Mon Mar 7 20:10:14 2022 Return-Path: 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 248AF3A0D3A for ; Mon, 7 Mar 2022 20:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 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, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=fastmailteam.com header.b=R6nW7bpH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=i3q0H/4C 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 F1rohluav0Sw for ; Mon, 7 Mar 2022 20:10:07 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1893A0D39 for ; Mon, 7 Mar 2022 20:10:06 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id CF0203201DA0; Mon, 7 Mar 2022 23:10:05 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute4.internal (MEProxy); Mon, 07 Mar 2022 23:10:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; bh=BILOVfEDk1w01i 9RURn0+BArnoDwMfkysd1zTiB/H8k=; b=R6nW7bpHITMco9bPZBB5Xan9IMZzS4 HA3O//h2sC5haG48ccRDmYSNp9l+2IhjBGYKnXgr433LnQ3l2tbGdnGjKhz8iZKV VGWqP/qEzY2l6U3Nem8U0kJB8IzaPDNX8WMYjtf6NMLgPwpObASQX8i2Bk++qbN8 O2iJDsvq7eO5CKJ4JTL6nrRBz9uIHkB5lLRuSNoPTT1Y2ig0E/6dNzv/ZSdLnKki VWVcNN5vqiBlulqgLVuKLNSAhBC98rOSImxC+uqr5gIxf9RRVT6fqjP2FvBNoNKV t92OCiZDWkFoFl4zoMl4kKwUoXX/SKFaKyyf9ZpgVSQZKmoVCJeR8h4Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=BILOVfEDk1w01i9RU Rn0+BArnoDwMfkysd1zTiB/H8k=; b=i3q0H/4C8b2NaFqqQb+SJfH5nCi8HwtAf fblQ26vyNrBn/qhxe4lRQmOT1ENiuGDRz8NOierZQ2RHVJgKuVU4+Ac37rmD/RwX y1oB5yOSD4lHa21333BwjVegh6/ryzbXI5YZq2QFqlS3Qj6NO4TZCsw4cNNsYiBa 8nzUjAHohjxifkogzfljJwSGdw07XhqRHP2g1OTuuNBB5/VFDOWrJ4OejfHcFGi9 ZRM1RHRFLosTPeqTmALRBhvmm+MuMoVlLKrQ1Ul0okNq0424kOB5cem9YWva5d3w Mzpijxspoje55OwFCDtmkudpgfk6fE9hFmQC20XkceAml903hs9cw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudduhedgieehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeevvdetvdduleekhfeghfetfeettdelhfehfeevffevleek uddtudffieevjeevhfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CA823AC0E98; Mon, 7 Mar 2022 23:10:04 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4869-g350fa62b48-fm-20220307.001-g350fa62b Mime-Version: 1.0 Message-Id: In-Reply-To: <20220307164209.7A5C4E43B4@rfc-editor.org> References: <20220307164209.7A5C4E43B4@rfc-editor.org> Date: Tue, 08 Mar 2022 15:09:44 +1100 From: "Neil Jenkins" To: rfc-editor , "Robert Stepanek" , "Murray S. Kucherawy" , "Francesca Palombini" , "Bron Gondwana" , "Daniel Migault" Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary=d2e43211ba214b00bebc009724dde7d1 Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC8984 (6873) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2022 04:10:12 -0000 --d2e43211ba214b00bebc009724dde7d1 Content-Type: text/plain On Tue, 8 Mar 2022, at 3:42 AM, RFC Errata System wrote: > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. I'm not sure who the verifying party is for this, but I agree with this erratum. Cheers, Neil. --d2e43211ba214b00bebc009724dde7d1 Content-Type: text/html
On Tue, 8 Mar 2022, at 3:42 AM, RFC Errata System wrote:
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

I'm not sure who the verifying party is for this, but I agree with this erratum.

Cheers,
Neil.
--d2e43211ba214b00bebc009724dde7d1-- From nobody Mon Mar 7 20:19:07 2022 Return-Path: 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 E82163A0D8D for ; Mon, 7 Mar 2022 20:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 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, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=fastmailteam.com header.b=YlgKKciA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dleNtXGd 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 jqVKEGxn2Vpe for ; Mon, 7 Mar 2022 20:19:01 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECCA3A0D7E for ; Mon, 7 Mar 2022 20:19:01 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 2F9FA3200973; Mon, 7 Mar 2022 23:19:00 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute4.internal (MEProxy); Mon, 07 Mar 2022 23:19:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; bh=4h94HAzjsaaWVo 9TWShPwsVJadICjPNogzZee2fPdv0=; b=YlgKKciAyC4p6MznES/pCLHKhY1CYN 8JERHoUiBQgb5KNclW6OaFS2vR09DZd4laZgpvHkvBkhDBGFj01k8SA0myJltjIc xD1QLODFIXOm2yCjaGeskRZ4abyFOXBxbw6xPrtxOGp1VOB/3Ne20EG8Mgfm+Pju 2dgYsAshoUSm4QdrFB3qWJCRfcZxoHf8VYL5DYrTLOsU4/EEYxzLo/3LUhjoD2/M GOg+LCRkBnVEEvicieJrmqclxbD0H0UQyG5sYH8BU7llYW9uWWOWav1GcoK1yJwF 6eC6Vf7EhNweFDEg5Il5gczHrAda81BcYw1qn7Jbzy3XxW2JMTDWKgWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=4h94HAzjsaaWVo9TW ShPwsVJadICjPNogzZee2fPdv0=; b=dleNtXGdsmIJhUaSvNkdYFGOkho1NZY1d 1jq7JqC50Wtna07EVrngE5uRpEG873moLEykB72Kl3FXwjd4mhAeGr980zQI9qrf a8QmXPMXEWjZWZ4HCHnqpFMrruH5zdR0wzwlsPi4cZkDHscjMHG8esVyuEUD//Zi LhpywtPbj5FnPD+/3oMsMxYBlMaIpTGOZZm1ncJlIbHznC1ZtKUUvqlWEF3jb9LN F0lfsUgL7yOS6rcfF565dhrz70j6J1oyOvSgJSShSpXFQKrypmHaJR0gNmhHxnI/ vIinMLAgvbNKVXnWQI2wofpcXAZ5f3TTHVB13rlyIqNnfci8JQcwA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudduhedgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeevvdetvdduleekhfeghfetfeettdelhfehfeevffevleek uddtudffieevjeevhfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7E41EAC0E98; Mon, 7 Mar 2022 23:18:59 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4869-g350fa62b48-fm-20220307.001-g350fa62b Mime-Version: 1.0 Message-Id: In-Reply-To: <20220307163210.73B6AE52D9@rfc-editor.org> References: <20220307163210.73B6AE52D9@rfc-editor.org> Date: Tue, 08 Mar 2022 15:18:27 +1100 From: "Neil Jenkins" To: rfc-editor , "Robert Stepanek" , "Murray S. Kucherawy" , "Francesca Palombini" , "Bron Gondwana" , "Daniel Migault" Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary=16d898a448ae4a8bb635fd7e828b7e70 Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC8984 (6872) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2022 04:19:06 -0000 --16d898a448ae4a8bb635fd7e828b7e70 Content-Type: text/plain On Tue, 8 Mar 2022, at 3:32 AM, RFC Errata System wrote: > Adds the recurrenceRules and excludedRecurrenceRules properties to the list of allowed properties of private events. > > Only the combination of recurrence rules, excluded recurrence rules and recurrence overrides allows to generate the full recurrence set for this event. > > Omitting the properties was an oversight during the initial publication of this RFC. I agree with this. Robert, I think we need to explicitly state *excluded* as an allowed property too though to make it clear that this should still be included in recurrenceOverrides? Cheers, Neil. --16d898a448ae4a8bb635fd7e828b7e70 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, 8 Mar 2= 022, at 3:32 AM, RFC Errata System wrote:
Adds the recurrenceRules and excludedRecu= rrenceRules properties to the list of allowed properties of private even= ts.

Only the combination of recurrence rule= s, excluded recurrence rules and recurrence overrides allows to generate= the full recurrence set for this event.

Om= itting the properties was an oversight during the initial publication of= this RFC.

I agree with this. = Robert, I think we need to explicitly state excluded as an allowe= d property too though to make it clear that this should still be include= d in recurrenceOverrides?

Cheers,
=
Neil.
--16d898a448ae4a8bb635fd7e828b7e70-- From nobody Tue Mar 8 06:20:59 2022 Return-Path: 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 341C53A160D for ; Tue, 8 Mar 2022 06:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=fastmailteam.com header.b=StpvSknw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nnsTKxrq 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 0q7Cmgt_GkEh for ; Tue, 8 Mar 2022 06:20:52 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.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 2733C3A160E for ; Tue, 8 Mar 2022 06:20:51 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id CAA903201F1D; Tue, 8 Mar 2022 09:20:50 -0500 (EST) Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Tue, 08 Mar 2022 09:20:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; bh=xwkRNVtaxhXzE5 Hk88XaYdDt3/CUBWIJjDEi4Mv5lWI=; b=StpvSknwpkQYF+FI2LAhczToEtN1Zz Ia/6Mxs4xIDERxtBFwDO8VUL04bK7lYonYwqq+7hHPPU7EDMBpa5rbqOyDVdQO7I V+JkPdNCG50DQ8CmYsbhsbDzuU+SkzwIHk747L2o0+y4k/jqLKztbGgBmRw3VLtb lS7E9hsrrZGt4HbdAgMaZ1tinhpnhHZeY3IVH9dF34GKIY3kOwgYcWLhqTi/BdPB 5MqXieI7RelQ8I9mnAPocx44ukIQ10YdF58cnBfuHOp/4C+8TO+6OIQUOXT459So wgwdt1sRQ1Tqi7TabRzHo9JR+bHlXDS0Z8UCtT2mQY2QDYYj0feKzDUQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=xwkRNVtaxhXzE5Hk8 8XaYdDt3/CUBWIJjDEi4Mv5lWI=; b=nnsTKxrqD+pLgny7i//CA7W1rxltfysB3 kyP7gI4azoLafrTXRo6RIIWdxywU46M/Fb1XvzZeUkF27yun6YGkUIKWAnVoYyf6 CrO3TYC6P3mbpB5pkLniS2FTS355qF5Bfvxk4cBHap1erSFO4kBEruSRcD1VJs4V X2155yqeROwSjD1tjNjux15Pd+XrgQncSenI7+VhBus6B0yj7UWU2E0q0c6lAldx kycwQsrsgxuWhe2tYlYbHTUt1OxgaYpCJK09r4RUn53Cs7jXcf1qwJcLd7+emxIV Rm1SEzQNw44h1izAIPVyVDT693CG0GO4eBo3zdA0HP8MoaCN1bClg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudduiedgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdftohgs vghrthcuufhtvghprghnvghkfdcuoehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtoh hmqeenucggtffrrghtthgvrhhnpeehgeeuvddtkefhtefgueefgfdvueetgeeffeelhedv udegjeejhfetuefgveevieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E544CAC0E99; Tue, 8 Mar 2022 09:20:49 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4869-g350fa62b48-fm-20220307.001-g350fa62b Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20220307163210.73B6AE52D9@rfc-editor.org> Date: Tue, 08 Mar 2022 09:20:19 -0500 From: "Robert Stepanek" To: "Neil Jenkins" , rfc-editor , "Murray S. Kucherawy" , "Francesca Palombini" , "Bron Gondwana" , "Daniel Migault" Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary=1919a4a5930045469f1357356e5a1412 Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC8984 (6872) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2022 14:20:58 -0000 --1919a4a5930045469f1357356e5a1412 Content-Type: text/plain On Mon, Mar 7, 2022, at 11:18 PM, Neil Jenkins wrote: > I think we need to explicitly state *excluded* as an allowed property too though to make it clear that this should still be included in recurrenceOverrides? Right, need to add that! I can't figure out how to update an errata, so maybe I need to cancel this one and create a new errata? Cheers, Robert --1919a4a5930045469f1357356e5a1412 Content-Type: text/html
On Mon, Mar 7, 2022, at 11:18 PM, Neil Jenkins wrote:
I think we need to explicitly state excluded as an allowed property too though to make it clear that this should still be included in recurrenceOverrides?

Right, need to add that! I can't figure out how to update an errata, so maybe I need to cancel this one and create a new errata?

Cheers,
Robert

--1919a4a5930045469f1357356e5a1412-- From nobody Tue Mar 8 06:22:58 2022 Return-Path: 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 7D22B3A160D for ; Tue, 8 Mar 2022 06:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 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, T_SCC_BODY_TEXT_LINE=-0.01, 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 qjz2Slpn9t5c for ; Tue, 8 Mar 2022 06:22:52 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC753A15C6 for ; Tue, 8 Mar 2022 06:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1646749370; d=isode.com; s=june2016; i=@isode.com; bh=86flLheoieYCdAIO5gsWxOr+jG/qIWdFcf29jgmP+rE=; 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=rKDPdwrGdj74DKsFpCmI0pK67i5SndDjzJBZvdofUR3J78kJZueiEcLz88YstlluFRKJ55 obQUnaDvwhXavsbLCS/ll5qVzsvTH2x2gNP0kprcP9BiBeZxljwVfLk+gLs30YKuyLVHTw c22UaQBdn4HUqibmlpwoCUOfLdpaR2Q=; Received: from [192.168.1.222] (host31-49-219-119.range31-49.btcentralplus.com [31.49.219.119]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 8 Mar 2022 14:22:49 +0000 Message-ID: <352332d5-14af-9311-ce9e-c7d8e74ecb16@isode.com> Date: Tue, 8 Mar 2022 14:22:37 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 To: Robert Stepanek , Neil Jenkins , rfc-editor , "Murray S. Kucherawy" , Francesca Palombini , Bron Gondwana , Daniel Migault Cc: calsify@ietf.org References: <20220307163210.73B6AE52D9@rfc-editor.org> From: Alexey Melnikov In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------C20vN99Nj2VMp10Sd1hoJi0l" Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC8984 (6872) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Calendaring and Scheduling Standards Simplification List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2022 14:22:57 -0000 This is a multi-part message in MIME format. --------------C20vN99Nj2VMp10Sd1hoJi0l Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 08/03/2022 14:20, Robert Stepanek wrote: > On Mon, Mar 7, 2022, at 11:18 PM, Neil Jenkins wrote: >> I think we need to explicitly state *excluded* as an allowed property >> too though to make it clear that this should still be included in >> recurrenceOverrides? > > Right, need to add that! I can't figure out how to update an errata, > so maybe I need to cancel this one and create a new errata? Just ask the responsible AD to edit the text, ADs can do that. --------------C20vN99Nj2VMp10Sd1hoJi0l Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

On 08/03/2022 14:20, Robert Stepanek wrote:

On Mon, Mar 7, 2022, at 11:18 PM, Neil Jenkins wrote:
I think we need to explicitly state excluded as an allowed property too though to make it clear that this should still be included in recurrenceOverrides?

Right, need to add that! I can't figure out how to update an errata, so maybe I need to cancel this one and create a new errata?
Just ask the responsible AD to edit the text, ADs can do that. 

  


--------------C20vN99Nj2VMp10Sd1hoJi0l--


From nobody Tue Mar  8 08:06:38 2022
Return-Path: 
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 AD2BA3A0D77 for ; Mon,  7 Mar 2022 12:37:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bedework-com.20210112.gappssmtp.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 AjZ6GHIIJx1l for ; Mon,  7 Mar 2022 12:36:57 -0800 (PST)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 7F4C63A0D75 for ; Mon,  7 Mar 2022 12:36:57 -0800 (PST)
Received: by mail-qk1-x734.google.com with SMTP id 85so4952983qkm.9 for ; Mon, 07 Mar 2022 12:36:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bedework-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=f/xKBc1iyek+UlZavgDUcrOire4el3HlWmPJviHDaS8=; b=1XVL0k5DKLsFqHo8pc/rY2C7gqx0XjRpe+PWmCVO3rowyjMmdqq0BEiGAaJ+WyKLzX yhaisT41ZFOHxrHr5R2/KcNjTBYKPJhMVzWgLU7tTMygMqPOGyN0Wxrhhm2KnTJYyps3 2rZe6U6FU5ksIhvQptdkwZdN3mjd0mxWWx8j3FW2wO4qI6j0hlmNBGKICKn/JZagXMMz JvYnuEk5q/0g4GrUvQq5meWJqqnv4I3K2wLegOqw2xLSGtYxcCTBXvp5bJAiI2pK81GA Xvh3zTdccTDsswd1UDOGBBMAu6N0SOSOT/GM/vUulMBeXZLjs1JVnEc23hd3XJW4FSah Yclg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=f/xKBc1iyek+UlZavgDUcrOire4el3HlWmPJviHDaS8=; b=e47AjwJ4U9254qt7nh0qcXBUQAp4LEi3vKBgYLV41iM8IDQOizvbiZx6qiuAWiWI5w xaOAyh9asLWdE65UbzvI/ZsOnBxMYVdJep1psd+MLPVezpvVPEvzJJBCtg0yNK6WcT/7 kQ076YR3xQLWBGOvOlwZB9LN40vcpHCUAO9Zki/r63f+RTqIS7l1SbYCy5aMAO7uQ+Nn iWeQaMSIAOUkKAGARE06KeGf9k+c7MIwZYBhRY6kYbE1W22d6iUbFL4czG3Kyi1SAAj6 iT/g6r2m6neH+G5fUJyRrRQXFz2P2xJ7W+EdNY+PqwezOlMQXuzZvZvZe9tGmZknjz7c Sb4Q==
X-Gm-Message-State: AOAM5338MxzWwIZasWOkjj/npAxvXzR6uG+9UFzi1kxyG8TOQ6wbCg5y Z2yEcPtnZWEEU8Ht8oNtzZNAPEFb/48Q
X-Google-Smtp-Source: ABdhPJwTSqM+q5K6w3+vlkUeJs1Ss5yQ5b3ndHxhxzx4sAMm7K3tcF/dzwqx8FlJYf8vQKWwjTpp1g==
X-Received: by 2002:a05:620a:45a7:b0:67a:ec24:d3fc with SMTP id bp39-20020a05620a45a700b0067aec24d3fcmr7919193qkb.180.1646685415720;  Mon, 07 Mar 2022 12:36:55 -0800 (PST)
Received: from [192.168.1.151] (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.gmail.com with ESMTPSA id g7-20020a376b07000000b006492f19ae76sm6636111qkc.27.2022.03.07.12.36.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 07 Mar 2022 12:36:55 -0800 (PST)
Message-ID: 
Date: Mon, 7 Mar 2022 15:36:53 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1
Content-Language: en-US
To: Benjamin Kaduk , Michael Douglass 
Cc: The IESG , draft-ietf-calext-ical-relations@ietf.org, calsify@ietf.org, calext-chairs@ietf.org
References: <164496396877.21317.914662615752443156@ietfa.amsl.com> <6643da72-0508-3d45-1ba7-604557df2a01@gmail.com> <20220307193840.GP22457@mit.edu>
From: Michael Douglass 
In-Reply-To: <20220307193840.GP22457@mit.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
X-Mailman-Approved-At: Tue, 08 Mar 2022 08:06:37 -0800
Subject: Re: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-ical-relations-09: (with DISCUSS and COMMENT)
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Calendaring and Scheduling Standards Simplification 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 07 Mar 2022 20:37:03 -0000

Thanks Ben.

Your comments were very helpful.

I'll probably make at least one change along the lines suggested below 
but I'll wait till after the calext session

On 3/7/22 14:38, Benjamin Kaduk wrote:
> Hi Michael,
>
> Most of this looks really good, and I'll go lift my Discuss shortly.
> Just a handful of notes scattered inline...
>
> On Sun, Feb 27, 2022 at 06:10:37PM -0500, Michael Douglass wrote:
>> Thank you for your detailed response - please see below ...
>>
>> On 2/15/22 17:26, Benjamin Kaduk via Datatracker wrote:
>>
>>> ...
>>>
>>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> The ABNF for linkparam (§8.2) incorporates a "langparam" production, but
>>> that is not defined in any of this document, RFC 5455, RFC 8288, or RFC
>>> 7986.  We need to define it somehow, whether by reference or directly.
>>> RFC 5545 does define a LANGUAGE parameter (our prose references a "LANG"
>>> parameter) and languageparam ABNF production, which is perhaps the
>>> simplest explanation for what was intended.
>> Yes - it should have been languageparam - corrected
> Excellent, I'm glad it was the easy fix.
>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> A couple broad comments before getting into the section-by-section
>>> details:
>>>
>>> I'm a little unclear on the value gained by having RELTYPE=REFID and
>>> RELTYPE=CONCEPT.  If the semantics were just supposed to be "is a member
>>> of the indicated group", then why do we need a relation type to say so.
>>> But if there's some other semantics associated, where do we define those
>>> semantics?
>> The idea is to associate one entity with others without that entity
>> necessarily having the associated attribute. The semantics are more like
>> - this is an aggregator for those things with the designated REFID or
>> CONCEPT
> Ah, thanks for the extra explanation.  Perhaps I was just being a bit dense
> when I first read it; I don't really have any suggestions for how we might
> add more text that would have prevented my confusion.
>
>>> There are a number of places (e.g., §1.4) where this document uses the
>>> term "collection" in a context that suggests that it should be a defined
>>> term of iCalendar, corresponding roughly to a "site" or administrative
>>> domain, but I didn't find any usage in RFC 5545 that would correspond to
>>> what's being described here.  Can we say more about what level of grouping
>>> this is intended to refer to?
>> More of a CalDAV thing. I'll precede the first occurrence with some text
>>
>> ------ OLD -------
>>
>> It is also often necessary to reference calendar components in other
>>
>> collections.  For example, a VEVENT might refer to a VTODO from which
>>
>> ------ NEW -------
>>
>> Calendar components are often grouped into collections to represent a
>> calendar or a series of tasks, for example [RFC4791] (CalDAV) calendar
>> collections.
>>
>> It is often necessary for calendar components in one such collection
>> to reference components in other collections.  For example, a VEVENT
>> might refer to a VTODO from which...
>>
>> ------------------
>>
>>> Section 1.1
>>>
>>>      The iCalendar [RFC5545] RELATED-TO property has no support for
>>>      temporal relationships as used by standard project management tools.
>>>
>>> I am admittedly not really the target audience of this specification, but
>>> I have no idea what the "standard project management tools" are that are
>>> being referred to.  Would (informative) references to a handful be
>>> appropriate?
>> I guess I should drop 'standard' and just write
>>
>>      temporal relationships as used by project management tools.
>>
>>
>> It's really the relationships which are 'standard' in the sense they are
>> apparently used by all/most project management tools.There is also the
>> Project Management Institute which has /A Guide to the Project
>> Management Body of Knowledge /which apparently defines these terms also.
>> I'm not sure if we want a reference to that - I think it's as close as
>> we get to a standard
>> //
>>
>>> Section 1.2
>>>
>>>      REFID is used to identify a key allowing the association of
>>>      components that are related to the same object and retrieval of a
>>>      component based on this key.  [...]
>>>
>>> This says "related to the same *object*" (emphasis mine), but the rest of
>>> the section just talks about an unstructured grouping.  It seems like we
>>> could give some hint of the nature of the "object" to which all the
>>> elements of the group are related, prior to the RELTYPE=REFID definition
>>> in §5.
>> Not sure how to reword this. The examples were an attempt to define
>> that. I should probably at least stick with component instead of object.
>>
>> I've tried a bit of rewording...
>>
>> ------ OLD -------
>>
>> REFID is used to identify a key allowing the association of
>> components that are related to the same object and retrieval of a
>> component based on this key.  Two examples of how this may be used
>> are to identify the tasks associated with a given project without
>> having to communicate the task structure of the project, and to group
>> all tasks associated to a specific package in a package delivery
>> system.
>>
>> ------ NEW -------
>>
>> REFID is used to identify a key allowing the association of
>> components that are all related to the referring, aggregating component and
>> the retrieval of components based on this key.  For example, this may be used
>> to identify the tasks associated with a given project without
>> having to communicate the task structure of the project. A further example
>> is the grouping of all sub-tasks associated with the delivery of a specific
>> package in a package delivery system.
>> ------------------
>>
>>> Section 1.3
>>>
>>>      The current [RFC5545] CATEGORY property is used as a free form
>>>      'tagging' field.  [...]
>>>
>>> In light of the discussion in the previous section about grouping without
>>> semantics, we might consider mentioning here that this is "tagging with
>>> semantics", just vaguely defined ones, as opposed to the REFID-type
>>> "tagging without semantics".
>> Added some text.
>>> Section 1.4
>>>
>>>      server-side management and stripping of inline data.  Clients may
>>>      choose to handle attachments differently from the LINK property as
>>>      they are often an integral part of the message - for example, the
>>>      agenda.
>>>
>>> (See the NITS entries as well, but) is it particularly noteworthy that
>>> clients might handle LINKs different from ATTACHments?  They are different
>>> properties after all -- why would someone assume equivalent treatment?
>> I'm not sure why - but it seems worth pointing out just in case. There's
>> some degree of similarity between a LINK and an ATTACHMENT - especially
>> if the attachment value is a uri.
>>
>> Also I think when I wrote this managed attachments wasn't an RFC. I have
>> the ref but the text is vague.
>>
>> ------------ OLD ----------
>>
>> The LINK property MUST NOT be treated as just another attachment.
>> The ATTACH property defined in [RFC5545] is being extended to handle
>> server-side management and stripping of inline data.  Clients may
>> choose to handle attachments differently from the LINK property as
>> they are often an integral part of the message - for example, the
>> agenda.
>>
>> For more information on managed attachments see [RFC8607]
>>
>> ------------ NEW ----------
>>
>> The LINK property MUST NOT be treated as just another attachment.
>> The ATTACH property defined in [RFC5545] has been extended by [RFC8607]
>> to handle server-side management and stripping of inline data and to
>> provide additional data about the attachment (size, filename etc).
>>
>> Additionally clients may choose to handle attachments differently
>> from the LINK property as attachments are often an integral part
>> of the message - for example, the agenda.
>> ---------------------------
>>
>>
>>> Section 1.5
>>>
>>>      To facilitate offline display the link type may identify important
>>>      pieces of data which should be downloaded in advance.
>>>
>>>      In general, the calendar entity should be self explanatory without
>>>      the need to download referenced meta-data such as a web page.
>>>
>>> I'm not sure how to relate these two statements.  It sounds like a "
>>> may happen, but in general don't do " scenario, in which case it might
>>> flow better to give the general advice first, followed by the specific
>>> scenario in which there is an exception to the general guidance.
>> It does read better - changed
>>> Section 2
>>>
>>>      The actual reference value can take three forms specified by the type
>>>      parameter
>>>
>>> Is this list fixed for eternity or do we want to give some guidance that
>>> implementations need to prepare for future extensibility?
>>>
>>>      REFERENCE:  In an XML environment it may be necessary to refer to a
>>>
>>> This qualification in the description ("XML environment") suggests that
>>> perhaps the name being used for these semantics is an overly generic name.
>> Having reread the text section has a number of problems, e.g - it's not
>> "type" - it's the VALUE parameter. I think the title is wrong - this is
>> really about LINK property references so I'll change the title. Also
>> LINK has no default type and - to get ahead a little - in the LINK
>> definition VALUE-TEXT should be VALUE=UID.
>>
>> Your point about REFERENCE stands - I'll change it to XML-REFERENCE
>> elsewhere.
>>
>> I'll update the text and get a new version out.
>>
>> I've added some text to point out that UID references may need updating
>> on import and export.
>>
>>> Section 4
>>>
>>> We do have some text here about the GAP parameter that specifies the lead
>>> or lag time here, but then we go on to describe the various RELTYPE values
>>> in language like "cannot start until", "can only be completed after",
>>> etc., that is very absolute and does not acknowledge the potential for a
>>> GAP.  I think it would be helpful to reframe as that we are making a
>>> comparison between the indicated pair of events, and that the relationship
>>> between when the events occur is affected by the GAP interval.
>>> (Also, the text in this section on the GAP parameter doesn't give a great
>>> sense that the lead time would be a negative gap.)
>> Rather than reframe I'll add a note and a couple of examples of the
>> relationships with a GAP parameter.
>>> Section 5
>>>
>>>      RELTYPE=FIRST:  Indicates that the referenced calendar component is
>>>         the first in a series the referenced calendar component is part
>>>         of.
>>>
>>> I wonder if we want to explicitly contrast this with PARENT and provide an
>>> example of them being different.
>> I added this to allow jscalendar and icalendar events to be mapped.
>> Unfortunately I omitted to add RELTYPE=NEXT.
>>
>> I'll add the NEXT relation,
>>
>> The difference is that PARENT, CHILD and SIBLING relationships are about
>> hierarchy and FIRST, NEXT about order. I can add some text.
>>
>>> Section 6.1
>>>
>>>         In addition to the values defined here any value defined in
>>>         [RFC8288] may be used.  However these uses SHOULD be documented in
>>>         an RFC updating both [RFC5545] and [RFC8288]
>>>
>>> In some sense this feels a little like saying "the current document SHOULD
>>> have documented this stuff, but we didn't".  Is there anything useful to
>>> say about why this documenting can't be done now?  (Oh, I guess there are
>>> rather more values in the registry than I remembered, though the number of
>>> them actually defined in RFC 8288 might be zero?)
>> In response to other comments I cut this back to
>>
>> In addition to the value defined here any link relation
>> in the link registry established by [RFC8288],
>> or new link relations, may be used.
>>
>> but I'm a little uneasy about that. Maybe add the text ", but should be
>> documented in an RFC" at the end?
>>
>> It seems to me that we should at least document how these are to be used
>> in a calendaring environment.
> Maybe something like "It is expected that link relation types seeing
> significant usage in calendaring will have the calendaring usage described
> in an RFC"?  There are probably a lot of different approaches here, and I
> have no strong sense of which would be "best".
>
>>> Section 8.1
>>>
>>>      Conformance:  This property can be specified zero or more times in
>>>         any iCalendar component.
>>>      [...]
>>>         Within the "VEVENT", "VTODO", or "VJOURNAL" calendar components,
>>>         more than one formal category can be specified by using multiple
>>>         CONCEPT properties.
>>>
>>> Are these two statements fully compatible?  The former seems to give
>>> leeway to put multiple CONCEPT properties in any iCalendar component, but
>>> the latter seems to limit to the "more than one" ability to just the three
>>> named components.
>> I suspect that's something that remained after a copy/paste exercise.
>> The paragraph naming components should go - it just repeats what was
>> written before it.
>>> Section 8.2
>>>
>>> I am not entirely sure when the TEXT value type would be used.  If it's
>>> just there to allow for certain types of extensibility, that might be
>>> worth stating specifically.
>> That should have been VALUE=UID.
>>>         There is no mapping for [RFC8288] "title*", "anchor", "rev" or
>>>         "media".
>>>
>>> Maybe "there is currently no mapping"?  Or is the definition of such
>>> mapping prevented for some technical reason(s)?
>> They don't work or have meaning in the calendar context
>>> Section 9
>>>
>>>      This specification updates the RELATED-TO property defined in
>>>      Section 3.8.4.5 of [RFC5545].
>>>
>>> I'd consider adding a note that "the contents of Section 9.1 below replace
>>> Section 3.8.4.5 of [RFC5545]" to clarify the relationship between the two
>>> sections.
>> Done
>>> Section 9.1
>>>
>>>         By default, the property value points to another calendar
>>>         component that has a PARENT relationship to the referencing
>>>         object.  The "RELTYPE" property parameter is used to either
>>>         explicitly state the default PARENT relationship type to the
>>>         referenced calendar component or to override the default PARENT
>>>         relationship type and specify either a CHILD or SIBLING
>>>         relationship or a temporal relationship.
>>>
>>> We allow some new relationship types that are neither CHILD/SIBLING nor
>>> temporal (e.g., CONCEPT, REFID).  Should those get some text in the
>>> description too?  (I am not sure if DEPENDS-ON and FIRST should get lumped
>>> in as "temporal", either -- we don't do so in §5.)
>> I'll change that to
>>
>>         relationship type and specify some other relationship.
>>
>> I'll add some text for the other types.
>>>         The FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTART
>>>         relationships define temporal relationships as specified in the
>>>         reltype parameter definition.
>>>
>>> Likewise here, it seems some more discussion is in order for the other
>>> relationship types.
>>>
>>>         Changes to a calendar component referenced by this property can
>>>         have an implicit impact on the related calendar component.  For
>>>
>>> Do we want to say anything about changes to a component referenced by this
>>> property using any of the new relationship types?
>> I've added a paragraph to explicitly mention the possibility of broken
>> links.
>>> Section 10
>>>
>>> Many thanks for referencing the URI security considerations and calling
>>> out "reliability and consistency"!
>>>
>>> We might say that the security considerations of RFC 5545 continue to
>>> apply.
>>>
>>> There are perhaps some privacy considerations if a user uses the new
>>> CATEGORY or REFID functionality to expose information about a related
>>> group of events, but it's a little hard to concoct a scenario where this
>>> information gets to an attacker other than the calendar server, which is
>>> already in something of a trusted position with respect to the user.
>>>
>>> Are there any considerations about the new linking and relation operators
>>> exposing information to other users about calendar components that they're
>>> not authorized to access?
>>>
>>> Very large "gap" parameters seem likely to lead to unexpected behavior.
>>>
>>> NITS
>>>
>>> Section 1.4
>>>
>>>      iCalendar component.  This new LINK property is closely aligned to
>>>      the LINK header defined in [RFC8288]
>>>
>>> There are probably some pedantic distinctions that could be made here
>>> relating to how RFC 8288 defines the generic concept of Web Linking (which
>>> is not intrinsically tied to HTTP), as well as its expression in an HTTP
>>> header *field*.
>> How about:
>>
>> component. This new LINK property is closely aligned to
>> RFC8288  which defines the generic concept
>> of Web Linking as well as its expression in the HTTP LINK header
>> field.
> Looks good, thanks.
>
>>> Also, please put a full stop at the end of the sentence.
>> Done
>>>      The ATTACH property defined in [RFC5545] is being extended to handle
>>>      server-side management and stripping of inline data.  [...]
>>>
>>> It's hard (at least on first read) to tell if this sentence is referring
>>> to the RFC 8607 work or something being done by this document.
>> ...is being extended in other specifications to handle
>>>                                                            Clients may
>>>      choose to handle attachments differently from the LINK property as
>>>      they are often an integral part of the message - for example, the
>>>      agenda.
>>>
>>> Please clarify whether "they" refers to attachments of the LINK property.
>>> The singular/plural signal implies it's "attachments" but we could
>>> probably be more clear to the reader.
>>>
>>> Also, two hyphens for an em dash.
>> replaced "they" with "attachments"
>>> Section 4
>>>
>>>      This section defines the usual temporal relationships for use with
>>>
>>> What's the context behind "usual"?  I don't remember (but may have missed)
>>> a previous reference giving context for temporal relationships.
>> Maybe I should remove "the usual". Looking at things liek
>>
>> https://project-management.info/pdm-precedence-diagramming-method/
>>
>> these relationships are almost universal - but I don't know what could
>> be considered a standard. That organization does appear to create
>> standards but I don't know I can go much beyond saying "widely used".
>>
>>>      RELTYPE=FINISHTOFINISH:  Task-B can only be completed after Task-A is
>>>         finished.  The related tasks may run in parallel before
>>>         completion.
>>>
>>>         For example, if the goal is to prepare a meal, we start the
>>>         potatoes, then the meat then the peas but they should all be
>>>         cooked at the same time.
>>>
>>> This doesn't look like a great example for "finish-to-finish", as we
>>> prefer all things to finish at the same time, rather than with a strict
>>> ordering between end times.
>> In finish-to-finish we're trying to express that one task cannot be
>> completed until another task has completed. Both may run concurrently
>> but it's the end of both that matters. Perhaps this is a better example?
>>
>> ------------ New --------------
>>
>> For example, in the development of two related pieces of software, e.g.
>> the api and the implementation, the design of the implementation (B)
>> cannot be completed until the design of the api (A) has been completed.
>>
>> -------------------------------
> I like it better, at least.
>
>>> Section 6.1
>>>
>>>      Registration:  These relation types are registered in [RFC8288]
>>>
>>> I think we mean '''registered in the "Link Relation Types" registry
>>> established by [RFC8288]'''.
>> Yes
>>> Section 8.2
>>>
>>>      Property Parameters:  The VALUE parameter is required.  Non-standard,
>>>         reference type or format type parameters can also be specified on
>>>         this property.  The LABEL parameter is defined in [RFC7986]
>>>
>>> I'm not sure I see what in the ABNF would correspond to the "reference
>>> type" parameters.  The closest seems to be the linkrelparam, but that's a
>>> relation type, not a reference type.
>> I think it should be
>>
>>      Property Parameters:  The VALUE parameter is required.
>>            Non-standard, link relation type,
>>            format type, label and language parameters can also be
>>            specified on this property. The LABEL parameter
>>            is defined in [RFC7986]
> Ok, that does seem easier for me to make sense of.
>
> Thanks again for all the good stuff here,
>
> Ben
>
>>> Section 9.1
>>>
>>> Looking at the diff from RFC 5545, we should title case "Property Name"
>>> and "Value Type".  We also have changed the order in which we list the
>>> options for property parameters but that seems unimportant.
>> OK
>>> Section 11.1
>>>
>>>      The following iCalendar property names have been added to the
>>>      iCalendar Properties Registry defined in Section 8.3.2 of [RFC5545]
>>>
>>> Pedantically, RELATED-TO is not "added" but is rather covered by the "has
>>> added a reference to this document where ... have been updated by this
>>> document".  So if we were to keep this phrasing we might make two tables,
>>> or we could try to fudge the wording here a bit.
>>>
>>>
>>>
>>> _______________________________________________
>>> calsify mailing list
>>> calsify@ietf.org
>>> https://www.ietf.org/mailman/listinfo/calsify


From nobody Wed Mar  9 06:15:37 2022
Return-Path: 
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 851043A11DC for ; Wed,  9 Mar 2022 06:15:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level: 
X-Spam-Status: No, score=-7.107 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_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=fastmailteam.com header.b=s5zX6U/X; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CNUelR+g
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 xQF3Qu9MQaef for ; Wed,  9 Mar 2022 06:15:27 -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 E2C5D3A11C5 for ; Wed,  9 Mar 2022 06:15:04 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 355715C0136; Wed,  9 Mar 2022 09:15:04 -0500 (EST)
Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Wed, 09 Mar 2022 09:15:04 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm2; bh=1HWg5Jjxd7CxZN Cg3F9wPAchoXt4zZPzHKnW1aScB2M=; b=s5zX6U/XwOkAVBHgvVHpFzTO3Jb4RB hIDtwCXvZ489CxXoS3q/1+vgPw0rf/QNqV22+0lAuz/v0IhWlvxlN2j2bJQVXfwY Wcohd9MI/9AFvRKJhYHjSJdymKYdgkV2CmLlRYTwgKnPItukxeZxyvk57BUWlmTn WRFSNSP2Ztf9382GZe8g61fWRvZIzmQ8WYQAepNdDjGPRy8P6eLJZ30zrvEuCnQK CmzM55C56l9kThoGRbA6JbDhzaGo512Njj646L0RDRRhltxE7cIS+lChn7/B/Y+h S/J2EioiJptRKXBdlhJ8P8bTUV8BY+liqRAsQOz1L7T5Dxe9Sj/po9kA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=1HWg5Jjxd7CxZNCg3 F9wPAchoXt4zZPzHKnW1aScB2M=; b=CNUelR+gc5RfXxJTHqwRQU66dZ3oqZMa5 AZumV80ps9XXG5qkn7fFzOGFBncMk9E1kueBoUOOkUVV7xLxCpf9McbMQLaON1j/ +k7H4jDaxmVXkLVrkg8a3CJVXYIhNHbK562bcqG2BFI5si8flpdiIC17UE2X2Jm1 cqyW8f5Tekk5TByVqN3JQJLM2L7ekRD5aLoXoXt1bhjFBSQ9TiCQEUlMT1NrNG84 DvWXc/boX80XiajVaydISE9kDIjEaybv5FGuCB8dhkENgPC5Px4CabmqwMg4aA17 vxUNtqwi9ywXPqmtc9ITnnnxaFnKPb2fyjO4zjYhGHHd8hXbXnIhg==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddruddukedgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdftohgs vghrthcuufhtvghprghnvghkfdcuoehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtoh hmqeenucggtffrrghtthgvrhhnpeegffeiveffffekhfffueffieefudeiledvgffhfffh geefledtgeegueelfeelfeenucffohhmrghinheprhhftgdqvgguihhtohhrrdhorhhgne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id DDECBAC0E98; Wed,  9 Mar 2022 09:15:03 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-4878-ga4f0600aa6-fm-20220308.002-ga4f0600a
Mime-Version: 1.0
Message-Id: 
In-Reply-To: <20220307163210.73B6AE52D9@rfc-editor.org>
References: <20220307163210.73B6AE52D9@rfc-editor.org>
Date: Wed, 09 Mar 2022 09:14:43 -0500
From: "Robert Stepanek" 
To: rfc-editor , "Neil Jenkins" , "Murray S. Kucherawy" , "Francesca Palombini" , "Bron Gondwana" , "Daniel Migault" 
Cc: calsify@ietf.org
Content-Type: multipart/alternative; boundary=0d2559ec7db046168337b80a51de1b0e
Archived-At: 
Subject: Re: [calsify] [Technical Errata Reported] RFC8984 (6872)
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Calendaring and Scheduling Standards Simplification 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 09 Mar 2022 14:15:36 -0000

--0d2559ec7db046168337b80a51de1b0e
Content-Type: text/plain

Hi Francesca,

could you please update the errata text as follows? Many thanks in advance.

Corrected text:

"private":  The details of the object are hidden; only the basic time
      and metadata are shared.  The following properties MAY be shared;
      any other properties MUST NOT be shared:

      *  @type

      *  created

      *  due

      *  duration

      *  estimatedDuration

      *  excluded

      *  excludedRecurrenceRules

      *  freeBusyStatus

      *  privacy

      *  recurrenceId

      *  recurrenceIdTimeZone

      *  recurrenceOverrides (Only patches that apply to another
         permissible property are allowed to be shared.)

      *  recurrenceRules

      *  sequence

      *  showWithoutTime

      *  start

      *  timeZone

      *  timeZones

      *  uid

      *  updated

Notes
Adds the excluded, excludedRecurrenceRules, recurrenceId, reccurenceIdTimeZone and recurrenceRules properties to the list of shared properties of private events.

Only the combination of all recurrence properties allows to generate the full recurrence set for the event.

Omitting the properties was an oversight during the initial publication of this RFC.

Thanks,
Robert

On Mon, Mar 7, 2022, at 11:32 AM, RFC Errata System wrote:
> The following errata report has been submitted for RFC8984,
> "JSCalendar: A JSON Representation of Calendar Data".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6872
> 
> --------------------------------------
> Type: Technical
> Reported by: Robert Stepanek 
> 
> Section: 4.4.3.
> 
> Original Text
> -------------
>    "private":  The details of the object are hidden; only the basic time
>       and metadata are shared.  The following properties MAY be shared;
>       any other properties MUST NOT be shared:
> 
>       *  @type
> 
>       *  created
> 
>       *  due
> 
>       *  duration
> 
>       *  estimatedDuration
> 
>       *  freeBusyStatus
> 
>       *  privacy
> 
>       *  recurrenceOverrides (Only patches that apply to another
>          permissible property are allowed to be shared.)
> 
>       *  sequence
> 
>       *  showWithoutTime
> 
>       *  start
> 
>       *  timeZone
> 
>       *  timeZones
> 
>       *  uid
> 
>       *  updated
> 
> Corrected Text
> --------------
>    "private":  The details of the object are hidden; only the basic time
>       and metadata are shared.  The following properties MAY be shared;
>       any other properties MUST NOT be shared:
> 
>       *  @type
> 
>       *  created
> 
>       *  due
> 
>       *  duration
> 
>       *  estimatedDuration
> 
>       *  excludedRecurrenceRules
> 
>       *  freeBusyStatus
> 
>       *  privacy
> 
>       *  recurrenceOverrides (Only patches that apply to another
>          permissible property are allowed to be shared.)
> 
>       *  recurrenceRules
> 
>       *  sequence
> 
>       *  showWithoutTime
> 
>       *  start
> 
>       *  timeZone
> 
>       *  timeZones
> 
>       *  uid
> 
>       *  updated
> 
> Notes
> -----
> Adds the recurrenceRules and excludedRecurrenceRules properties to the list of allowed properties of private events.
> 
> Only the combination of recurrence rules, excluded recurrence rules and recurrence overrides allows to generate the full recurrence set for this event.
> 
> Omitting the properties was an oversight during the initial publication of this RFC.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC8984 (draft-ietf-calext-jscalendar-32)
> --------------------------------------
> Title               : JSCalendar: A JSON Representation of Calendar Data
> Publication Date    : July 2021
> Author(s)           : N. Jenkins, R. Stepanek
> Category            : PROPOSED STANDARD
> Source              : Calendaring Extensions
> Area                : Applications and Real-Time
> Stream              : IETF
> Verifying Party     : IESG
> 

--0d2559ec7db046168337b80a51de1b0e
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


Hi Francesca,

could you please update the errata text as f=
ollows? Many thanks in advance.

Corrected t=
ext:

"private":  The details of the object are hidden; only t=
he basic time
      and metadata are shared.  The following properties MAY be shared;
      any other properties MUST NOT be shared:

      *  @type

      *  created

      *  due

      *  duration

      *  estimatedDuration

      *  excluded

      *  excludedRecurrenceRules

      *  freeBusyStatus

      *  privacy

      *  recurrenceId

      *  recurrenceIdTimeZone

      *  recurrenceOverrides (Only patches that apply to another
         permissible property are allowed to be shared.)

      *  recurrenceRules

      *  sequence

      *  showWithoutTime

      *  start

      *  timeZone

      *  timeZones

      *  uid

      *  updated

Notes
Adds the excluded, exclude=
dRecurrenceRules, recurrenceId, reccurenceIdTimeZone and recurrenceRules=
 properties to the list of shared properties of private events.

Only the combination of all recurrence properties allows to generat=
e the full recurrence set for the event.

Omitting the properties was an oversight during the initial publication =
of this RFC.

Thanks,
Robert

On Mon, Mar 7, 2022, at 11:32 AM, RFC Errata=
 System wrote:
<=
div>The following errata report has been submitted for RFC8984,
"JSCalendar: A JSON Representation of Calendar Data".

--------------------------------------
Yo=
u may review the report below and at:

-----------------------------------=
---
Type: Technical
Reported by: Robert Step=
anek <rsto@fastmailteam.com<=
/a>>






      *  estimatedDuration

      *  excludedRecurrenc=
eRules

      *&nbs=
p; freeBusyStatus

    &=
nbsp; *  privacy

   &nb=
sp;  *  recurrenceOverrides (Only patches that apply to anothe=
r
         permiss=
ible property are allowed to be shared.)

&n=
bsp;     *  recurrenceRules

<=
/div>
      *  sequence
=

      *  showWithoutTime

      *  start<=
br>

      *  time=
Zone

      * =
 timeZones

      *=
  uid

      *=
  updated

Notes
-----
Adds the recurrenceRules and excludedRecurrenceRules propert=
ies to the list of allowed properties of private events.
<=
br>
Only the combination of recurrence rules, excluded recurre=
nce rules and recurrence overrides allows to generate the full recurrenc=
e set for this event.

Omitting the properti=
es was an oversight during the initial publication of this RFC.

Instructions:
-------------
=

This erratum is currently posted as "Reported". If necessary, pleas=
e
use "Reply All" to discuss whether it should be verified=
 or
rejected. When a decision is reached, the verifying pa=
rty  
can log in to change the status and edit t=
he report, if necessary. 

------------=
--------------------------
RFC8984 (draft-ietf-calext-jsca=
lendar-32)
--------------------------------------
Title          &=
nbsp;    : JSCalendar: A JSON Representation of Calendar =
Data
Publication Date    : July 2021
Author(s)         &=
nbsp; : N. Jenkins, R. Stepanek
Category   =
         : PROPOSED STANDARD
=

Source         &=
nbsp;    : Calendaring Extensions
Area =
;            =
;   : Applications and Real-Time
Stream &nb=
sp;            : =
IETF
Verifying Party     : IESG



--0d2559ec7db046168337b80a51de1b0e--


From nobody Thu Mar 17 06:16:06 2022
Return-Path: 
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 E2A483A11F2; Thu, 17 Mar 2022 06:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.11
X-Spam-Level: 
X-Spam-Status: No, score=-7.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 OwtwUfjdutxQ; Thu, 17 Mar 2022 06:15:46 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0614.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::614]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 831E63A120E; Thu, 17 Mar 2022 06:15:45 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IYTYzA4Yly4kCaxKJY7s9I9SgGZtP+NSPlkK+EA+WcFzVu/ZKSY/Tf84vCRGzrR8NTxXtCl4IdGgEpDukx0lHhtyAYw5xUMh4HORU6nomYRgYNVyiaQn+jyNl94TGYuYada8YX63dEscEzepZLv5rAH4f3EhslqoPAzco6d4NG4azyTkp5w/6VB+cxvVMOIX1xLvP3n0HwlVsJiqniB2hfuuGeKTsmTRFfucCnskLqL83BNLTuhgUzZI2UEC0H28xXcEbcSqNrzvmgOLcHkisNncGu5ongx+J9OZuqoITrkvlgeJlAYCW6JfuET87ohNXhhJhrDwUphTGFcgVif/EA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;  s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=maVQRwBnnnAV7bDy5NVLES45hdoubOrvoEiIK7b8yyQ=; b=JqgXq6CpeM/Ng3AWMK9XmKzvyUFkti+i/Us5rwjvDrBlNEI3F4nu3Ah+3zEnzMjVrrqrfuNETPSbjKMtNRu9Qhp9GTwl5NywN46aEKiCUsWYhUeq5YiU6yPWgHPvy+AEASpzIDm65+cvi/EwpQWwZN/WbP64oCQHRDTJUq9pwGYRCeHfJsXSzlnStmc3gCZFLznryqwTRTPEu4mwIycCZY2KBf5VRKhD2GyIhuNrmG1XAJUQvQGvMvOx0tuIijQhtP8NVtLJsmHKAWq845ffRuJ7YTVVZcargIVUfAwkur+r2PbYMHHoWrJDSROU1pmbh0D+bBk7pJon2B3+VWyLHw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=maVQRwBnnnAV7bDy5NVLES45hdoubOrvoEiIK7b8yyQ=; b=WmHTYgucK3XbS0hcIerec+bZZEwTsAWoUyEwo7qwpzHUlwLHk+JWfygrP0hwXjZuq8/TkPipjfiS72SaiYeoRlC0XMO0TP287MsozNhfNJ4PPzP57XCGqoDvniGPnxZkWl396NnN82Xd+URF0kpp0eXheM+IcCDA0OemS5KWaV8=
Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by VI1PR0701MB6989.eurprd07.prod.outlook.com (2603:10a6:800:17e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.10; Thu, 17 Mar 2022 13:15:40 +0000
Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::a10e:4f8d:2a7f:ffac]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::a10e:4f8d:2a7f:ffac%5]) with mapi id 15.20.5081.017; Thu, 17 Mar 2022 13:15:39 +0000
From: Francesca Palombini 
To: Michael Douglass , Benjamin Kaduk ,  Michael Douglass 
CC: "draft-ietf-calext-ical-relations@ietf.org" , The IESG , "calext-chairs@ietf.org" , "calsify@ietf.org" 
Thread-Topic: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-ical-relations-09: (with DISCUSS and COMMENT)
Thread-Index: AQHYIrsQNOEPVmaFQU2GrgXvspA5OqyoGP+AgAxXbwCAABBEgIAPOvsr
Date: Thu, 17 Mar 2022 13:15:39 +0000
Message-ID: 
References: <164496396877.21317.914662615752443156@ietfa.amsl.com> <6643da72-0508-3d45-1ba7-604557df2a01@gmail.com> <20220307193840.GP22457@mit.edu> 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 226f3c93-0836-4a44-de53-08da08183ba5
x-ms-traffictypediagnostic: VI1PR0701MB6989:EE_
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LwH9T/Gnb4upFNO4yHZ08pAunVSbTCc+x1i0VzHJhvdF7TpbI9516TSHYXyYQS66SYyGEpIMZtgWyc/GTVQQsDnwjNK6X0r2VMcwPBBeCeNeCldxOC2VvzZS5P3VL06XnNdUOVHfRwWvPB1Ipuo9k7zN0YkO6TzAzFOzVW0bYs0gfsPE46xn84WP3nuSvb0Hr0+Wk83e8O9dlWkMfgchMCqBkQV8mW9Br1h4wQ87VSGFQWosiIMirYYqjsWSuwabXqesn8xaotsAK/q21PL5QPgbA/4lQ0kD3VsvKVNEQ2pvp2tBys8dCHX7hdnIKjISnzT2Q6t/sB6fAOgaMtngZPxPymeyKDBZD8qdcopicT4G8pjtIJZKd/hj2rlRp29/vW99idq4VT5hTeSxzaIT7Bdf3UP6R5+w2jAws1I3o5/fTgMOqNFycHsDKp899ShkVJwPpMrBS8LZVByoDsKLNa9JSfQgK8I+uW1//BmEPo/VyHQFBKc1VZWnwDSfesffwcNOJhfoxld5aWdHvkepbtMaJs4EzOBhLpyU7MG6jFvUKR/L6NIV4lGSMIUs0W1prWhC8tWn+y3D/5wa0k2iHYQ9rajugmkKPJ1lgirOyZ4XhdicBMufpTlzeLTMec52X2+AkvZ0MJN3XiGPae6izsWQzcGU5Mr1rwD9Z8Ywheu/lWFNhajckoN5oZpYSd0lAQ8+Rf5ist/mregIZUb+0I9VoiglFh5wj9kdmEFmU6m66kkWKf8L5QuzUXJJTb30f5bv4piqCY5tN4TTV71GC8XbDFdHBu4lyaKf6FVOeZE=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;  IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE;  SFS:(13230001)(4636009)(366004)(91956017)(86362001)(7696005)(6506007)(8676002)(66946007)(64756008)(66446008)(66476007)(66556008)(76116006)(4326008)(53546011)(82960400001)(966005)(122000001)(71200400001)(38070700005)(316002)(54906003)(110136005)(508600001)(38100700002)(83380400001)(166002)(9686003)(186003)(52536014)(5660300002)(8936002)(44832011)(2906002)(30864003)(33656002)(55016003); DIR:OUT; SFP:1101; 
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?d5yQG6dD9GwVnr3qswreNSTGoi5rx4ep69wMp+5qtYF+SkEe2z/117mC?= =?Windows-1252?Q?8eU0PpVBk8XR4dDi5uiWzrghmscBL0B98eCH4kB+Qn7804pveDK0Ufs+?= =?Windows-1252?Q?22ZQptv3ZK7n5SA7+2SDRBKv4JOJarB6TGNseYLIuVRxJS+iEStKftGa?= =?Windows-1252?Q?SPvd0Q9KYU+e6R0CgyTjcl1pRmGwrvjiSbDcJ3pbTW7GH0Va1U5GE+cx?= =?Windows-1252?Q?QF9sgNqxSd/UHU5ZvhjoOmCzIYMeztQrOM1mDr0xv6BnTR5xTq6fkaXN?= =?Windows-1252?Q?G+lsgM0D1lVug7eR0edFTJTax9ePl0Yf1oyMTie27at22OT2ZZqXAEHs?= =?Windows-1252?Q?s8gMbh3v6d92tlMH8s39e9HpThw9iTcQ0/sp38+RzwpVC9bbJHiK8gRO?= =?Windows-1252?Q?LhcsgJheBIOnEJeq8e57bCpbSWEFBtdE+lJnEEu7Dh+gIN9IEBcQWdc4?= =?Windows-1252?Q?1RsuBaaI8eMMha+ApKL9pXj3QN4lSVMtexe+t2IhnyVs4V0CgDvinMV5?= =?Windows-1252?Q?D+VCKQg7q+Tjl6jYmciPwQoBQ+EMZu12pTwffjeqhc8VcqCM4Hd7gUJO?= =?Windows-1252?Q?3o8qHuQd+lK4R9q9m4pvEypf5Ky1k609bZaZHsDdNcKU1pM5Nidmto8t?= =?Windows-1252?Q?T0wNy0/XX5g3R1fJeiRNk5ZijCJsOKk/cyENE7I6DVZq0iF6Z76Vn2YV?= =?Windows-1252?Q?kSdkbUrTjGkKyyizPA0STJELvwHHVs+ew/oq39V/7h9m34ThWffJBO5J?= =?Windows-1252?Q?LBoMR4DpFcMAraW3DsYQYo8xTRYe23Omq8jfHfLFc3zAlt7KGTBeJfqC?= =?Windows-1252?Q?iFOHYmHEZ0/LMaSFMHxPyw/d8aKA6zOzMpTrE2QvmGmuioRDWgAwn43u?= =?Windows-1252?Q?AJ5DWgRNQX4fECNELiX0Q64OX84CtEIVpNAl8u0dbQQWNmc52oHStjet?= =?Windows-1252?Q?ncD0FQmYraGiCe9h9Wj/Ml4UkZWkxTw2QoCNpJD/0daOwCWURlQmCtcM?= =?Windows-1252?Q?WCJWA9ckKSVJAvBd9QiwYyfnko4+nSzgAksPZ9j5u7d9FM6p1ePCMqWB?= =?Windows-1252?Q?IV+yVXGkhcmfsbqI21xpar01SzqD5YYeFyS9ROY1yLiXgdcuqQ91UwzP?= =?Windows-1252?Q?RpJwmLeFeryx5aMxSTrluB/seSQiLfewETJaIhNUoUR9oOBfpeyGYqSA?= =?Windows-1252?Q?D3Lo/8f6ChM8bq9z/4IH18pbDW2SsNeBCKevRiicJ5XyTj8S2i+BMExa?= =?Windows-1252?Q?/aLW8hPkhOXSgEWbtlmAjCHIgQhwE+rwyWjuk4D+1bfh0gP2mJwWH2d4?= =?Windows-1252?Q?j3Clb7GuTvxRTZDAdUGwTIZuFVLkD67JBLt+HlEHPSo4wnSASs/BBbTf?= =?Windows-1252?Q?qEDz2320xXyiT+B6dBp177jlTznMKGWViCTZ7S9tozAXvzEJAdtwdX+5?= =?Windows-1252?Q?yUWga6WTLfqJczCDVSd1/h7qv7S666iU/7gFRCk1/pETCcEnHj07XPw3?= =?Windows-1252?Q?kvr70kPYOfFR6Od2vhUhWY7Buj5N+1JguOiS8BdJ/0baTDap+954RuVp?= =?Windows-1252?Q?guTv2Viu4OJpZotrlJlGlSx3rO7ZOUXEYzJO+dnrpoKUIOOubLuhr4kE?= =?Windows-1252?Q?yJhOqaayAN0mUyONi1DwYPkm3kMdibTCt0sBagAio7Dz1/3Yhuak/F0K?= =?Windows-1252?Q?RZY2s/OGjoDnK/Cr0nOXvF5zYHzrc2Uw?=
Content-Type: multipart/alternative; boundary="_000_HE1PR07MB42176DEA5394FCB69E0E5D8998129HE1PR07MB4217eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 226f3c93-0836-4a44-de53-08da08183ba5
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2022 13:15:39.5091 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: I6z0irCo8QiL8sUOmgwooLJ88Wj85riLv/JENOYlBq+jkaJeholVBjmlFRZvZVXSQyRN6RGzWbiThr4jffuzFP3YT6vIfuOuhbDZmBlbdcgjEi8GAPZXzPyB9WnDWhKC
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB6989
Archived-At: 
Subject: Re: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-ical-relations-09: (with DISCUSS and COMMENT)
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Calendaring and Scheduling Standards Simplification 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Mar 2022 13:15:53 -0000

--_000_HE1PR07MB42176DEA5394FCB69E0E5D8998129HE1PR07MB4217eurp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Indeed, thank you very much Ben for the thoughtful review.

Mike: I will mark this as =93revised ID needed=94 while waiting for the las=
t (final) update with this minor change, then when v-11 is posted I=92ll se=
nd this forward to the RFC Editor.

Thanks for the good work!
Francesca

From: iesg  on behalf of Michael Douglass 
Date: Monday, 7 March 2022 at 21:40
To: Benjamin Kaduk , Michael Douglass 
Cc: draft-ietf-calext-ical-relations@ietf.org , The IESG , calext-chairs@ietf.org , calsify@ietf.org 
Subject: Re: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-ical-r=
elations-09: (with DISCUSS and COMMENT)
Thanks Ben.

Your comments were very helpful.

I'll probably make at least one change along the lines suggested below
but I'll wait till after the calext session

On 3/7/22 14:38, Benjamin Kaduk wrote:
> Hi Michael,
>
> Most of this looks really good, and I'll go lift my Discuss shortly.
> Just a handful of notes scattered inline...
>
> On Sun, Feb 27, 2022 at 06:10:37PM -0500, Michael Douglass wrote:
>> Thank you for your detailed response - please see below ...
>>
>> On 2/15/22 17:26, Benjamin Kaduk via Datatracker wrote:
>>
>>> ...
>>>
>>>
>>> ----------------------------------------------------------------------
>>> DISCUSS:
>>> ----------------------------------------------------------------------
>>>
>>> The ABNF for linkparam (=A78.2) incorporates a "langparam" production, =
but
>>> that is not defined in any of this document, RFC 5455, RFC 8288, or RFC
>>> 7986.  We need to define it somehow, whether by reference or directly.
>>> RFC 5545 does define a LANGUAGE parameter (our prose references a "LANG=
"
>>> parameter) and languageparam ABNF production, which is perhaps the
>>> simplest explanation for what was intended.
>> Yes - it should have been languageparam - corrected
> Excellent, I'm glad it was the easy fix.
>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> A couple broad comments before getting into the section-by-section
>>> details:
>>>
>>> I'm a little unclear on the value gained by having RELTYPE=3DREFID and
>>> RELTYPE=3DCONCEPT.  If the semantics were just supposed to be "is a mem=
ber
>>> of the indicated group", then why do we need a relation type to say so.
>>> But if there's some other semantics associated, where do we define thos=
e
>>> semantics?
>> The idea is to associate one entity with others without that entity
>> necessarily having the associated attribute. The semantics are more like
>> - this is an aggregator for those things with the designated REFID or
>> CONCEPT
> Ah, thanks for the extra explanation.  Perhaps I was just being a bit den=
se
> when I first read it; I don't really have any suggestions for how we migh=
t
> add more text that would have prevented my confusion.
>
>>> There are a number of places (e.g., =A71.4) where this document uses th=
e
>>> term "collection" in a context that suggests that it should be a define=
d
>>> term of iCalendar, corresponding roughly to a "site" or administrative
>>> domain, but I didn't find any usage in RFC 5545 that would correspond t=
o
>>> what's being described here.  Can we say more about what level of group=
ing
>>> this is intended to refer to?
>> More of a CalDAV thing. I'll precede the first occurrence with some text
>>
>> ------ OLD -------
>>
>> It is also often necessary to reference calendar components in other
>>
>> collections.  For example, a VEVENT might refer to a VTODO from which
>>
>> ------ NEW -------
>>
>> Calendar components are often grouped into collections to represent a
>> calendar or a series of tasks, for example [RFC4791] (CalDAV) calendar
>> collections.
>>
>> It is often necessary for calendar components in one such collection
>> to reference components in other collections.  For example, a VEVENT
>> might refer to a VTODO from which...
>>
>> ------------------
>>
>>> Section 1.1
>>>
>>>      The iCalendar [RFC5545] RELATED-TO property has no support for
>>>      temporal relationships as used by standard project management tool=
s.
>>>
>>> I am admittedly not really the target audience of this specification, b=
ut
>>> I have no idea what the "standard project management tools" are that ar=
e
>>> being referred to.  Would (informative) references to a handful be
>>> appropriate?
>> I guess I should drop 'standard' and just write
>>
>>      temporal relationships as used by project management tools.
>>
>>
>> It's really the relationships which are 'standard' in the sense they are
>> apparently used by all/most project management tools.There is also the
>> Project Management Institute which has /A Guide to the Project
>> Management Body of Knowledge /which apparently defines these terms also.
>> I'm not sure if we want a reference to that - I think it's as close as
>> we get to a standard
>> //
>>
>>> Section 1.2
>>>
>>>      REFID is used to identify a key allowing the association of
>>>      components that are related to the same object and retrieval of a
>>>      component based on this key.  [...]
>>>
>>> This says "related to the same *object*" (emphasis mine), but the rest =
of
>>> the section just talks about an unstructured grouping.  It seems like w=
e
>>> could give some hint of the nature of the "object" to which all the
>>> elements of the group are related, prior to the RELTYPE=3DREFID definit=
ion
>>> in =A75.
>> Not sure how to reword this. The examples were an attempt to define
>> that. I should probably at least stick with component instead of object.
>>
>> I've tried a bit of rewording...
>>
>> ------ OLD -------
>>
>> REFID is used to identify a key allowing the association of
>> components that are related to the same object and retrieval of a
>> component based on this key.  Two examples of how this may be used
>> are to identify the tasks associated with a given project without
>> having to communicate the task structure of the project, and to group
>> all tasks associated to a specific package in a package delivery
>> system.
>>
>> ------ NEW -------
>>
>> REFID is used to identify a key allowing the association of
>> components that are all related to the referring, aggregating component =
and
>> the retrieval of components based on this key.  For example, this may be=
 used
>> to identify the tasks associated with a given project without
>> having to communicate the task structure of the project. A further examp=
le
>> is the grouping of all sub-tasks associated with the delivery of a speci=
fic
>> package in a package delivery system.
>> ------------------
>>
>>> Section 1.3
>>>
>>>      The current [RFC5545] CATEGORY property is used as a free form
>>>      'tagging' field.  [...]
>>>
>>> In light of the discussion in the previous section about grouping witho=
ut
>>> semantics, we might consider mentioning here that this is "tagging with
>>> semantics", just vaguely defined ones, as opposed to the REFID-type
>>> "tagging without semantics".
>> Added some text.
>>> Section 1.4
>>>
>>>      server-side management and stripping of inline data.  Clients may
>>>      choose to handle attachments differently from the LINK property as
>>>      they are often an integral part of the message - for example, the
>>>      agenda.
>>>
>>> (See the NITS entries as well, but) is it particularly noteworthy that
>>> clients might handle LINKs different from ATTACHments?  They are differ=
ent
>>> properties after all -- why would someone assume equivalent treatment?
>> I'm not sure why - but it seems worth pointing out just in case. There's
>> some degree of similarity between a LINK and an ATTACHMENT - especially
>> if the attachment value is a uri.
>>
>> Also I think when I wrote this managed attachments wasn't an RFC. I have
>> the ref but the text is vague.
>>
>> ------------ OLD ----------
>>
>> The LINK property MUST NOT be treated as just another attachment.
>> The ATTACH property defined in [RFC5545] is being extended to handle
>> server-side management and stripping of inline data.  Clients may
>> choose to handle attachments differently from the LINK property as
>> they are often an integral part of the message - for example, the
>> agenda.
>>
>> For more information on managed attachments see [RFC8607]
>>
>> ------------ NEW ----------
>>
>> The LINK property MUST NOT be treated as just another attachment.
>> The ATTACH property defined in [RFC5545] has been extended by [RFC8607]
>> to handle server-side management and stripping of inline data and to
>> provide additional data about the attachment (size, filename etc).
>>
>> Additionally clients may choose to handle attachments differently
>> from the LINK property as attachments are often an integral part
>> of the message - for example, the agenda.
>> ---------------------------
>>
>>
>>> Section 1.5
>>>
>>>      To facilitate offline display the link type may identify important
>>>      pieces of data which should be downloaded in advance.
>>>
>>>      In general, the calendar entity should be self explanatory without
>>>      the need to download referenced meta-data such as a web page.
>>>
>>> I'm not sure how to relate these two statements.  It sounds like a "
>>> may happen, but in general don't do " scenario, in which case it mig=
ht
>>> flow better to give the general advice first, followed by the specific
>>> scenario in which there is an exception to the general guidance.
>> It does read better - changed
>>> Section 2
>>>
>>>      The actual reference value can take three forms specified by the t=
ype
>>>      parameter
>>>
>>> Is this list fixed for eternity or do we want to give some guidance tha=
t
>>> implementations need to prepare for future extensibility?
>>>
>>>      REFERENCE:  In an XML environment it may be necessary to refer to =
a
>>>
>>> This qualification in the description ("XML environment") suggests that
>>> perhaps the name being used for these semantics is an overly generic na=
me.
>> Having reread the text section has a number of problems, e.g - it's not
>> "type" - it's the VALUE parameter. I think the title is wrong - this is
>> really about LINK property references so I'll change the title. Also
>> LINK has no default type and - to get ahead a little - in the LINK
>> definition VALUE-TEXT should be VALUE=3DUID.
>>
>> Your point about REFERENCE stands - I'll change it to XML-REFERENCE
>> elsewhere.
>>
>> I'll update the text and get a new version out.
>>
>> I've added some text to point out that UID references may need updating
>> on import and export.
>>
>>> Section 4
>>>
>>> We do have some text here about the GAP parameter that specifies the le=
ad
>>> or lag time here, but then we go on to describe the various RELTYPE val=
ues
>>> in language like "cannot start until", "can only be completed after",
>>> etc., that is very absolute and does not acknowledge the potential for =
a
>>> GAP.  I think it would be helpful to reframe as that we are making a
>>> comparison between the indicated pair of events, and that the relations=
hip
>>> between when the events occur is affected by the GAP interval.
>>> (Also, the text in this section on the GAP parameter doesn't give a gre=
at
>>> sense that the lead time would be a negative gap.)
>> Rather than reframe I'll add a note and a couple of examples of the
>> relationships with a GAP parameter.
>>> Section 5
>>>
>>>      RELTYPE=3DFIRST:  Indicates that the referenced calendar component=
 is
>>>         the first in a series the referenced calendar component is part
>>>         of.
>>>
>>> I wonder if we want to explicitly contrast this with PARENT and provide=
 an
>>> example of them being different.
>> I added this to allow jscalendar and icalendar events to be mapped.
>> Unfortunately I omitted to add RELTYPE=3DNEXT.
>>
>> I'll add the NEXT relation,
>>
>> The difference is that PARENT, CHILD and SIBLING relationships are about
>> hierarchy and FIRST, NEXT about order. I can add some text.
>>
>>> Section 6.1
>>>
>>>         In addition to the values defined here any value defined in
>>>         [RFC8288] may be used.  However these uses SHOULD be documented=
 in
>>>         an RFC updating both [RFC5545] and [RFC8288]
>>>
>>> In some sense this feels a little like saying "the current document SHO=
ULD
>>> have documented this stuff, but we didn't".  Is there anything useful t=
o
>>> say about why this documenting can't be done now?  (Oh, I guess there a=
re
>>> rather more values in the registry than I remembered, though the number=
 of
>>> them actually defined in RFC 8288 might be zero?)
>> In response to other comments I cut this back to
>>
>> In addition to the value defined here any link relation
>> in the link registry established by [RFC8288],
>> or new link relations, may be used.
>>
>> but I'm a little uneasy about that. Maybe add the text ", but should be
>> documented in an RFC" at the end?
>>
>> It seems to me that we should at least document how these are to be used
>> in a calendaring environment.
> Maybe something like "It is expected that link relation types seeing
> significant usage in calendaring will have the calendaring usage describe=
d
> in an RFC"?  There are probably a lot of different approaches here, and I
> have no strong sense of which would be "best".
>
>>> Section 8.1
>>>
>>>      Conformance:  This property can be specified zero or more times in
>>>         any iCalendar component.
>>>      [...]
>>>         Within the "VEVENT", "VTODO", or "VJOURNAL" calendar components=
,
>>>         more than one formal category can be specified by using multipl=
e
>>>         CONCEPT properties.
>>>
>>> Are these two statements fully compatible?  The former seems to give
>>> leeway to put multiple CONCEPT properties in any iCalendar component, b=
ut
>>> the latter seems to limit to the "more than one" ability to just the th=
ree
>>> named components.
>> I suspect that's something that remained after a copy/paste exercise.
>> The paragraph naming components should go - it just repeats what was
>> written before it.
>>> Section 8.2
>>>
>>> I am not entirely sure when the TEXT value type would be used.  If it's
>>> just there to allow for certain types of extensibility, that might be
>>> worth stating specifically.
>> That should have been VALUE=3DUID.
>>>         There is no mapping for [RFC8288] "title*", "anchor", "rev" or
>>>         "media".
>>>
>>> Maybe "there is currently no mapping"?  Or is the definition of such
>>> mapping prevented for some technical reason(s)?
>> They don't work or have meaning in the calendar context
>>> Section 9
>>>
>>>      This specification updates the RELATED-TO property defined in
>>>      Section 3.8.4.5 of [RFC5545].
>>>
>>> I'd consider adding a note that "the contents of Section 9.1 below repl=
ace
>>> Section 3.8.4.5 of [RFC5545]" to clarify the relationship between the t=
wo
>>> sections.
>> Done
>>> Section 9.1
>>>
>>>         By default, the property value points to another calendar
>>>         component that has a PARENT relationship to the referencing
>>>         object.  The "RELTYPE" property parameter is used to either
>>>         explicitly state the default PARENT relationship type to the
>>>         referenced calendar component or to override the default PARENT
>>>         relationship type and specify either a CHILD or SIBLING
>>>         relationship or a temporal relationship.
>>>
>>> We allow some new relationship types that are neither CHILD/SIBLING nor
>>> temporal (e.g., CONCEPT, REFID).  Should those get some text in the
>>> description too?  (I am not sure if DEPENDS-ON and FIRST should get lum=
ped
>>> in as "temporal", either -- we don't do so in =A75.)
>> I'll change that to
>>
>>         relationship type and specify some other relationship.
>>
>> I'll add some text for the other types.
>>>         The FINISHTOSTART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTAR=
T
>>>         relationships define temporal relationships as specified in the
>>>         reltype parameter definition.
>>>
>>> Likewise here, it seems some more discussion is in order for the other
>>> relationship types.
>>>
>>>         Changes to a calendar component referenced by this property can
>>>         have an implicit impact on the related calendar component.  For
>>>
>>> Do we want to say anything about changes to a component referenced by t=
his
>>> property using any of the new relationship types?
>> I've added a paragraph to explicitly mention the possibility of broken
>> links.
>>> Section 10
>>>
>>> Many thanks for referencing the URI security considerations and calling
>>> out "reliability and consistency"!
>>>
>>> We might say that the security considerations of RFC 5545 continue to
>>> apply.
>>>
>>> There are perhaps some privacy considerations if a user uses the new
>>> CATEGORY or REFID functionality to expose information about a related
>>> group of events, but it's a little hard to concoct a scenario where thi=
s
>>> information gets to an attacker other than the calendar server, which i=
s
>>> already in something of a trusted position with respect to the user.
>>>
>>> Are there any considerations about the new linking and relation operato=
rs
>>> exposing information to other users about calendar components that they=
're
>>> not authorized to access?
>>>
>>> Very large "gap" parameters seem likely to lead to unexpected behavior.
>>>
>>> NITS
>>>
>>> Section 1.4
>>>
>>>      iCalendar component.  This new LINK property is closely aligned to
>>>      the LINK header defined in [RFC8288]
>>>
>>> There are probably some pedantic distinctions that could be made here
>>> relating to how RFC 8288 defines the generic concept of Web Linking (wh=
ich
>>> is not intrinsically tied to HTTP), as well as its expression in an HTT=
P
>>> header *field*.
>> How about:
>>
>> component. This new LINK property is closely aligned to
>> RFC8288  which defines the generic concept
>> of Web Linking as well as its expression in the HTTP LINK header
>> field.
> Looks good, thanks.
>
>>> Also, please put a full stop at the end of the sentence.
>> Done
>>>      The ATTACH property defined in [RFC5545] is being extended to hand=
le
>>>      server-side management and stripping of inline data.  [...]
>>>
>>> It's hard (at least on first read) to tell if this sentence is referrin=
g
>>> to the RFC 8607 work or something being done by this document.
>> ...is being extended in other specifications to handle
>>>                                                            Clients may
>>>      choose to handle attachments differently from the LINK property as
>>>      they are often an integral part of the message - for example, the
>>>      agenda.
>>>
>>> Please clarify whether "they" refers to attachments of the LINK propert=
y.
>>> The singular/plural signal implies it's "attachments" but we could
>>> probably be more clear to the reader.
>>>
>>> Also, two hyphens for an em dash.
>> replaced "they" with "attachments"
>>> Section 4
>>>
>>>      This section defines the usual temporal relationships for use with
>>>
>>> What's the context behind "usual"?  I don't remember (but may have miss=
ed)
>>> a previous reference giving context for temporal relationships.
>> Maybe I should remove "the usual". Looking at things liek
>>
>> https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-313273af-45444=
5555731-c6425350d8ccb11e&q=3D1&e=3D5275fae3-e0fe-41ff-b644-6d633dd1d924&u=
=3Dhttps%3A%2F%2Fproject-management.info%2Fpdm-precedence-diagramming-metho=
d%2F
>>
>> these relationships are almost universal - but I don't know what could
>> be considered a standard. That organization does appear to create
>> standards but I don't know I can go much beyond saying "widely used".
>>
>>>      RELTYPE=3DFINISHTOFINISH:  Task-B can only be completed after Task=
-A is
>>>         finished.  The related tasks may run in parallel before
>>>         completion.
>>>
>>>         For example, if the goal is to prepare a meal, we start the
>>>         potatoes, then the meat then the peas but they should all be
>>>         cooked at the same time.
>>>
>>> This doesn't look like a great example for "finish-to-finish", as we
>>> prefer all things to finish at the same time, rather than with a strict
>>> ordering between end times.
>> In finish-to-finish we're trying to express that one task cannot be
>> completed until another task has completed. Both may run concurrently
>> but it's the end of both that matters. Perhaps this is a better example?
>>
>> ------------ New --------------
>>
>> For example, in the development of two related pieces of software, e.g.
>> the api and the implementation, the design of the implementation (B)
>> cannot be completed until the design of the api (A) has been completed.
>>
>> -------------------------------
> I like it better, at least.
>
>>> Section 6.1
>>>
>>>      Registration:  These relation types are registered in [RFC8288]
>>>
>>> I think we mean '''registered in the "Link Relation Types" registry
>>> established by [RFC8288]'''.
>> Yes
>>> Section 8.2
>>>
>>>      Property Parameters:  The VALUE parameter is required.  Non-standa=
rd,
>>>         reference type or format type parameters can also be specified =
on
>>>         this property.  The LABEL parameter is defined in [RFC7986]
>>>
>>> I'm not sure I see what in the ABNF would correspond to the "reference
>>> type" parameters.  The closest seems to be the linkrelparam, but that's=
 a
>>> relation type, not a reference type.
>> I think it should be
>>
>>      Property Parameters:  The VALUE parameter is required.
>>            Non-standard, link relation type,
>>            format type, label and language parameters can also be
>>            specified on this property. The LABEL parameter
>>            is defined in [RFC7986]
> Ok, that does seem easier for me to make sense of.
>
> Thanks again for all the good stuff here,
>
> Ben
>
>>> Section 9.1
>>>
>>> Looking at the diff from RFC 5545, we should title case "Property Name"
>>> and "Value Type".  We also have changed the order in which we list the
>>> options for property parameters but that seems unimportant.
>> OK
>>> Section 11.1
>>>
>>>      The following iCalendar property names have been added to the
>>>      iCalendar Properties Registry defined in Section 8.3.2 of [RFC5545=
]
>>>
>>> Pedantically, RELATED-TO is not "added" but is rather covered by the "h=
as
>>> added a reference to this document where ... have been updated by this
>>> document".  So if we were to keep this phrasing we might make two table=
s,
>>> or we could try to fudge the wording here a bit.
>>>
>>>
>>>
>>> _______________________________________________
>>> calsify mailing list
>>> calsify@ietf.org
>>> https://www.ietf.org/mailman/listinfo/calsify

--_000_HE1PR07MB42176DEA5394FCB69E0E5D8998129HE1PR07MB4217eurp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable











Indeed, t=
hank you very much Ben for the thoughtful review.


&nbs=
p;


Mike: I w=
ill mark this as =93revised ID needed=94 while waiting for the last (final)=
 update with this minor change, then when v-11 is posted I=92ll send this f=
orward to the RFC Editor.



&nbs=
p;


Thanks fo=
r the good work!

Francesca


&nbs=
p;





From: iesg <iesg-bounces@ietf.org> on be=
half of Michael Douglass <mdouglass@bedework.com>

Date: Monday, 7 March 2022 at 21:40

To: Benjamin Kaduk <kaduk@mit.edu>, Michael Douglass <mikea=
douglass@gmail.com>

Cc: draft-ietf-calext-ical-relations@ietf.org <draft-ietf-calext-=
ical-relations@ietf.org>, The IESG <iesg@ietf.org>, calext-chairs@=
ietf.org <calext-chairs@ietf.org>, calsify@ietf.org <calsify@ietf.=
org>

Subject: Re: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext=
-ical-relations-09: (with DISCUSS and COMMENT)






Thanks Ben.



Your comments were very helpful.



I'll probably make at least one change along the lines suggested below 

but I'll wait till after the calext session



On 3/7/22 14:38, Benjamin Kaduk wrote:

> Hi Michael,

>

> Most of this looks really good, and I'll go lift my Discuss shortly.
> Just a handful of notes scattered inline...

>

> On Sun, Feb 27, 2022 at 06:10:37PM -0500, Michael Douglass wrote:

>> Thank you for your detailed response - please see below ...

>>

>> On 2/15/22 17:26, Benjamin Kaduk via Datatracker wrote:

>>

>>> ...

>>>

>>>

>>> --------------------------------------------------------------=
--------

>>> DISCUSS:

>>> --------------------------------------------------------------=
--------

>>>

>>> The ABNF for linkparam (=A78.2) incorporates a "langparam=
" production, but

>>> that is not defined in any of this document, RFC 5455, RFC 828=
8, or RFC

>>> 7986.  We need to define it somehow, whether by reference=
 or directly.

>>> RFC 5545 does define a LANGUAGE parameter (our prose reference=
s a "LANG"

>>> parameter) and languageparam ABNF production, which is perhaps=
 the

>>> simplest explanation for what was intended.

>> Yes - it should have been languageparam - corrected

> Excellent, I'm glad it was the easy fix.

>

>>> --------------------------------------------------------------=
--------

>>> COMMENT:

>>> --------------------------------------------------------------=
--------

>>>

>>> A couple broad comments before getting into the section-by-sec=
tion

>>> details:

>>>

>>> I'm a little unclear on the value gained by having RELTYPE=3DR=
EFID and

>>> RELTYPE=3DCONCEPT.  If the semantics were just supposed t=
o be "is a member

>>> of the indicated group", then why do we need a relation t=
ype to say so.

>>> But if there's some other semantics associated, where do we de=
fine those

>>> semantics?

>> The idea is to associate one entity with others without that entit=
y

>> necessarily having the associated attribute. The semantics are mor=
e like

>> - this is an aggregator for those things with the designated REFID=
 or

>> CONCEPT

> Ah, thanks for the extra explanation.  Perhaps I was just being a=
 bit dense

> when I first read it; I don't really have any suggestions for how we m=
ight

> add more text that would have prevented my confusion.

>

>>> There are a number of places (e.g., =A71.4) where this documen=
t uses the

>>> term "collection" in a context that suggests that it=
 should be a defined

>>> term of iCalendar, corresponding roughly to a "site"=
 or administrative

>>> domain, but I didn't find any usage in RFC 5545 that would cor=
respond to

>>> what's being described here.  Can we say more about what =
level of grouping

>>> this is intended to refer to?

>> More of a CalDAV thing. I'll precede the first occurrence with som=
e text

>>

>> ------ OLD -------

>>

>> It is also often necessary to reference calendar components in oth=
er

>>

>> collections.  For example, a VEVENT might refer to a VTODO fr=
om which

>>

>> ------ NEW -------

>>

>> Calendar components are often grouped into collections to represen=
t a

>> calendar or a series of tasks, for example [RFC4791] (CalDAV) cale=
ndar

>> collections.

>>

>> It is often necessary for calendar components in one such collecti=
on

>> to reference components in other collections.  For example, a=
 VEVENT

>> might refer to a VTODO from which...

>>

>> ------------------

>>

>>> Section 1.1

>>>

>>>      The iCalendar [RFC5545] RELATED-=
TO property has no support for

>>>      temporal relationships as used b=
y standard project management tools.

>>>

>>> I am admittedly not really the target audience of this specifi=
cation, but

>>> I have no idea what the "standard project management tool=
s" are that are

>>> being referred to.  Would (informative) references to a h=
andful be

>>> appropriate?

>> I guess I should drop 'standard' and just write

>>

>>      temporal relationships as used by pr=
oject management tools.

>>

>>

>> It's really the relationships which are 'standard' in the sense th=
ey are

>> apparently used by all/most project management tools.There is also=
 the

>> Project Management Institute which has /A Guide to the Project

>> Management Body of Knowledge /which apparently defines these terms=
 also.

>> I'm not sure if we want a reference to that - I think it's as clos=
e as

>> we get to a standard

>> //

>>

>>> Section 1.2

>>>

>>>      REFID is used to identify a key =
allowing the association of

>>>      components that are related to t=
he same object and retrieval of a

>>>      component based on this key.&nbs=
p; [...]

>>>

>>> This says "related to the same *object*" (emphasis m=
ine), but the rest of

>>> the section just talks about an unstructured grouping.  I=
t seems like we

>>> could give some hint of the nature of the "object" t=
o which all the

>>> elements of the group are related, prior to the RELTYPE=3DREFI=
D definition

>>> in =A75.

>> Not sure how to reword this. The examples were an attempt to defin=
e

>> that. I should probably at least stick with component instead of o=
bject.

>>

>> I've tried a bit of rewording...

>>

>> ------ OLD -------

>>

>> REFID is used to identify a key allowing the association of

>> components that are related to the same object and retrieval of a<=
br>
>> component based on this key.  Two examples of how this may be=
 used

>> are to identify the tasks associated with a given project without<=
br>
>> having to communicate the task structure of the project, and to gr=
oup

>> all tasks associated to a specific package in a package delivery
>> system.

>>

>> ------ NEW -------

>>

>> REFID is used to identify a key allowing the association of

>> components that are all related to the referring, aggregating comp=
onent and

>> the retrieval of components based on this key.  For example, =
this may be used

>> to identify the tasks associated with a given project without

>> having to communicate the task structure of the project. A further=
 example

>> is the grouping of all sub-tasks associated with the delivery of a=
 specific

>> package in a package delivery system.

>> ------------------

>>

>>> Section 1.3

>>>

>>>      The current [RFC5545] CATEGORY p=
roperty is used as a free form

>>>      'tagging' field.  [...]

>>>

>>> In light of the discussion in the previous section about group=
ing without

>>> semantics, we might consider mentioning here that this is &quo=
t;tagging with

>>> semantics", just vaguely defined ones, as opposed to the =
REFID-type

>>> "tagging without semantics".

>> Added some text.

>>> Section 1.4

>>>

>>>      server-side management and strip=
ping of inline data.  Clients may

>>>      choose to handle attachments dif=
ferently from the LINK property as

>>>      they are often an integral part =
of the message - for example, the

>>>      agenda.

>>>

>>> (See the NITS entries as well, but) is it particularly notewor=
thy that

>>> clients might handle LINKs different from ATTACHments?  T=
hey are different

>>> properties after all -- why would someone assume equivalent tr=
eatment?

>> I'm not sure why - but it seems worth pointing out just in case. T=
here's

>> some degree of similarity between a LINK and an ATTACHMENT - espec=
ially

>> if the attachment value is a uri.

>>

>> Also I think when I wrote this managed attachments wasn't an RFC. =
I have

>> the ref but the text is vague.

>>

>> ------------ OLD ----------

>>

>> The LINK property MUST NOT be treated as just another attachment.<=
br>
>> The ATTACH property defined in [RFC5545] is being extended to hand=
le

>> server-side management and stripping of inline data.  Clients=
 may

>> choose to handle attachments differently from the LINK property as=


>> they are often an integral part of the message - for example, the<=
br>
>> agenda.

>>

>> For more information on managed attachments see [RFC8607]

>>

>> ------------ NEW ----------

>>

>> The LINK property MUST NOT be treated as just another attachment.<=
br>
>> The ATTACH property defined in [RFC5545] has been extended by [RFC=
8607]

>> to handle server-side management and stripping of inline data and =
to

>> provide additional data about the attachment (size, filename etc).=


>>

>> Additionally clients may choose to handle attachments differently<=
br>
>> from the LINK property as attachments are often an integral part
>> of the message - for example, the agenda.

>> ---------------------------

>>

>>

>>> Section 1.5

>>>

>>>      To facilitate offline display th=
e link type may identify important

>>>      pieces of data which should be d=
ownloaded in advance.

>>>

>>>      In general, the calendar entity =
should be self explanatory without

>>>      the need to download referenced =
meta-data such as a web page.

>>>

>>> I'm not sure how to relate these two statements.  It soun=
ds like a "<X>

>>> may happen, but in general don't do <X>" scenario, =
in which case it might

>>> flow better to give the general advice first, followed by the =
specific

>>> scenario in which there is an exception to the general guidanc=
e.

>> It does read better - changed

>>> Section 2

>>>

>>>      The actual reference value can t=
ake three forms specified by the type

>>>      parameter

>>>

>>> Is this list fixed for eternity or do we want to give some gui=
dance that

>>> implementations need to prepare for future extensibility?

>>>

>>>      REFERENCE:  In an XML envir=
onment it may be necessary to refer to a

>>>

>>> This qualification in the description ("XML environment&q=
uot;) suggests that

>>> perhaps the name being used for these semantics is an overly g=
eneric name.

>> Having reread the text section has a number of problems, e.g - it'=
s not

>> "type" - it's the VALUE parameter. I think the title is =
wrong - this is

>> really about LINK property references so I'll change the title. Al=
so

>> LINK has no default type and - to get ahead a little - in the LINK=


>> definition VALUE-TEXT should be VALUE=3DUID.

>>

>> Your point about REFERENCE stands - I'll change it to XML-REFERENC=
E

>> elsewhere.

>>

>> I'll update the text and get a new version out.

>>

>> I've added some text to point out that UID references may need upd=
ating

>> on import and export.

>>

>>> Section 4

>>>

>>> We do have some text here about the GAP parameter that specifi=
es the lead

>>> or lag time here, but then we go on to describe the various RE=
LTYPE values

>>> in language like "cannot start until", "can onl=
y be completed after",

>>> etc., that is very absolute and does not acknowledge the poten=
tial for a

>>> GAP.  I think it would be helpful to reframe as that we a=
re making a

>>> comparison between the indicated pair of events, and that the =
relationship

>>> between when the events occur is affected by the GAP interval.=


>>> (Also, the text in this section on the GAP parameter doesn't g=
ive a great

>>> sense that the lead time would be a negative gap.)

>> Rather than reframe I'll add a note and a couple of examples of th=
e

>> relationships with a GAP parameter.

>>> Section 5

>>>

>>>      RELTYPE=3DFIRST:  Indicates=
 that the referenced calendar component is

>>>         the first in a=
 series the referenced calendar component is part

>>>         of.

>>>

>>> I wonder if we want to explicitly contrast this with PARENT an=
d provide an

>>> example of them being different.

>> I added this to allow jscalendar and icalendar events to be mapped=
.

>> Unfortunately I omitted to add RELTYPE=3DNEXT.

>>

>> I'll add the NEXT relation,

>>

>> The difference is that PARENT, CHILD and SIBLING relationships are=
 about

>> hierarchy and FIRST, NEXT about order. I can add some text.

>>

>>> Section 6.1

>>>

>>>         In addition to=
 the values defined here any value defined in

>>>         [RFC8288] may =
be used.  However these uses SHOULD be documented in

>>>         an RFC updatin=
g both [RFC5545] and [RFC8288]

>>>

>>> In some sense this feels a little like saying "the curren=
t document SHOULD

>>> have documented this stuff, but we didn't".  Is ther=
e anything useful to

>>> say about why this documenting can't be done now?  (Oh, I=
 guess there are

>>> rather more values in the registry than I remembered, though t=
he number of

>>> them actually defined in RFC 8288 might be zero?)

>> In response to other comments I cut this back to

>>

>> In addition to the value defined here any link relation

>> in the link registry established by [RFC8288],

>> or new link relations, may be used.

>>

>> but I'm a little uneasy about that. Maybe add the text ", but=
 should be

>> documented in an RFC" at the end?

>>

>> It seems to me that we should at least document how these are to b=
e used

>> in a calendaring environment.

> Maybe something like "It is expected that link relation types see=
ing

> significant usage in calendaring will have the calendaring usage descr=
ibed

> in an RFC"?  There are probably a lot of different approache=
s here, and I

> have no strong sense of which would be "best".

>

>>> Section 8.1

>>>

>>>      Conformance:  This property=
 can be specified zero or more times in

>>>         any iCalendar =
component.

>>>      [...]

>>>         Within the &qu=
ot;VEVENT", "VTODO", or "VJOURNAL" calendar compon=
ents,

>>>         more than one =
formal category can be specified by using multiple

>>>         CONCEPT proper=
ties.

>>>

>>> Are these two statements fully compatible?  The former se=
ems to give

>>> leeway to put multiple CONCEPT properties in any iCalendar com=
ponent, but

>>> the latter seems to limit to the "more than one" abi=
lity to just the three

>>> named components.

>> I suspect that's something that remained after a copy/paste exerci=
se.

>> The paragraph naming components should go - it just repeats what w=
as

>> written before it.

>>> Section 8.2

>>>

>>> I am not entirely sure when the TEXT value type would be used.=
  If it's

>>> just there to allow for certain types of extensibility, that m=
ight be

>>> worth stating specifically.

>> That should have been VALUE=3DUID.

>>>         There is no ma=
pping for [RFC8288] "title*", "anchor", "rev"=
 or

>>>         "media&qu=
ot;.

>>>

>>> Maybe "there is currently no mapping"?  Or is t=
he definition of such

>>> mapping prevented for some technical reason(s)?

>> They don't work or have meaning in the calendar context

>>> Section 9

>>>

>>>      This specification updates the R=
ELATED-TO property defined in

>>>      Section 3.8.4.5 of [RFC5545].
>>>

>>> I'd consider adding a note that "the contents of Section =
9.1 below replace

>>> Section 3.8.4.5 of [RFC5545]" to clarify the relationship=
 between the two

>>> sections.

>> Done

>>> Section 9.1

>>>

>>>         By default, th=
e property value points to another calendar

>>>         component that=
 has a PARENT relationship to the referencing

>>>         object.  =
The "RELTYPE" property parameter is used to either

>>>         explicitly sta=
te the default PARENT relationship type to the

>>>         referenced cal=
endar component or to override the default PARENT

>>>         relationship t=
ype and specify either a CHILD or SIBLING

>>>         relationship o=
r a temporal relationship.

>>>

>>> We allow some new relationship types that are neither CHILD/SI=
BLING nor

>>> temporal (e.g., CONCEPT, REFID).  Should those get some t=
ext in the

>>> description too?  (I am not sure if DEPENDS-ON and FIRST =
should get lumped

>>> in as "temporal", either -- we don't do so in =A75.)=


>> I'll change that to

>>

>>         relationship type =
and specify some other relationship.

>>

>> I'll add some text for the other types.

>>>         The FINISHTOST=
ART, FINISHTOFINISH, STARTTOFINISH or STARTTOSTART

>>>         relationships =
define temporal relationships as specified in the

>>>         reltype parame=
ter definition.

>>>

>>> Likewise here, it seems some more discussion is in order for t=
he other

>>> relationship types.

>>>

>>>         Changes to a c=
alendar component referenced by this property can

>>>         have an implic=
it impact on the related calendar component.  For

>>>

>>> Do we want to say anything about changes to a component refere=
nced by this

>>> property using any of the new relationship types?

>> I've added a paragraph to explicitly mention the possibility of br=
oken

>> links.

>>> Section 10

>>>

>>> Many thanks for referencing the URI security considerations an=
d calling

>>> out "reliability and consistency"!

>>>

>>> We might say that the security considerations of RFC 5545 cont=
inue to

>>> apply.

>>>

>>> There are perhaps some privacy considerations if a user uses t=
he new

>>> CATEGORY or REFID functionality to expose information about a =
related

>>> group of events, but it's a little hard to concoct a scenario =
where this

>>> information gets to an attacker other than the calendar server=
, which is

>>> already in something of a trusted position with respect to the=
 user.

>>>

>>> Are there any considerations about the new linking and relatio=
n operators

>>> exposing information to other users about calendar components =
that they're

>>> not authorized to access?

>>>

>>> Very large "gap" parameters seem likely to lead to u=
nexpected behavior.

>>>

>>> NITS

>>>

>>> Section 1.4

>>>

>>>      iCalendar component.  This =
new LINK property is closely aligned to

>>>      the LINK header defined in [RFC8=
288]

>>>

>>> There are probably some pedantic distinctions that could be ma=
de here

>>> relating to how RFC 8288 defines the generic concept of Web Li=
nking (which

>>> is not intrinsically tied to HTTP), as well as its expression =
in an HTTP

>>> header *field*.

>> How about:

>>

>> component. This new LINK property is closely aligned to

>> RFC8288  which defines the generic concept

>> of Web Linking as well as its expression in the HTTP LINK header
>> field.

> Looks good, thanks.

>

>>> Also, please put a full stop at the end of the sentence.

>> Done

>>>      The ATTACH property defined in [=
RFC5545] is being extended to handle

>>>      server-side management and strip=
ping of inline data.  [...]

>>>

>>> It's hard (at least on first read) to tell if this sentence is=
 referring

>>> to the RFC 8607 work or something being done by this document.=


>> ...is being extended in other specifications to handle

>>>          &nb=
sp;            =
            &nb=
sp;            =
            Clients =
may

>>>      choose to handle attachments dif=
ferently from the LINK property as

>>>      they are often an integral part =
of the message - for example, the

>>>      agenda.

>>>

>>> Please clarify whether "they" refers to attachments =
of the LINK property.

>>> The singular/plural signal implies it's "attachments"=
; but we could

>>> probably be more clear to the reader.

>>>

>>> Also, two hyphens for an em dash.

>> replaced "they" with "attachments"

>>> Section 4

>>>

>>>      This section defines the usual t=
emporal relationships for use with

>>>

>>> What's the context behind "usual"?  I don't rem=
ember (but may have missed)

>>> a previous reference giving context for temporal relationships=
.

>> Maybe I should remove "the usual". Looking at things lie=
k

>>

>> 
https://protect2.fireeye.com/v1/url?k=3D31323334-501d5122-313273af-45444555=
5731-c6425350d8ccb11e&q=3D1&e=3D5275fae3-e0fe-41ff-b644-6d633dd1d92=
4&u=3Dhttps%3A%2F%2Fproject-management.info%2Fpdm-precedence-diagrammin=
g-method%2F

>>

>> these relationships are almost universal - but I don't know what c=
ould

>> be considered a standard. That organization does appear to create<=
br>
>> standards but I don't know I can go much beyond saying "widel=
y used".

>>

>>>      RELTYPE=3DFINISHTOFINISH:  =
Task-B can only be completed after Task-A is

>>>         finished. =
; The related tasks may run in parallel before

>>>         completion.
>>>

>>>         For example, i=
f the goal is to prepare a meal, we start the

>>>         potatoes, then=
 the meat then the peas but they should all be

>>>         cooked at the =
same time.

>>>

>>> This doesn't look like a great example for "finish-to-fin=
ish", as we

>>> prefer all things to finish at the same time, rather than with=
 a strict

>>> ordering between end times.

>> In finish-to-finish we're trying to express that one task cannot b=
e

>> completed until another task has completed. Both may run concurren=
tly

>> but it's the end of both that matters. Perhaps this is a better ex=
ample?

>>

>> ------------ New --------------

>>

>> For example, in the development of two related pieces of software,=
 e.g.

>> the api and the implementation, the design of the implementation (=
B)

>> cannot be completed until the design of the api (A) has been compl=
eted.

>>

>> -------------------------------

> I like it better, at least.

>

>>> Section 6.1

>>>

>>>      Registration:  These relati=
on types are registered in [RFC8288]

>>>

>>> I think we mean '''registered in the "Link Relation Types=
" registry

>>> established by [RFC8288]'''.

>> Yes

>>> Section 8.2

>>>

>>>      Property Parameters:  The V=
ALUE parameter is required.  Non-standard,

>>>         reference type=
 or format type parameters can also be specified on

>>>         this property.=
  The LABEL parameter is defined in [RFC7986]

>>>

>>> I'm not sure I see what in the ABNF would correspond to the &q=
uot;reference

>>> type" parameters.  The closest seems to be the linkr=
elparam, but that's a

>>> relation type, not a reference type.

>> I think it should be

>>

>>      Property Parameters:  The VALUE=
 parameter is required.

>>            =
Non-standard, link relation type,

>>            =
format type, label and language parameters can also be

>>            =
specified on this property. The LABEL parameter

>>            =
is defined in [RFC7986]

> Ok, that does seem easier for me to make sense of.

>

> Thanks again for all the good stuff here,

>

> Ben

>

>>> Section 9.1

>>>

>>> Looking at the diff from RFC 5545, we should title case "=
Property Name"

>>> and "Value Type".  We also have changed the ord=
er in which we list the

>>> options for property parameters but that seems unimportant.
>> OK

>>> Section 11.1

>>>

>>>      The following iCalendar property=
 names have been added to the

>>>      iCalendar Properties Registry de=
fined in Section 8.3.2 of [RFC5545]

>>>

>>> Pedantically, RELATED-TO is not "added" but is rathe=
r covered by the "has

>>> added a reference to this document where ... have been updated=
 by this

>>> document".  So if we were to keep this phrasing we m=
ight make two tables,

>>> or we could try to fudge the wording here a bit.

>>>

>>>

>>>

>>> _______________________________________________

>>> calsify mailing list

>>> calsify@ietf.org

>>> http=
s://www.ietf.org/mailman/listinfo/calsify








--_000_HE1PR07MB42176DEA5394FCB69E0E5D8998129HE1PR07MB4217eurp_--


From nobody Sat Mar 19 05:40:40 2022
Return-Path: 
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 68EA33A1221 for ; Sat, 19 Mar 2022 05:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level: 
X-Spam-Status: No, score=-2.106 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, T_SCC_BODY_TEXT_LINE=-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=fastmailteam.com header.b=Fxgvw9Is; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d8ogZDVL
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 3dBrBUnb1kXX for ; Sat, 19 Mar 2022 05:40:33 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46923A07A9 for ; Sat, 19 Mar 2022 05:40:33 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C62435C01A4 for ; Sat, 19 Mar 2022 08:40:32 -0400 (EDT)
Received: from imap43 ([10.202.2.93]) by compute1.internal (MEProxy); Sat, 19 Mar 2022 08:40:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm2; bh=meyHj6eShcualEvRzjcP6pL4zqhgyuAvBKFU5K L89jU=; b=Fxgvw9Isr8NHFzaQ50xrcwcfkmRZCBOJSSFiiP7QSLoOyp7AhBImkR NJ+Ch9wZYj58dM42ox88IhEGwOk3AwXFdfjdJHvJCKnx9BFf+hNPEzE9C9LTFDIb JncSNgyT+IFjQJKP8+2+wJcc/icsO/yZ9O/s8q5u1XcxTHeocpSnctzVJzdmEdpQ pQlNgbMwI8mjxaXoCtoMx3DG8uRGe1kTiLlgGPMMIIY7nmCnXD2rVYg2DkMH6iP2 fSLrrxabb/pTKMWIgv3DzUtPfVr9bkHL+R9DZjQogmO6P77lSugal9PGjr0RHgx1 YSqZXCTwmATxXbPlME9yB3ny4+Q8KLpQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date: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=fm3; bh=meyHj6eShcualEvRzjcP6pL4zqhgyuAvBKFU5KL89 jU=; b=d8ogZDVLCxVhU/jAdHxDxpCrB4x2fpPU9Tdl01w6JlJcSHliKN8ar+u9f 2e/N/KqfSbONpCvFyf1yQOj/FxascJaJ+Ab8q9XNFsaWxl2H4xsrRldp+fWWyYqp 9MS82geJRKcYAEeX36w/HLphGIcR5HTv4hrxBvfUFZ15HZm4EE5jukBvtz6l6gYe iWe1/ggeo4tRKtYWQgBayU/qOaSS1rBD6uIyNqNRjTy9LnKVULpimIdHH6gfyZGb wPdxXeA3IvaI0mFVpLn0L3iUaT+Opo1yWhdgEo8T71BVpwXUwaiepd8eGPvEKTDs VcQ6N8JqEJrs541JoLizUT2SEgWog==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudefkedggedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpefhjeehkeejkeehve eutdejteeihffffeduiedttdejhfelteevueehudeltdeuffenucffohhmrghinhepihgv thhfrdhorhhgnecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrh homhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9C4F1AC0E98; Sat, 19 Mar 2022 08:40:32 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-4907-g25ce6f34a9-fm-20220311.001-g25ce6f34
Mime-Version: 1.0
Message-Id: 
Date: Sat, 19 Mar 2022 13:40:12 +0100
From: "Bron Gondwana" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=2d5edd2006d54547a144e678f091f7bf
Archived-At: 
Subject: [calsify] Slides!
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Calendaring and Scheduling Standards Simplification 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Mar 2022 12:40:39 -0000

--2d5edd2006d54547a144e678f091f7bf
Content-Type: text/plain

Hi authors / speakers at the CALEXT session at IETF113.

Can you please either email me your slides or upload them to https://datatracker.ietf.org/meeting/113/session/calext so they're in the datatracker and available in meetecho before the meeitng.  It's much easier if everything is in the system before the session.

Thanks,

Bron.

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


--2d5edd2006d54547a144e678f091f7bf
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


Hi authors / speakers at the CALEXT session at IETF11=
3.

Can yo=
u please either email me your slides or upload them to https://datatrac=
ker.ietf.org/meeting/113/session/calext so they're in the datatracke=
r and available in meetecho before the meeitng.  It's much easier i=
f everything is in the system before the session.

Thanks,
=


Bron.

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


--2d5edd2006d54547a144e678f091f7bf--


From nobody Sun Mar 20 06:08:11 2022
Return-Path: 
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 DD19D3A087E; Sun, 20 Mar 2022 06:07:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 elyehniK9TYc; Sun, 20 Mar 2022 06:07:39 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B7C3A085E; Sun, 20 Mar 2022 06:07:39 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 499) id 0AC803BA9D; Sun, 20 Mar 2022 06:07:39 -0700 (PDT)
To: rsto@fastmailteam.com, neilj@fastmailteam.com, rsto@fastmailteam.com
From: RFC Errata System 
Cc: francesca.palombini@ericsson.com, iesg@ietf.org, calsify@ietf.org, iana@iana.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20220320130739.0AC803BA9D@rfc-editor.org>
Date: Sun, 20 Mar 2022 06:07:39 -0700 (PDT)
Archived-At: 
Subject: [calsify] [Errata Verified] RFC8984 (6872)
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Calendaring and Scheduling Standards Simplification 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Mar 2022 13:07:44 -0000

The following errata report has been verified for RFC8984,
"JSCalendar: A JSON Representation of Calendar Data". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6872

--------------------------------------
Status: Verified
Type: Technical

Reported by: Robert Stepanek 
Date Reported: 2022-03-07
Verified by: Francesca Palombini (IESG)

Section: 4.4.3.

Original Text
-------------
   "private":  The details of the object are hidden; only the basic time
      and metadata are shared.  The following properties MAY be shared;
      any other properties MUST NOT be shared:

      *  @type

      *  created

      *  due

      *  duration

      *  estimatedDuration

      *  freeBusyStatus

      *  privacy

      *  recurrenceOverrides (Only patches that apply to another
         permissible property are allowed to be shared.)

      *  sequence

      *  showWithoutTime

      *  start

      *  timeZone

      *  timeZones

      *  uid

      *  updated

Corrected Text
--------------
   "private":  The details of the object are hidden; only the basic time
      and metadata are shared.  The following properties MAY be shared;
      any other properties MUST NOT be shared:
 
      *  @type
 
      *  created
 
      *  due
 
      *  duration
 
      *  estimatedDuration
 
      *  excluded
 
      *  excludedRecurrenceRules
 
      *  freeBusyStatus
 
      *  privacy
 
      *  recurrenceId
 
      *  recurrenceIdTimeZone
 
      *  recurrenceOverrides (Only patches that apply to another
         permissible property are allowed to be shared.)
 
      *  recurrenceRules
 
      *  sequence
 
      *  showWithoutTime
 
      *  start
 
      *  timeZone
 
      *  timeZones
 
      *  uid
 
      *  updated

Notes
-----
Adds the excluded, excludedRecurrenceRules, recurrenceId, recurrenceIdTimeZone and recurrenceRules properties to the list of shared properties of private events.
 
Only the combination of all recurrence properties allows to generate the full recurrence set for the event.
 
Omitting the properties was an oversight during the initial publication of this RFC.

--------------------------------------
RFC8984 (draft-ietf-calext-jscalendar-32)
--------------------------------------
Title               : JSCalendar: A JSON Representation of Calendar Data
Publication Date    : July 2021
Author(s)           : N. Jenkins, R. Stepanek
Category            : PROPOSED STANDARD
Source              : Calendaring Extensions
Area                : Applications and Real-Time
Stream              : IETF
Verifying Party     : IESG


From nobody Sun Mar 20 08:52:25 2022
Return-Path: 
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 5DD573A0E50; Sun, 20 Mar 2022 08:52:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 xBiQxEQHkmXz; Sun, 20 Mar 2022 08:52:00 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958A73A0E4C; Sun, 20 Mar 2022 08:51:58 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 499) id E60863BA9D; Sun, 20 Mar 2022 08:51:57 -0700 (PDT)
To: rsto@fastmailteam.com, neilj@fastmailteam.com, rsto@fastmailteam.com
From: RFC Errata System 
Cc: francesca.palombini@ericsson.com, iesg@ietf.org, calsify@ietf.org, iana@iana.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20220320155157.E60863BA9D@rfc-editor.org>
Date: Sun, 20 Mar 2022 08:51:57 -0700 (PDT)
Archived-At: 
Subject: [calsify] [Errata Verified] RFC8984 (6873)
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Calendaring and Scheduling Standards Simplification 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Mar 2022 15:52:05 -0000

The following errata report has been verified for RFC8984,
"JSCalendar: A JSON Representation of Calendar Data". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6873

--------------------------------------
Status: Verified
Type: Technical

Reported by: Robert Stepanek 
Date Reported: 2022-03-07
Verified by: Francesca Palombini (IESG)

Section: 4.3.2.

Original Text
-------------
Identifies the time zone of the main JSCalendar object, of which this
JSCalendar object is a recurrence instance.  This property MUST be
set if the "recurrenceId" property is set.  It MUST NOT be set if the
"recurrenceId" property is not set.

Corrected Text
--------------
Identifies the time zone of the main JSCalendar object, of which this
JSCalendar object is a recurrence instance.  It MUST NOT be set if the
"recurrenceId" property is not set.

Notes
-----
A recurrence instance may be in floating time, in which case the value of the "recurrenceIdTimeZone" property is null. As null is the default value of the "recurrenceIdTimeZone" property, it is NOT required to be set if "recurrenceId" is set.

--------------------------------------
RFC8984 (draft-ietf-calext-jscalendar-32)
--------------------------------------
Title               : JSCalendar: A JSON Representation of Calendar Data
Publication Date    : July 2021
Author(s)           : N. Jenkins, R. Stepanek
Category            : PROPOSED STANDARD
Source              : Calendaring Extensions
Area                : Applications and Real-Time
Stream              : IETF
Verifying Party     : IESG


From nobody Sun Mar 20 12:17:43 2022
Return-Path: 
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 0B5263A0BC6 for ; Sun, 20 Mar 2022 12:16:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 NGt-5wJKYehY for ; Sun, 20 Mar 2022 12:16:46 -0700 (PDT)
Received: from mail.audriga.com (mail.audriga.com [176.221.42.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13453A0A27 for ; Sun, 20 Mar 2022 12:16:45 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id 2C113A0B6 for ; Sun, 20 Mar 2022 20:16:44 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mail.audriga.com
Received: from mail.audriga.com ([127.0.0.1]) by localhost (mail.audriga.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckhVnmBuUNst for ; Sun, 20 Mar 2022 20:16:41 +0100 (CET)
Received: from [31.133.136.205] (dhcp-88cd.meeting.ietf.org [31.133.136.205]) (Authenticated sender: joris@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id C1F75A0FF for ; Sun, 20 Mar 2022 20:16:41 +0100 (CET)
Content-Type: multipart/alternative; boundary="------------MiPA9V7TFaXgx7Tul0yjKP5E"
Message-ID: 
Date: Sun, 20 Mar 2022 20:16:41 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: calsify@ietf.org
References: <164668093918.9645.7682855794392438410@ietfa.amsl.com>
From: Joris Baum 
In-Reply-To: <164668093918.9645.7682855794392438410@ietfa.amsl.com>
Archived-At: 
Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscontact-vcard-00.txt
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Calendaring and Scheduling Standards Simplification 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 20 Mar 2022 19:16:58 -0000

This is a multi-part message in MIME format.
--------------MiPA9V7TFaXgx7Tul0yjKP5E
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

we are currently in the process of implementing that draft. So far, we 
found two discussion-worthy things I wanted to share:

  * Currently there are only `private` and `work` defined as Context
    (see
    https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-01.html#name-context
    ). We observed multiple systems (e.g. Roundcube or Android Contacts)
    where `other` can be chosen as a value for context as well. vCards
    with `other` currently cannot be mapped to JSContact. It might make
    sense to extend the values of Context with `other`.
  * When mapping from vCard to JSContact it is recommended to use
    `label` to identify the corresponding vCard property (see
    https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-vcard-00.html#section-3.5.2
    ). However, it is an optional property for a lot of JSContact
    properties right now. I suggest to either make the `label` a
    mandatory property in JSContact or add a small section on how to
    handle the case of a missing `label` property in a card object.


Regards,

Joris


On 07.03.22 20:22, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Calendaring Extensions WG of the IETF.
>
>          Title           : JSContact: Converting from and to vCard
>          Authors         : Mario Loffredo
>                            Robert Stepanek
> 	Filename        : draft-ietf-calext-jscontact-vcard-00.txt
> 	Pages           : 41
> 	Date            : 2022-03-07
>
> Abstract:
>     This document defines how to convert contact information as defined
>     in the JSContact [draft-ietf-calext-jscontact] specification from and
>     to vCard.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-calext-jscontact-vcard/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscontact-vcard-00
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Joris Baum
Tel: +49 721 170293 16
Fax: +49 721 170293 179

http://www.audriga.com  |http://www.twitter.com/audriga

--------------------------------------------------------------------------
audriga GmbH | Alter Schlachthof 57 | 76137 Karlsruhe
Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
--------------------------------------------------------------------------

--------------MiPA9V7TFaXgx7Tul0yjKP5E
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi,

    

    we are currently in the process of implementing that draft. So far,
    we found two discussion-worthy things I wanted to share:

    

    
    
      
  • Currently there are only `private` and `work` defined as
        Context (see
https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-01.html#name-context
        ). We observed multiple systems (e.g. Roundcube or Android
        Contacts) where `other` can be chosen as a value for context as
        well. vCards with `other` currently cannot be mapped to
        JSContact. It might make sense to extend the values of Context
        with `other`.
    • 
      
  • When mapping from vCard to JSContact it is recommended to use
        `label` to identify the corresponding vCard property (see
https://www.ietf.org/archive/id/draft-ietf-calext-jscontact-vcard-00.html#section-3.5.2
        ). However, it is an optional property for a lot of JSContact
        properties right now. I suggest to either make the `label` a
        mandatory property in JSContact or add a small section on how to
        handle the case of a missing `label` property in a card object.
    
      
    • 
    

    

    Regards,

    

    Joris

    

    


    

    
On 07.03.22 20:22,
      internet-drafts@ietf.org wrote:

    

    

      
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring Extensions WG of the IETF.

        Title           : JSContact: Converting from and to vCard
        Authors         : Mario Loffredo
                          Robert Stepanek
	Filename        : draft-ietf-calext-jscontact-vcard-00.txt
	Pages           : 41
	Date            : 2022-03-07

Abstract:
   This document defines how to convert contact information as defined
   in the JSContact [draft-ietf-calext-jscontact] specification from and
   to vCard.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-calext-jscontact-vcard/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscontact-vcard-00


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify


    

    
-- 
Joris Baum
Tel: +49 721 170293 16
Fax: +49 721 170293 179

http://www.audriga.com | http://www.twitter.com/audriga

--------------------------------------------------------------------------
audriga GmbH | Alter Schlachthof 57 | 76137 Karlsruhe
Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
--------------------------------------------------------------------------

  


--------------MiPA9V7TFaXgx7Tul0yjKP5E--


From nobody Tue Mar 22 03:55:38 2022
Return-Path: 
X-Original-To: calsify@ietf.org
Delivered-To: calsify@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AA53A0F5E for ; Tue, 22 Mar 2022 03:55:34 -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.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164794653497.30530.4836425625223071972@ietfa.amsl.com>
Date: Tue, 22 Mar 2022 03:55:34 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [calsify] Milestones changed for calext WG
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Calendaring and Scheduling Standards Simplification 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2022 10:55:35 -0000

Changed milestone "Submit Subscription Upgrade document to IESG for
publication", set due date to April 2022 from January 2022.

Changed milestone "Submit task draft to IESG", set due date to May 2022 from
January 2022, added draft-ietf-calext-ical-tasks to milestone, removed
draft-apthorp-ical-tasks from milestone.

Changed milestone "Submit JSCalendar mapping document to IESG for
publication", set due date to July 2022 from April 2022.

Changed milestone "Submit JSON Contact document to IESG", set due date to
July 2022 from April 2022.

Changed milestone "Submit vpoll document to IESG for publication", set due
date to December 2022 from June 2022.

Changed milestone "Submit Serverside Subscription draft to IESG for
publication", set due date to December 2022 from June 2022.

Changed milestone "Submit calendar series document to IESG for publication",
set due date to December 2022 from July 2022.

URL: https://datatracker.ietf.org/wg/calext/about/


From nobody Tue Mar 22 09:00:07 2022
Return-Path: 
X-Original-To: calsify@ietf.org
Delivered-To: calsify@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 762973A005F; Tue, 22 Mar 2022 08:59:51 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: calsify@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: calsify@ietf.org
Message-ID: <164796479133.30733.395776603250113688@ietfa.amsl.com>
Date: Tue, 22 Mar 2022 08:59:51 -0700
Archived-At: 
Subject: [calsify] I-D Action: draft-ietf-calext-ical-relations-11.txt
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Calendaring and Scheduling Standards Simplification 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2022 15:59:52 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring Extensions WG of the IETF.

        Title           : Support for iCalendar Relationships
        Author          : Michael Douglass
	Filename        : draft-ietf-calext-ical-relations-11.txt
	Pages           : 21
	Date            : 2022-03-22

Abstract:
   This specification updates the iCalendar RELATED-TO property defined
   in RFC5545 by adding new relation types and introduces new iCalendar
   properties LINK, CONCEPT and REFID to allow better linking and
   grouping of iCalendar components and related data.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-calext-ical-relations/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-calext-ical-relations-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-ical-relations-11


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts



From nobody Tue Mar 22 10:17:10 2022
Return-Path: 
X-Original-To: calsify@ietf.org
Delivered-To: calsify@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9695B3A0123; Tue, 22 Mar 2022 10:17:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: calsify@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: calsify@ietf.org
Message-ID: <164796942847.30806.5701380478225528195@ietfa.amsl.com>
Date: Tue, 22 Mar 2022 10:17:08 -0700
Archived-At: 
Subject: [calsify] I-D Action: draft-ietf-calext-subscription-upgrade-06.txt
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Calendaring and Scheduling Standards Simplification 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Mar 2022 17:17:09 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring Extensions WG of the IETF.

        Title           : Calendar subscription upgrades
        Author          : Michael Douglass
	Filename        : draft-ietf-calext-subscription-upgrade-06.txt
	Pages           : 15
	Date            : 2022-03-22

Abstract:
   This specification updates RFC5545 to add the value DELETED to the
   STATUS property.

   This specification also adds values to the Preferences Registry
   defined in RFC7240 to add the subscribe-enhanced-get and limit
   preferences and to the link relations directory defined in RFC8288.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-calext-subscription-upgrade/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-calext-subscription-upgrade-06.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-subscription-upgrade-06


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts



From nobody Tue Mar 22 20:31:04 2022
Return-Path: 
X-Original-To: calsify@ietf.org
Delivered-To: calsify@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 676F13A0D15; Tue, 22 Mar 2022 20:29:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: calsify@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: calsify@ietf.org
Message-ID: <164800618427.30864.12599836574253709012@ietfa.amsl.com>
Date: Tue, 22 Mar 2022 20:29:44 -0700
Archived-At: 
Subject: [calsify] I-D Action: draft-ietf-calext-ical-tasks-03.txt
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Calendaring and Scheduling Standards Simplification 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Mar 2022 03:29:45 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring Extensions WG of the IETF.

        Title           : Task Extensions to iCalendar
        Authors         : Adrian Apthorp
                          Michael Douglass
	Filename        : draft-ietf-calext-ical-tasks-03.txt
	Pages           : 30
	Date            : 2022-03-22

Abstract:
   This document defines extensions to the Internet Calendaring and
   Scheduling Core Object Specification (iCalendar) (RFC5545) to provide
   improved status tracking, scheduling and specification of tasks.

   It also defines how Calendaring Extensions to WebDAV (CalDAV) (RFC
   4791) servers can be extended to support certain automated task
   management behaviours.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-calext-ical-tasks/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-calext-ical-tasks-03.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-ical-tasks-03


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts



From nobody Wed Mar 23 03:00:40 2022
Return-Path: 
X-Original-To: calsify@ietf.org
Delivered-To: calsify@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E823A0D43; Wed, 23 Mar 2022 02:59:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: Bron Gondwana , The IESG , brong@fastmailteam.com, calext-chairs@ietf.org, calsify@ietf.org, draft-ietf-calext-ical-relations@ietf.org, francesca.palombini@ericsson.com, rfc-editor@rfc-editor.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <164802959358.31055.8899660071467186165@ietfa.amsl.com>
Date: Wed, 23 Mar 2022 02:59:53 -0700
Archived-At: 
Subject: [calsify] Protocol Action: 'Support for iCalendar Relationships' to Proposed Standard (draft-ietf-calext-ical-relations-11.txt)
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Calendaring and Scheduling Standards Simplification 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Mar 2022 09:59:57 -0000

The IESG has approved the following document:
- 'Support for iCalendar Relationships'
  (draft-ietf-calext-ical-relations-11.txt) as Proposed Standard

This document is the product of the Calendaring Extensions Working Group.

The IESG contact persons are Murray Kucherawy and Francesca Palombini.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-calext-ical-relations/





Technical Summary

  This spec extends the iCalendar format (RFC5545) to add new
  properties (LINK, CONCEPT and REFID) to allow better linking
  and grouping of related iCalendar records.

Working Group Summary

  This document has been around for a long time and been through
  multiple revisions and discussions since it was first proposed
  in 2013, and first accepted by this working group in 2016.

  The main delay has been my (Bron, document Shepherd) fault, as
  it's had multiple working group last calls, and then I've just
  not gotten around to submitting it until the document expired.
  Blame 2020.

Document Quality

  The extensions to iCalendar are all very easy to understand and
  to implement.  The concepts in this document have already been
  implemented in the jscalendar format (RFC8984) - though there is
  not need to cross-reference them, as that will be done in a
  separate mapping document between the two protocols, which is
  still being finalised, and will reference both this docuement
  and that one (draft-ietf-calext-jscalendar-icalendar).

Personnel

  Document Shepherd - Bron Gondwana (CALEXT co-chair)
  Responsible Area Director - Francesca Palombini



From nobody Wed Mar 23 07:58:08 2022
Return-Path: 
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 171BC3A0141 for ; Wed, 23 Mar 2022 07:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level: 
X-Spam-Status: No, score=-2.107 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=fastmailteam.com header.b=WW3NKRW1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=S3RatrQ+
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 1PvZyGX0afjy for ; Wed, 23 Mar 2022 07:58:01 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B608E3A1500 for ; Wed, 23 Mar 2022 07:57:42 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 32CA0320187F for ; Wed, 23 Mar 2022 10:57:42 -0400 (EDT)
Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Wed, 23 Mar 2022 10:57:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm2; bh=+5gEHhwHe+KLybYutIlXyqErULr0cKbfriYckL auhQ4=; b=WW3NKRW1JBmtaFY2AcUV9tTMhkdoP4hTsO8BEDPCq/mG797GHvGic3 QJvQx1SeccqLrPSOgVPSMKKJyfPiaAK2OxUik/X0V+md0mfjMOqlftQEgwgDOW/K Xj3HtOAo+JP4K04K/OougzgL/isOtjclCF3dDWvIMQicobZbECalO7RZuW7L09Jc xRJHa8No8yk5vjZr71nAteKkj2CqPOBhRBtIILu9qzNCx4L0CSB06xwSgsbe8fPO 9tXsYTJsKHHakl4feSASEJyhVB+kXpQpnmxtadDev6BW35d5Qcs2/5f00tpUviNF LloWXKPcRIA3WMXhbG8352P+Rzc6liKw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date: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=fm3; bh=+5gEHhwHe+KLybYutIlXyqErULr0cKbfriYckLauh Q4=; b=S3RatrQ+J9wUKbg5eSc8TKioku8RZGjZD6P6XfJn6iQiSYxdUzxIb9HYz SAkYQ0wHIpngbjlU7NaurnGkedeYz8Y4tABExAy5ZwuE1KpxqQRjmbeedQ/3uUGI 7QIWY36DUs760NrSQzXukHv+LKR6TBJxxTnS+oiboZ4p/m+2brWGtp+xaOs30ADE cdUCfi8BEBsKBfqdg9U8Wgeps/PYZc/qKmH/Q+9yRdPvzx2ZB3sgSLgRzuL2Yih+ kZMeVUNh/IQ/3aTSSku1XCHRC4nrb6vRoep+Ynlrlu3AVRuuv9+hjxJ3FD22acff /mo2H2paaQCIyzClf6RElCXWijing==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudegjedgieelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvteetieeviefhge eitdegiefgudevleehgfffleegleeuhefhiedtleegtdffgeenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilh htvggrmhdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A99D5AC0E98; Wed, 23 Mar 2022 10:57:41 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-4911-g925b585eab-fm-20220323.003-g925b585e
Mime-Version: 1.0
Message-Id: <5fbb2f1b-9e22-4edd-9188-c66404bc7c61@dogfood.fastmail.com>
Date: Wed, 23 Mar 2022 15:57:21 +0100
From: "Bron Gondwana" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=7e782ce9f7b349629de8eefc21ed5667
Archived-At: 
Subject: [calsify] Minutes for IETF113 uploaded
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Calendaring and Scheduling Standards Simplification 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Mar 2022 14:58:06 -0000

--7e782ce9f7b349629de8eefc21ed5667
Content-Type: text/plain

Hi all,

I've uploaded the notes from the meeting yesterday at IETF113.  There were really two bits of action from this meeting, simple and complex!

*Simple:
*
 * Mike to upload new subscription-upgrade, then WGLC from Bron
 * Robert/Mario to continue work on jscontact
*Complex:*
 * Bron to put a "call for adoption of changes" for a 5 part series of documents.
   * Tasks to be released basically as-is with an eye for jscalendar alignment
   * NEW jscalendar-bis
   * NEW icalendar-geo -> convert to URI type
   * NEW icalendar-subsecond-support
   * UPDATE jscalendar-icalendar mapping to be proposed-standard (standards track)

I'm going to do a generalised "call for adoption of this plan", and take a lack of dissent as being support for doing it all en-mass rather than doing separate calls for adoption for each document.

Cheers,

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


--7e782ce9f7b349629de8eefc21ed5667
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


Hi all,

I'v=
e uploaded the notes from the meeting yesterday at IETF113.  There =
were really two bits of action from this meeting, simple and complex!

Simple:
  • Mi=
ke to upload new subscription-upgrade, then WGLC from Bron
  • Robert/Mario to continue work on jscontact
Complex:
<=
ul>
  • Bron to put a "call for adoption of =
changes" for a 5 part series of documents.
    • Tasks to be released basically as-is with an eye for jsc=
alendar alignment
    • NEW jscalenda=
r-bis
    • NEW icalendar-geo -> c=
onvert to URI type
    • NEW icalenda=
r-subsecond-support
    • UPDATE jsca=
lendar-icalendar mapping to be proposed-standard (standards track)

    =

    I'm going to do a generalised "call fo=
r adoption of this plan", and take a lack of dissent as being support fo=
r doing it all en-mass rather than doing separate calls for adoption for=
 each document.

    Cheers,

    Bron.
    --
    &nbs=
p; Bron Gondwana, CEO, Fastmail Pty Ltd
      brong@fastmailteam.com


    
--7e782ce9f7b349629de8eefc21ed5667--


From nobody Wed Mar 23 08:06:22 2022
Return-Path: 
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 20D0F3A1748 for ; Wed, 23 Mar 2022 08:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level: 
X-Spam-Status: No, score=-2.106 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_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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=fastmailteam.com header.b=cCfXB4Zz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YduMxDEi
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 WcgzQmY4edch for ; Wed, 23 Mar 2022 08:05:42 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC3E3A172A for ; Wed, 23 Mar 2022 08:05:42 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id BD8703202056 for ; Wed, 23 Mar 2022 11:05:41 -0400 (EDT)
Received: from imap43 ([10.202.2.93]) by compute5.internal (MEProxy); Wed, 23 Mar 2022 11:05:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to; s=fm2; bh=Wp5mCOsko3XhvGJT+35Yxz7UwyaHSLzHNZudCk 9hnsM=; b=cCfXB4ZzlcGdwG67GXP0sCWkhmyh+hGHdRH/R+yW0nezIPGhDbQlB7 s8Joc0T18L31Od+IxPtTdw8qadceSn//QNQbF1vwtWJ+vgxKu+lRUOrvvooGbHrW M5lH3ztqbqmkKClvqE5YLKpIxIisGZwPl8wTN0zZG9+f/tyNarBuYRSHFloilNQG vLkcWSUBjUS6o90hTewbbUoMQGM5iKNRrdBZzH8gPDrIXV2yoqe/Z45yl5H89Bp0 VH6Ri9ZP+qSNcFK4TSSLN+nt6jRvX0m3l9NMpiPUY1oqzh0KVQmbR5YBPVKMR73m Y2kpgVMUDHi/6lzaY3dJoAOgfaobdilw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date: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=fm3; bh=Wp5mCOsko3XhvGJT+35Yxz7UwyaHSLzHNZudCk9hn sM=; b=YduMxDEieaOW1HolwEkVzF6lCvO/g6wK2ViQkDxcRMfCWyAe1cvi4cfms 3tbfbULCrGpLj0wXqRJ9aOm/rorNyeLV3/biRylevfi3MbJ/24WVdNklaMSVCuPJ j54yOoAac9I+bKEX5i7L2WoQRNm6zXPtkmlemI0kbBtu5JU//Lv44JLmQzbJhCNE qkgi9TYg8AUyi6Cq9zb0327gKX6W9yXg1G3lP9OQMwGRDxTJrhKVZGwazr1ORwPH K4VmMh7SGkh+iOwyJ+UnWrpK613XfyynrAzxj1ohXUdSU7M+JVmMJlhf1xxd/3fb aeRReIJV36LEDvJZYdSj8y5iZjCGg==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudegjedgjedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvteetieeviefhge eitdegiefgudevleehgfffleegleeuhefhiedtleegtdffgeenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilh htvggrmhdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 14961AC0E98; Wed, 23 Mar 2022 11:05:41 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-4911-g925b585eab-fm-20220323.003-g925b585e
Mime-Version: 1.0
Message-Id: <30c53c4f-e432-45ed-9fb1-de58f02aae0e@dogfood.fastmail.com>
Date: Wed, 23 Mar 2022 16:05:15 +0100
From: "Bron Gondwana" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=5f08693924f940d4acd2b248b8698650
Archived-At: 
Subject: [calsify] Call for adoption of jscalendar alignment plan
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Calendaring and Scheduling Standards Simplification 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Mar 2022 15:05:55 -0000

--5f08693924f940d4acd2b248b8698650
Content-Type: text/plain

Hi All,

Rather than doing a separate series of "call for adoption" on documents, I'm doing a call for adoption of an entire plan here.  The plan was discussed during the CALEXT session at IETF113 and received support there.  Here's the plan.

*Intent:**
*

Fully align jscalendar and icalendar formats, to allow lossless conversion between them, with the mapping document being changed from informational to standards track.  The end result will be jscalendar and icalendar being aligned, and all future specs will be updates to BOTH RFC5545 and jscalendar-bis.

*Steps:*
 * new doc: icalendar extension for subsecond support (separate document so only those who care need implement it)
 * new doc: updates to RFC5545, for the fields that are needed to represent non-subsecond things from jscalendar.
 * new doc: jscalendar-bis, roll in technical eratta and ensure alignment with everything else needed by the mapping document.
 * changed status: jscalendar-icalendar changes from information to proposed-standard.  Publish as a group with jscalendar-bis and the icalendar updates.

If you have any objections to this plan, or questions you wanted answered before all these documents are adopted and updated, please reply to this message by Friday April 8th.  Feel free to reply with support and offers to author/review parts of this too!

Thanks,

Bron.

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


--5f08693924f940d4acd2b248b8698650
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


    Hi All,

    Rat=
her than doing a separate series of "call for adoption" on documents, I'=
m doing a call for adoption of an entire plan here.  The plan was d=
iscussed during the CALEXT session at IETF113 and received support there=
.  Here's the plan.

    Intent:

    Fully align jscalendar and icalendar formats, to allow lossless convers=
ion between them, with the mapping document being changed from informati=
onal to standards track.  The end result will be jscalendar and ica=
lendar being aligned, and all future specs will be updates to BOTH RFC55=
45 and jscalendar-bis.

    Steps:
    • new doc: icalendar extension for subsecond sup=
port (separate document so only those who care need implement it)
    • new doc: updates to RFC5545, for the =
fields that are needed to represent non-subsecond things from jscalendar=
.
    • new doc: jscalendar-bis, roll=
 in technical eratta and ensure alignment with everything else needed by=
 the mapping document.
    • changed =
status: jscalendar-icalendar changes from information to proposed-standa=
rd.  Publish as a group with jscalendar-bis and the icalendar updat=
es.

    If you have any objections to this plan, or questio=
ns you wanted answered before all these documents are adopted and update=
d, please reply to this message by Friday April 8th.  Feel free to =
reply with support and offers to author/review parts of this too!

    Thanks,

    Bron.

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


    
--5f08693924f940d4acd2b248b8698650--


From nobody Tue Mar 29 05:08:53 2022
Return-Path: 
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 47A5F3A11CE; Tue, 29 Mar 2022 05:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level: 
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 bYxd-xm62los; Tue, 29 Mar 2022 05:08:46 -0700 (PDT)
Received: from mail.audriga.com (mail.audriga.com [176.221.42.35]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69BA23A11F3; Tue, 29 Mar 2022 05:08:46 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.audriga.com (Postfix) with ESMTP id 27801A0FA; Tue, 29 Mar 2022 14:08:40 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mail.audriga.com
Received: from mail.audriga.com ([127.0.0.1]) by localhost (mail.audriga.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3nx3NU1XybV; Tue, 29 Mar 2022 14:08:37 +0200 (CEST)
Received: from [192.168.0.134] (ip-046-223-162-244.um13.pools.vodafone-ip.de [46.223.162.244]) (Authenticated sender: joris@audriga.com) by mail.audriga.com (Postfix) with ESMTPSA id BCBA8A0B6; Tue, 29 Mar 2022 14:08:37 +0200 (CEST)
Content-Type: multipart/alternative; boundary="------------2V0P7Gpt2ttiQdXkqvYSeKdc"
Message-ID: <32d05385-b458-696c-96a6-a97a2409a090@audriga.com>
Date: Tue, 29 Mar 2022 14:08:37 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: calsify@ietf.org, jmap@ietf.org
Cc: =?UTF-8?Q?Happel_Hans-J=c3=b6rg?= 
References: 
From: Joris Baum 
In-Reply-To: 
Archived-At: 
Subject: [calsify] draft-ietf-calext-ical-tasks-03 Review
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Calendaring and Scheduling Standards Simplification 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Mar 2022 12:08:51 -0000

This is a multi-part message in MIME format.
--------------2V0P7Gpt2ttiQdXkqvYSeKdc
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,


I just had a look at the draft-ietf-calext-ical-tasks-03 spec. In 
general, it looks good to me. Most of my comments are small things which 
might or might not require some more clarification.

General note: Typically, collaborative software development tools allow 
tracking the changes to any task property. Such a "history"-feature is 
most likely out of scope for that draft, but it looks like `VSTATUS` 
could be used (to some extent) for that feature. Maybe it would make 
sense to state in the draft that tracking history of all properties is 
not covered by the spec?

Section 4:

  * Task Actors mentions "Organizer" as an actor. In the picture, it is
    not part of that group. I suggest to either leave it out in the text
    or change the group name in the picture (probably the latter).
  * The Task Actors roles seem to be purely informational. Maybe it
    would make sense to specify how they are supposed to be mapped to an
    iCalendar equivalent, like `ORGANIZER`?

Section 12.2:

  * A "name-space" is mentioned, but it seems to be not defined what a
    "name-space" should look like.
  * When using IANA registered values for `REASON` as done in one of the
    examples (`REASON:out-of-office`) do not seem to be of `URI` type. I
    guess that is not in line with its definition?


The following are probably merely minor notes (about spelling, style and 
copy+paste errors). You would probably have found them yourself before a 
WGLC, but I think it does not hurt to include them:

Section 7.2:

  * "See section 3.1.3 Task Domain Data Handling." You probably meant
    section 7.3 ?
  * "Extensions [Doug114] to the RELATED-TO" Reference not included. You
    probably meant draft-ietf-calext-ical-relations ?
  * REL is used as a param in the examples, e.g.
    `LINK;REL="vacation-system";VALUE=URI:http://example.com/vacation-approval?id=1234`.
    But it is not part of draft-ietf-calext-ical-relations. I guess it
    comes from an earlier version of the spec?

Section 9: "In addition a number of different patterns of resource or 
assignee identification are anticipated." - "In addition, a number of 
different patterns of resource or assignee identification are 
anticipated." (very minor, but it confused me for a short while)

Section 10.3: "As situations chnage further VSTATUS components" → "As 
situations change further VSTATUS components"

Section 10.4:

  * "Alarms (VLARM components)" → "Alarms (VALARM components)"
  * "Task Generating System, e.g., a BPMS" → Maybe specify what a BPMS
    is. However, Wikipedia seems to understand it.

Section 19: I am unable to open or find the [TARCH] reference?


Regards,

Joris


-- 
Joris Baum
Tel: +49 721 170293 16
Fax: +49 721 170293 179

http://www.audriga.com  |http://www.twitter.com/audriga

--------------------------------------------------------------------------
audriga GmbH | Alter Schlachthof 57 | 76137 Karlsruhe
Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
--------------------------------------------------------------------------

--------------2V0P7Gpt2ttiQdXkqvYSeKdc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
    Hi,
    
    

    
    
    
    
    I just had a look at the draft-ietf-calext-ical-tasks-03 spec. In
      general, it looks good to me. Most of my comments are small things
      which might or might not require some more clarification.
    
    
    General note: Typically, collaborative software development tools
      allow tracking the changes to any task property. Such a
      "history"-feature is most likely out of scope for that draft, but
      it looks like `VSTATUS` could be used (to some extent) for that
      feature. Maybe it would make sense to state in the draft that
      tracking history of all properties is not covered by the spec?
    
    
    Section 4: 
    
    
    
    
      
      
    • Task Actors mentions "Organizer" as an actor. In the picture,
        it is not part of that group. I suggest to either leave it out
        in the text or change the group name in the picture (probably
        the latter).
      • 
      
    • The Task Actors roles seem to be purely informational. Maybe
        it would make sense to specify how they are supposed to be
        mapped to an iCalendar equivalent, like `ORGANIZER`?
      • 
    
    
    
    Section 12.2:
    
    
      
      
    • A "name-space" is mentioned, but it seems to be not defined
        what a "name-space" should look like.
      
      
      • 
      
    • When using IANA registered values for `REASON` as done in one
        of the examples (`REASON:out-of-office`) do not seem to be of
        `URI` type. I guess that is not in line with its definition?
      • 
    
    
    

    
      The following are probably merely minor notes (about spelling,
      style and copy+paste errors). You would probably have found them
      yourself before a WGLC, but I think it does not hurt to include
      them:
    
    
    
    
    
    
    
    
    Section 7.2:
    
    
      
      
    • "See section 3.1.3 Task Domain Data Handling." You probably
        meant section 7.3 ?
      • 
      
    • "Extensions [Doug114] to the RELATED-TO" Reference not
        included. You probably meant draft-ietf-calext-ical-relations ?
      • 
      
    • REL is used as a param in the examples, e.g.
`LINK;REL="vacation-system";VALUE=URI:http://example.com/vacation-approval?id=1234`.
        But it is not part of draft-ietf-calext-ical-relations. I guess
        it comes from an earlier
        version of the spec?
      • 
    
    
    
    Section 9: "In addition a number of different patterns of
      resource or assignee identification are anticipated." - "In
      addition, a number of different patterns of resource or assignee
      identification are anticipated." (very minor, but it confused me
      for a short while)
    
    
    Section 10.3: "As situations chnage further VSTATUS components" →
      "As situations change further VSTATUS components"
    
    
    Section 10.4:
    
    
      
      
    • "Alarms (VLARM components)" → "Alarms (VALARM components)"
      • 
      
    • "Task Generating System, e.g., a BPMS" → Maybe specify what a
        BPMS is. However, Wikipedia seems to understand it.
      • 
    
    
    
    Section 19: I am unable to open or find the [TARCH] reference?
    
    
    
    

    
    
    
    
    Regards,
    
    
    Joris
    
    

    
    
    
    
    -- 
Joris Baum
Tel: +49 721 170293 16
Fax: +49 721 170293 179

http://www.audriga.com | http://www.twitter.com/audriga

--------------------------------------------------------------------------
audriga GmbH | Alter Schlachthof 57 | 76137 Karlsruhe
Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
--------------------------------------------------------------------------
    
  


--------------2V0P7Gpt2ttiQdXkqvYSeKdc--