From nobody Wed Jun 10 05:31:59 2020 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 A8F883A0593 for ; Wed, 10 Jun 2020 05:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=neoAMV89; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fYunDAhF 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 omvUOYm5x5t1 for ; Wed, 10 Jun 2020 05:31:55 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA983A0484 for ; Wed, 10 Jun 2020 05:31:55 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6EF695C0192 for ; Wed, 10 Jun 2020 08:31:54 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 10 Jun 2020 08:31:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=xfTN57c ugna1SFetfR8hH+F6yQnYMuYkGv5NZJZxcEM=; b=neoAMV89LkE1D4rIh8lH0Dl sK2QKtRlF36eqptICDUQgVLJx12FHYTVQQ2XekNAx7P395De8g1xxgSv6u503IS8 +bbli+sRFHfZPlfBbr5cVQhEYLyJpfGvDh0XJr65V1i3gWjVIwm0fIuNuHo8hGjU R+AlxCPXSX4lsChnyXphshkESnplXjC7tJDUpRkCXLlIAhHPsY2PtLTzPTE1fyhL u3afmybrlCd8co1fYbLt5WT1hPcdgdeJNX/mVESBsHYf86I5EvXY5JifLR0GvOZW R3Hm86Fy1YGCxkWBWDV41Gx+8hVtAbfXPm52qy6H0IGreREPzc5FG4beqxyB6lw= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=xfTN57 cugna1SFetfR8hH+F6yQnYMuYkGv5NZJZxcEM=; b=fYunDAhFZSocGb1vWa3i1P knALmE2zza5Pf/nRWwqBCqxPyOSfxIVxKV1pVAYP9tTS8OfQUf4XHKcwdmzR1W+L s03US/09bLMVP/zIDZ7oxWncZGV9/irK2/3CNRknD2aash2XP3VU+AdT8p/ZHzJ4 5eNQrKAyoh4yRh/klIcJ/Y38XrGqEqOPMrFGSN0B9z/QPAWT+UMJXVSq8pyxMGCJ 3F2gyi6m5aVOvlLKWjU0PpYBwlROK/qZLR1jgQuvgUUJruztrtDFsB70QAwYPGA4 UZHaiJSD5AqSbOD8D6GljRiiahFJg+wZvkhWVdzvbKHd4HGgM7ilyLQnGLXmR/gQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehiedgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffvdekfeegle eiueettddtffehveevffefkeduvddttdekiefgjeduvdfhvdduleenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E4B65180091; Wed, 10 Jun 2020 08:31:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990 Mime-Version: 1.0 Message-Id: <5742d7f7-4a77-4f53-a46d-2125e7c2b4d9@dogfood.fastmail.com> In-Reply-To: <1e51cd80-feac-4fbf-87dd-5528599d836d@dogfood.fastmail.com> References: <1e51cd80-feac-4fbf-87dd-5528599d836d@dogfood.fastmail.com> Date: Wed, 10 Jun 2020 22:31:33 +1000 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=c936a35ac1b94924a9b9b274d9d71095 Archived-At: Subject: Re: [calsify] =?utf-8?q?Working_Group_Last_Call=3A_draft-ietf-calext?= =?utf-8?q?-valarm-extensions-01?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 12:31:57 -0000 --c936a35ac1b94924a9b9b274d9d71095 Content-Type: text/plain Obviously, that date came and went and I got sidetracked with other things. I will submit this document and we don't need to put it on the agenda for the interim next week! Cheers, Bron. On Wed, Apr 22, 2020, at 22:29, Bron Gondwana wrote: > As there's been no feedback on the list about this document and Ken believes it's complete, we agreed in yesterday's interim meeting to take this one to WGLC. > > We'll make it 3 weeks, so you have until *Wednesday 13 May *to review and respond to this document. > > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --c936a35ac1b94924a9b9b274d9d71095 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Obviously, that date came and went and I got sidetrac= ked with other things.  I will submit this document and we don't ne= ed to put it on the agenda for the interim next week!

Che= ers,

Bron.
On Wed, Apr 22, 2020, at 22:29, Bron Gondwana wrote:
As there's been no feedback on the list about this document a= nd Ken believes it's complete, we agreed in yesterday's interim meeting = to take this one to WGLC.
We'll make it 3 weeks, so you = have until Wednesday 13 May to review and respond to this documen= t.

Cheers,
Bron.

--
=
  Bron Gondwana, CEO, Fastmail Pty Ltd
  br= ong@fastmailteam.com


____________________________________________= ___
calsify mailing list


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


--c936a35ac1b94924a9b9b274d9d71095-- From nobody Thu Jun 11 03:19:18 2020 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 CDB103A17EB for ; Thu, 11 Jun 2020 03:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=N0Wx77ia; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jutj9G01 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 YPwGgIiRXZ6L for ; Thu, 11 Jun 2020 03:19:15 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C7F3A17E9 for ; Thu, 11 Jun 2020 03:19:15 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id B94F9A73; Thu, 11 Jun 2020 06:19:14 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 11 Jun 2020 06:19:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=1PLl SdM1F01NluKvNTUKl1RsGth+Nga+LsXr1Jghsf8=; b=N0Wx77iaBBjHpu2/Sfr6 vPXbDryElhK6HjwJEBtEOqrhkqF4uAjSrVwOBGzKdLgeBBL9/fM9YkF99pOTCLnC +YUx66DT4JOYIyqz7NDduaW38+EGVrYzUXP6IMtsHbWCGp5OyIhotKhQmOGILgCa rsav4i6pRjzmwnx6EyTYf1HAESc8GQ/QF/E298JiQHV+hO50ghRwtNM2n7LKEeoC NL7gjNiTSTvgZfBcqii9xq7YuvCWqCxF6d/4KaFGBoCL4c5baM3N2UECbvlaIeg3 rh6Ievoiqb0p6M6BhVnmzpoKPpbVnTilZc/8QSDKVPgGlqcCFV6rrUgNWfJ1Dqgg rA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=1PLlSd M1F01NluKvNTUKl1RsGth+Nga+LsXr1Jghsf8=; b=jutj9G01SZBi7CgIJlvb8A wNU7WsoF+cT5WSqZJq6F8lWhHOcdFj98FOdU/lCNDl0NmbSnhh+JaKGQ6r57ANGi G2s+HE/52Q1VgHVN2VuVGQhDkkUn3Ll8HqaldjtbqiL1xhTLTfnMDoGjrg7fT9LQ rDl2LeKrvlG+fJtmSGu+WjNLC2d1h71Bi/MjlXRudmoALVHYVtFWez8B3C3Cvwhk oAQ1WddzT23yz2eumVOASyfuOo4qnnIMXwgxUTl42TqQ9s+1P/OXQtpqORv00ZuA j+2I+y9JvfH8B8DJr16uq5TVzxT/TMk4g1x8dayRV5vpZKHTPp7eWy0CzapbBywg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudehledgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepffdvkeefgeelieeutedttdffheevvefffeekuddvtddt keeigfejuddvhfdvudelnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhm rghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1D64F180091; Thu, 11 Jun 2020 06:19:14 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990 Mime-Version: 1.0 Message-Id: <8d865dbc-73c5-49df-8533-71f302912a5d@dogfood.fastmail.com> In-Reply-To: <280f31e7-ffdc-4ef0-a95e-aa03dc40a28a@dogfood.fastmail.com> References: <280f31e7-ffdc-4ef0-a95e-aa03dc40a28a@dogfood.fastmail.com> Date: Thu, 11 Jun 2020 20:18:53 +1000 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=4216a238d3a84e55ae8efee5e7e62425 Archived-At: Subject: Re: [calsify] =?utf-8?q?Call_for_adoption=3A_draft-douglass-serversi?= =?utf-8?q?de-subscriptions?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 10:19:17 -0000 --4216a238d3a84e55ae8efee5e7e62425 Content-Type: text/plain Mike, there were no objections! Sorry I dropped the ball on following up on this. If you could please upload the document as: draft-ietf-calext-serverside-subscriptions I'll approve it, and put it on the agenda for the interim meeting next week. Cheers, Bron. On Wed, Apr 22, 2020, at 22:22, Bron Gondwana wrote: > The draft is expired, but it's here: https://datatracker.ietf.org/doc/draft-douglass-serverside-subscriptions/ > > As per the virtual interim meeting yesterday, there is interest in this work. > > This draft would be a starting point, but is not necessarily the final product. > > If you have any issues with this working group taking on the work, please reply here by *Wednesday May 6th.* > > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --4216a238d3a84e55ae8efee5e7e62425 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Mike, there were no objections!  Sorry I dropped= the ball on following up on this.  If you could please upload the = document as:

draft-ietf-calext-serverside-subscriptions

I'll approve it, and put it on the agenda for the interim = meeting next week.

=
Cheers,

Bron.

On Wed, Apr 22, 2020, at 22:22, Bron Gond= wana wrote:
The draft is expired, but it's here: https://datatracker.ietf.org/doc/draft-douglass-serverside-subs= criptions/

As per the virtual interim meeting yesterd= ay, there is interest in this work.

This draft would be a= starting point, but is not necessarily the final product.

If you have any issues with this working group taking on the work, ple= ase reply here by Wednesday May 6th.

Cheers,

Bron.

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

___= ____________________________________________
calsify maili= ng list
<= br>

--
  Bron Gondwana, CEO, Fastm= ail Pty Ltd
  brong@fastmailteam.com

--4216a238d3a84e55ae8efee5e7e62425-- From nobody Sun Jun 14 16:53:24 2020 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 9DD1C3A077A; Sun, 14 Jun 2020 16:53:22 -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.3.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <159217880258.24163.5139578826247270468@ietfa.amsl.com> Date: Sun, 14 Jun 2020 16:53:22 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-27.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2020 23:53:23 -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 : JSCalendar: A JSON representation of calendar data Authors : Neil Jenkins Robert Stepanek Filename : draft-ietf-calext-jscalendar-27.txt Pages : 78 Date : 2020-06-14 Abstract: This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format, and to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also JSON-based, JSCalendar is not a direct mapping from iCalendar, but defines the data model independently and expands semantics where appropriate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-27 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-27 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 15 12:48:57 2020 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 54FC93A0D2D for ; Mon, 15 Jun 2020 12:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NfvSG1vBG0bZ for ; Mon, 15 Jun 2020 12:48:53 -0700 (PDT) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 4AEB43A0D26 for ; Mon, 15 Jun 2020 12:48:53 -0700 (PDT) Received: by mail-vk1-xa33.google.com with SMTP id s6so1035979vkb.9 for ; Mon, 15 Jun 2020 12:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qKM57f7SBspf+iWQDM8QKgR92Ma6vR5OIKrHGbuWuQo=; b=IOivOXUGV0e5WMXcqndFFbVZFKs0ZQ3fF548s8lKOGji0/8owpmkF0RqM4S+38sUSj 4SxwY1KtzHu55N82VP/mDmYdOh7AvkylI9GZJTg1+OdhSABDMFw1iCirsdAHum3AxWJP HRzcreN0VZCb8sU3WRLpQcwqeVMjZgpUYrhD+U1kDd8Bdd7b1XIQW+hqB1TD1sUKXMeS AdNIP2mIodT83hxQr9dzXXxxDyxEdPnzSh+DBHibr2BaxvBHShwJ/Q2KWSkg0gDfr0rN V6aVhlX8SkrhIOcEQu+pJrLEGhh+14JlSDJfZ/+PHsc5R6p/1wmEh9i75pagGgdGvOOV DrgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qKM57f7SBspf+iWQDM8QKgR92Ma6vR5OIKrHGbuWuQo=; b=LzpObUkuM89wFSqUd2taD1m3SucBMUSDvPLle08rTriCpovQdvmaObtrzuFTCuv6oX yKH0/VOUDyYkiGxcmyp2+ewTyH8/5PtWsoKDjR2X3OjNA++Kl2joY959Y7HXqkchIfJr 5tsZmmgJY1ZtQmzWiClCbR/C1HOup5b/doBsnLpt81ztZFWkieIYKPAGqUM/+IaaVGTq K853hBN5B08mypWo0uF/LjKEmE18AwgbUc2//rItYs3vPIP8M3KuH7Oukvx8QHBYc2QL Nckq5HD1XpGBWxHZhSn0x11iDHglEV1M5dKb8oUQyPsCA0VxknLwfYnnPJmBXzxLBvOe +nYw== X-Gm-Message-State: AOAM531yAFxUTFEm4n5XDHV61bCq/MBs4hSbUNSmOx7r6bXiWCvYEMzd VcarPETgwNrL3mZdhqpja/CFI8p7/njKApiKeuxLDzTo X-Google-Smtp-Source: ABdhPJyInj7KhHs2yZuKuZ4NXumkHykrS5Lpi+cJZm5HWzHZ97xg2JzuTc200Qjrpp3pUzh0/WP92UwNg3wsA+w7BeM= X-Received: by 2002:a05:6122:33a:: with SMTP id d26mr20347090vko.30.1592250531881; Mon, 15 Jun 2020 12:48:51 -0700 (PDT) MIME-Version: 1.0 References: <1e51cd80-feac-4fbf-87dd-5528599d836d@dogfood.fastmail.com> <5742d7f7-4a77-4f53-a46d-2125e7c2b4d9@dogfood.fastmail.com> In-Reply-To: <5742d7f7-4a77-4f53-a46d-2125e7c2b4d9@dogfood.fastmail.com> From: Daniel Migault Date: Mon, 15 Jun 2020 15:48:40 -0400 Message-ID: To: Bron Gondwana Cc: IETF-Calsify Content-Type: multipart/alternative; boundary="00000000000058a80e05a824b7f5" Archived-At: Subject: Re: [calsify] Working Group Last Call: draft-ietf-calext-valarm-extensions-01 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 19:48:56 -0000 --00000000000058a80e05a824b7f5 Content-Type: text/plain; charset="UTF-8" Hi, I apologize for the very late comments. I hope this helps and I do not believe this goes beyond nits in any cases. Yours, Daniel VALARM Extensions for iCalendar draft-ietf-calext-valarm-extensions-01 1. Introduction The iCalendar [RFC5545] specification defines a set of components used to describe calendar data. One of those is the "VALARM" component which appears as a sub-component of "VEVENT" and "VTODO" components. The "VALARM" component is used to specify a reminder for an event or task. Different alarm actions are possible, as are different ways to specify how the alarm is triggered. As iCalendar has become more widely used and as client-server protocols such as CalDAV [RFC4791] have become more popular, several I guess there is an wording issue. I suppose that " have become more popular" should be removed. [ ... ] 3. Extensible syntax for VALARM Section 3.6.6 of [RFC5545] defines the syntax for "VALARM" components and properties within them. However, as written, it is hard to extend this by adding, e.g., a new property common to all types of alarm. Since many of the extensions defined in this document need to extend the base syntax, an alternative form for the base syntax is defined here, with the goal of simplifying specification of the extensions. A "VALARM" calendar component is re-defined by the following notation: alarmcext = "BEGIN" ":" "VALARM" CRLF alarmprop "END" ":" "VALARM" CRLF alarmprop = *( ; the following are REQUIRED, ; but MUST NOT occur more than once action / trigger / Daboo & Murchison Expires July 20, 2020 [Page 3] Internet-Draft VALARM Extensions January 2020 ; one set of action properties MUST be ; present and MUST match the action specified ; in the ACTION property actionprops / ; the following is OPTIONAL, ; and MAY occur more than once x-prop / iana-prop ) actionprops = audiopropext / disppropext / emailpropext I believe this should go after *ext have been defined, though I am not very familiar with ABNF. audiopropext = *( ; 'duration' and 'repeat' are both OPTIONAL, ; and MUST NOT occur more than once each, ; but if one occurs, so MUST the other duration / repeat / ; the following is OPTIONAL, ; but MUST NOT occur more than once attach ) disppropext = *( ; the following are REQUIRED, ; but MUST NOT occur more than once description / ; 'duration' and 'repeat' are both OPTIONAL, ; and MUST NOT occur more than once each, ; but if one occurs, so MUST the other duration / repeat ) emailpropext = *( ; the following are all REQUIRED, Daboo & Murchison Expires July 20, 2020 [Page 4] Internet-Draft VALARM Extensions January 2020 ; but MUST NOT occur more than once description / summary / ; the following is REQUIRED, ; and MAY occur more than once attendee / ; 'duration' and 'repeat' are both OPTIONAL, ; and MUST NOT occur more than once each, ; but if one occurs, so MUST the other duration / repeat I have the impression that attach is missing as OPTIONAL that MAY appear more than once. 4. Alarm Unique Identifier This extension adds a "UID" property to "VALARM" components to allow a unique identifier to specified. The value of this property can to be specified then be used to refer uniquely to the "VALARM" component. [ ... ] 6. Alarm Acknowledgement There is currently no way for a "VALARM" component to indicate whether it has been triggered and acknowledged. With the advent of a standard client/server protocol for calendaring and scheduling data ([RFC4791]) it is quite possible for an event with an alarm to exist on multiple clients in addition to the server. If each of those is responsible for performing the action when an alarm triggers, then multiple "alerts" are generated by different devices. In such a situation, a calendar user would like to be able to "dismiss" the alarm on one device and have it automatically dismissed on the others too. It is probably due to my lake of expertise, but I have the impression the acknowledgment properties only works under some conditions. Typically, I imagine that devices not being connected, are hosting the VALARMS components locally, in which case, these devices will not consider the acknowledgment properties. Similarly, when devices are connected to a centralized calendar, I suppose - but might completely wrong - that the alarms are simultaneously sent to the various devices. The ability to switch off all alarms relies on the ability of these devices to be able to synch the calendar objects. I am wondering if most systems have a push mechanism to "switch off" the alarms on the other devices. [ ... ] 6.1. Acknowledged Property Property Name: ACKNOWLEDGED Purpose: This property specifies the UTC date and time at which the corresponding alarm was last sent or acknowledged. Value Type: DATE-TIME Property Parameters: IANA and non-standard property parameters can be specified on this property. Conformance: This property can be specified within "VALARM" calendar components. Description: This property is used to specify when an alarm was last sent or acknowledged. This allows clients to determine when a pending alarm has been acknowledged by a calendar user so that any alerts can be dismissed across multiple devices. It also allows clients to track repeating alarms or alarms on recurring events or to-dos to ensure that the right number of missed alarms can be tracked. Clients SHOULD set this property to the current date-time value in UTC when a calendar user acknowledges a pending alarm. Certain kinds of alarm may not provide feedback as to when the calendar user sees them, for example email based alerts. For those kinds of alarms, the client SHOULD set this property when the alarm is triggered and the action successfully carried out. When an alarm is triggered on a client, clients can check to see if an "ACKNOWLEDGED" property is present. If it is, and the value of that property is greater than or equal to the computed trigger time for the alarm, then the client SHOULD NOT trigger the alarm. Just for clarification, I assume that the computed trigger time defined by the TRIGGER property corresponds in the case of a repeated alarm to the first occurence of the alarm. and the control only apply to the repeated alarms. More specifically, unless I am missing something, it seems hard to me to have an ACKNOWLEDGED time before the alarm is triggered for the first time. I suspect some checks should be done on the acknowledged time and make sure the time is not in the future. [ ... ] 9. Security Considerations VALARMs, if not monitored properly, can be used to "spam" users and/ or leak personal information. For instance, an unwanted audio or display alert could be considered spam. Or an email alert could be used to leak a user's location to a third party or to send unsolicited email to multiple users. Therefore, CalDAV clients and servers that accept iCalendar data from a third party (e.g. via iTIP [RFC5546], a subscription feed, or a shared calendar) SHOULD remove all VALARMs from the data prior to storing in their calendar system. As an attacker, I am wondering if I can format also an acknowledgment or snoozing property to avoid or limit the alarm. Suppose I am able to provision an acknowledgment property with a time greater than the computed triggered time. Unless the system controls the acknowledged time from the client, it seems to me feasible that the acknowledged time is set in the future. Even with such control, it could also disable the repeat properties. I am also wondering how loosely synchronized devices may interfere between each other. I do not see major issues as the time is always related to the time of the event. Loose time synchronization does not seem - but I might be wrong - the calendar objects, but will impact the time acknowledgment / snoozing properties are received, if there are any checks. 10. Privacy Considerations Proximity VALARMs, if not used carefully, can leak a user's past, present, or future location. For instance, storing an iCalendar resource containing proxmity VALARMs to a shared calendar on CalDAV server can expose to anyone that has access to that calendar the user's intent to leave from or arrive at a particular location at some future time. Furthermore, if a CalDAV client updates the shared iCalendar resource with an ACKNOWLEDGED property when the alarm is I think that is an additional ACKNOWLEDGED property. While PROXIMITY gives an exact location, the intention. I am unsure about the information ACKNOWLEDGE by itself provides (without proximity). Typically, as far as I understand, it indicates the user has seen the alarm, but does not give the reason that is whether he is willing to ignore the alarm or going to the event itself. Am I missing something ? triggered, will leak the exact date and time that the user left from or arrived at the location. Therefore, CalDAV clients that implement proximity alarms SHOULD give users the option of storing and/or acknowledging the alarms on the local device only and not storing the alarm and/or acknowledgment on a remote server. On Wed, Jun 10, 2020 at 8:32 AM Bron Gondwana wrote: > Obviously, that date came and went and I got sidetracked with other > things. I will submit this document and we don't need to put it on the > agenda for the interim next week! > > Cheers, > > Bron. > > On Wed, Apr 22, 2020, at 22:29, Bron Gondwana wrote: > > As there's been no feedback on the list about this document and Ken > believes it's complete, we agreed in yesterday's interim meeting to take > this one to WGLC. > > We'll make it 3 weeks, so you have until *Wednesday 13 May *to review and > respond to this document. > > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Daniel Migault Ericsson --00000000000058a80e05a824b7f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I apologize for the very late= comments. I hope this helps and I do not believe this goes beyond nits in = any cases.

Yours,=C2=A0
Daniel


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 VALARM Extensions for iCalendar
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-calext-valarm-extensions-0= 1

1.=C2=A0 Introduction

=C2=A0 =C2=A0The iCalendar [RFC5545] = specification defines a set of components
=C2=A0 =C2=A0used to describe = calendar data.=C2=A0 One of those is the "VALARM"
=C2=A0 =C2= =A0component which appears as a sub-component of "VEVENT" and &qu= ot;VTODO"
=C2=A0 =C2=A0components.=C2=A0 The "VALARM" com= ponent is used to specify a reminder for
=C2=A0 =C2=A0an event or task.= =C2=A0 Different alarm actions are possible, as are
=C2=A0 =C2=A0differe= nt ways to specify how the alarm is triggered.

=C2=A0 =C2=A0As iCale= ndar has become more widely used and as client-server
=C2=A0 =C2=A0proto= cols such as CalDAV [RFC4791] have become more popular, several

<= mglt>
I guess there is an wording issue. I suppose that " have b= ecome more popular" should be removed.

</mglt>

[ = ... ]

3.=C2=A0 Extensible syntax for VALARM

=C2=A0 =C2=A0Sect= ion 3.6.6 of [RFC5545] defines the syntax for "VALARM" components=
=C2=A0 =C2=A0and properties within them.=C2=A0 However, as written, it = is hard to
=C2=A0 =C2=A0extend this by adding, e.g., a new property comm= on to all types of
=C2=A0 =C2=A0alarm.=C2=A0 Since many of the extension= s defined in this document need to
=C2=A0 =C2=A0extend the base syntax, = an alternative form for the base syntax is
=C2=A0 =C2=A0defined here, wi= th the goal of simplifying specification of the
=C2=A0 =C2=A0extensions.=

=C2=A0 =C2=A0A "VALARM" calendar component is re-defined = by the following
=C2=A0 =C2=A0notation:

=C2=A0 =C2=A0alarmcext = =C2=A0=3D "BEGIN" ":" "VALARM" CRLF
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 alarmprop
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "END" ":"= "VALARM" CRLF

=C2=A0 =C2=A0alarmprop =C2=A0=3D *(

= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; the following are= REQUIRED,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; but= MUST NOT occur more than once

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 action / trigger /




Daboo & Murc= hison =C2=A0 =C2=A0 =C2=A0 =C2=A0 Expires July 20, 2020 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Page 3]
=0C
Internet-Draft = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VALARM Extensions =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 January 2020


=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; one set of action proper= ties MUST be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; p= resent and MUST match the action specified
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; in the ACTION property

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 actionprops /

=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; the following is OPTIONAL,<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; and MAY occur = more than once

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 x-prop / iana-prop

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 )

=C2=A0 =C2=A0actionprops =3D audiopropext / disppropext= / emailpropext

<mglt>
I believe t= his should go after *ext have been defined, though I am not very familiar w= ith ABNF.=C2=A0
</mglt>

=C2=A0 =C2=A0audiopropext = =C2=A0=3D *(

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0; 'duration' and 'repeat' are both OPTIONAL,<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; a= nd MUST NOT occur more than once each,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; but if one occurs, so MUST the othe= r

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0duration / repeat /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0; the following is OPTIONAL,
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; but MUST NOT occur mo= re than once

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0attach

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0)

=C2=A0 =C2=A0disppropext =3D *(

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; the following = are REQUIRED,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0; but MUST NOT occur more than once

=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description /

=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; 'duration' and &#= 39;repeat' are both OPTIONAL,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0; and MUST NOT occur more than once each,
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; but if one occurs= , so MUST the other

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0duration / repeat

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0)

=C2=A0 =C2=A0emailpropext =3D *(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; the follo= wing are all REQUIRED,



Daboo & Murchison =C2=A0 =C2=A0 = =C2=A0 =C2=A0 Expires July 20, 2020 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 [Page 4]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0VALARM Extensions =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 January 2020


=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; but MUST NOT occur more than once
<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 descripti= on / summary /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ; the following is REQUIRED,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; and MAY occur more than once

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 attendee /
<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; 'du= ration' and 'repeat' are both OPTIONAL,
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; and MUST NOT occur more than o= nce each,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= ; but if one occurs, so MUST the other

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 duration / repeat

<mglt>I have the impression that attach is missing as OPTIONAL that MAY appear m= ore than once.

</mglt>


4.=C2=A0 Alarm Unique Identi= fier

=C2=A0 =C2=A0This extension adds a "UID" property to = "VALARM" components to allow
=C2=A0 =C2=A0a unique identifier = to specified.=C2=A0 The value of this property can

<mglt>
t= o be specified
</mglt>

=C2=A0 =C2=A0then be used to refer u= niquely to the "VALARM" component.

[ ... ]


6.= =C2=A0 Alarm Acknowledgement

=C2=A0 =C2=A0There is currently no way = for a "VALARM" component to indicate
=C2=A0 =C2=A0whether it h= as been triggered and acknowledged.=C2=A0 With the advent of a
=C2=A0 = =C2=A0standard client/server protocol for calendaring and scheduling data=C2=A0 =C2=A0([RFC4791]) it is quite possible for an event with an alarm = to exist
=C2=A0 =C2=A0on multiple clients in addition to the server.=C2= =A0 If each of those is
=C2=A0 =C2=A0responsible for performing the acti= on when an alarm triggers, then
=C2=A0 =C2=A0multiple "alerts"= are generated by different devices.=C2=A0 In such a
=C2=A0 =C2=A0situat= ion, a calendar user would like to be able to "dismiss" the
= =C2=A0 =C2=A0alarm on one device and have it automatically dismissed on the= others
=C2=A0 =C2=A0too.

<mglt>
It is probably due to m= y lake of expertise, but I have the impression the acknowledgment propertie= s only works under some conditions. Typically, I imagine that devices not b= eing connected, are hosting the VALARMS components locally, in which case, = these devices will not consider the acknowledgment properties.
Similarly= , when devices are connected to a centralized calendar, I suppose - but mig= ht completely wrong - that the alarms are simultaneously sent to the variou= s devices. The ability to switch off all alarms relies on the ability of th= ese devices to be able to synch the calendar objects. I am wondering if mos= t systems have a push mechanism to "switch off" the alarms on the= other devices.
</mglt>

[ ... ]

6.1.=C2=A0 Acknowled= ged Property

=C2=A0 =C2=A0Property Name: =C2=A0ACKNOWLEDGED

= =C2=A0 =C2=A0Purpose: =C2=A0This property specifies the UTC date and time a= t which the
=C2=A0 =C2=A0 =C2=A0 corresponding alarm was last sent or ac= knowledged.

=C2=A0 =C2=A0Value Type: =C2=A0DATE-TIME

=C2=A0 = =C2=A0Property Parameters: =C2=A0IANA and non-standard property parameters = can
=C2=A0 =C2=A0 =C2=A0 be specified on this property.

=C2=A0 = =C2=A0Conformance: =C2=A0This property can be specified within "VALARM= " calendar
=C2=A0 =C2=A0 =C2=A0 components.

=C2=A0 =C2=A0Des= cription: =C2=A0This property is used to specify when an alarm was last
= =C2=A0 =C2=A0 =C2=A0 sent or acknowledged.=C2=A0 This allows clients to det= ermine when a
=C2=A0 =C2=A0 =C2=A0 pending alarm has been acknowledged b= y a calendar user so that any
=C2=A0 =C2=A0 =C2=A0 alerts can be dismiss= ed across multiple devices.=C2=A0 It also allows
=C2=A0 =C2=A0 =C2=A0 cl= ients to track repeating alarms or alarms on recurring events or
=C2=A0 = =C2=A0 =C2=A0 to-dos to ensure that the right number of missed alarms can b= e
=C2=A0 =C2=A0 =C2=A0 tracked.

=C2=A0 =C2=A0 =C2=A0 Clients SHOU= LD set this property to the current date-time value in
=C2=A0 =C2=A0 =C2= =A0 UTC when a calendar user acknowledges a pending alarm.=C2=A0 Certain=C2=A0 =C2=A0 =C2=A0 kinds of alarm may not provide feedback as to when th= e calendar
=C2=A0 =C2=A0 =C2=A0 user sees them, for example email based = alerts.=C2=A0 For those kinds
=C2=A0 =C2=A0 =C2=A0 of alarms, the client= SHOULD set this property when the alarm is
=C2=A0 =C2=A0 =C2=A0 trigger= ed and the action successfully carried out.

=C2=A0 =C2=A0 =C2=A0 Whe= n an alarm is triggered on a client, clients can check to see
=C2=A0 =C2= =A0 =C2=A0 if an "ACKNOWLEDGED" property is present.=C2=A0 If it = is, and the value
=C2=A0 =C2=A0 =C2=A0 of that property is greater than = or equal to the computed trigger
=C2=A0 =C2=A0 =C2=A0 time for the alarm= , then the client SHOULD NOT trigger the alarm.

<mglt>
Just= for clarification, I assume that the computed trigger time defined by the = TRIGGER property corresponds in the case of a repeated alarm to the first o= ccurence of the alarm. and the control only apply to the repeated alarms. M= ore specifically, unless I am missing something, it seems hard to me to hav= e an ACKNOWLEDGED time before the alarm is triggered for the first time. = =C2=A0 =C2=A0

I suspect some checks should be done on the acknowledg= ed time and make sure the time is not in the future. =C2=A0
</mglt>= ;

[ ... ]

9.=C2=A0 Security Considerations

=C2=A0 =C2= =A0VALARMs, if not monitored properly, can be used to "spam" user= s and/
=C2=A0 =C2=A0or leak personal information.=C2=A0 For instance, an= unwanted audio or
=C2=A0 =C2=A0display alert could be considered spam.= =C2=A0 Or an email alert could be
=C2=A0 =C2=A0used to leak a user's= location to a third party or to send
=C2=A0 =C2=A0unsolicited email to = multiple users.=C2=A0 Therefore, CalDAV clients and
=C2=A0 =C2=A0servers= that accept iCalendar data from a third party (e.g. via iTIP
=C2=A0 =C2= =A0[RFC5546], a subscription feed, or a shared calendar) SHOULD remove
= =C2=A0 =C2=A0all VALARMs from the data prior to storing in their calendar s= ystem.

<mglt>
As an attacker, I am wondering if I can forma= t also an acknowledgment or snoozing property to avoid or limit the alarm.<= br>Suppose I am able to provision an acknowledgment property with a time gr= eater than the computed triggered time. Unless the system controls the ackn= owledged time from the client, it seems to me feasible that the acknowledge= d time =C2=A0is set in the future. Even with such control, it could also di= sable the repeat properties. =C2=A0

I am also wondering how loosely = synchronized devices may interfere between each other. I do not see major i= ssues as the time is always related to the time of the event. Loose time sy= nchronization does not seem - but I might be wrong - the calendar objects, = but will impact the time acknowledgment / snoozing properties are received,= if there are any checks.


</mglt>

10.=C2=A0 Privacy= Considerations

=C2=A0 =C2=A0Proximity VALARMs, if not used carefull= y, can leak a user's past,
=C2=A0 =C2=A0present, or future location.= =C2=A0 For instance, storing an iCalendar
=C2=A0 =C2=A0resource containi= ng proxmity VALARMs to a shared calendar on CalDAV
=C2=A0 =C2=A0server c= an expose to anyone that has access to that calendar the
=C2=A0 =C2=A0us= er's intent to leave from or arrive at a particular location at
=C2= =A0 =C2=A0some future time.=C2=A0 Furthermore, if a CalDAV client updates t= he shared
=C2=A0 =C2=A0iCalendar resource with an ACKNOWLEDGED property = when the alarm is
<mglt>
I think that is an additional ACKNOWLE= DGED property.

While PROXIMITY gives an exact location, the intentio= n. I am unsure about the information ACKNOWLEDGE by itself provides (withou= t proximity). Typically, as far as I understand, it indicates the user has = seen the alarm, but does not give=C2=A0the reason that is whether he is wil= ling to ignore the alarm or going to the event itself.=C2=A0 Am I missing s= omething ?
</mglt>
=C2=A0 =C2=A0triggered, will leak the exact = date and time that the user left from
=C2=A0 =C2=A0or arrived at the loc= ation.=C2=A0 Therefore, CalDAV clients that implement
=C2=A0 =C2=A0proxi= mity alarms SHOULD give users the option of storing and/or
=C2=A0 =C2=A0= acknowledging the alarms on the local device only and not storing the
= =C2=A0 =C2=A0alarm and/or acknowledgment on a remote server.

<= div>

On Wed, Jun 10, 2020 at 8:32 AM Bron Gondwana <brong@fastmailteam.com> wrote:
Obviously, that date came and went and I got sid= etracked with other things.=C2=A0 I will submit this document and we don= 9;t need to put it on the agenda for the interim next week!

Cheer= s,

Bron.

On Wed, Apr 22, 2020, at 22:29, Bron Gondwana wrote:
As there's been no feedback on the list about this document an= d Ken believes it's complete, we agreed in yesterday's interim meet= ing to take this one to WGLC.
We'll make it 3 weeks, so you = have until Wednesday 13 May to review and respond to this document.<= br>

Cheers,

Bron.

--
=C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd


_______________________________________________
calsify mailing list


--
=C2=A0 Bron Gondwana, CEO, Fastmail Pty L= td


___________________________________= ____________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify


--
Daniel Migault
Ericsson
--00000000000058a80e05a824b7f5-- From nobody Sun Jun 21 19:58:25 2020 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 35E643A08CB for ; Sun, 21 Jun 2020 19:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7KtRSdYcoVkS for ; Sun, 21 Jun 2020 19:58:23 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 E98223A08C6 for ; Sun, 21 Jun 2020 19:58:22 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id e11so5021527qkm.3 for ; Sun, 21 Jun 2020 19:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=hlXKLzh4zFlCEpCHvvduJ6pp0Lp04tEa4MaDHvEyD1E=; b=c8IecJEwV4kkfjatG6fA4XRulQUz3dBLYoligAHoodnFVvdzB6kHpjxLVRuRniV96y PR5M2PJLTmhnxFQM1pDpNh0NnbVw7qymdbE/+0VWmjuyohaQ8nebCrcVcK8yEO5rJi5+ E3Y8RiTm97pyT2XIUpF4ebSz8vEUovKjTe/PhDST7uJQO4iTchFl2KlAHomgAIg6adg7 6EDEwk084R+E5zDvm73UBqKZE0CV6OwwlHfJ3onFNbpnws6VXIMkZkUxKiqLm5NsX3LU ZhDXPnucW+9ICMqlgMkrZBlnGQqD6Bo3araEwoObj0o980HX0pGDMOLi7YF6DroKL0TJ 2LPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=hlXKLzh4zFlCEpCHvvduJ6pp0Lp04tEa4MaDHvEyD1E=; b=f/1YriL1O8J4mfD7sk6ijCqcBlhusxwtTUOzWTseHdINmHjJX9Lxzxh53e89TcDojs GxILfHDNaHsuYEOGM49XXqO8XYzHiXIYAaul55vUVJgOwmXDGfeqH40pZh/0VEAC5UM3 zNAx6Z6tjpNfMZMZ9iG5ARWbIWn6vkIdJFsMSTTpN5xtr187Vzj501sYIUUjYRH1bRI8 qzMoj/3LaUvdbOd6Qhc7ARIarMA+R3kR4kcqOMeOwkFOe5UxSOyounuSY4eqrakiKNbJ 9uboJ/HUD47XaQ44tCUxjs13gfix/113V3Waiu0vTJtFtevyWahcRXraGHvKe+/8Kf6y pSkg== X-Gm-Message-State: AOAM5332Iu4vDQ+QSB1x+jbkrhY58cYVwQytst00qd+BEGucyE4gR6+C iHosIwLdoGDYjK2Nc8XtyXlM4M6FYrg= X-Google-Smtp-Source: ABdhPJzs89ngjExqbH2vEZjX07QNHc3YqysXmV7i86nIq90uyxu19obozMhkK367T8Vxt1oebpoghg== X-Received: by 2002:a05:620a:1388:: with SMTP id k8mr13910888qki.216.1592794701724; Sun, 21 Jun 2020 19:58:21 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id m10sm13500463qtg.94.2020.06.21.19.58.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 21 Jun 2020 19:58:21 -0700 (PDT) To: calsify@ietf.org From: Michael Douglass Message-ID: <41817321-1e49-04bb-e5f6-11e257274198@gmail.com> Date: Sun, 21 Jun 2020 22:58:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------F366AF6B693C2CA404403068" Content-Language: en-US Archived-At: Subject: [calsify] draft-ietf-calext-jscalendar-27 - section 4.4.5 Participants X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 02:58:24 -0000 This is a multi-part message in MIME format. --------------F366AF6B693C2CA404403068 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I think where we are is that any participant that cannot be scheduled has no sendTo property. If so shouldn't this text: Type: "Id[Participant]" (optional). A map of participant ids to participants, describing their participation in the calendar object. If this property is set, then the "replyTo" property of this calendar object MUST define at least one reply method. say Type: "Id[Participant]" (optional). A map of participant ids to participants, describing their participation in the calendar object. If this property is set and any participant has a sendTo property, then the "replyTo" property of this calendar object MUST define at least one reply method. --------------F366AF6B693C2CA404403068 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I think where we are is that any participant that cannot be scheduled has no sendTo property.

If so shouldn't this text:

Type: "Id[Participant]" (optional).

   A map of participant ids to participants, describing their
   participation in the calendar object.

   If this property is set, then the "replyTo" property of this calendar
   object MUST define at least one reply method.

say

   Type: "Id[Participant]" (optional).

   A map of participant ids to participants, describing their
   participation in the calendar object.

   If this property is set and any participant has a sendTo property, then the "replyTo" property of this calendar
   object MUST define at least one reply method.


--------------F366AF6B693C2CA404403068-- From nobody Sun Jun 21 22:51:53 2020 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 A85223A0925 for ; Sun, 21 Jun 2020 22:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=34eogKHq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HeOaPAo7 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 WykuQdQ-32eJ for ; Sun, 21 Jun 2020 22:51:48 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C113A0912 for ; Sun, 21 Jun 2020 22:51:48 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 820CD5C148A for ; Mon, 22 Jun 2020 01:51:47 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 22 Jun 2020 01:51:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=u1Rd/0V Zh8b+ghT1G2yVmQ3GX+UgWngFsTIdyAm+e3E=; b=34eogKHqjIr5xAYmxbyTndX mmfQnzDQMr4gYNzXh6ZTJ6lzF55NS1rjnkeDf8u+1lzH9U7LzgCk9PTS2yRIpSdU 0lZaIYbRGwx+Wrk+NcZLqIYjHeMQenS77HhFNLI8dZ/smoZj0FVerLJJLDlJczUw ksQR/Kygxb4JAzo44Z+Yflr1JY0SFlg2iLaGgbye90LJDj0ngrdmYkd0P1DPfS3D Qcbc48C++PixJAWflJfta5PT42Ox4Ae0xWbjIDYzrNnj4DHYJuS2Dn88bRFrIymF Wwcp8tSeMbiGbVxGPRdQJ5imgFZAivasFB36jIbKISe+4Amb3JkFXtlxNg09Wrg= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=u1Rd/0 VZh8b+ghT1G2yVmQ3GX+UgWngFsTIdyAm+e3E=; b=HeOaPAo74+xFy6oZrTuoho TjwmnNkVhTiDH7sejRYUqsRuTzy+7zR6PELy1OsTrM8vGVSPdNYCL7xjF0MPfhGC ArCvlo/g5iWCbs6eSZznMouQjMhEpGUKLrDKGTgxcwD9PJF2q1btfG1RCi8EdXm/ dAAdz4PCr3PEy/G/ppPHq7v0GCyhoRD6J5QukH9fYktbd2L548ToqSyf8GmsbNFF oBtVlcMA3vjqQLub0XkpOo5k8H5GQ/iyMG5uU7MJD1G5DRHs/P/Fvuzg2jMeie7L QkKKSeUIOSFu3Nv4tbddm/wVHP4wb17SQBQ1A22ns91LYjbpVhtutJSVWP2qQq4Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekuddgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepheeuhfdujedtie evkedvhfffgfelfeelhfefkeehhfekleekhfefueefveffjeeinecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5DFFD180094; Mon, 22 Jun 2020 01:51:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-558-g574930d-fm-idx2020-20200618.005-g574930d4 Mime-Version: 1.0 Message-Id: In-Reply-To: <41817321-1e49-04bb-e5f6-11e257274198@gmail.com> References: <41817321-1e49-04bb-e5f6-11e257274198@gmail.com> Date: Mon, 22 Jun 2020 15:51:19 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=4193f1a1fdf9458db1e1079f0017a17f Archived-At: Subject: Re: [calsify] =?utf-8?q?draft-ietf-calext-jscalendar-27_-_section_4?= =?utf-8?q?=2E4=2E5_Participants?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 05:51:50 -0000 --4193f1a1fdf9458db1e1079f0017a17f Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, 22 Jun 2020, at 12:58, Michael Douglass wrote: > I think where we are is that any participant that cannot be scheduled = has no sendTo property.=20 > If so shouldn't this text: [=E2=80=A6] say [=E2=80=A6] Agreed, I'll make the change. Neil. --4193f1a1fdf9458db1e1079f0017a17f Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mon, 22 Jun = 2020, at 12:58, Michael Douglass wrote:
I think where we are is that any participant that cannot be scheduled has no sendTo property.
If so shouldn't t= his text: [=E2=80=A6] say [=E2=80=A6]

Agreed, I'll make the change.

Neil.=
--4193f1a1fdf9458db1e1079f0017a17f-- From nobody Tue Jun 23 07:57:04 2020 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 D54A13A0F8B for ; Tue, 23 Jun 2020 07:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 zH7ethfuTuPF for ; Tue, 23 Jun 2020 07:57:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052703A0F06 for ; Tue, 23 Jun 2020 07:56:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A5570F40716; Tue, 23 Jun 2020 07:56:48 -0700 (PDT) To: bernard.desruisseaux@oracle.com, superuser@gmail.com, barryleiba@computer.org, lear@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: LarsHenriksen@get2net.dk, calsify@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200623145648.A5570F40716@rfc-editor.org> Date: Tue, 23 Jun 2020 07:56:48 -0700 (PDT) Archived-At: Subject: [calsify] [Technical Errata Reported] RFC5545 (6212) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 14:57:03 -0000 The following errata report has been submitted for RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6212 -------------------------------------- Type: Technical Reported by: Lars Henriksen Section: 3.8.5.3 Original Text ------------- Daily until December 24, 1997: DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=DAILY;UNTIL=19971224T000000Z ==> (1997 9:00 AM EDT) September 2-30;October 1-25 (1997 9:00 AM EST) October 26-31;November 1-30;December 1-23 Corrected Text -------------- Daily until December 24, 1997: DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=DAILY;UNTIL=19971224T140000Z ^^ ==> (1997 9:00 AM EDT) September 2-30;October 1-25 (1997 9:00 AM EST) October 26-31;November 1-30;December 1-24 ^^ Notes ----- The UNTIL rule part has value type DATE-TIME (same as DTSTART), but the introductory text "Daily until December 24, 1997" mentions a DATE only. Assuming that "until", like UNTIL, is inclusive, I would expect (1997 9:00 AM EST) December 24 to be the last instance, i.e. the unstated time is 9:00 AM. Translating to UTC you get 19971224T140000Z The same error occurs in all examples of section 3.8.5.3 with "December 24, 1997", four in all: pages 123 (above), 125 (twice) and 126. The resulting occurrences are only affected for pages 123 and 125 (second). 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. -------------------------------------- RFC5545 (draft-ietf-calsify-rfc2445bis-10) -------------------------------------- Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Publication Date : September 2009 Author(s) : B. Desruisseaux, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG From nobody Tue Jun 23 18:02:43 2020 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 850EF3A0D25 for ; Tue, 23 Jun 2020 18:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=QZImL5CE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kwClcpq3 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 TuxFIJRUQtiY for ; Tue, 23 Jun 2020 18:02:41 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B183A0B87 for ; Tue, 23 Jun 2020 18:02:40 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 283685C009F for ; Tue, 23 Jun 2020 21:02:40 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Tue, 23 Jun 2020 21:02:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=wW0KC8T MfA7h74yQghTD1Z+pAkdCJa/RM2jhYeiZjfI=; b=QZImL5CEB2RkVTSDtxffIWH 4e63JRJ/HMi5+C9psS7uaoqNbK2C9UToAlYZ7C+mZApcoJFvVdT5+bRwZXDctYK+ zvD/SaYhHImkJ8SACYuLRrexDrO05JQ0PacftVlUXt0m3Q2DkXprph2f/Spvc2gu 5q1Rn8hIsFUKgJPO3AQMeUWwjU53bH3UzvDevqpBy+VCT70LTrEBr1EJZoqx7uxW CTfhe9tbV4s1CBxMYy8fTJi4TIB2klZ0oJXCcv+8X+BrHHmLb3Q3HCqhKtrVBUAS gRvYV42ZA71mWBy/brjKMMBqzcNmSxt+qfmvxZI6mYZA0Rn07LuFmh5Rddt2/OQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=wW0KC8 TMfA7h74yQghTD1Z+pAkdCJa/RM2jhYeiZjfI=; b=kwClcpq3dj0YzaY5KgEWat zolzGFSrGizZu5uKfQUBmedTHC4zT2HZ/Y89gne/XcVeosnmI610IVW1zbk3blkH uLscnE9+J1YJLC9Bj7D+x5iqyzZDRq24WnuY2GUeXh7lshNnql20iBSYerGZEUH+ /rFPp9ZyZJsj62Ja1MihOO68HqM9rpCH1uWdJnUzhKY2xeREXMXGUR1GAMPtsfk0 xG4Kv+w7zwFKiB1IU+fNDCqcUA5xAJkqZaGyVKXPdpHD+vJ690Xsz5XZIHWuJ2kk 2l1vJZN9APLL35THsGocYmNZtBSynilY06GCOMtkUSUxGtDF9tq00g/ZhCxeSsaQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekiedggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvedvtedvudelke fhgefhteeftedtlefhheefveffveelkedutdduffeiveejvefhnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DC13E180091; Tue, 23 Jun 2020 21:02:39 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-565-g8923300-fm-idx2020-20200622.001-g89233000 Mime-Version: 1.0 Message-Id: In-Reply-To: <20200623145648.A5570F40716@rfc-editor.org> References: <20200623145648.A5570F40716@rfc-editor.org> Date: Wed, 24 Jun 2020 11:02:39 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=b68fdfbcdb564d3a837ca5fa4e5738ad Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6212) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 01:02:43 -0000 --b68fdfbcdb564d3a837ca5fa4e5738ad Content-Type: text/plain Hmm, this is a bit confusing. The DTSTART/RRULE do match the dates it says (the last one will be on Dec 23 as the UNTIL time is before 9am); there's no requirement for the UNTIL to align exactly with an occurrence. However, the English description above says "until December 24", which I would probably interpret as inclusive too. Perhaps this is what should change (to say December 23) rather than the DTSTART/RRULE and dates? Neil. --b68fdfbcdb564d3a837ca5fa4e5738ad Content-Type: text/html
Hmm, this is a bit confusing. The DTSTART/RRULE do match the dates it says (the last one will be on Dec 23 as the UNTIL time is before 9am); there's no requirement for the UNTIL to align exactly with an occurrence. However, the English description above says "until December 24", which I would probably interpret as inclusive too. Perhaps this is what should change (to say December 23) rather than the DTSTART/RRULE and dates?

Neil.
--b68fdfbcdb564d3a837ca5fa4e5738ad-- From nobody Tue Jun 23 19:34:55 2020 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 3658B3A00D2 for ; Tue, 23 Jun 2020 19:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TOoQqF1ZqKAA for ; Tue, 23 Jun 2020 19:34:44 -0700 (PDT) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 663643A00B0 for ; Tue, 23 Jun 2020 19:34:44 -0700 (PDT) Received: by mail-qk1-x736.google.com with SMTP id f18so560185qkh.1 for ; Tue, 23 Jun 2020 19:34:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=5LN6cFk+tQe82mJb9E5X1WthipCfWlHQjnsn6HTxiAA=; b=Hb1RlapHoGPoHyJyA/UHp09gnqTq9SRx51bC0Dqqr5MuPhi11+0+01rOSp0Wi2RbLm epBW93xVyfqVDmYwe4vmS8lHbZBYfpNd7LesgsublU9rVn9N4mgeQKudK35Vexe8EF/F yz8FRyWGjtiBQmxdWPb/dm6h0Ylf9wXmoMXzqRmDyEqYM3c9YakW7OaMOaS9hp51DfPF KaNUCIkf5pnCZgYBDtNYDGL3/yGQnpTuMrkJ/gk3OjmqGkMmJHRzk3FSB/QZZI05aRWH tCM13T/LEUvVy6TljoNstBMDylryRUuuUQnIQx/OtfCk6qAG0Zm52FyScSUFSrVlInpY v4lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=5LN6cFk+tQe82mJb9E5X1WthipCfWlHQjnsn6HTxiAA=; b=s7LUsm2EAfOj6NbSN590VpiLjjsb4C+fw9HJbG4DsqcuRDV1S+QUWFtk3hm+JydZA0 DZyUhMc272vhxXac9kgN//DsmvyN3mZRoznZUkZtGjz9y3nnRr8PZ2ToGdiYqdubgZ3B TkNvO/cAWj+3gYCtIa+8WH9cC0w1vTga87iLlSJNGygpq25D3mrfLVqKAlpVPmrPAeW0 yvzZvA9DOh112E2fjpq97X4HDAc+KcJNO5PP7F1z7+fPzoZfYAzjRFYRNqZ0AJJCLzzF /eTGP5Jo6P2hs7LNdEb9SkWX6vrxtK1P1Jhdra6nx3FGEx4Kd80MLvHVA5MVyWijfqEC sJxw== X-Gm-Message-State: AOAM530j5pBdqTgcss1IAJ/ZotJY8af+Xit6Ty3XbiVJg8j9vZcd23OV +UY+VLAW07hN27FVv4M558Y9tNFQNqk= X-Google-Smtp-Source: ABdhPJy6IL5ffIxmdb1IM0dZ6u/kUteY0MOShOH2ktD13qTzs76FebWknWDp5iaoeuA+pn2V5pa6ZA== X-Received: by 2002:a05:620a:22ce:: with SMTP id o14mr24134699qki.169.1592966083071; Tue, 23 Jun 2020 19:34:43 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id 207sm2216353qki.134.2020.06.23.19.34.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jun 2020 19:34:42 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <16c59d9a-952b-15b6-8485-ed9320af8c70@gmail.com> Date: Tue, 23 Jun 2020 22:34:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [calsify] jscalendar and iCalendar ATTENDEE DIR parameter X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 02:34:54 -0000 How should this be mapped? We're using the linkids to refer to a link but there doesn't appear to be any appropriate rel value. Having read through them I'm assuming we should probably define one (directory?) which has essentially the same meaning as the dir parameter The same sort of question arises for ALTREP and LOCATION. 5545 talks about html and text representations then has urls pointing to ldap and vcf resources. From nobody Tue Jun 23 20:10:09 2020 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 007C33A03F3 for ; Tue, 23 Jun 2020 20:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 weaZVA8PEci3 for ; Tue, 23 Jun 2020 20:10:06 -0700 (PDT) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 94DD13A03F2 for ; Tue, 23 Jun 2020 20:10:06 -0700 (PDT) Received: by mail-qv1-xf2d.google.com with SMTP id g7so412115qvx.11 for ; Tue, 23 Jun 2020 20:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=qXsqNNHt2+ZoFF7pjFoKyZv+eHk/WEzTsoODjKiYjWo=; b=p/z3oBpxvNGxZi3G9TYCvRI71xjZtfbV4lpPYffvuVOuRdn+cNJKOkLCsn07tjXobW 5l7/uVj4z+KfrqLuG561iU4aVP4zxfcFsXt2DLZW1L3SDpyuQgUQ9Dc1JrxR05nxWC3N VwY3NCE1HKHR+r6c6Hw21c/jiidlMsmewOZVousKdMftmwgu27l1amF5chbx3DEJSOmE YsA/b9X9KJUzR1rVJa7JnrLcwSF+RgtKjip2DXcmaSuQC1S7HbSCliGwmcJffPiUdz8W rlzmnTZr4MD30nXipvPqGB+9J4sVsBn/HKmP2YyMCP8NOyl8jkb8A2gTJZyTNcrUNUs/ X4pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=qXsqNNHt2+ZoFF7pjFoKyZv+eHk/WEzTsoODjKiYjWo=; b=Umo52SMUYpzqtEsrHtnwrbZxX3zqxJl++jSQXjDkbc68S2ROtqCZX8GXH3LFR4bsYk yt/dYP7rfFUpY23j5qhU0lQ6yzzhszR7/L+SgZOC9M8HfGghx2MPEQAWqFrbriTA8xnh z/Pu/6pJfbe2t092WDz7JgHHPF72H8ltfQEm1LhmtPZOAHtkxE15OUWrLRasW662Y5hO VpGUVW27BTniMv0Qv3KG2HZ7LQy73UJIMSBtDiMi10JCy0yGbvbeWQpQLAeoeP7FY5lH 7ngV4gRx5oXg1UNMC09lvdBovlh/Yarsnu2BHNxf0KqPKoHaH74TuPME9w74oMs5o+P9 EBFg== X-Gm-Message-State: AOAM531xKuYo695+JZ481D/6FpCuXkYN8bdrjqiFiqwiTKOebzdRMsuF sxvxXbyV7eh09RLmStgM2WNIfw76UVs= X-Google-Smtp-Source: ABdhPJwp9MKpzmenD5KkD8zH8Onnuk9dyafkkeKLYcFGdwC3oZ+dlW8GK0KIuw/eUpUDTQiIWeYtAQ== X-Received: by 2002:a0c:f109:: with SMTP id i9mr15153521qvl.154.1592968205287; Tue, 23 Jun 2020 20:10:05 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id d79sm2334098qkb.101.2020.06.23.20.10.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jun 2020 20:10:04 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <92d62769-8b2f-05c1-3bff-98644425369f@gmail.com> Date: Tue, 23 Jun 2020 23:10:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------797F0BA97CB01FAD4CF46419" Content-Language: en-US Archived-At: Subject: [calsify] jscalendar - ATTENDEE and MEMBER X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 03:10:08 -0000 This is a multi-part message in MIME format. --------------797F0BA97CB01FAD4CF46419 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Trying to come up with conversion approach... Reading iTip the MEMBER parameter will be present if a group is invited and is then expanded? The text in 5546 confuses me a little: Failing (1), look for "Attendees" where "CUTYPE=GROUP" or "CUTYPE=UNKNOWN". The CUA then determines if the "Calendar User" is a member of one of these groups. If so, the "REPLY" method sent to the "Organizer" MUST contain a new "ATTENDEE" property in which: Wouldn't the attendee be added on the REQUEST? I guess it's possible the organizer doesn't know who the group members are but it's also possible the attendee CUA has no idea. Also that text above is the only place CUTYPE=GROUP appears so there's not much help there. I guess it's true that if a MEMBER parameter is present then there SHOULD be an ATTENDEE with that address. When doing the conversion this might imply we need to do groups first because we won't necessarily know the key(s) for the memberOf property. Locating that participant: an instance may be overridden with an added group in which case the participant appears only in the override, otherwise it's in the master. --------------797F0BA97CB01FAD4CF46419 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Trying to come up with conversion approach...

Reading iTip the MEMBER parameter will be present if a group is invited and is then expanded?

The text in 5546 confuses me a little:

Failing (1), look for "Attendees" where "CUTYPE=GROUP" or
       "CUTYPE=UNKNOWN".  The CUA then determines if the "Calendar User"
       is a member of one of these groups.  If so, the "REPLY" method
       sent to the "Organizer" MUST contain a new "ATTENDEE" property in
       which:

Wouldn't the attendee be added on the REQUEST? I guess it's possible the organizer doesn't know who the group members are but it's also possible the attendee CUA has no idea. Also that text above is the only place CUTYPE=GROUP appears so there's not much help there.

I guess it's true that if a MEMBER parameter is present then there SHOULD be an ATTENDEE with that address.

When doing the conversion this might imply we need to do groups first because we won't necessarily know the key(s) for the memberOf property.

Locating that participant: an instance may be overridden with an added group in which case the participant appears only in the override, otherwise it's in the master. 

--------------797F0BA97CB01FAD4CF46419-- From nobody Tue Jun 23 21:10:58 2020 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 B24BC3A07AF for ; Tue, 23 Jun 2020 21:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 IqnWb-yRucGE for ; Tue, 23 Jun 2020 21:10:56 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 A30213A07AB for ; Tue, 23 Jun 2020 21:10:56 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id l188so677984qkf.10 for ; Tue, 23 Jun 2020 21:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=3mpI9jdBYq2nLiHxuYOiZAEc1cDX3EG7GBwaLTwlazw=; b=C73ZCEUT4/4g3cIARssOuUugJs4ZQryGA4guKmxFQqmC/Y+LH4dNe1A1sU+FZW2OTx j28/YcRJYj5S/vE9A7Z3OVi4V3EYyw95EQaYJ3ElTqVS15FBRfoJ45P4kkfK6TThBB2c 94QkL+rxe1MJyNnmhuOCzLfq6gk4vTJcfBgFufccW0kYZuUtQi5FnonCxBcODHOQk8Jd GAtNMFjdLkGLY0A6CkP1aNne49UtjkxjQuBFMUSPHJCTkwAnKM98CF99fF4DUSv//G2r X26zNUf1kUFlRGW+dRqzEQeyBLYPRUG3SkT4poDgiiaDzWIxOLm/Hbz+czG68LakScr0 LTCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=3mpI9jdBYq2nLiHxuYOiZAEc1cDX3EG7GBwaLTwlazw=; b=Q0Icbt3auzNkTXytGoy5heWb5z/Tc6904qZM+Qv3kcr2+gfalemvp3QOjkai7RN1FY bpHctEhQNio7kmujAxX59UX28f0D0rn5tlXnKRd9M02XSONZqfHR9NcfFAqEcQwcqjlr I7Pu/LLF3LpgRAL8mHBZkfBHRqa+HAMPoXsI+nCbNXDcq7xP775G8q5krFTPM2QQ/My/ +IhUbXQF+0GptSB3Xv8xcPlda3zW0buEVaD6CuYtvvPV6SuZrkEW2b7oQeCVGhArfYOz zcbcR+c7/uI+fMGHrj/2zi7vkOL940nkDryJxVZpj/fr5IeAd0/j4ShYjb5CsBQZ0GVL 5QNg== X-Gm-Message-State: AOAM530bTprK2wcpdAnx4dJ1sAwydvmRX22UIsqm24k8Ygso3WDvxUvd qeTRvsQo9TZR4Ewy/0ZtlpTOnSUb46M= X-Google-Smtp-Source: ABdhPJykYgsG5D18q207KNOY6oYu1ZyxWkCGeYOwxN4pEpcvxBqT4pyOMMylBZ0FuJFEOyVTmhvcDw== X-Received: by 2002:a05:620a:20db:: with SMTP id f27mr9385162qka.345.1592971855558; Tue, 23 Jun 2020 21:10:55 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id x197sm2348599qka.74.2020.06.23.21.10.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jun 2020 21:10:55 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <187ee0a7-a57b-8efd-1682-d07b64391f06@gmail.com> Date: Wed, 24 Jun 2020 00:10:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [calsify] 5546 and 6638 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 04:10:58 -0000 6638 show is updates 5546 but 5546 has no indication that it is updated by 6638. Is this an errata or a Tracker bug? From nobody Tue Jun 23 21:21:20 2020 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 9BE893A07BE for ; Tue, 23 Jun 2020 21:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4EyiWbj17ToV for ; Tue, 23 Jun 2020 21:21:17 -0700 (PDT) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 9F7C53A07BD for ; Tue, 23 Jun 2020 21:21:17 -0700 (PDT) Received: by mail-qv1-xf34.google.com with SMTP id dm12so465001qvb.9 for ; Tue, 23 Jun 2020 21:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=YdxZGR6irCN6KanYbtX5OZoblj1odDYblZRxiUYujdM=; b=m9ERpFhWirYTNBNumgL1qcrb8OXCdUMfaJBrXvd9ieV0VWDBjOFq48kF9sn2m1fi33 aRIEm43naz+HMUS9s65xI4ze/OPXhMbGTtZ2GW/BcUsSIoVuGR0DPPB8SsLC+VpYn9eJ AFzb5KC7vgRDoq5vBNkAP2uodj25BGSeMFUaQiWhCP4H+Z1uPxLFLX/g78qWSJ7TzzqH fwQa26eRoeJnI2IboxKd45w1+6YoCEGrJ8A2iK9R9GkCB7yFSeAsUUajObepX/SbPAuh bpKT5fuKTPIX0ltLHm82tA7pFs5oAxyNVlT6mMOq2UwI02VQByHZyQt5a3hMLLQXsp73 cP1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=YdxZGR6irCN6KanYbtX5OZoblj1odDYblZRxiUYujdM=; b=QFdrEgYQ5zoGgIBn2gfkWxOSxVLiYSsxJIsu9B6L3Aln9xfj9uTmkdj1m0uFTyGGqT cy1LOjWuEo9Oj/4DsFrKGgKoyYzRzN+YuptG6sfbQYKICW7iSopq8Eu0w5ZpJGt2UC/L zCy/Otp0vO6YpOZUsP4QqM/3jAcvTQ9HaDlPAK22hQleO3B9ILXYccMXxGyoE/vsD0xC 7feZ6v7zDyEDiW5PaUdAZx7DoFVj+fZacXJRa4GIhqPOtzzQui16K1kh0sP1I0udDLte F3BGUkltdMt00vv8VbqESZIKswQsOwjSsyXu9VS+qXVlifYDot9bkkIAEOdSBjE5N86Y QZTg== X-Gm-Message-State: AOAM531Zox1EpKsZBBnDqhyZG95LTtZfSjA6t4KcgDMJTMI20g6d8EaT QhL+5KE92lQFjopxpdNWPK9R+wDVJC8= X-Google-Smtp-Source: ABdhPJznhuG+QX+939JI/Ri1umYZfBKGZaxI9F5/Zgvyq/FUZ3QLos1qQrdil3LRw9EkLZ04cl7byg== X-Received: by 2002:a0c:b712:: with SMTP id t18mr28852757qvd.245.1592972476618; Tue, 23 Jun 2020 21:21:16 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id s52sm2743191qtj.52.2020.06.23.21.21.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jun 2020 21:21:16 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <0a9ee93d-d94d-cda6-56ed-f0e04adc63e0@gmail.com> Date: Wed, 24 Jun 2020 00:21:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [calsify] jscalendar and 6638 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 04:21:19 -0000 We have schedule-agent from 6638 Can we add SCHEDULE-FORCE-SEND and SCHEDULE-STATUS? From nobody Tue Jun 23 22:54:17 2020 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 9AC123A0B86 for ; Tue, 23 Jun 2020 22:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=gZB5lvdN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=K+qrF6q5 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 m-66wEEWWiJ7 for ; Tue, 23 Jun 2020 22:54:08 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53DD3A0B85 for ; Tue, 23 Jun 2020 22:54:08 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C3DC84BE for ; Wed, 24 Jun 2020 01:54:07 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 24 Jun 2020 01:54:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm3; bh=yOkwaAYBkLIQnCeHsXArbnTNlESrLXiyy3FBiDA tEbA=; b=gZB5lvdNcaFA5oBqcPb9TPBfzn7XVPY8CwhPdH++IvL7Cgw4l00w/ag e2CAjNPA+HhyNNnKeGg3ClDH0gQYcUfBNbhLCV3D+1qE0yUfp+RC0NTfXWLJtBJI zEfDtBqMCFFKz6g0sDLRMdptzKswXtsVR+YWOJ2p7yIjnxr9wP8Ha9QvYiNhS3xo gsKJJAP8AOtQWijBfw1+K20e3spoKgQLZ4N8vd1LZZKmDof43EGmkSUAZD/A8NiI Eo3RbuB906GQsni+o2D+7c4KdIeG8r6T4HEMvcm/rpF6eLXv+avffL+EKtuP+mGB azd09lZFSezTmsnuM1q4VGx4kDBDgdA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=yOkwaAYBkLIQnCeHsXArbnTNlESrL Xiyy3FBiDAtEbA=; b=K+qrF6q59lQNdMv5rAW6ZCgq/sw2fqlOPsrhVHrC944VP hDJD7r3vUOBSyKHEu+LAIwYK8ST/k6SqSZIHNacNIiW3JSJqSfOWc7fKTpEL5Ogh FsI20F+3HwjsEJW7dd430QOLlWJgWG6uNGIfh76psUTQq1LqcwLoP4u0mTkQFBqK W/C5BASv1bODCxD1IbUQnTcJ9Pj/mtjv1dVHyYWYsty7DzfubygXPgBiQKHLaZYN ZDFmVQ5JZ0bmg+4zTX13k+ETEf3AaD1lo8NobhG/HsKOfkU5FPUELqkxXbh5Mw/w YI8qX2dxSovDK6T/HjZpwRBz6X3+j2G3xQpg1NFkg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudekiedguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhephfejheekjeekhe evuedtjeetiefhffefudeitddtjefhleetveeuheduledtueffnecuffhomhgrihhnpehi vghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DD63E180091; Wed, 24 Jun 2020 01:54:06 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-565-g8923300-fm-idx2020-20200622.001-g89233000 Mime-Version: 1.0 Message-Id: <9ef4c6c3-80c2-48c4-9064-be7616dac481@dogfood.fastmail.com> Date: Wed, 24 Jun 2020 15:53:44 +1000 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=e1e3011616c541e2a9211878d478c46d Archived-At: Subject: [calsify] Action points from last week's interim meeting X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 05:54:14 -0000 --e1e3011616c541e2a9211878d478c46d Content-Type: text/plain Hi all, here's the action points from last week's meeting. *Full minutes are available in the datatracker:** * https://datatracker.ietf.org/meeting/interim-2020-calext-02/materials/minutes-interim-2020-calext-02-202006182300 If you have any action points, please make sure that you do them! Thanks. *Full list of action points:** * ACTION: Bron to refresh scheduling-controls draft before the next meeting. ACTION: Mike to post a summary of where we are at for eventpub in the next few days. ACTION: Mike will post calext version of serverside subscription draft in the next day or two. ACTION: Mike will refresh draft for icalendar series. ACTION: Mike to refresh draft for subscription upgrade ACTION: Mike to check if we've switched to PARTICIPANT rather than VOTER in vpoll, then refresh draft. ACTION: Neil/Robert to add EXRULEs to jscalendar format if needed. ACTION: more discussion on list about jscalendar and EXRULE ACTION: Ken will check with Apple about their serverside subscriptions. ACTION: Ken to test libical to see what it does with EXRULEs. ACTION: Ken to read, review and submit changes to valarm extensions if needed. ACTION: Ken to double check if there's anything in valarm extensions that's not already covered by JSCalendar. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --e1e3011616c541e2a9211878d478c46d Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi all, here's the action points from last week's meeting.=

Full minutes are available in the datatracker:=





ACTION: Mike to refresh draft for subscri= ption upgrade
ACTION: Mike t= o check if we've switched to PARTICIPANT rather than VOTER in vpoll, the= n refresh draft.

ACTION: Neil/Robert to a= dd EXRULEs to jscalendar format if needed.
ACTION: more discussion on list ab= out jscalendar and EXRULE
ACTION: Ken will check with App= le about their serverside subscriptions.
ACTION: Ken to test libical to see what it does with EXRULE= s.
ACTION: K= en to read, review and submit changes to valarm extensions if needed.
ACTION: Ken to doub= le check if there's anything in valarm extensions that's not already cov= ered by JSCalendar.

Cheers,

Bron.

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


--e1e3011616c541e2a9211878d478c46d-- From nobody Tue Jun 23 23:10:49 2020 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 22A443A0B9D for ; Tue, 23 Jun 2020 23:10:47 -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.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159297904712.31313.3447756436769820677@ietfa.amsl.com> Date: Tue, 23 Jun 2020 23:10:47 -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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 06:10:47 -0000 Changed milestone "Adopt a draft for Server Side Subscription", resolved as "Done". Changed milestone "Submit valarm document to IESG for publication", set due date to July 2020 from May 2020. Changed milestone "Submit scheduling controls document to IESG for publication", set due date to August 2020 from May 2020. Changed milestone "Send JSCalendar draft to IESG", set due date to August 2020 from June 2020. Changed milestone "Submit calendar series document to IESG for publication", set due date to December 2020 from June 2020. Changed milestone "Submit Subscription Upgrade document to IESG for publication", set due date to December 2020 from July 2020. Changed milestone "Submit Serverside Subscription draft to IESG for publication", set due date to December 2020 from October 2020. Changed milestone "Submit vpoll document to IESG for publication", set due date to March 2021 from October 2020. URL: https://datatracker.ietf.org/wg/calext/about/ From nobody Wed Jun 24 00:35:38 2020 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 D5C603A0C15 for ; Wed, 24 Jun 2020 00:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 t-nNw_ErIznN for ; Wed, 24 Jun 2020 00:35:36 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436DD3A0C13 for ; Wed, 24 Jun 2020 00:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2942; q=dns/txt; s=iport; t=1592984136; x=1594193736; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=gFnu2VkIVMOk91Zksbjg612RR4XgB+T5VjdDhYfYIqI=; b=R6lYcZFLpyrQPdm9yT2lxxvnHjFpizsq71i729rKavTC9Y9swOTCS9kN 3DoTt1ff8EMHNnYj3azMcNyFYaRY0KxvcuwwsBhr/sTBZBhfvkBVTtVsO IVATEi7RAZ+HBfq6jELFxKGu0Nz3yc1chPMPCX+g2Hiuyw6B5yk9sdv7e Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AADxAfNe/xbLJq1mGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFKAoEhgkoBIBIsjSWHayWTbYgUCwEBAQw?= =?us-ascii?q?BAS8EAQGERwKCFSU4EwIDAQELAQEFAQEBAgEGBG2FZ0IBEAGFHgEBAQECAXk?= =?us-ascii?q?FCwsEFC5XBhODJoJdILZMdIE0hVGFBIE4AYx8ggCBOAwQgk0+gQSHAIItBLR?= =?us-ascii?q?kgmSDA5YrAx2RDY10rDODTwIEBgUCFYFqIoFWMxoIGxVlAYI+PhIZDY42jjE?= =?us-ascii?q?/AzA3AgYIAQEDCYYiin0BAQ?= X-IronPort-AV: E=Sophos; i="5.75,274,1589241600"; d="scan'208,217"; a="27394485" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2020 07:35:32 +0000 Received: from [10.61.241.223] ([10.61.241.223]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 05O7ZVak030064 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Jun 2020 07:35:32 GMT From: Eliot Lear Message-Id: <47A062D0-71F7-4008-B8A2-79AD7B2079C5@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2AF0393E-9608-4F65-A145-1901E81118C8" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 24 Jun 2020 09:35:31 +0200 In-Reply-To: Cc: calsify@ietf.org To: Neil Jenkins References: <20200623145648.A5570F40716@rfc-editor.org> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.241.223, [10.61.241.223] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6212) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 07:35:38 -0000 --Apple-Mail=_2AF0393E-9608-4F65-A145-1901E81118C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hiya, > On 24 Jun 2020, at 03:02, Neil Jenkins wrote: >=20 > Hmm, this is a bit confusing. The DTSTART/RRULE do match the dates it = says (the last one will be on Dec 23 as the UNTIL time is before 9am); = there's no requirement for the UNTIL to align exactly with an = occurrence. However, the English description above says "until December = 24", which I would probably interpret as inclusive too. Perhaps this is = what should change (to say December 23) rather than the DTSTART/RRULE = and dates? Either change would be fine, but as reported, Lars' corrected text is = correct, and since he took the time to report it, I suggest that we mark = this erratum as verified because the original text could lead to = confusion about what the meaning of UNTIL is. Eliot= --Apple-Mail=_2AF0393E-9608-4F65-A145-1901E81118C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hiya,

On 24 Jun 2020, at 03:02, Neil Jenkins <neilj@fastmailteam.com> wrote:

Hmm, = this is a bit confusing. The DTSTART/RRULE do match the dates it says = (the last one will be on Dec 23 as the UNTIL time is before 9am); = there's no requirement for the UNTIL to align exactly with an = occurrence. However, the English description above says "until December = 24", which I would probably interpret as inclusive too. Perhaps this is = what should change (to say December 23) rather than the DTSTART/RRULE = and dates?


Either change would be = fine, but as reported, Lars' corrected text is correct, and since he = took the time to report it, I suggest that we mark this erratum = as verified because the original text could = lead to confusion about what the meaning of UNTIL is.

Eliot
= --Apple-Mail=_2AF0393E-9608-4F65-A145-1901E81118C8-- From nobody Wed Jun 24 00:44:47 2020 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 DFF0B3A0C1B for ; Wed, 24 Jun 2020 00:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 mUHINz05Qlua for ; Wed, 24 Jun 2020 00:44:45 -0700 (PDT) Received: from mx01.lytzenitmail.dk (mx09.lytzenitmail.dk [185.147.72.157]) (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 74AD13A0C13 for ; Wed, 24 Jun 2020 00:44:44 -0700 (PDT) IronPort-SDR: 6i6L8Ki8Xn2Fw3oYfTGBllGVnodwpr44RhOSfCN5C/9HcoOExyhcNP3gGoSmeJA3K7qjbNvksM SCeX5pgO8rp9UoS6MHzIK4ofjPwL7s33h9ZR0sc+Vv+JMJNEVs7e2pIGKdd6OZmFRgLIm7H73C x77Au7PCVo1ITonTfNz3yNKhEVvQacZWQFoajjuQw/kjUjOMoLiX8YcYga02Yj9Nc9uT30VVBb WQZa2VtpnhM7pHNWC0AqEcV9kbN3p6a/rjYAmuxWbg52Q+zBxkT/x5SyUEj3PAkB3fuFEju3Xt UUM= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2APAAB4A/Ne/ygef2RmGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAB4ExAgEBAQEBCwGDBGmOA4gRD48?= =?us-ascii?q?kilKBfAsBAQE7AgQBAYRHAoIVASQ2Bw4CAwEBAQMCBQEBAQUBAQEBAQEFBIY?= =?us-ascii?q?PRYVzAQU6JhkQCw0LHBI9GgaGNgQBtzCBNBoCiHeBQIE4AYxigVs/gRGDED6?= =?us-ascii?q?BBIcAgi0EtGSCZIELC5gJAg0gkSEDjV2yBAKCBk2DXU8ZjjcMC44mP2oCBgg?= =?us-ascii?q?BAQMJWCOQJAEB?= X-IPAS-Result: =?us-ascii?q?A2APAAB4A/Ne/ygef2RmGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQFAB4ExAgEBAQEBCwGDBGmOA4gRD48kilKBfAsBAQE7A?= =?us-ascii?q?gQBAYRHAoIVASQ2Bw4CAwEBAQMCBQEBAQUBAQEBAQEFBIYPRYVzAQU6JhkQC?= =?us-ascii?q?w0LHBI9GgaGNgQBtzCBNBoCiHeBQIE4AYxigVs/gRGDED6BBIcAgi0EtGSCZ?= =?us-ascii?q?IELC5gJAg0gkSEDjV2yBAKCBk2DXU8ZjjcMC44mP2oCBggBAQMJWCOQJAEB?= X-IronPort-AV: E=Sophos;i="5.75,274,1589234400"; d="scan'208";a="6031068" Received: from unknown (HELO sv900pomx006.lytzenitmail.dk) ([100.127.30.40]) by mx01.lytzenitmail.dk with ESMTP; 24 Jun 2020 09:44:42 +0200 Received: from euklid.home (87-58-243-49-dynamic.dk.customer.tdc.net [87.58.243.49]) by sv900pomx006.lytzenitmail.dk (Postfix) with ESMTPA id 5C8037E; Wed, 24 Jun 2020 09:44:42 +0200 (CEST) Date: Wed, 24 Jun 2020 09:44:41 +0200 From: Lars Henriksen To: Neil Jenkins Cc: calsify@ietf.org Message-ID: <20200624074441.GA10321@euklid.home> References: <20200623145648.A5570F40716@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6212) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 07:44:46 -0000 On Wed, Jun 24, 2020 at 11:02:39AM +1000, Neil Jenkins wrote: > > Hmm, this is a bit confusing. The DTSTART/RRULE do match the dates it says > (the last one will be on Dec 23 as the UNTIL time is before 9am); there's no > requirement for the UNTIL to align exactly with an occurrence. However, the > English description above says "until December 24", which I would probably > interpret as inclusive too. Perhaps this is what should change (to say > December 23) rather than the DTSTART/RRULE and dates? That wouldn't solve the ambiguity. The problem is how to convert "December 24, 1997" to a DATE-TIME value type. In doing that you have to choose a local time. Look at the example on page 124: Every day in January, for 3 years: DTSTART;TZID=America/New_York:19980101T090000 RRULE:FREQ=YEARLY;UNTIL=20000131T140000Z; BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA or RRULE:FREQ=DAILY;UNTIL=20000131T140000Z;BYMONTH=1 Here the problem occurs for "January 31, 2000". Lars From nobody Wed Jun 24 04:05:50 2020 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 4F6FF3A0D51 for ; Wed, 24 Jun 2020 04:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 OlrJxlYNxVIw for ; Wed, 24 Jun 2020 04:05:46 -0700 (PDT) Received: from mx01.lytzenitmail.dk (mx09.lytzenitmail.dk [185.147.72.157]) (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 66DC03A0D5B for ; Wed, 24 Jun 2020 04:05:46 -0700 (PDT) IronPort-SDR: FvtlnEHVzD0UKmwvaH5uAjmIWfU8VrQyk8fJmGdeHPR95l5iS3A+9qVQ34cY+UEewfoQuHjkil wBtXFUeuZLXwgIUC0+BDj7qZbjakqlJ0nyi3pcNRdPFMn4hvK/anRKEf8y5UzayetMN+XVDVt4 MT63nBwYhEZaYd8lAGLxaacTZy3IcDzi54zXxAyJTln3XFO+FDqRK66KXNspWBP6N+oZPVKhcc YIKMOeAkIsX8lUZaSKYz55hPG2bNeMdZQLkqVlKmpMw2eV//s3Vr3N0+F/qD0t1lFfkkxz77Gv zdo= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CfAAAGM/Ne/ykef2RmGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQFAB4FDg25ejSWICw+PJIxOCwEBAQE?= =?us-ascii?q?BAQEBATUCBAEBhEcCghYBJDgTAgMBAQEDAgUBAQEFAQEBAQEBBQSGD0WFcwE?= =?us-ascii?q?FOiYZEAsNCxwSPRoGE4YjBAG3MIE0GgKJBIFAgTgBjGKBWz+EIT6BBIcAgi0?= =?us-ascii?q?EtGeCZIELC5gKAg0gkSEDjV+yFoF4TYNcUBmOQ44xPzM3AgYIAQEDCVgjkF0?= =?us-ascii?q?BAQ?= X-IPAS-Result: =?us-ascii?q?A2CfAAAGM/Ne/ykef2RmGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQFAB4FDg25ejSWICw+PJIxOCwEBAQEBAQEBATUCBAEBh?= =?us-ascii?q?EcCghYBJDgTAgMBAQEDAgUBAQEFAQEBAQEBBQSGD0WFcwEFOiYZEAsNCxwSP?= =?us-ascii?q?RoGE4YjBAG3MIE0GgKJBIFAgTgBjGKBWz+EIT6BBIcAgi0EtGeCZIELC5gKA?= =?us-ascii?q?g0gkSEDjV+yFoF4TYNcUBmOQ44xPzM3AgYIAQEDCVgjkF0BAQ?= X-IronPort-AV: E=Sophos;i="5.75,275,1589234400"; d="scan'208";a="6032921" Received: from unknown (HELO sv900pomx007.lytzenitmail.dk) ([100.127.30.41]) by mx01.lytzenitmail.dk with ESMTP; 24 Jun 2020 13:05:44 +0200 Received: from euklid.home (87-58-243-49-dynamic.dk.customer.tdc.net [87.58.243.49]) by sv900pomx007.lytzenitmail.dk (Postfix) with ESMTPA id 2DD147E; Wed, 24 Jun 2020 13:05:43 +0200 (CEST) Date: Wed, 24 Jun 2020 13:05:43 +0200 From: Lars Henriksen To: Eliot Lear Cc: calsify@ietf.org Message-ID: <20200624110543.GB12099@euklid.home> References: <20200623145648.A5570F40716@rfc-editor.org> <47A062D0-71F7-4008-B8A2-79AD7B2079C5@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47A062D0-71F7-4008-B8A2-79AD7B2079C5@cisco.com> Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6212) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 11:05:49 -0000 On Wed, Jun 24, 2020 at 09:35:31AM +0200, Eliot Lear wrote: > > On 24 Jun 2020, at 03:02, Neil Jenkins <[1]neilj@fastmailteam.com> wrote: > > Hmm, this is a bit confusing. The DTSTART/RRULE do match the dates it says > (the last one will be on Dec 23 as the UNTIL time is before 9am); there's no > requirement for the UNTIL to align exactly with an occurrence. However, the > English description above says "until December 24", which I would probably > interpret as inclusive too. Perhaps this is what should change (to say > December 23) rather than the DTSTART/RRULE and dates? > > Either change would be fine, Hmm, not quite. The example should illustrate how to interpret an English text like "until December 24, 1997" for an UNTIL rule part of value type DATE-TIME. In doing that you have to pick a local time from the context. The UNTIL value of the example converted to local time is 7:00 PM EST, December 23, 1997, which certainly is after 9am and eliminates December 24, but seems completely arbitrary. Lars From nobody Tue Jun 30 08:26:10 2020 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 AB5643A0A0D for ; Tue, 30 Jun 2020 08:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 sJsGksOXJzKA for ; Tue, 30 Jun 2020 08:26:07 -0700 (PDT) Received: from mx01.lytzenitmail.dk (mx09.lytzenitmail.dk [185.147.72.157]) (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 B713E3A09E8 for ; Tue, 30 Jun 2020 08:26:06 -0700 (PDT) IronPort-SDR: YiguD23oA/JN6tnhXUixH00EIONeINr6IEaz1vGR00MLpk97iMXPKX8AyzqShf45iYwmUAhNbU zG2U29W9HFW2gGJLIxSsyuNhmFvcjRlE8GNDQjr6hCdShp+8qr+Rfr15ixtGYLlRV1/YXpK9FS k4l2WpAtOzW5pj1L6oNI0Erse2ceIkAKXuYuaw8qaDTYFF+/UPPda9Xyi3gE+pjMg3326xtuPb jaMpc54/CcVWc18n/ADFAsbTsGAFFC2Jx6oK36OkhAaaebwNqh0Ps25O/p0S5AS4SO0VYCph/O B4c= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2CaAwDfWPte/ygef2RgHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAB4FDgXuBCmmOEIgjjyWMUAsBAQEhGgIEAQGERwKCLQEkOBM?= =?us-ascii?q?CAwEBAQMCBQEBAQUBAQEBAQEFBIYPRYVvBjomKQsNJxI9GoJ0g0gEAa8qgTQ?= =?us-ascii?q?aAokdgUCBOIxogVs/hCE+gQSEBoJ8gi0EtQCCZoELC5gdAg0ggnOJLYUOA41?= =?us-ascii?q?lsjyBeE2DXU8ZjkOOMT9qAgYIAQEDCVgjjyoBAQ?= X-IPAS-Result: =?us-ascii?q?A2CaAwDfWPte/ygef2RgHAEBAQEBAQcBARIBAQQEAQFAB?= =?us-ascii?q?4FDgXuBCmmOEIgjjyWMUAsBAQEhGgIEAQGERwKCLQEkOBMCAwEBAQMCBQEBA?= =?us-ascii?q?QUBAQEBAQEFBIYPRYVvBjomKQsNJxI9GoJ0g0gEAa8qgTQaAokdgUCBOIxog?= =?us-ascii?q?Vs/hCE+gQSEBoJ8gi0EtQCCZoELC5gdAg0ggnOJLYUOA41lsjyBeE2DXU8Zj?= =?us-ascii?q?kOOMT9qAgYIAQEDCVgjjyoBAQ?= X-IronPort-AV: E=Sophos;i="5.75,297,1589234400"; d="scan'208";a="6110413" Received: from unknown (HELO sv900pomx008.lytzenitmail.dk) ([100.127.30.40]) by mx01.lytzenitmail.dk with ESMTP; 30 Jun 2020 17:26:04 +0200 Received: from euklid.home (87-58-243-49-dynamic.dk.customer.tdc.net [87.58.243.49]) by sv900pomx008.lytzenitmail.dk (Postfix) with ESMTPA id 5488D6D for ; Tue, 30 Jun 2020 17:26:04 +0200 (CEST) Date: Tue, 30 Jun 2020 17:26:03 +0200 From: Lars Henriksen To: calsify@ietf.org Message-ID: <20200630152603.GA24346@euklid.home> References: <20200623145648.A5570F40716@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200623145648.A5570F40716@rfc-editor.org> Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6212) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 15:26:09 -0000 The erratum hasn't aroused much interest, possibly because it concerns an example that isn't normative? What purpose do examples then serve? I assume they are there to illustrate and clarify the use of normative rules and regulations. The example in question does the opposite. It is confusing and obscure. I'll explain. The event (1997 9:00 AM EDT) September 2 shall be repeated daily until December 24, 1997. To this end (1997 7:00 PM EST) December 23 is used to set the value of the recurrence rule part UNTIL. Because DTSTART is apecified as a date with time and time zone reference, UNTIL becomes UNTIL=19971224T000000Z Now, please justify the choice of 7pm EST, December 23, 1997. Lars Henriksen From nobody Tue Jun 30 17:07:20 2020 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 938703A07CA for ; Tue, 30 Jun 2020 17:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=TO1IDVFa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tff+1sez 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 kWqKgxe3ywRY for ; Tue, 30 Jun 2020 17:07:18 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528CD3A07C7 for ; Tue, 30 Jun 2020 17:07:18 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 72B125CD; Tue, 30 Jun 2020 20:07:17 -0400 (EDT) Received: from imap38 ([10.202.2.88]) by compute4.internal (MEProxy); Tue, 30 Jun 2020 20:07:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm3; bh=aWNn cPhR0oXqidanReCADx938VbMpJj0QgRRXBaHZg0=; b=TO1IDVFaiz2WfgaWTqR5 PYwyz2xjC9BOq/LnGrpsxVbma/BGZCOTOf4+05hdtmh7cZVJKr7bafVXiqYt5EHu Bbh1W564u3FCJdC5t2u1A0LOQIxy4CPH4WU672Nrg6Zp5DFMf0owAOyd4vz3KvAZ qp/BlxClY+0NW0q0Qlsot/anlm+Jtj9b+m2t+4ovA4b2xJX2ghyfmTpzxjgKKIM+ ojHvSuH8ijCVy2Klf6uQOPv9cRWITMTLMGLXV0bVJ1rCqrN4MJ30hmeJ05AAdJY0 l5YlAWa2yv3iYgt/OZqIsWCw4KDg82GbTN39dS5JCY+URsOH5J1Y3r0AMgBmZNbL 0A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=aWNncP hR0oXqidanReCADx938VbMpJj0QgRRXBaHZg0=; b=tff+1sezyvEXSBECNYiogC HnGEQKUZ7EaEpjKLd3SDg8p1lbtBESr3VMqr6R0uOAxtgjRNLepY/jLC9TTR2LHD n33JGoWjQJ46EGDVL6VOImJlNL6M6D0ykrxiqB7VUSDvlbEvq6hpMxW9RbwqziCw b/V/stLgXEEelPHaRuLl76ihO8Vdai0udnNJRWrbkpm8xbnf7kkUxGjL3ksKNaPF VYX2XbRbL3HWu5/e/S/JxGKWJ+LViHmZ/mAbdUkgHJ0luqcFbj8bgBAjAI82hx6N gs/wL2pRlP2Z/f603W0QbXAIHBrTy+eqDXbdaTn5b1l2BT1udAnyh/j+yhmnlsVQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtddugdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepvedvtedvudelkefhgefhteeftedtlefhheefveffveelkedu tdduffeiveejvefhnecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 54C164AA005C; Tue, 30 Jun 2020 20:07:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-598-ga0ddc1b-fm-idx2020-20200630.003-ga0ddc1ba Mime-Version: 1.0 Message-Id: In-Reply-To: <47A062D0-71F7-4008-B8A2-79AD7B2079C5@cisco.com> References: <20200623145648.A5570F40716@rfc-editor.org> <47A062D0-71F7-4008-B8A2-79AD7B2079C5@cisco.com> Date: Wed, 01 Jul 2020 10:07:15 +1000 From: "Neil Jenkins" To: "Eliot Lear" Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary=861a305d702b44349a59008b8f901caa Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6212) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 00:07:20 -0000 --861a305d702b44349a59008b8f901caa Content-Type: text/plain On Wed, 24 Jun 2020, at 17:35, Eliot Lear wrote: > Either change would be fine, but as reported, Lars' corrected text is correct, and since he took the time to report it, I suggest that we mark this erratum as *verified* Sounds reasonable to me. Neil. --861a305d702b44349a59008b8f901caa Content-Type: text/html
On Wed, 24 Jun 2020, at 17:35, Eliot Lear wrote:
Either change would be fine, but as reported, Lars' corrected text is correct, and since he took the time to report it, I suggest that we mark this erratum as verified

Sounds reasonable to me.

Neil.
--861a305d702b44349a59008b8f901caa--