From nobody Wed Jul 1 22:11:29 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 9E6273A0CCA for ; Wed, 1 Jul 2020 22:11:27 -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=x+Pj8+nN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GKTMXvKd 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 TjvDLfqzF6gu for ; Wed, 1 Jul 2020 22:11:26 -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 62AD03A0CC9 for ; Wed, 1 Jul 2020 22:11:26 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 156ED9C4 for ; Thu, 2 Jul 2020 01:11:24 -0400 (EDT) Received: from imap38 ([10.202.2.88]) by compute4.internal (MEProxy); Thu, 02 Jul 2020 01:11:24 -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=En2ryZY c/D+XvJkQypjt+Y3KcPHmiwXV3oFtGqaiOaQ=; b=x+Pj8+nNaw2ZKwJfbkpPM00 wdh3c31JIHt42sUpUcsL6bLw669vAELblsdvDdjcDNnCg5/Gb+y2eWlnVACR5vQJ FqjAtQLRC4tnsagfVayTONFcW72rAG/v1y7rD0oMd8boz/PxvJ0OdeDpmEcmKF+0 GmBO+UZnsj+it5UTmWXzlreSAeVBdAjH28/uX3semo4n/YmBrRQ534f7vWtXXS1J Z1zsnnfBiBDkvDQwPY2VQNQz2qzOT8CyHMIDPOBiu0FoDuO4Q6Hs20LxZVJgYMLr +sNSv5+NuL7PR0DJiWXkewWzzi4TCl9HwVZ9WJgGGiv6xTdEX/Nul5N/WnxOTgg= = 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=En2ryZ Yc/D+XvJkQypjt+Y3KcPHmiwXV3oFtGqaiOaQ=; b=GKTMXvKdqcLKwZbmb8yJoJ +jmu382rE4oKFQYRy0ssLJ/jIzAQkd6k4MW7u0WbgkN+5qz6+R3/0tJpO1z/xbu1 x0oGD8V0Cny0n9Z/7yU7mxBI+ubJ9Vnsnr7lwMo3IdIK51pqAvctM9Ara6PVST+2 KPEc1mlhzYk6JzUn1BruuguoIu03VwN6mAkfhGneRz6d9m4718hgnLK963uZ12gQ u0I+AlTV5VjmsmN9E+aEIdw/ZsBHYsk5VFTEAwCeNVlgECvBr+KmWUpyAlfR9QXT Y5gzMMojmNmmBPe/psBAJ3fzEyk3GLi6Yai5GptEPpN0EyhCwC8b/U6QwM5JC+Zg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtdefgdeludcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevvdetvdduleekhf eghfetfeettdelhfehfeevffevleekuddtudffieevjeevhfenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 605934AA005C; Thu, 2 Jul 2020 01:11:23 -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: <96261515-b222-48f2-b7c5-bdf364493f62@dogfood.fastmail.com> In-Reply-To: <92d62769-8b2f-05c1-3bff-98644425369f@gmail.com> References: <92d62769-8b2f-05c1-3bff-98644425369f@gmail.com> Date: Thu, 02 Jul 2020 15:11:22 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=32e4bbac12e34b0b9b1e8e3194e28a62 Archived-At: Subject: Re: [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: Thu, 02 Jul 2020 05:11:28 -0000 --32e4bbac12e34b0b9b1e8e3194e28a62 Content-Type: text/plain The idea as I understand it is: 1. You create an event where you add a group attendee (kind: `group` in JSCalendar); the sendTo method for this group participant may be an email alias that expands to several individual people. 2. The recipients RSVP. To do so, they add a new "individual" participant (ATTENDEE) representing just them, and they set the memberOf property (MEMBER parameter in iCal) to indicate the group participant they are part of that caused them to be invited. Of course this requires both: * The client to know the alias resolutions so it can work out which group the individual is part of. * The server to know the alias resolutions so it can verify this is true and the user isn't just gate crashing. This is doable within a closed system, probably not in a federated environment. In that situation, you'd just have to behave like the invitation was forwarded to you (i.e. you add yourself and hope the server will accept). Neil. --32e4bbac12e34b0b9b1e8e3194e28a62 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
The idea as I u= nderstand it is:
  1. You create an event where you add a gr= oup attendee (kind: group in JSCalendar); the s= endTo method for this group participant may be an email alias that expan= ds to several individual people.
  2. The recipients RSVP. To do = so, they add a new "individual" participant (ATTENDEE) representing just= them, and they set the memberOf property (MEMBER parameter in iCal) to = indicate the group participant they are part of that caused them to be i= nvited.
Of course this requires both:
    The client to know the alias resolutions so it can work out which group= the individual is part of.
  • The server to know the alias res= olutions so it can verify this is true and the user isn't just gate cras= hing.
This is doable within a closed system, probably = not in a federated environment. In that situation, you'd just have to be= have like the invitation was forwarded to you (i.e. you add yourself and= hope the server will accept).

Neil.
--32e4bbac12e34b0b9b1e8e3194e28a62-- From nobody Wed Jul 1 22:18: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 299233A0CD6 for ; Wed, 1 Jul 2020 22:18: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=1AJQz9H6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=K1qTzYAV 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 KHP5umpIZJ9T for ; Wed, 1 Jul 2020 22:18:54 -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 70EE73A0CD5 for ; Wed, 1 Jul 2020 22:18:54 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id CACEB92B for ; Thu, 2 Jul 2020 01:18:53 -0400 (EDT) Received: from imap38 ([10.202.2.88]) by compute4.internal (MEProxy); Thu, 02 Jul 2020 01:18:53 -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=7CMX+w9 kUu9u8TdqZ9acljjchVI/Jvah0RlcPjwgkh8=; b=1AJQz9H6e1qqPLlgPI6G84c D7W4rk6oy2EJoO3Ugg+W7vImuCN4/vRUPmppEY9GK5vMcaF7bsHcFhMHOLhVBG6g H+S0u7UEivnrttg+eAUW+oVEi1WspW39MUaf90hEH0knXhRBjnlqloOgP6Dnsrvx qWpumLmo35lsRrugHY7BrpNASp0kjcRlxOvEf3kXThnlOrCsZVFIagwN484fGkAU Bpvrd2R2nintraf68uyQeF3drGKsCSSiMM075GjIjWs3tWYYvBZluPn++6+IlWv0 zQVO3AWud/UdURPY9TcBB8cLsJ2HrNuV1qWTa1IIy5aH2aJIlrLl/g5yKVkwSbA= = 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=7CMX+w 9kUu9u8TdqZ9acljjchVI/Jvah0RlcPjwgkh8=; b=K1qTzYAVmncX6Isr6UNr5L gs79MmVT+7jpSoLr2MhekiUoYzVoLrB9x2K4t8zsv7qC/Q5ob3zbwFrDdgfzrs/U +aaZI8gOcevR62nYlvA9ffdh7+UhYDfdwwYy2oTVBBpDbO1n8fGhLe0vVAgb4KLA QYA4ACeWU/Z+vsxfLDMuXveZQbp7KOPQMw59fksq8ABHHN9DLjmpvpR32ghyPS7o GY6kCHfLIzLuKA5WxLiIW943zjhUYhZqz81FZNPykAoYf02t757ePZldvTUu6/ZY u4wh+/fj58s34gPdvdxyVV/wyK2OUZ0WbxW9bBrO+fg6UWD3AUXKKdUuFKYyAhKg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtdefgdelvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffueekjeekfeehhe efkeefkeeileekffdvudeftefgiefhjeevleeiueevteeuhfenucffohhmrghinhepihgv thhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 17A1E4AA005C; Thu, 2 Jul 2020 01:18:53 -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: <5394288a-b523-4f99-b88d-b983d06ea23d@dogfood.fastmail.com> In-Reply-To: <16c59d9a-952b-15b6-8485-ed9320af8c70@gmail.com> References: <16c59d9a-952b-15b6-8485-ed9320af8c70@gmail.com> Date: Thu, 02 Jul 2020 15:18:52 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=a6ab5b3773264864bf153f0a117590f1 Archived-At: Subject: Re: [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: Thu, 02 Jul 2020 05:18:56 -0000 --a6ab5b3773264864bf153f0a117590f1 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, 24 Jun 2020, at 12:34, Michael Douglass wrote: > How should this be mapped? >=20 > We're using the linkids to refer to a link but there doesn't appear to= =20 > be any appropriate rel value. I suggest "about " =E2=80= =93 the context here is the participant, and this is a link to more info= rmation about that participant. > The same sort of question arises for ALTREP and LOCATION. The same rel seems appropriate there too to me. Neil. --a6ab5b3773264864bf153f0a117590f1 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Wed, 24 Jun = 2020, at 12:34, Michael Douglass wrote:
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.
<= /blockquote>

I suggest "about" =E2=80=93 the context here is th= e participant, and this is a link to more information about that partici= pant.

The same sort of question arises for ALTREP and LOCATION.

The same rel seems appropriate there= too to me.

Neil.
--a6ab5b3773264864bf153f0a117590f1-- From nobody Wed Jul 1 22:21: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 4AF043A0CDA for ; Wed, 1 Jul 2020 22:21: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_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=C8POuYt+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MLH7OCmp 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 DQJMfn1uUVOP for ; Wed, 1 Jul 2020 22:21:15 -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 2D2083A0CD9 for ; Wed, 1 Jul 2020 22:21:15 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B9ECD783 for ; Thu, 2 Jul 2020 01:21:13 -0400 (EDT) Received: from imap38 ([10.202.2.88]) by compute4.internal (MEProxy); Thu, 02 Jul 2020 01:21:13 -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=Ao24gSn 6s1GDh/zBpkea8+M7VRDE56GDDtFVyYJjsuI=; b=C8POuYt+ZWZbcrB4l5WIhtL /VHQ7/rnM5sz3WsRkqpMh5xJo9++1/I3L2mZN/6auMuZwdGcNSuogCmWlVnJRwVn mMPzTh3GrT0E1IDA3Vcg4A8VJU+d+h9NT/cKlzcmo4XbrMKcLdHBg5JvE3BwJeFD hjX+8z2Q/iROoF6dOJQLI9IXWj32QLwLz2wguoTh02ncGkozhEFgEuglOZ1oXyZW FVgerwhRj/hMb+KQ64LNIO+bxUIQja1gfAHHstUPDD5MBVxfs1MuMYtHcUrQ5Rme bbL5riDJM6sSrDuWSqOzGRufhi1zZTO4LDQuDar7mbkXPo+/ZTTrTPl2PfgAsyA= = 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=Ao24gS n6s1GDh/zBpkea8+M7VRDE56GDDtFVyYJjsuI=; b=MLH7OCmpXDl7OQXFUsV8h2 hqK7TK7WSNerXDucoGKuufbrIZfez5auSeRPh3RxCZ7EzKdbWHO91epcS4o8lIwr fB3oc+z7rik8ZedfnZIcX0ANloSRTnVYIAQaynWSz4RmTWYSa1XjGZjRM0Im9Ue/ 1vsNME2LL8ZSvx56S8gfZzlE64sPltw/8PBS4+nxO/0sKcsEibHl24zC1DZVS/MA KyKdEmavjCsUyfTKraPu1jU6Vru+PN85ManAtIwXoZuBg0dcCbWRzUQkDCHIzAPA pztjVyobQ2aUKRssexCIAwwRpjBAjfrxWQVpRdpf6mMgS9jFtNmZoxm/PVpSvXmA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtdefgdelfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevvdetvdduleekhf eghfetfeettdelhfehfeevffevleekuddtudffieevjeevhfenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 081414AA005C; Thu, 2 Jul 2020 01:21:12 -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: <0a9ee93d-d94d-cda6-56ed-f0e04adc63e0@gmail.com> References: <0a9ee93d-d94d-cda6-56ed-f0e04adc63e0@gmail.com> Date: Thu, 02 Jul 2020 15:21:12 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=a3039110910447a6befb7725849d8bfb Archived-At: Subject: Re: [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: Thu, 02 Jul 2020 05:21:16 -0000 --a3039110910447a6befb7725849d8bfb Content-Type: text/plain On Wed, 24 Jun 2020, at 14:21, Michael Douglass wrote: > We have schedule-agent from 6638 > Can we add SCHEDULE-FORCE-SEND and SCHEDULE-STATUS? I guess so. I'll look at adding those. Neil. --a3039110910447a6befb7725849d8bfb Content-Type: text/html
On Wed, 24 Jun 2020, at 14:21, Michael Douglass wrote:
We have schedule-agent from 6638
Can we add SCHEDULE-FORCE-SEND and SCHEDULE-STATUS?

I guess so. I'll look at adding those.

Neil.
--a3039110910447a6befb7725849d8bfb-- From nobody Thu Jul 2 17:23:42 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 80C793A0ACB; Thu, 2 Jul 2020 17:21:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: barryleiba@computer.org, calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373569951.29538.3111845918223884431@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:21:39 -0700 Archived-At: Subject: [calsify] calext - Requested session has been scheduled for IETF 108 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: Fri, 03 Jul 2020 00:21:48 -0000 Dear Daniel Migault, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. calext Session 1 (0:50 requested) Friday, 31 July 2020, Session II 1300-1350 Room Name: Room 2 size: 2 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/sessions/calext.ics Request Information: --------------------------------------------------------- Working Group Name: Calendaring Extensions Area Name: Applications and Real-Time Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 50 Minutes Number of Attendees: None Conflicts to Avoid: Chair Conflict: jmap extra ace drip People who must be present: Barry Leiba Daniel Migault Bron Gondwana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jul 2 19:56: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 695A13A0B90 for ; Thu, 2 Jul 2020 19:56: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 D8hMA12SaoMz for ; Thu, 2 Jul 2020 19:56:55 -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 E3E453A0B8F for ; Thu, 2 Jul 2020 19:56:54 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id z63so27622929qkb.8 for ; Thu, 02 Jul 2020 19:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=PGdIc1wpAq1LjVbkJb2gipZLIS8QgX7N/F8xBaUu20c=; b=TYmyP+HYfXkr1enRP+dtyW4hhU6PkmZSxE14xo8sb4oTWXPqCX37Ik7F5gdVTqITsI rWRy450BcW2tkzkG6oQkbR/99iMJ5C6HY9b9PDEff1inDKrzdqeoRswKRSb8+VN4GwqE uN3H4riWQSQ4cB0VgjEY77hmLxZkNYif61tyJpeeXg1Eackad4VwPKhuZjrlxaSFyXOp w9deXmj24xOyEPF29VyBT8coNOdQ/wCmP5fJ0JlH2tQOiwlU99hRRIlbaJo8/8UurIXA ZcTu2jM6apcAgDg1cp5IfyuN5H48wRqSB5b9KuqruOhRiIXsrCX4eQEFbva0YdbFrgvW Kl4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=PGdIc1wpAq1LjVbkJb2gipZLIS8QgX7N/F8xBaUu20c=; b=lKQO0f4dz9JeE2igkZAD2RFOtPCoibp+0uKZkIqIx/1Mr0T1r1co3JW8xR8BLYmMXq Zk5FT4cqPf4rK3WMOG0qNjno6xRn9wRBbSxef0qpzHsvjwatDfXRD6BbA3sJIR3ppDlI 8pkKjrMWceZQP021yCZ1ADJkQo8EcEsAC7pBo3XO4SbRHBmojyzICP3S81yyqpGOtust Oac+ALbY/9q1YjzkHWfP3K3cyGWezHWam0f0iRUbxKqsiQ0zsKpWbXrv4PLYtrneOsL/ H2Jc3omioq3dlBEdoNgv44XUtZXbOvKtz50dJLg8BlOtGWRNg5+H+wOhXoTthKnV14n0 M24w== X-Gm-Message-State: AOAM530zIHeZh1hcyBmnj7KAdQIQ+nq/C59XYAaFr5vdY/uVlRTpaqyt 8bIIMZnZoFOjummtWs21QuC/aGEn X-Google-Smtp-Source: ABdhPJx2LCuGLDsZ7eChqsZU+NC/bt3c7O/A4oS/eHXTUPajsuQw8hwyvF+3DAsqwUaX/P1BnsxcRA== X-Received: by 2002:ae9:c010:: with SMTP id u16mr31927674qkk.37.1593745013452; Thu, 02 Jul 2020 19:56:53 -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 f22sm12938519qko.89.2020.07.02.19.56.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Jul 2020 19:56:52 -0700 (PDT) To: Neil Jenkins , calsify@ietf.org References: <16c59d9a-952b-15b6-8485-ed9320af8c70@gmail.com> <5394288a-b523-4f99-b88d-b983d06ea23d@dogfood.fastmail.com> From: Michael Douglass Message-ID: <5aed7945-a8f9-4609-55c9-ce84b203c862@gmail.com> Date: Thu, 2 Jul 2020 22:56:51 -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 In-Reply-To: <5394288a-b523-4f99-b88d-b983d06ea23d@dogfood.fastmail.com> Content-Type: multipart/alternative; boundary="------------DE4C1A7A7CA4A41C4E479B7D" Content-Language: en-US Archived-At: Subject: Re: [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: Fri, 03 Jul 2020 02:56:56 -0000 This is a multi-part message in MIME format. --------------DE4C1A7A7CA4A41C4E479B7D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/2/20 01:18, Neil Jenkins wrote: > On Wed, 24 Jun 2020, at 12:34, Michael Douglass wrote: >> 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. > > I suggest "about " – > the context here is the participant, and this is a link to more > information about that participant. I've read that and it doesn't seem right. One is not 'about' the other as in "a review about dog food". However, I reread the definition for "alternate" in the html spec and it seems closer to what we want. I think dir and altrep are both about an alternative representation of the subject. Can we use that? > >> The same sort of question arises for ALTREP and LOCATION. > > The same rel seems appropriate there too to me. > > Neil. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------DE4C1A7A7CA4A41C4E479B7D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 7/2/20 01:18, Neil Jenkins wrote:
On Wed, 24 Jun 2020, at 12:34, Michael Douglass wrote:
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.

I suggest "about" – the context here is the participant, and this is a link to more information about that participant.

I've read that and it doesn't seem right. One is not 'about' the other as in "a review about dog food".

However, I reread the definition for "alternate" in the html spec and it seems closer to what we want. I think dir and altrep are both about an alternative representation of the subject. Can we use that?


The same sort of question arises for ALTREP and LOCATION.

The same rel seems appropriate there too to me.

Neil.

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------DE4C1A7A7CA4A41C4E479B7D-- From nobody Thu Jul 2 21:58:32 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 5652D3A0C95 for ; Thu, 2 Jul 2020 21:58:30 -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=J0M1WvHX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=O/1d52cT 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 DytVsN53sHeD for ; Thu, 2 Jul 2020 21:58:29 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C1A3A0C92 for ; Thu, 2 Jul 2020 21:58:29 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 18BB61835; Fri, 3 Jul 2020 00:58:28 -0400 (EDT) Received: from imap38 ([10.202.2.88]) by compute4.internal (MEProxy); Fri, 03 Jul 2020 00:58:28 -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=v7XqmkD amQQqn2j/MiHNWhQYL6PgxPOohEjz20jEcMI=; b=J0M1WvHXlhNrrMMURsJW4M7 gP1Btjtr7uFgLusoRWcGiSPwSpu+2u12OyUSyhwhCJM5qdjZQSenTHSi5uizVEdP fpAMin6u5qAoR7cOCGVvIMvQaGkoiLCg4d1f/Epc0eujuNc5eT+p3o8EKLRwgVm7 t+yuP4OYTakJtmuf9+nkYwgEclDf2s5wMa5J+iYXtWNKn+QnT/AelH4Qxt8yqm39 teNKJmMZicoaYTei3YFunMpTlywhCFToV9kStDJ2qPdHxnUjU8ryEehLcZkyIBaQ LPtyeJpGzB4iHRTKxv12Kf7pP62dRT1II2k/nszNwQTV4Jp3J4QdZMaZ74MjjpQ= = 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=v7Xqmk DamQQqn2j/MiHNWhQYL6PgxPOohEjz20jEcMI=; b=O/1d52cTQJwK40qBb7ki93 rf9Aw18BZcF0y3UNQpep+o8GZio55WsbnfR9lUyYKHJY+Qh0wVO+fZXkDjY6GIbF t0ppEHO83b9XFh4dTLHSH1J+DR8x3ipwY5HrMYhAyEUAp9VUPqRvcPKUpTuMZnhK ruIni8YhjeN4ZacwOePzYFVaPjD+2d03Ng16X8M9wpcNV/W36Wy8WdFAYssZamsT /kfrLoVAc3XHiqtfRJTpVrhps18dKRMbKtEZPAkUDnUIj9v+gZWYbWHPEVPNzOQn p1fo0SVbnAdeZ3aHH/sBbDfgjJrc1EF1JWej0fY0TRAHqt+EOIWNeGIN/r7SKsWA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtdehgdeklecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepvedvtedvudelkefhgefhteeftedtlefhheefveffveelkedu tdduffeiveejvefhnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5B75B4AA005C; Fri, 3 Jul 2020 00:58:27 -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: <1aa81af4-a2f3-442c-b8f5-5290b83c6437@dogfood.fastmail.com> In-Reply-To: <5aed7945-a8f9-4609-55c9-ce84b203c862@gmail.com> References: <16c59d9a-952b-15b6-8485-ed9320af8c70@gmail.com> <5394288a-b523-4f99-b88d-b983d06ea23d@dogfood.fastmail.com> <5aed7945-a8f9-4609-55c9-ce84b203c862@gmail.com> Date: Fri, 03 Jul 2020 14:58:26 +1000 From: "Neil Jenkins" To: "Michael Douglass" , calsify@ietf.org Content-Type: multipart/alternative; boundary=487fc9899b4f40e895fc440331425166 Archived-At: Subject: Re: [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: Fri, 03 Jul 2020 04:58:30 -0000 --487fc9899b4f40e895fc440331425166 Content-Type: text/plain On Fri, 3 Jul 2020, at 12:56, Michael Douglass wrote: > However, I reread the definition for "alternate" in the html spec and it seems closer to what we want. I think dir and altrep are both about an alternative representation of the subject. Can we use that? Works for me. Neil. --487fc9899b4f40e895fc440331425166 Content-Type: text/html
On Fri, 3 Jul 2020, at 12:56, Michael Douglass wrote:
However, I reread the definition for "alternate" in the html spec and it seems closer to what we want. I think dir and altrep are both about an alternative representation of the subject. Can we use that?

Works for me.

Neil.
--487fc9899b4f40e895fc440331425166-- From nobody Mon Jul 13 11:31:23 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 6CBD33A1686; Mon, 13 Jul 2020 11:31: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.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <159466508239.27258.16533986392484822795@ietfa.amsl.com> Date: Mon, 13 Jul 2020 11:31:22 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-valarm-extensions-02.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: Mon, 13 Jul 2020 18:31:22 -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 : VALARM Extensions for iCalendar Authors : Cyrus Daboo Kenneth Murchison Filename : draft-ietf-calext-valarm-extensions-02.txt Pages : 16 Date : 2020-07-13 Abstract: This document defines a set of extensions to the iCalendar VALARM component to enhance use of alarms and improve interoperability between clients and servers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-valarm-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-valarm-extensions-02 https://datatracker.ietf.org/doc/html/draft-ietf-calext-valarm-extensions-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-valarm-extensions-02 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 Jul 13 11:32: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 CA6463A169C for ; Mon, 13 Jul 2020 11:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=fastmail.com header.b=H9nbpNWK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KQF3rI4C 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 xC6tXO_2is9P for ; Mon, 13 Jul 2020 11:32:13 -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 6B2B13A16BE for ; Mon, 13 Jul 2020 11:31:58 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 760A63E8; Mon, 13 Jul 2020 14:31:57 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 13 Jul 2020 14:31:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm3; bh=UvlDvtQBN8QI5SNN1X7HAjeoB7f qFFs6BhMgWYpBxgw=; b=H9nbpNWKaFS1DKqRaQrusyvmdwaHCS6wnEBtxIJr2iU gwC5qFeXs6/w+T/Fa8JGgN6z4fSNPq5yqu4B/omsDlL19p5JkJYo6PAVKbgNGPKd z8lEcX/2xvqlFMDJk3+rPZKTdYmImtKg4GeCeEmqs4WGiibzvsHUzeZxPDjYRzVh lgUIOGM4eWW9/7HSKutu4ZgLgOt5t/HGONTs/drVmmVC0z4p60zhAa1wHtM0PGlV X+LJkThN6tNH36rBHmd9pWWVEr9atv3670MDeU8M1dVl0c/9hlAMzVm4TfhaEuku 7IJ+t8rWU5QaSJtNH1ZUb83e0dZu7uylH0yETRLiB0g== 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=UvlDvt QBN8QI5SNN1X7HAjeoB7fqFFs6BhMgWYpBxgw=; b=KQF3rI4CV8ARLVrXuTLO6h roYyCv20VdWIVzS73DABNyWn6eiefvp/jDI6J+tGQL/zvmGWm3sMYsVQcJpa4C6i jD9NHDNU+c1+UZXGfqHQ558cmSLr6sDuSPE5BHluy0cEb1NqBX9HrhnzrPA9km9j 1ZccEuGAXXDYAQPQ+x7t6RfyUCnQD10iP7UNcvga21/or7TT+9A5+EP0jbyN0MWd ak1IExXX4fzFrmFblx5YNMkGrf9YOetzEBkVQ5wmSF/xmZ9QHVBAEWyTrPMXOWHA In6hi30REoEMC8BfOhoWYkNpMqAXukEWVhKU7m2c3lEd/YRF2yKru5Id95yAVYzg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvdekgdduvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtsegrtderredtfeejnecuhfhrohhmpefmvghnucfo uhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlrdgtohhmqeenucggtffrrg htthgvrhhnpeffuefhvefggfdvudeuvdetieejuedvvdekudeggedvffevgfduffeuieel geeggeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeejgedrjeejrdekhedrvd ehtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm uhhrtghhsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id A8A9A3280060; Mon, 13 Jul 2020 14:31:56 -0400 (EDT) To: Daniel Migault , Bron Gondwana Cc: IETF-Calsify References: <1e51cd80-feac-4fbf-87dd-5528599d836d@dogfood.fastmail.com> <5742d7f7-4a77-4f53-a46d-2125e7c2b4d9@dogfood.fastmail.com> From: Ken Murchison Message-ID: Date: Mon, 13 Jul 2020 14:31:56 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4C8F2C8E52EA27C894A6AA57" Content-Language: en-US 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, 13 Jul 2020 18:32:17 -0000 This is a multi-part message in MIME format. --------------4C8F2C8E52EA27C894A6AA57 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Daniel, Thanks for the review and sorry for my slow reply.  Responses inline.  I just posted -02 with a few changes and can make more if required. On 6/15/20 3:48 PM, Daniel Migault wrote: > 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. > > I'm not sure exactly what the issue is with the current wording, but I changed "popular" to "prevalent". > > [ .... ] > > 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. > It is standard with ABNF (at least as far as I have seen) to structure the definitions this way. > >    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. > > > Yes, good catch. > > 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 > Fixed. > >    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. > The mechanism for "switching off" alarms on devices, is that each device should sync the iCalendar resource with the server just prior to firing the alarm.  If the VALARM contains an ACKNOWLEDGED property on/after the trigger time, then the device should not fire the alarm. For disconnected devices, there is no solution that I'm aware of. > > [ ... ] > > 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. > > There is a computed trigger time that corresponds to each occurrence.  Does that clarify? > [ ... ] > > 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. In order to do this via CalDAV, the attacker would have to have credentials to update the iCalendar resource.  If they have the user's credentials, they can do a lot more damage than just silencing alarms. > > 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. I'm not sure I follow. > > > > > 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 ? > A proximity alarm would trigger when you arrive/leave a certain location.  If the user acknowledges the alarm, then they would leak WHEN they where at that location.  I'm open to new suggested text. >    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 > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Kenneth Murchison Senior Software Developer Fastmail US LLC --------------4C8F2C8E52EA27C894A6AA57 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Daniel,

Thanks for the review and sorry for my slow reply.  Responses inline.  I just posted -02 with a few changes and can make more if required.


On 6/15/20 3:48 PM, Daniel Migault wrote:
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

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

</mglt>


I'm not sure exactly what the issue is with the current wording, but I changed "popular" to "prevalent".




[ .... ]

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

<mglt>
I believe this should go after *ext have been defined, though I am not very familiar with ABNF. 
</mglt>


It is standard with ABNF (at least as far as I have seen) to structure the definitions this way.




   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

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

</mglt>


Yes, good catch.




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

<mglt>
to be specified
</mglt>


Fixed.




   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.

<mglt>
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.
</mglt>


The mechanism for "switching off" alarms on devices, is that each device should sync the iCalendar resource with the server just prior to firing the alarm.  If the VALARM contains an ACKNOWLEDGED property on/after the trigger time, then the device should not fire the alarm.

For disconnected devices, there is no solution that I'm aware of.



[ ... ]

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.

<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 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.  
</mglt>


There is a computed trigger time that corresponds to each occurrence.  Does that clarify?



[ ... ]

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.

<mglt>
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. 


In order to do this via CalDAV, the attacker would have to have credentials to update the iCalendar resource.  If they have the user's credentials, they can do a lot more damage than just silencing alarms.



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.


I'm not sure I follow.





</mglt>

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
<mglt>
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 ?
</mglt>


A proximity alarm would trigger when you arrive/leave a certain location.  If the user acknowledges the alarm, then they would leak WHEN they where at that location.  I'm open to new suggested text.


   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 <brong@fastmailteam.com> 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


_______________________________________________
calsify mailing list


--
  Bron Gondwana, CEO, Fastmail Pty Ltd


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


--
Daniel Migault
Ericsson

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

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
--------------4C8F2C8E52EA27C894A6AA57-- From nobody Mon Jul 13 12:33: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 1C5BA3A00B2 for ; Mon, 13 Jul 2020 12:33:54 -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 oJUl7N_9tyLf for ; Mon, 13 Jul 2020 12:33:52 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id B8F1E3A0101 for ; Mon, 13 Jul 2020 12:33:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 1F9EA3021FBF15; Mon, 13 Jul 2020 15:33:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFc7SUVPir9D; Mon, 13 Jul 2020 15:33:51 -0400 (EDT) Received: from cyrus.local (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 944653021FBF08; Mon, 13 Jul 2020 15:33:51 -0400 (EDT) Date: Mon, 13 Jul 2020 15:33:51 -0400 From: Cyrus Daboo To: Ken Murchison , Daniel Migault , Bron Gondwana cc: IETF-Calsify Message-ID: In-Reply-To: References: X-Mailer: Mulberry/5.0.0a1 (macOS/10.15.6) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=3386 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, 13 Jul 2020 19:33:54 -0000 Hi Ken, --On Mon, 13 Jul 2020 14:31:56 -0400 Ken Murchison =20 wrote: >> >> 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. >> > > > The mechanism for "switching off" alarms on devices, is that each device > should sync the iCalendar resource with the server just prior to firing t= he > alarm.=C2=A0 If the VALARM contains an ACKNOWLEDGED property on/after the > trigger time, then the device should not fire the alarm. Actually that is not the typical case. Certainly devices should pre-check=20 the ACKNOWLEDGED property before triggering the alarm, but in most cases=20 that will not be set. The typical case has alarms triggering simulataneously on all the devices=20 belonging to a user. Those will popup an alert on all devices. The user the= n=20 acks the alert on one device. That device adds the ACKNOWLEDGED property an= d=20 writes the event back to the server. The server then triggers a push=20 notification to the other devices. The other devices sync the changed event= .=20 The other devices spot the presence of the ACKNOWLEDGED property and=20 automatically dismiss the visual alert. It might be worth noting one operational consideration here: there is a=20 "stampeding herd effect" caused by this ack behavior. Specifically, in=20 enterprise enrvironments, meetings often occur at the start of an hour.=20 Those meetings can often involve multiple attendees, each of whom may setup= =20 their own alarm. So servers will get hammered with lots of requests when th= e=20 alarms trigger and start to get ack'd by the users. That gets multipled by = the number of devices each user has, since those will receive a push=20 notification and then sync the ack changes from the server. In our enterprise system, we saw very large spikes in requests on the hour,= =20 a smaller spike at 45 mins past the hour, and further smaller spikes at 15 = mins and 30 mins past the hour. There were typically large spikes at 9 am/1= 0=20 am/11 am, smaller at 12 pm/1 pm (lunch time), then bigger again at 2 pm/3=20 pm, and tailing off after that. These were all traced to the alarm ack=20 behavior . In our case, the client defaults to setting up alarms 15 mins=20 before a meeting (though many people change that to occur at the time of th= e=20 meeting) - hence the noticeable spike at 45 mins past the hour. That,=20 combined with meetings that start on the half-hour, give rise to the patter= n=20 we saw. I am not sure if this issue should be described in the spec, but it was=20 definitely a performance/scaleability issue that had to be accounted for. > For disconnected devices, there is no solution that I'm aware of. Correct. The user would have to manually dismiss UI alerts on all=20 disconnected devices. --=20 Cyrus Daboo From nobody Tue Jul 21 11:18:26 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 2A3133A0DEE for ; Tue, 21 Jul 2020 11:18:25 -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 5uEyIyRZsdOE for ; Tue, 21 Jul 2020 11:18:23 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 C4BD33A0DF0 for ; Tue, 21 Jul 2020 11:18:23 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id n4so6535446uae.5 for ; Tue, 21 Jul 2020 11:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=FIhZ5yaMhQUTC8iwD5r0R03I/VctniX6Opr687aVnS8=; b=SUIPSBIwrLnC8jI3RNbQktbtfIWv9NaM2dHnyvocfSUsc630CJoKw50Cj7ERHxP9I4 +g8wZu8VeO45hES+Ebj6l+ZMKIP5FiS5Dn26JxqSYOHrPfxTHt2iu1NDYQEFsXs6rnjI 7Gz4gLR05xLsOp95nkX7t8g5/D/z2iwE9rmf7J+kWvNg7IrjhHotqjQhNxcwDXoDdHD/ WKoqlKxigaB39vRe5hzaBgS5vtTBMpH4LyeWRLfdD5406GC6oej19zwFu1Jqw1/xVmXk u/whB+cAMm34sPZkjfWnAs62tuOgOiN3NGH7KVG8Vnx326BgjCMuqJXZaFdrtgZG9sMk uvIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FIhZ5yaMhQUTC8iwD5r0R03I/VctniX6Opr687aVnS8=; b=sVNrPp1OfwH/DxIWXJ5kG5lxGwqzeXY4/wuZdqo9LAfkv/0Sd4MR7cpcXVnSOoMulK k5YVZi8woHWFomiwvSvDa94a8VgEvY8m1PcyloeY6LXGUurWJeWI3yra5Hf1m+iVMl2q UUYY5Kt+Zs4XL1m5ZW639SAG6NOm5oLBqxV023EU5g+UPDIJ3PMCrmN1XEgrmgxMwGAo TamV02wfY3kI0TxvmMB4U1mYeb8dobkqjdeRHfrASO8oaXifQB/XWmQsVNox54UxWKI7 ucilyq7k19eOEIcvE+hMhqMdUNOasxRVLPeF0ydmJp3qVAUBtYNK7d1sEhLUS4lzof53 xYsw== X-Gm-Message-State: AOAM532wiNOaVc7lJ1q+tRScpIFbcnBzHTQPjM9rKeLQm5Z/lSIi98zp BpAOnsJFMcR3QmIBIxq7wQBo5Z60RMOTCNqSrLf8QICc X-Google-Smtp-Source: ABdhPJxfS6ZffvReUgrYQri2X/uPzvZSgnGplfCZ9XktGerz6U9l1GGqCKmcokaqPkamjxEgTKcdakQFNc7j6rWa85I= X-Received: by 2002:ab0:48c8:: with SMTP id y8mr20331430uac.114.1595355502617; Tue, 21 Jul 2020 11:18:22 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Tue, 21 Jul 2020 14:18:11 -0400 Message-ID: To: IETF-Calsify Content-Type: multipart/alternative; boundary="00000000000006296405aaf7a6bd" Archived-At: Subject: [calsify] IETF 108 - tentative agenda 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, 21 Jul 2020 18:18:25 -0000 --00000000000006296405aaf7a6bd Content-Type: text/plain; charset="UTF-8" Hi, Please see a tentative agenda [1] for the IETF 108 WG meeting Friday 2020-07-31 13:00 UTC. Feel free to propose other topics and update the agenda accordingly. Please upload your presentation by July 28 here: https://datatracker.ietf.org/meeting/108/session/calext Yours, Bron and Daniel [1] https://codimd.ietf.org/notes-ietf-108-calext -- Daniel Migault Ericsson --00000000000006296405aaf7a6bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Please see a tentative agenda= [1] for the IETF 108 WG meeting=C2=A0Friday 2020-07-31 13:00 UTC. Feel free= to propose other topics and update the agenda accordingly.=C2=A0

Please upload your presentation by July 28 here:

Yours,=C2=A0
Bron and Daniel

[1]= =C2=A0https://cod= imd.ietf.org/notes-ietf-108-calext

-- <= br>
Daniel Migault
Ericsson
--00000000000006296405aaf7a6bd-- From nobody Sun Jul 26 20:17:17 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 5E85D3A1650; Sun, 26 Jul 2020 20:17:15 -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.10.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <159581983523.20681.3003800626772598978@ietfa.amsl.com> Date: Sun, 26 Jul 2020 20:17:15 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-28.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: Mon, 27 Jul 2020 03:17:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : JSCalendar: A JSON representation of calendar data Authors : Neil Jenkins Robert Stepanek Filename : draft-ietf-calext-jscalendar-28.txt Pages : 80 Date : 2020-07-26 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-28 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-28 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-28 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 Tue Jul 28 09:12:34 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 76A663A0EB3 for ; Tue, 28 Jul 2020 09:12:26 -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, NICE_REPLY_A=-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 ZzU9aZKt0cft for ; Tue, 28 Jul 2020 09:12:24 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 D3A4E3A0EAA for ; Tue, 28 Jul 2020 09:12:17 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id k18so15212465qtm.10 for ; Tue, 28 Jul 2020 09:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=ncyBKzc22QR6pMrWygUJl/mVavbPHLZ19dlm/GR6eLg=; b=OXh4Ao8b8D1I91FJt10QmGvb4k1YS1rQh0q4MJr2sT7dkbAISFGDO3wOpxRJmu8Yww dEo7HYy+3vkoru/9/y3N2LKAyC9z93uWr/dq4uYlFJeVtlehIQsrBJBoFlVq45k9GeNo LyF/jn4ch+w3/JroUQDQ9zEiQ9fCvQCR/kkn3oFRiLpqCxXfmlxj4B+i88tbNx5v7IZZ nSjvHiUAkS0vS3jyQg71hPQBmyvPIjI3iChaH4eH20WzfxdlW+ttFF0y5YDeSFg1AElo pjPrFl0+7vkg/hjfGYK5t83XrcZUy3LtonzXlJQ/W1wf38XcAljp2QBgEdNKnQJxjphK UoFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ncyBKzc22QR6pMrWygUJl/mVavbPHLZ19dlm/GR6eLg=; b=iOpicoNSX0X97AXL4H26l+bJzT+Gw25cmXZfkWc61uZQyreMqa5PwURp6xz3n+jNAi twOsIlmcHy3Pij/yxudq8yRFwgQJIjj7fs75z29B2YzRIgDiaOsMjNpTTUFQ4NxF7nAQ m5fxnJLHcl3zcaydvq76NjV4+wHAPFg118LcboJjLKj++8dy3YxTgQBb42n2vZxB+05k qHmrmHvdlBJbGSVhhgS5cFUseSefmgzwH+J4N+ECzjwLaWBfIFKRj1voz6fiMpGJ4An0 5lXSE2EgGkbi0X8hv8zCOIMagWWQakkL4EXClF/NZsRSdz9niH+G0WJohpARv0NzwH9R HUwQ== X-Gm-Message-State: AOAM530yBNTayWspIRW3ZNSqg+a8UtogMqSu1E+OGEFcprf6gXUIt+jO rc1DIIL/O24bgNznQ+NbN7c= X-Google-Smtp-Source: ABdhPJzh4ZW8ffK6kptTWIhrvje/PAseV/ROF/bH3Easrsj8ITl3LLoXuUTPAC08SWYEdfPIPVu5EQ== X-Received: by 2002:ac8:73d9:: with SMTP id v25mr14895328qtp.82.1595952736757; Tue, 28 Jul 2020 09:12: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 p66sm23350071qkf.58.2020.07.28.09.12.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jul 2020 09:12:13 -0700 (PDT) To: Daniel Migault , IETF-Calsify , Bron Gondwana References: From: Michael Douglass Message-ID: <94aa1195-17b1-5dbd-ef0f-e40768889d2e@gmail.com> Date: Tue, 28 Jul 2020 12:12:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------975F7B79DC62FC631674D39B" Content-Language: en-US Archived-At: Subject: Re: [calsify] IETF 108 - tentative agenda 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, 28 Jul 2020 16:12:32 -0000 This is a multi-part message in MIME format. --------------975F7B79DC62FC631674D39B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Somehow ical-relations dropped off the radar. Can we add it to the agenda. The last message was from Daniel to calsify at 5/15/18 > > This email starts a 2 week WGLC for > draft-ietf-calext-ical-relations-04 [1]. The WGLC call period ends on > May 29. Please review the draft and indicate if the draft is ready to > be sent to the IESG. > > Yours, > Calext co-chairs > > > [1] https://datatracker.ietf.org/doc/draft-ietf-calext-ical-relations/ > On 7/21/20 14:18, Daniel Migault wrote: > Hi, > > Please see a tentative agenda [1] for the IETF 108 WG meeting Friday > 2020-07-31 13:00 UTC. Feel free to propose other topics and update the > agenda accordingly. > > Please upload your presentation by July 28 here: > https://datatracker.ietf.org/meeting/108/session/calext > > Yours, > Bron and Daniel > > [1] https://codimd.ietf.org/notes-ietf-108-calext > > -- > Daniel Migault > Ericsson > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------975F7B79DC62FC631674D39B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Somehow ical-relations dropped off the radar. Can we add it to the agenda.

The last message was from Daniel to calsify at 5/15/18


This email starts a 2 week WGLC for draft-ietf-calext-ical-relations-04 [1]. The WGLC call period ends on May 29. Please review the draft and indicate if the draft is ready to be sent to the IESG. 

Yours,
Calext co-chairs


On 7/21/20 14:18, Daniel Migault wrote:
Hi, 

Please see a tentative agenda [1] for the IETF 108 WG meeting Friday 2020-07-31 13:00 UTC. Feel free to propose other topics and update the agenda accordingly. 

Please upload your presentation by July 28 here:

Yours, 
Bron and Daniel

[1] https://codimd.ietf.org/notes-ietf-108-calext

--
Daniel Migault
Ericsson

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------975F7B79DC62FC631674D39B-- From nobody Tue Jul 28 09:52:21 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 34E233A0D65; Tue, 28 Jul 2020 09:52:16 -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.10.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <159595513614.12810.10128239239880655439@ietfa.amsl.com> Date: Tue, 28 Jul 2020 09:52:16 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-serverside-subscriptions-00.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: Tue, 28 Jul 2020 16:52:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : Serverside Subscriptions Author : Michael Douglass Filename : draft-ietf-calext-serverside-subscriptions-00.txt Pages : 11 Date : 2020-07-28 Abstract: This specification provides a mechanism whereby subscriptions to external resources can be handled by the server. This specification updates [RFC4791] to add new properties for the MKCOL request. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-serverside-subscriptions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-serverside-subscriptions-00 https://datatracker.ietf.org/doc/html/draft-ietf-calext-serverside-subscriptions-00 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 Tue Jul 28 15:23: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 5B75A3A098E for ; Tue, 28 Jul 2020 15:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 yAFFmZ5qySbM for ; Tue, 28 Jul 2020 15:23:21 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 809473A09B8 for ; Tue, 28 Jul 2020 15:23:21 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id p8so3595646vsm.12 for ; Tue, 28 Jul 2020 15:23:21 -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=iLS18jYdicNW+uFSNStUWvvPQEnFvfC6bf95UUNG3Tw=; b=PKXoklEoi947mYj9f6iFZdI1luYVoyyj3N1k7ZqjyjCyKiDsHMO35OdZB0+mKmqyG/ R1mBYnFa6uJYSBk3uLq2g67bmOF0TafTWVwZTGyL5BAq7NgDSzPEbxByyDTguBf7k93C g/9TBRsg/0TQxOOImQYvr/x+XLE6wOU//rkL/88IWKXmLibpiU4g2Ajt2zH9JgtAAhpm 6tSOe1/VdQbgzZ1/NjeYZcemFRYnaodB5JnXi0USp+M4sCZekewFN6drySPVFS6BwJz/ M2kQ2yGozeCRSaM8hySo6TWKqgWbNIv90/O15jc3kKC1WlonbWnnuFX9vd/z2UXUHjxW S2Vg== 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=iLS18jYdicNW+uFSNStUWvvPQEnFvfC6bf95UUNG3Tw=; b=DGQgKXMRjj5CO6G43kdIa3pVJlKDjoiCSBqFSPS4OALFS515lY9koI/L4DufDf6JC7 JirXk5Th/Vypyd1v0j//d0b3ICglYME08Swiz2Thfwh1nWoVD5oL9lHj4FmdVBfPwLiP rEiETjtnvj6zzO+ePQp9EwClOJr2vuHa8NB3sDijZWXXIqTExlIfU/eRPTbxUHPaNAQ1 BM8JZj2UqAtla7xW5RiMAqjN/vx4OjH1Xril64PgDAA7L21z2YtDFIFS0qEfiELaueMR n75BgPbW/CtCYCyRUkzZ1ihxmFrUVcPvJksRcjezA1d6xeln7315YRdBMa8fAHBLjAjQ Mqhg== X-Gm-Message-State: AOAM532Osf8wfp8MsLoOHlJGV0guf+/PdkjQQzjiy3ezW4YMdMYM/ia1 hKENXRar+cf3PsbH7WBdvbesY0yOPtVqVRqHIFI= X-Google-Smtp-Source: ABdhPJz1r2M1cbnolmpSze3n8+f3L4jP0u9tU067kP7rRAYmrIN9Q8ZWzB6G701IYlq9I1uZyQI7bO9sk3oeaKUsJbw= X-Received: by 2002:a05:6102:31bc:: with SMTP id d28mr21785708vsh.180.1595975000445; Tue, 28 Jul 2020 15:23:20 -0700 (PDT) MIME-Version: 1.0 References: <94aa1195-17b1-5dbd-ef0f-e40768889d2e@gmail.com> In-Reply-To: <94aa1195-17b1-5dbd-ef0f-e40768889d2e@gmail.com> From: Daniel Migault Date: Tue, 28 Jul 2020 18:23:09 -0400 Message-ID: To: Michael Douglass Cc: IETF-Calsify , Bron Gondwana Content-Type: multipart/alternative; boundary="000000000000f8d7dd05ab87e279" Archived-At: Subject: Re: [calsify] IETF 108 - tentative agenda 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, 28 Jul 2020 22:23:23 -0000 --000000000000f8d7dd05ab87e279 Content-Type: text/plain; charset="UTF-8" Thanks Michael, I have added the item to the agenda. Currently no slides have been uploaded, so please do that asap ;-) Maybe that worth trying to complete the template for all documents here - feel free to update and edit the presentation by Thursday morning EST here: https://docs.google.com/presentation/d/1XH1Khy3XsmGK0ivjCUj2ouz-uqEMye1YDLjKne989Lc/edit?usp=sharing You can also upload your own presentation here: https://datatracker.ietf.org/meeting/108/session/calext The current agenda is for CALEXT - IETF 108 Friday, July 31, 2020 13:00-13:50 UTC Agenda Administrivia - Note Well and agenda bashing, Chairs, 5min - Document status update, Chairs, 5min - Document status update, Area Director, 5min Current Working Group Documents - draft-ietf-calext-jscalendar 10 min - draft-ietf-calext-valarm-extensions/ 5 min - draft-ietf-calext-icalendar-series 5 min - draft-ietf-calext-subscription-upgrade 5 min - draft-ietf-calext-vpoll 5 min - draft-ietf-calext-ical-relations-04 5 min - draft-ietf-calext-jscalendar-icalendar 5 min Links: Meetecho: http://www.meetecho.com/ietf108/calext/ Jabber: xmpp:calext@jabber.ietf.org?join (this is part of the MeetEcho interface) Etherpad: https://codimd.ietf.org/notes-ietf-108-calext (This is where you are) On Tue, Jul 28, 2020 at 12:12 PM Michael Douglass wrote: > Somehow ical-relations dropped off the radar. Can we add it to the agenda. > > The last message was from Daniel to calsify at 5/15/18 > > > This email starts a 2 week WGLC for draft-ietf-calext-ical-relations-04 > [1]. The WGLC call period ends on May 29. Please review the draft and > indicate if the draft is ready to be sent to the IESG. > > Yours, > Calext co-chairs > > > [1] https://datatracker.ietf.org/doc/draft-ietf-calext-ical-relations/ > > > On 7/21/20 14:18, Daniel Migault wrote: > > Hi, > > Please see a tentative agenda [1] for the IETF 108 WG meeting Friday > 2020-07-31 13:00 UTC. Feel free to propose other topics and update the > agenda accordingly. > > Please upload your presentation by July 28 here: > https://datatracker.ietf.org/meeting/108/session/calext > > Yours, > Bron and Daniel > > [1] https://codimd.ietf.org/notes-ietf-108-calext > > -- > Daniel Migault > Ericsson > > _______________________________________________ > calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify > > -- Daniel Migault Ericsson --000000000000f8d7dd05ab87e279 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Michael, I have added the item to the agenda.=C2=A0=

Currently no slides have been uploaded, so please = do that asap ;-)
Maybe that worth trying to complete the te= mplate for all documents here - feel free to update and edit the presentati= on by Thursday morning EST here:

You ca= n also upload your own presentation here:

The current agenda=C2=A0is for=C2=A0CALEXT - IETF 108 Friday, July 31, 2020 13:00-13:50 UTC

Agenda

Administrivia

  • Note Well and agenda bashing, Chairs, = 5min
  • Document status update, Chairs, 5min
  • Document status update, Area Dire= ctor, 5min

Current Wo= rking Group Documents

Link= s:

On Tue, Jul 28, 2020 at 12:12 PM Michael Douglass <mikeadouglass@gmail.com> wrote:
=20 =20 =20

Somehow ical-relations dropped off the radar. Can we add it to the agenda.

The last message was from Daniel to calsify at 5/15/18


This email starts a 2 week WGLC for draft-ietf-calext-ical-relations-04 [1]. The WGLC call period ends on May 29. Please review the draft and indicate if the draft is ready to be sent to the IESG.=C2=A0

Yours,
Calext co-chairs


On 7/21/20 14:18, Daniel Migault wrote:
=20
Hi,=C2=A0

Please see a tentative agenda [1] for the IETF 108 WG meeting=C2=A0Friday 2020-07-31 13:00 UTC. Feel free to propose other topics and update the agenda accordingly.=C2=A0

Please upload your presentation by July 28 here:

Yours,=C2=A0
Bron and Daniel

[1]=C2=A0https://codimd.ietf.org/notes-ietf-108-calext

--
Daniel Migault
Ericsson

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


--
Daniel Migault
Ericsson
--000000000000f8d7dd05ab87e279-- From nobody Tue Jul 28 17:16:52 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 A37103A0CA1; Tue, 28 Jul 2020 17:16:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.11.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <159598180462.11163.10423811603608485264@ietfa.amsl.com> Date: Tue, 28 Jul 2020 17:16:44 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-icalendar-series-01.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: Wed, 29 Jul 2020 00:16:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : Support for Series in iCalendar Author : Michael Douglass Filename : draft-ietf-calext-icalendar-series-01.txt Pages : 27 Date : 2020-07-28 Abstract: This specification updates [RFC5545] by defining a new repeating set of events known as a series. This differs from recurrences in that each instance is a separate entity with a parent relationship to a specified template entity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-icalendar-series/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-icalendar-series-01 https://datatracker.ietf.org/doc/html/draft-ietf-calext-icalendar-series-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-icalendar-series-01 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 Wed Jul 29 08:57:57 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 BC1913A0BDF; Wed, 29 Jul 2020 08:57:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.11.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <159603827169.10314.13892066191403194604@ietfa.amsl.com> Date: Wed, 29 Jul 2020 08:57:51 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-ical-relations-05.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: Wed, 29 Jul 2020 15:57:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : Support for iCalendar Relationships Author : Michael Douglass Filename : draft-ietf-calext-ical-relations-05.txt Pages : 19 Date : 2020-07-29 Abstract: This specification updates RELATED-TO defined in [RFC5545] and introduces new iCalendar properties LINK, CONCEPT and REFID to allow better linking and grouping of iCalendar components and related data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-ical-relations/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-ical-relations-05 https://datatracker.ietf.org/doc/html/draft-ietf-calext-ical-relations-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-ical-relations-05 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 Wed Jul 29 14:10:27 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 6E39C3A0FEF for ; Wed, 29 Jul 2020 14:10:20 -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 APG6Bq75RITB for ; Wed, 29 Jul 2020 14:10:19 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 741E73A0FB9 for ; Wed, 29 Jul 2020 14:10:08 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id h21so12391131qtp.11 for ; Wed, 29 Jul 2020 14:10:08 -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=Di4/Gt9oydOlJ+bP1ZwZfPbGNVqmTOkngdKkYTl4qWA=; b=EetiYYl5albPN2DOgrkVXAKKv04692zaq9riiq9rgv6KZXI748uHZ/7cRsY0Dq3xDG Ui/P8Xo7d+9mTPFMHlEaLyeraAjBdO6Z63e79Ligc3rpUAC0LPQn2DMrIX8YDTBcvWO+ AisGQ5HCBkb79x0oSM/WcVp3OsZcAH02CeL3I0KpseIcGONxqbbZJgPTmxYyOkfVUapg P7+PI50AxDFAwGLVc8H9KzQSryn5Ct6AmQ9tkofikQ8cmdHWHX1A1c7wLeZHoYLOSBZs 4UmRrt9OBtjREr6oZO3knIo0pr3IQcF6aynQuD8rAVgdz7lAYtqfLxT/E72HwWZxxbpr lROA== 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=Di4/Gt9oydOlJ+bP1ZwZfPbGNVqmTOkngdKkYTl4qWA=; b=ValvqPlvBq+B0HMIEjg/TQea10wixX0Ri8RSpR6poyDXsMh3N7egSNdUh0oqhjZqsC o1eeQYgtqHbAavNoczhmJkfK2tintj7Pshq0WzSxI0bkshcBkvvMi9o7csLdaf+iAK7w ESUNg/meQX4fbHmD0g2Td7cVqCNBuTtqwulFipXjI1bkjFTkjq5yJ2kW+jOc0TUaiQV1 /odMJyt21wmwbeTwGK775j2SqZkKtWmde4Ok1clm0zRYlp5v6Imy8+t82DdvdQDH3yUx yu9PmYnweSD5bRtYqT5OOt1FCVRdn0cG+61yK7hsdJeCTCNXbdNY4jZXcbA0wM0uQ58y h2iA== X-Gm-Message-State: AOAM531pIIMdTyJagk29cDKo0z4YU70wnUxigQ339z4BYy8uqVZCJ4hh 1dq/rnvsKsz9KSnR7E1EyiU+Gd9HYPk= X-Google-Smtp-Source: ABdhPJx8b5Jkc3H5N+Wf+z8fPth7Exp17jPwfnOl29C3Ec4nUPgi4oub3VIqjZAZ8EkXLsBXr6RByw== X-Received: by 2002:ac8:51c1:: with SMTP id d1mr275948qtn.385.1596057007343; Wed, 29 Jul 2020 14:10:07 -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 142sm2388702qki.130.2020.07.29.14.10.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jul 2020 14:10:06 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <4b406ac9-b88b-57c7-8b78-1b770330d18f@gmail.com> Date: Wed, 29 Jul 2020 17:10:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.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, description 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, 29 Jul 2020 21:10:25 -0000 We had some discussion for eventpub about descriptions as a number of vendors have a need to provide plain text and marked up text - mostly html. We came up with a solution for eventpub but we're back to square one with jscalendar. I'm afraid I missed this doing the ical->jscal but was reminded going the other way. Currently jscalendar has "description" and "descriptionContentType" properties. I suggest we make this multi-valued with a "Description" object with "content" and "contentType" fields. HTML has been asked for for many years but some clients need a plain text version. Eventpub also added a DERIVED parameter to flag which copy was the real source. From nobody Wed Jul 29 14:18:16 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 A9EC63A0F10 for ; Wed, 29 Jul 2020 14:18:14 -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 eQC8bYgA64_p for ; Wed, 29 Jul 2020 14:18:13 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 99EF43A0F0E for ; Wed, 29 Jul 2020 14:18:13 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id r19so3068757qvw.11 for ; Wed, 29 Jul 2020 14:18:13 -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=FigOr9QwqBUrAyehTS/s3EYjA2+TZm2zNN84NBeEm/Y=; b=ghHiL5wb7zWK5q+QzqYcClTduGBu512Bl5v7iGTKqR2jVOHLyDBfK66q7Sk1u9Qn45 n/9PyyGkb6pypEOrsY/mpUvUqBZPqyhyw1ueFhJap/VcqmHLqqRwIIev7YRhOABsYqA0 dcBxxEdmthaieAtPUGA0+EaScqW8RRz32pV5snAKD+3evJ9b6+wAVwlEPApSkatk0J2L Cl8g/jDoBR5cqimhomP0HLTA0iSe1xlD/a5puJe+nKtQ3QR39LE0ErlMgC4p8lLNGLl5 We4q1Hb4wce4lDcUgS1IaADGfZ/10+wDUDH98kiAoyRBB7AjfAOx+rUXURpgLC17fJ8R jHXQ== 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=FigOr9QwqBUrAyehTS/s3EYjA2+TZm2zNN84NBeEm/Y=; b=p9nTwCGTu4OKygmwLToPQHHjAvZrMYZ27S40Dl2duSj/PYRSINOi0FCUkfVHhNcY8t nFQ3cp869rTOrVwh/WLoMP3UI4REqMxepm/oYb+QOzwNUnaiLdINhSoVhw94i6MmUbg4 PkIouOKqWmuDZlezfi9lbWaVrgLxo6mejXosI84ZnbytDp3qShTg5q3Tmc+eEdVogQlB x90MkBRasrxotjGfOUMrQ20z8RLmxX79guMxDyoMcaDKGNs0iCpfX3gxDg/e/HRu6Wct yknmLRtoXNNOtw/vZ7/Anjxi5x25NVm19lx6LJ3XGWKXmHZ7PqWrkD1Q4R0Z0kNWP3nl f+nA== X-Gm-Message-State: AOAM531AQKrIoJhg6XpVzQFHKf4e9dmypr4peK6QOxQlY6jxxa11CXY5 WHAFdEf0QSoZJbM837IjUlUH+IRCWJY= X-Google-Smtp-Source: ABdhPJz9ZbECtsB+5eq393goPyREmZHggyh104RU000brBkKF36eJHXPGWMqLqfh5FPF+fwwxRBSlA== X-Received: by 2002:a05:6214:140d:: with SMTP id n13mr225976qvx.69.1596057492432; Wed, 29 Jul 2020 14:18:12 -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 x198sm2807609qka.37.2020.07.29.14.18.11 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jul 2020 14:18:12 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <8b83f4eb-5c2e-7b20-d1ad-0e17ccd13519@gmail.com> Date: Wed, 29 Jul 2020 17:18:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.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 URL 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, 29 Jul 2020 21:18:15 -0000 Still trying to resolve this: The current suggestion is to express it as a link which is fine but it's a heavily used property in public events - for example it may point to an exhibition web site. The problem I have is how to determine which out of a possible multitude of links is the one used to (re)represent the event. May I suggest we add a linkids property to the task/event objects. This makes for a reasonably reversible mapping. From nobody Wed Jul 29 20:35:54 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 230523A0B0A; Wed, 29 Jul 2020 20:35:43 -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.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <159608014306.19132.12080107760086956798@ietfa.amsl.com> Date: Wed, 29 Jul 2020 20:35:43 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-subscription-upgrade-02.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: Thu, 30 Jul 2020 03:35:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : Calendar subscription upgrades Author : Michael Douglass Filename : draft-ietf-calext-subscription-upgrade-02.txt Pages : 15 Date : 2020-07-29 Abstract: This specification updates [RFC5545] to add the value DELETED to the STATUS property. This specification also updates [RFC7240] to add the subscribe- enhanced-get and limit preferences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-subscription-upgrade/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-subscription-upgrade-02 https://datatracker.ietf.org/doc/html/draft-ietf-calext-subscription-upgrade-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-subscription-upgrade-02 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 Wed Jul 29 21:06:46 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 30DF93A0CB8; Wed, 29 Jul 2020 21:06:45 -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.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <159608200488.27973.9505556588306157911@ietfa.amsl.com> Date: Wed, 29 Jul 2020 21:06:44 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-icalendar-02.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: Thu, 30 Jul 2020 04:06:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : JSCalendar: Converting from and to iCalendar Authors : Neil Jenkins Robert Stepanek Michael Douglass Filename : draft-ietf-calext-jscalendar-icalendar-02.txt Pages : 54 Date : 2020-07-29 Abstract: This document provides the required methods for converting JSCalendar from and to iCalendar. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar-icalendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-icalendar-02 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-icalendar-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-icalendar-02 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 Thu Jul 30 03:58:26 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 B73B43A1087 for ; Thu, 30 Jul 2020 03:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=3PYw77OS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KcpIXtEf 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 SVVD5cizndSM for ; Thu, 30 Jul 2020 03:58:22 -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 6E0883A10BF for ; Thu, 30 Jul 2020 03:58:02 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id D2FF2B39 for ; Thu, 30 Jul 2020 06:58:01 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute7.internal (MEProxy); Thu, 30 Jul 2020 06:58:01 -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=hmYMXrC GWmjHxGW/CnHjIkSzvl9QPx2o5Npz/eGtv/E=; b=3PYw77OSMiHk23tVrMS3XVI urTPqiOfvFJqO3679aEzBk8ru469OwlSnqaSq8GAyjwQ3Vaz3I1d+WGJhvKvLTe9 j7unR+ICYC05MBWvrCVENKF5u5WMAkEq8f7exJF29yTjoFQWZNhPdhR18DHCIntf WVb5k/BKh8a/aetiQHK+79hdS9VwoBa0HT/oEi7Zcrx8aYHWx4LT9NohflyE8Q6i FCLiObRRTSYaxS7PdsGIVPAWwcDjKWFb09CUxsA+b5xs+DgcpAX46cxK/Xjzaswx qHSGVqPsRjAKklpX+Gt4DAVN5YeZKHRQSqktZHSGN86WzA7DgoPNPseSnDILBmg= = 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=hmYMXr CGWmjHxGW/CnHjIkSzvl9QPx2o5Npz/eGtv/E=; b=KcpIXtEfvI+PqXXXsX1kjz sm9h5GZNtrqo+nGadhB4oonSTF+lQekwaa5ktvqYumIKzJzg3UFqYFoq3JYtybyW nXrV8B+h//WmwhW7JLybJepPUdm8vLpPtr9UALl30l9GUA2O6LRHwncObDKgJnEH +yBnJe42IJ7cDw6Tgs1Sc076xPd8KWhWtKe+8aoLDm0d9Sxb/l4/DZEJM2GkN02G rrkooBZaZK0Hz7mlnZYJiUCXVWHxCPEj7Tfqm1hRwerqHcwJww1pCPioVfqRFnlg dc6qZF8XVA4YL4U3us8FTGHFxdXm06q1OZ3036UrrA8fXqq9zENXm2yn1j/LU4iA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieeigdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeehgeeuvddtke fhtefgueefgfdvueetgeeffeelhedvudegjeejhfetuefgveevieenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C3331180519; Thu, 30 Jul 2020 06:58:00 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: <8048c18f-ef3c-47d2-b33b-a2b785620d20@www.fastmail.com> In-Reply-To: <8b83f4eb-5c2e-7b20-d1ad-0e17ccd13519@gmail.com> References: <8b83f4eb-5c2e-7b20-d1ad-0e17ccd13519@gmail.com> Date: Thu, 30 Jul 2020 12:57:40 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=a0735b0e87a64d22b3b5b26a38652218 Archived-At: Subject: Re: [calsify] jscalendar and URL 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, 30 Jul 2020 10:58:24 -0000 --a0735b0e87a64d22b3b5b26a38652218 Content-Type: text/plain Hi Mike, On Wed, Jul 29, 2020, at 11:18 PM, Michael Douglass wrote: > The problem I have is how to determine which out of a possible multitude > of links is the one used to (re)represent the event. Wouldn't the "describedby" rel be enough for that in the Link object? > > May I suggest we add a linkids property to the task/event objects. This > makes for a reasonably reversible mapping. You mean as a top-level property? If it is multi-valued, how would that help to determine which one of these add to URL? Also: would that be a subset of the ids found in the links property? On which basis? Cheers, Robert --a0735b0e87a64d22b3b5b26a38652218 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Mike,

On Wed, Jul 29, 2020, at 11:18 PM, Michael Dougla= ss wrote:
T= he problem I have is how to determine which out of a possible multitude&= nbsp;
of links is the one used to (re)represent the event.=

Wouldn't the "describedby" re= l be enough for that in the Link object?


May I sugges= t we add a linkids property to the task/event objects. This 
makes for a reasonably reversible mapping.

You mean as a top-level property? If it is multi-va= lued, how would that help to determine which one of these add to URL? Al= so: would that be a subset of the ids found in the links property? On wh= ich basis?

Cheers,
Robert
=
--a0735b0e87a64d22b3b5b26a38652218-- From nobody Thu Jul 30 04:18: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 40E263A1140 for ; Thu, 30 Jul 2020 04:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=PwlegqUj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fEi/WQ2Y 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 vhLnd_Kvi5qb for ; Thu, 30 Jul 2020 04:18:44 -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 89DF83A1100 for ; Thu, 30 Jul 2020 04:18:39 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 129F7B27 for ; Thu, 30 Jul 2020 07:18:39 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute7.internal (MEProxy); Thu, 30 Jul 2020 07:18:39 -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=7ns5p9h VMFxNvoGWXM6fnj5B9q+MaU7iDUeVt9+tFj4=; b=PwlegqUj4rLlBsetKORFo9m vZy3Xqd8XoIO8x4cY2UsX2WJxADeZ05oJJiYDX+9O4Y4d8jgFL1ZnpYANcB4kfK5 SVdd7rZ2OxnWAvjjpFqDm4wV95QoFGUmH3zvLPR3u0FooNYjL2OFT1O9wHlFQZlm tn/5uWT7CS4R6++v9Z9B4zSaMMlPAxflwt1h7BJb9h1qzWXAl7gngPucvhvdC47p ISJSnk7zIN1H4JhWDVhPoCdudVQMb8uSWh4RkVWAeRSPdlrrmn1vo1e8KmXwfyY+ ejNZwYQgSPnc3E7pW7UcCLONiSdHmq3GzugSx5HhXwDTTbWan/vLliGKUgsUAsw= = 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=7ns5p9 hVMFxNvoGWXM6fnj5B9q+MaU7iDUeVt9+tFj4=; b=fEi/WQ2YmyUhyYmZCq3bwm 8H/Fc/fXVI+w9V147HQm60lfXsTjqcrXqmkoouyZUAa3rOjtVEjMw3x55NdPj4Qd 0DV+KZ6JTRyt4Ulzt8oGpfznKX0clU6JCAIbOJEcbMD0tUIjnmteEPgDcvNvAae/ m2pjlg7RD/mvwaPsDoUMWkubPcDDybq24f7ohcOog2sGXt51JlC9OYzboJ+3KbN3 dzZ3WuGUFn4NKXdEsK0HWrGLtMiD2e22/VoaIWhRWebZLofF33MZqFj9xL2ye4g6 FDtWbCmg509b8ePcVT5pBBAhXGW03gkNhevImUCrLckVK2MdwI+vn+8q9fFFDCkg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieeigdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeehgeeuvddtke fhtefgueefgfdvueetgeeffeelhedvudegjeejhfetuefgveevieenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6D72418051C; Thu, 30 Jul 2020 07:18:38 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: In-Reply-To: <4b406ac9-b88b-57c7-8b78-1b770330d18f@gmail.com> References: <4b406ac9-b88b-57c7-8b78-1b770330d18f@gmail.com> Date: Thu, 30 Jul 2020 13:18:18 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=14b142543b1543abb89ca9dc3bdec2cf Archived-At: Subject: Re: [calsify] Jscalendar, description 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, 30 Jul 2020 11:18:53 -0000 --14b142543b1543abb89ca9dc3bdec2cf Content-Type: text/plain On Wed, Jul 29, 2020, at 11:10 PM, Michael Douglass wrote: > Currently jscalendar has "description" and "descriptionContentType" > properties. > > I suggest we make this multi-valued with a "Description" object with > "content" and "contentType" fields. With multi-valued descriptions (and the already supported Link.cid property) we are getting close to a MIME multipart/alternative. If we conclude to add this, then we should still keep the content types restricted to subtypes of "text", and we should only allow a single description for a given subtype. In practice, that means html and plain text descriptions. I guess we'll address this also in the IETF calext session tomorrow. Cheers, Robert --14b142543b1543abb89ca9dc3bdec2cf Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, Jul 29,= 2020, at 11:10 PM, Michael Douglass wrote:
Currently jscalendar has "description" = and "descriptionContentType" 
properties.

I suggest we make this multi-valued with a "Descriptio= n" object with 
"content" and "contentType" fields.

With multi-valued descriptions = (and the already supported Link.cid property) we are getting close to a = MIME multipart/alternative. If we conclude to add this, then we should s= till keep the content types restricted to subtypes of "text", and we sho= uld only allow a single description for a given subtype. In practice, th= at means html and plain text descriptions.

= I guess we'll address this also in the IETF calext session tomorrow.
=

Cheers,
Robert
--14b142543b1543abb89ca9dc3bdec2cf-- From nobody Thu Jul 30 08:39:22 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 848CB3A09CF for ; Thu, 30 Jul 2020 08:39:20 -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, NICE_REPLY_A=-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 0gZeO3wuR47l for ; Thu, 30 Jul 2020 08:39:18 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 432583A09C4 for ; Thu, 30 Jul 2020 08:39:18 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id ed14so12714840qvb.2 for ; Thu, 30 Jul 2020 08:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=MG9hu1SYWZpN4SNzsxx7Kz1MHdUjU4zwpMEQM3rv8j4=; b=cjKFOzfRIDISkV2p04aTKs4Zh+KVSC2HgJn96Xc1J0b/XFvmMYiTM2z3+O7iXRgupr fYPv/w/e/+DuSpad+GfPuWjNBlRaxI68N0w8wC39mMcOx6jJ5v+uxid4PYLa3hotr+FK +wcgFCPz87YNAaeM1tt5l7GlBc3GisO/XeDvwDx/+0Xt/vOsM+ag/Jf7jLyyCETCjJJj ut09fYXmYVk2grdm94h8YImJDh1TN+/GL4x/mfwtM1NucGD/OCctBZ6uS4y/Wa+jHIHZ QSYZ+lmYLiuqoxOcLtwAWAfgzJB8tDoU0G51gSvAeQn2Jb/+XigAQTXE4KD9CkwgA1dG aD0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=MG9hu1SYWZpN4SNzsxx7Kz1MHdUjU4zwpMEQM3rv8j4=; b=gHgzkR6bSyYa0Wbw56DIF9paO/MseZRFqi/Ikmj1AiPimn95WW8QVywIEy3LRAluVl 0mTsGy0IWGZAjtR+9ahtCZ5DrwjTbeG3dvHhkr3yQgS12NJta9K9Oud6j2G0Ihf1cGpO CXNNuAzNqOdCnJrz/QW/H26sfnY7tH+DBpBwiqM17g2pCVwUoJbPSI8omILR7pwUgdxb LgOdsA6XLdlPSXLerpqRpcNFAP8ngQIe/aDudCR9SdwOfFUYvgz7374cvp+HiG6FHt2+ 1yYumnZ7r8TQDqy1t/hsXaDmojCGVcpQH+SsZ8anWF+kmojoyE7nCLTVN/sjMbONc2L4 MeOw== X-Gm-Message-State: AOAM531iEXT2hMXXvQvcdeI6jgVgozALFofVfOJYxL4AmAXaemrE6PRW EqS7guD9Wynxf5+EDm4jCT1HZNoFpqM= X-Google-Smtp-Source: ABdhPJxy0pJf9jELkdhfcF8G7dWBCvt0XV3xTRgs2Z2OE36ULIcmMc5zzOfIhPbbtNoVw7Pd4YAYNA== X-Received: by 2002:a05:6214:11f3:: with SMTP id e19mr3492056qvu.220.1596123557053; Thu, 30 Jul 2020 08:39:17 -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 e129sm3779203qkf.132.2020.07.30.08.39.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jul 2020 08:39:14 -0700 (PDT) To: Robert Stepanek , calsify@ietf.org References: <8b83f4eb-5c2e-7b20-d1ad-0e17ccd13519@gmail.com> <8048c18f-ef3c-47d2-b33b-a2b785620d20@www.fastmail.com> From: Michael Douglass Message-ID: <8f4cd5f5-0713-b634-72ae-d012b43fb1d3@gmail.com> Date: Thu, 30 Jul 2020 11:39:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <8048c18f-ef3c-47d2-b33b-a2b785620d20@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------A2095B24697437A2EC608E18" Content-Language: en-US Archived-At: Subject: Re: [calsify] jscalendar and URL 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, 30 Jul 2020 15:39:21 -0000 This is a multi-part message in MIME format. --------------A2095B24697437A2EC608E18 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/30/20 06:57, Robert Stepanek wrote: > Hi Mike, > > On Wed, Jul 29, 2020, at 11:18 PM, Michael Douglass wrote: >> The problem I have is how to determine which out of a possible multitude >> of links is the one used to (re)represent the event. > > Wouldn't the "describedby" rel be enough for that in the Link object? As long as we don't have another link with "describedBy" rel I guess it might. I'm trying to resolve what happens when a client receives a jscalendar object and they want to display what would currently be in the icalendar url. >> >> May I suggest we add a linkids property to the task/event objects. This >> makes for a reasonably reversible mapping. > > You mean as a top-level property? If it is multi-valued, how would > that help to determine which one of these add to URL? It doesn't altogether I agree. However - for an event converted from icalendar with a URL property there would only be one. Otherwise the use of the rel would perhaps provide an idea for a suitable candidate. > Also: would that be a subset of the ids found in the links property? > On which basis? Isn't that what the linkids properties are in location and participant? The idea is to KNOW which of the links are related to the event/task object rather than having to try to guess. > > Cheers, > Robert > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------A2095B24697437A2EC608E18 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 7/30/20 06:57, Robert Stepanek wrote:
Hi Mike,

On Wed, Jul 29, 2020, at 11:18 PM, Michael Douglass wrote:
The problem I have is how to determine which out of a possible multitude 
of links is the one used to (re)represent the event.

Wouldn't the "describedby" rel be enough for that in the Link object?

As long as we don't have another link with "describedBy" rel I guess it might.

I'm trying to resolve what happens when a client receives a jscalendar object and they want to display what would currently be in the icalendar url.



May I suggest we add a linkids property to the task/event objects. This 
makes for a reasonably reversible mapping.

You mean as a top-level property? If it is multi-valued, how would that help to determine which one of these add to URL?

It doesn't altogether I agree. However - for an event converted from icalendar with a URL property there would only be one.

Otherwise the use of the rel would perhaps provide an idea for a suitable candidate. 

Also: would that be a subset of the ids found in the links property? On which basis?
Isn't that what the linkids properties are in location and participant? The idea is to KNOW which of the links are related to the event/task object rather than having to try to guess.

Cheers,
Robert

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------A2095B24697437A2EC608E18-- From nobody Thu Jul 30 08:42:15 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 71DB13A0AE5 for ; Thu, 30 Jul 2020 08:42:10 -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, NICE_REPLY_A=-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 ahM_kpGimdTw for ; Thu, 30 Jul 2020 08:42:08 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 7D82D3A0AC3 for ; Thu, 30 Jul 2020 08:42:06 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id h21so14263365qtp.11 for ; Thu, 30 Jul 2020 08:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=hrvlgpF1e1sjjSzVQjX8cI4JikLX8ROqD3v37KJR46A=; b=PL/Xw5uCB9DXM+N2wDCnydZOLBj1ygH9v7SlNJxBb4VVBcCp9lMyCTo+PpoAauJVMP Gm9JmeAnxVBWEhg7u/9npVIbpzVdGEH22a7LUhuQoVmD03jjH7kL0i9xteJWXruxcmV6 GExi13Zcb33VzbU+v1F32prTn7piXqRo/V+iGT2cPDCRnba1JADxIwsrpvrnNy1vwI7i ZcFDDRJkBd1RunL6xfDV2ZWkOqQUHkuq/MopD+dAnzal57mJs87katX1rTVlBSyc61hi G20f1xZZC9+hvqwxocgAUKx7JaAgi+cq6LNBlPzGfufuLFXa+N8h/+nU/sQBRldEsoQE d8ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=hrvlgpF1e1sjjSzVQjX8cI4JikLX8ROqD3v37KJR46A=; b=iXqF99n4/EtqCePVFcLtM4LtpFj5PP4nX7uaS8g/hkbLuQI6bEi33q/2t79G0UWqCM oKkVe2vQnm5+UF1BzYF1k0Whnx3Na1SOojiT7wkNua6zS8IpU61rDaMzU7jOa54VXLoR iakC0PlfZY4xZlX+0BR3RLNmVWXMAmJea2ePrOMq4wAoVHTdL+lFXbcPJFDdeqvZO0SP m6Ey3KfWvPLVndiDNrhjidoq0gFYisN2PjDbLrE494i/wAApD8IAbAOOgi1HWandrz/B u8X/BACz/PuWsI1I190MUQTpLk8NtJ7o33QBagcwR0QIFQwCKvbkiHUYi0f0TZDP6hzq Nw8w== X-Gm-Message-State: AOAM531A4iiLgTYvM6XsN6kJWRjcLCWUqIi0/Rtag9mtD6rwF6gQtlUi lT2p6bhXIudTxw2kAvPlQXEx7sQDyMw= X-Google-Smtp-Source: ABdhPJzsqOhWbnonNhefu7YXxnf0vyYjIUXTEk2I52teeBislemqltOIrR2e5G/jclBpXHqHY3sxpg== X-Received: by 2002:ac8:ac3:: with SMTP id g3mr3597684qti.178.1596123725328; Thu, 30 Jul 2020 08:42: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 n6sm4314367qkh.74.2020.07.30.08.42.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 30 Jul 2020 08:42:04 -0700 (PDT) To: Robert Stepanek , calsify@ietf.org References: <4b406ac9-b88b-57c7-8b78-1b770330d18f@gmail.com> From: Michael Douglass Message-ID: <6ad0826f-3e82-0cf7-9a97-a1b67ad29fe2@gmail.com> Date: Thu, 30 Jul 2020 11:42:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E9770A60A6C9A3FC2C86B64D" Content-Language: en-US Archived-At: Subject: Re: [calsify] Jscalendar, description 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, 30 Jul 2020 15:42:15 -0000 This is a multi-part message in MIME format. --------------E9770A60A6C9A3FC2C86B64D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 7/30/20 07:18, Robert Stepanek wrote: > On Wed, Jul 29, 2020, at 11:10 PM, Michael Douglass wrote: >> Currently jscalendar has "description" and "descriptionContentType" >> properties. >> >> I suggest we make this multi-valued with a "Description" object with >> "content" and "contentType" fields. > > With multi-valued descriptions (and the already supported Link.cid > property) we are getting close to a MIME multipart/alternative. If we > conclude to add this, then we should still keep the content types > restricted to subtypes of "text", and we should only allow a single > description for a given subtype. In practice, that means html and > plain text descriptions. That seems fine to me. The issue we wanted to resolve was the appearance of html descriptions and the need to also have a plain text alternative. As you suggest - in the future any other related content can be addressed by links > > I guess we'll address this also in the IETF calext session tomorrow. > > Cheers, > Robert > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------E9770A60A6C9A3FC2C86B64D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 7/30/20 07:18, Robert Stepanek wrote:
On Wed, Jul 29, 2020, at 11:10 PM, Michael Douglass wrote:
Currently jscalendar has "description" and "descriptionContentType" 
properties.

I suggest we make this multi-valued with a "Description" object with 
"content" and "contentType" fields.

With multi-valued descriptions (and the already supported Link.cid property) we are getting close to a MIME multipart/alternative. If we conclude to add this, then we should still keep the content types restricted to subtypes of "text", and we should only allow a single description for a given subtype. In practice, that means html and plain text descriptions.

That seems fine to me. The issue we wanted to resolve was the appearance of html descriptions and the need to also have a plain text alternative.

As you suggest - in the future any other related content can be addressed by links


I guess we'll address this also in the IETF calext session tomorrow.

Cheers,
Robert


_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------E9770A60A6C9A3FC2C86B64D-- From nobody Thu Jul 30 18:53:03 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 A68F93A0AA9 for ; Thu, 30 Jul 2020 18:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=tWZOtono; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eCc7OTqM 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 wSOItDTOYaX2 for ; Thu, 30 Jul 2020 18:52:58 -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 BA3FE3A0AA8 for ; Thu, 30 Jul 2020 18:52:58 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id C8DDF7A2 for ; Thu, 30 Jul 2020 21:52:57 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Thu, 30 Jul 2020 21:52:57 -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=JBBHvEL 5ZW34LGwI80aq2YF5+SaEFF+dRWLJCRqvz3A=; b=tWZOtonoKVrrRHpDuOjUEhZ 1Scc1GC/BcZL8JoTmx0JToqAWQHcTnZPzT+fXo+5200nseC0IOgPLa4vvupdUnyv lcBgGiMHweQK6xdv1MPxw19nOd3KOlqRpZj7sQjGD3tsleF2yE+/kfJJsW9l2WSg BM5bWyMUkF0BHegLGZ8kQwgVwEnCKIFYclAqSZay2Tc619srTrlDzKKmuzVMneoy 2KILdOaDtwxbeA3CM9zCX4PbJCYfSD7a43jZQ1u8iZisNJLb+boS9tPgODHV8ZiR 6Hj0KROAGEmnEY/Px2GaYS3TEuCQewbJqLAcNz61tD/fXPpyfTmI0JTMzASfFlA= = 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=JBBHvE L5ZW34LGwI80aq2YF5+SaEFF+dRWLJCRqvz3A=; b=eCc7OTqMuRsnrzhLllalO4 uF5YpIskrZ59bYVuD9k/M1ic9NboVyUsRZotcNHlyc/DZWzpSlg8lWSl6RfFKXrt iPsYYW73oeLru1c6fpeNfcLo0bPy3gsP0wvCqSaa3DpGncEWDp+V+n/IHZDTZZNU q98/gOpi12jMRDag5Dy0fXx2OWWO8CfhfrgNMfzoC1e5kkanITjxVRfb5FXSWqOz q3XplF57HIzTW0F8kXkcbPBiDStC3IhIjPd3JCePAkUsizf0wuFmAi6AFK0OQzjF KitqaeU8LomEHjEokAaxDD84Q5a/tiGN6T3NpAnTi+Rxy5M+QbUWVj+ZRSVwXp9Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieejgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevvdetvdduleekhf eghfetfeettdelhfehfeevffevleekuddtudffieevjeevhfenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D179A180558; Thu, 30 Jul 2020 21:52:56 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: <8b2d9417-b822-4c78-a7e6-90a8d356f0e3@dogfood.fastmail.com> In-Reply-To: <6ad0826f-3e82-0cf7-9a97-a1b67ad29fe2@gmail.com> References: <4b406ac9-b88b-57c7-8b78-1b770330d18f@gmail.com> <6ad0826f-3e82-0cf7-9a97-a1b67ad29fe2@gmail.com> Date: Fri, 31 Jul 2020 11:52:56 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=e8a064e1aeef4f5bb2da52dfbad3ebfb Archived-At: Subject: Re: [calsify] Jscalendar, description 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: Fri, 31 Jul 2020 01:53:01 -0000 --e8a064e1aeef4f5bb2da52dfbad3ebfb Content-Type: text/plain I seem to recall discussing this at CalConnect a while back and the conclusion was no one hand wrote both HTML + plain text versions and the client can do just as good a job of autoconverting HTML; given people already shove HTML into iCalendar DESCRIPTION despite it definitely not being allowed, I'd rather keep what we have, which is simpler than some kind of multi-valued thing. Neil. --e8a064e1aeef4f5bb2da52dfbad3ebfb Content-Type: text/html
I seem to recall discussing this at CalConnect a while back and the conclusion was no one hand wrote both HTML + plain text versions and the client can do just as good a job of autoconverting HTML; given people already shove HTML into iCalendar DESCRIPTION despite it definitely not being allowed, I'd rather keep what we have, which is simpler than some kind of multi-valued thing.

Neil.
--e8a064e1aeef4f5bb2da52dfbad3ebfb-- From nobody Fri Jul 31 03:21:51 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 16E653A1223 for ; Fri, 31 Jul 2020 03:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=TI1kHYv+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RwmEySjK 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 INymZk8wI5ni for ; Fri, 31 Jul 2020 03:21:30 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20583A121F for ; Fri, 31 Jul 2020 03:21:29 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 77DF35C0165 for ; Fri, 31 Jul 2020 06:21:28 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute7.internal (MEProxy); Fri, 31 Jul 2020 06:21:28 -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=IyiASR/ XqRInQuHgRbMb/LUFP57cHmxE9XU76N+tLSU=; b=TI1kHYv+JxzxFKZBfGiC+8J UrvDT0c5GyP4u4AWBxRkwbWH0ku/jo1wiyGbitp1g04Utq4mAlOc5LtSAi9uKQpX /EURI5aCcfb5e4M0lWUs7qZHGfYrWZVUh+VjYf/Op7XR6Yv8AGhCF2bWgPHH0/Q6 WLEENHIwO9oWikWy9JPUn2wGGIR7kbHwFNt9un21EmayZa3+U08FXgvOPwosBf2v WSQohdGgptbn8Ghz65hzH/AsywX87a4AspDjNwTWxJ2eGAmuvmSR0hQxixugnM3U aQSknh9YmBb55vtnTcS8tM9WK2iqSS04HlblulsdG6odzJPWVYY1mheksZ9nTXQ= = 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=IyiASR /XqRInQuHgRbMb/LUFP57cHmxE9XU76N+tLSU=; b=RwmEySjKEvv+zGcMDuEoPL pfz6ZVR19Grbg0CeqMG2tiawwhhxZdTLjlZMjx54MjH8SWSxpgoVvOt7f0/2RRyv Xm66bf0tzed+mGO0BRT+KtFfGr+8ZB3FeSZopN0FIuMpcr2I0zdeppKPstIkNIdI DdeP4BHs+235XrwM4GTCKw0uBBo3RM59ifwvplvfUU9KuY8KzrDlubliZo2pNyWA Fjbw7R2XYs5nd+LzBm2w4CzpggXFiShKh0y+wlDg0a4Z6pYA9gDLwOHoaxX1IDJP MLBdJMSJFe8xWbiT0QN+g7Y1Uz2xI1ni4KbLHGzQqSlyFzCh1LxUnjq3E8X+qd3Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieekgddvkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeehgeeuvddtke fhtefgueefgfdvueetgeeffeelhedvudegjeejhfetuefgveevieenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1E352180569; Fri, 31 Jul 2020 06:21:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: <31d48d33-c36e-4c3e-a67f-219e1553dbb8@www.fastmail.com> In-Reply-To: <8b2d9417-b822-4c78-a7e6-90a8d356f0e3@dogfood.fastmail.com> References: <4b406ac9-b88b-57c7-8b78-1b770330d18f@gmail.com> <6ad0826f-3e82-0cf7-9a97-a1b67ad29fe2@gmail.com> <8b2d9417-b822-4c78-a7e6-90a8d356f0e3@dogfood.fastmail.com> Date: Fri, 31 Jul 2020 12:21:07 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=1975d9025e2f4b469d84530c8b601121 Archived-At: Subject: Re: [calsify] Jscalendar, description 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: Fri, 31 Jul 2020 10:21:43 -0000 --1975d9025e2f4b469d84530c8b601121 Content-Type: text/plain On Fri, Jul 31, 2020, at 3:52 AM, Neil Jenkins wrote: > I seem to recall discussing this at CalConnect a while back and the conclusion was no one hand wrote both HTML + plain text versions and the client can do just as good a job of autoconverting HTML This is also what I recall from CalConnect XLIV in Zurich in 2019. --1975d9025e2f4b469d84530c8b601121 Content-Type: text/html
On Fri, Jul 31, 2020, at 3:52 AM, Neil Jenkins wrote:
I seem to recall discussing this at CalConnect a while back and the conclusion was no one hand wrote both HTML + plain text versions and the client can do just as good a job of autoconverting HTML

This is also what I recall from CalConnect XLIV in Zurich in 2019.
--1975d9025e2f4b469d84530c8b601121-- From nobody Fri Jul 31 07:17:50 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 6CE803A13C5 for ; Fri, 31 Jul 2020 07:17:48 -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.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159620506842.32691.177205243064980496@ietfa.amsl.com> Date: Fri, 31 Jul 2020 07:17:48 -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: Fri, 31 Jul 2020 14:17:49 -0000 Changed milestone "Submit icalendar relations document to IESG for publication", set state to active from review, accepting new milestone. Changed milestone "Submit JSCalendar mapping document to IESG for publication", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/calext/about/ From nobody Fri Jul 31 07:56:33 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 E47E83A13BC for ; Fri, 31 Jul 2020 07:56:30 -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 rOFmORZLCIBU for ; Fri, 31 Jul 2020 07:56:29 -0700 (PDT) Received: from mail-vs1-xe36.google.com (mail-vs1-xe36.google.com [IPv6:2607:f8b0:4864:20::e36]) (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 A3C9B3A13BA for ; Fri, 31 Jul 2020 07:56:29 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id p25so15865521vsg.4 for ; Fri, 31 Jul 2020 07:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Wgzsxe43glBw8bxhuy7qdRYFYk16/m8Mlh0f8Lcsbrs=; b=V8wmDe0J1g8O2OLDy6s/Bei8KpLeMi2kU3v/xEaS6/3zIXN1PvNSADjR2QrXi6Dri5 NIE5Vvj7468HMF4nbBHPonsiaeENM8HgE5bv5dW1gCUfmTADLbzkPm3zSzZtvwTWwvJW 2KZvyQl3pmd1ZPpBLDC7tfQaP3y6SDZ98o8U+JLTC6JFvyv6420XdBV4Veb+CUnCE/f3 ApIDhS20vc4X+BYkd977XAwVnymMPAqLs0vh1boHetkozOucf7PLD/8SwyM8gEALoXpA OVXzhP9pFmJugigEeFLZOqHsoJRiYO7tPH9ZIgl1FPnqPw2S8zh600kaFe8CFTJ/cSED zEiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Wgzsxe43glBw8bxhuy7qdRYFYk16/m8Mlh0f8Lcsbrs=; b=WswPGXZEq9Is4lVtQ5N9E5ydLf1xZQHhCcgTF+PWJ9Y4uWihP8ArPz7an+h9vD43VO qzrPsFw2hxQxwkcR1E1/Drhs8LZP7LaLVSyS1Prtfd7eqN2/6Ru9iOFvaiae3bJKn57Y 4YNlD35CTFwqfxG+rYJE/yVfpW5fbsqzIfLtub1c89i2JfRFwe8UvfhrN6ys+cshkPPT Jvp9rsScHjOvax0azYB4dmGswLBGC7J35ydllt3vg9r+zsX+Ou89dbE3BY7b92Uug598 nN3M/8f3tj71JJ71NNxN0r1kHrwdXZBPECmZmTDX/3MVyNDu0U+iKrD9qilfkGKt+sdn vi2A== X-Gm-Message-State: AOAM533hlyt/mjajog+qA3l8twtOWkL6OzW7PvxeynxJScVbYT/mhNUc RlsQK28trBvH471hkKDLEVY+d4NGQShSxY91mM4fhUs9 X-Google-Smtp-Source: ABdhPJza5l49xaGmNaVGTSgjROjmf0hGqGI7/I+Lb9vIf83qSst+Bn1o4yXXQUDlI1P//FhakDu6DRJxchn7czZkLQk= X-Received: by 2002:a67:e28c:: with SMTP id g12mr3373437vsf.31.1596207388442; Fri, 31 Jul 2020 07:56:28 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Fri, 31 Jul 2020 10:56:17 -0400 Message-ID: To: IETF-Calsify Content-Type: multipart/alternative; boundary="0000000000006044f805abbdfe0d" Archived-At: Subject: [calsify] Second WGL for draft-ietf-calext-jscalendar 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: Fri, 31 Jul 2020 14:56:31 -0000 --0000000000006044f805abbdfe0d Content-Type: text/plain; charset="UTF-8" This mail starts a second WGLC for draft-ietf-calext-jscalendar [1] that will end on August 15 2020. Please state on the mailing list whether you believe the draft is ready to be shipped to the IESG or raise your concerns if you have any. Yours, Bron and Daniel [1] https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ -- Daniel Migault Ericsson --0000000000006044f805abbdfe0d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This mail starts a second WGLC for draft-ie= tf-calext-jscalendar=C2=A0[1] that will end= on=C2=A0August 15 2020.=C2=A0 Please state on the mailing list whether you= believe the draft is ready to be shipped to the IESG or raise your concern= s if you have any.=C2=A0

--
Daniel Migault
Ericsson
--0000000000006044f805abbdfe0d-- From nobody Fri Jul 31 11:41:21 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 9557B3A0CA5 for ; Fri, 31 Jul 2020 11:40:52 -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 Ou8pj_jndtGC for ; Fri, 31 Jul 2020 11:40:49 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 BBD403A0B8D for ; Fri, 31 Jul 2020 11:40:48 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id z26so3840968uaa.4 for ; Fri, 31 Jul 2020 11:40:48 -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=SEkddgILyteyZqICZ2zq/YK6CcFPj2/DWBW9CeTjE5I=; b=nQRsRB/4YM3PI4vZ/R4q4ykDFEl1aQccdaBFG2wjB1xDpMetOUru5cKVAwetHrOKJK mjxXiwS/kgIf1IqUaVPm6aU+1rl8LEUX/HkW9SrvVcr5RFvh9EyfGU+v9aTeHObuWRvV UPI83Q+kX+f7aWCHq7UGCLgGPAfkV5enZrV8YX0S+OZDubHWo0NnTivpiWex88c7VQnW Ap3V5BUm8fpuPFw9Gio4Jd3iPzu/XdBeB1MdEsiN2yFI/OfsmcRJJkw7A/Q8ch1mA8WK 2W+067M0SLSAz0RgRASZ1MjTvxPaGdFHLXh2Iub4y5OKYIcJS1GSNcPgAJAjzUDfSLjg hm5Q== 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=SEkddgILyteyZqICZ2zq/YK6CcFPj2/DWBW9CeTjE5I=; b=UIJft8fV+BMKSoQlibiDKBnBNt1uQ1WLbVHMFbyxTiYB66+Xnhj9eWEoOcSQtDnW88 2YG5EB0eWrFceuYbsaNaWEV5Syv3J7lwKb1VoC1zRC/SuT5wGCWCCRlc+mg7MxBGyEm6 vLgDduZRPrg2/18in/1AshMtMcKc9EjTmVMS8BFGKqGkx+cUZTUXeLGzvUqx8hxacoWT Xiagp43SmtxU7ZzSu1Tw2kDJy8ggSg4VX5oeQTzAetb47LTTnfl7y+RTx9O20TtPRvM3 qlBzAeyX8hR0hoyU0zVqMaL9MEwphbL+bjMCV7lSRIPL8IlI4T//SbL8jC9+c36VxvKj rHTQ== X-Gm-Message-State: AOAM530Kg2IpxaAAYExGHlWu/H/rE7t0LVLJ8R1Zh3c3W1MZRIAmUacF lj9KrNyLoT70G1LPMVKegT8DWC5vDsF0P4+z57M= X-Google-Smtp-Source: ABdhPJyUGcrx6hpMQlZ5lbEH+Ymrpfz0DMqdnCN4dcq/Th84PndCcFb4hCqjHdoepjs30fwyKyhxEzxL+9JnoIV1kE4= X-Received: by 2002:ab0:7406:: with SMTP id r6mr3843730uap.23.1596220847483; Fri, 31 Jul 2020 11:40:47 -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: From: Daniel Migault Date: Fri, 31 Jul 2020 14:40:36 -0400 Message-ID: To: Ken Murchison Cc: Bron Gondwana , IETF-Calsify Content-Type: multipart/alternative; boundary="00000000000098f09405abc12087" 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: Fri, 31 Jul 2020 18:40:53 -0000 --00000000000098f09405abc12087 Content-Type: text/plain; charset="UTF-8" Hi, Thanks for the responses. I will write the shepherd to meet the milestone, so that should be shipped in a few hours. Yours, Daniel On Mon, Jul 13, 2020 at 2:31 PM Ken Murchison wrote: > Hi Daniel, > > Thanks for the review and sorry for my slow reply. Responses inline. I > just posted -02 with a few changes and can make more if required. > > > On 6/15/20 3:48 PM, Daniel Migault wrote: > > 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. > > > > > I'm not sure exactly what the issue is with the current wording, but I > changed "popular" to "prevalent". > not remembering exactly why I put this comment - I wonder if I was not myself omitting an "and". In any case, you are better qualify to tell the wording is fine. > > > > [ .... ] > > 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. > > > > It is standard with ABNF (at least as far as I have seen) to structure the > definitions this way. > > > My comment was brought from errors raised by the tools. I do not find this as a big issue - especially if you are telling me you are adopting a standard way to present. > > > 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. > > > > > Yes, good catch. > > > > > 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 > > > > Fixed. > > > > > 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. > > > > The mechanism for "switching off" alarms on devices, is that each device > should sync the iCalendar resource with the server just prior to firing the > alarm. If the VALARM contains an ACKNOWLEDGED property on/after the > trigger time, then the device should not fire the alarm. > > For disconnected devices, there is no solution that I'm aware of. > > > > [ ... ] > > 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. > > > > There is a computed trigger time that corresponds to each occurrence. > Does that clarify? > > > yes. > > [ ... ] > > 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. > > > In order to do this via CalDAV, the attacker would have to have > credentials to update the iCalendar resource. If they have the user's > credentials, they can do a lot more damage than just silencing alarms. > > > correct. I think I was thinking locally at the time of the comment, but as you state, such attacker may access far more interesting information. > > 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. > > > I'm not sure I follow. > > > > > > > > 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 ? > > > > A proximity alarm would trigger when you arrive/leave a certain location. > If the user acknowledges the alarm, then they would leak WHEN they where at > that location. I'm open to new suggested text. > > > Seems fine. I think I mis-interpreted the proximity alarm. > 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 > > _______________________________________________ > calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify > > -- > Kenneth Murchison > Senior Software Developer > Fastmail US LLC > > -- Daniel Migault Ericsson --00000000000098f09405abc12087 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,=C2=A0

Th= anks for the responses. I will write the shepherd to meet the milestone, so= that should be shipped in a few hours.=C2=A0

Your= s,=C2=A0
Daniel
On Mon, Jul 13, 2020 at 2:31 PM Ken Murchison <murch@fastmail.com> wrote:
=20 =20 =20

Hi Daniel,

Thanks for the review and sorry for my slow reply.=C2=A0 Responses inline.=C2=A0 I just posted -02 with a few changes and can make more = if required.


On 6/15/20 3:48 PM, Daniel Migault wrote:
=20
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=A0dra= ft-ietf-calext-valarm-extensions-01

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 i= s the "VALARM"
=C2=A0 =C2=A0component which appears as a sub-component of "= VEVENT" and "VTODO"
=C2=A0 =C2=A0components.=C2=A0 The "VALARM" component i= s 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=A0different ways to specify how the alarm is triggered= .

=C2=A0 =C2=A0As iCalendar has become more widely used and as client-server
=C2=A0 =C2=A0protocols such as CalDAV [RFC4791] have become more popular, several

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

</mglt>


I'm not sure exactly what the issue is with the current wording, but I changed "popular" to "prevalent".

=
<mglt>
not remembering exactly why I put = this comment - I wonder if I was not myself omitting an "and". In= any case, you are better qualify to tell the wording=C2=A0is fine.=C2=A0
<mglt>=C2=A0




[ .... ]

3.=C2=A0 Extensible syntax for VALARM

=C2=A0 =C2=A0Section 3.6.6 of [RFC5545] defines the syntax for &q= uot;VALARM" components
=C2=A0 =C2=A0and properties within them.=C2=A0 However, as writte= n, it is hard to
=C2=A0 =C2=A0extend this by adding, e.g., a new property common t= o all types of
=C2=A0 =C2=A0alarm.=C2=A0 Since many of the extensions 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, with the goal of simplifying specifica= tion of the
=C2=A0 =C2=A0extensions.

=C2=A0 =C2=A0A "VALARM" calendar component is re-define= d 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 fol= lowing are REQUIRED,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; but MUS= T NOT occur more than once

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




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 3]
=0C
Internet-Draft =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VA= LARM 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 properties MUST be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; present= 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 actionpro= ps /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; the fol= lowing is OPTIONAL,
=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 / emailpr= opext

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


It is standard with ABNF (at least as far as I have seen) to structure the definitions this way.


<mglt>
My comment wa= s brought from errors raised by the tools.=C2=A0 I do not find this as=C2= =A0 a big issue - especially if you are telling me you are adopting a stand= ard way to present.=C2=A0
</mglt>=C2=A0



=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,
=C2=A0 =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 = =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 = =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 more 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; t= he following are REQUIRED,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; b= ut MUST NOT occur more than once

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0des= cription /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; &= #39;duration' and 'repeat' are both OPTIONAL,
=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; b= ut if one occurs, so MUST the other

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dur= ation / 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 following 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=A0VA= LARM 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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 de= scription / 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 at= tendee /

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ; = 'duration' 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 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=A0 du= ration / repeat

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

</mglt>


Yes, good catch.




4.=C2=A0 Alarm Unique Identifier

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

<mglt>
to be specified
</mglt>


Fixed.




=C2=A0 =C2=A0then be used to refer uniquely to the "VALARM&q= uot; component.

[ ... ]


6.=C2=A0 Alarm Acknowledgement

=C2=A0 =C2=A0There is currently no way for a "VALARM" c= omponent to indicate
=C2=A0 =C2=A0whether it has 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 a= n 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 action when an alarm triggers, then
=C2=A0 =C2=A0multiple "alerts" are generated by differe= nt devices.=C2=A0 In such a
=C2=A0 =C2=A0situation, a calendar user would like to be able to "dismiss" the
=C2=A0 =C2=A0alarm on one device and have it automatically dismis= sed on the others
=C2=A0 =C2=A0too.

<mglt>
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.
</mglt>


The mechanism for "switching off" alarms on devices, is th= at each device should sync the iCalendar resource with the server just prior to firing the alarm.=C2=A0 If the VALARM contains an ACKNOWLEDG= ED property on/after the trigger time, then the device should not fire the alarm.

For disconnected devices, there is no solution that I'm aware of= .



[ ... ]

6.1.=C2=A0 Acknowledged Property

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

=C2=A0 =C2=A0Purpose: =C2=A0This property specifies the UTC date = and time at which the
=C2=A0 =C2=A0 =C2=A0 corresponding alarm was last sent or acknowl= edged.

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

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

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

=C2=A0 =C2=A0Description: =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 clie= nts to determine when a
=C2=A0 =C2=A0 =C2=A0 pending alarm has been acknowledged by a cal= endar user so that any
=C2=A0 =C2=A0 =C2=A0 alerts can be dismissed across multiple devi= ces.=C2=A0 It also allows
=C2=A0 =C2=A0 =C2=A0 clients 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 mi= ssed alarms can be
=C2=A0 =C2=A0 =C2=A0 tracked.

=C2=A0 =C2=A0 =C2=A0 Clients SHOULD set this property to the curr= ent date-time value in
=C2=A0 =C2=A0 =C2=A0 UTC when a calendar user acknowledges a pend= ing alarm.=C2=A0 Certain
=C2=A0 =C2=A0 =C2=A0 kinds of alarm may not provide feedback as t= o when the calendar
=C2=A0 =C2=A0 =C2=A0 user sees them, for example email based aler= ts.=C2=A0 For those kinds
=C2=A0 =C2=A0 =C2=A0 of alarms, the client SHOULD set this proper= ty when the alarm is
=C2=A0 =C2=A0 =C2=A0 triggered and the action successfully carrie= d out.

=C2=A0 =C2=A0 =C2=A0 When an alarm is triggered on a client, clie= nts can check to see
=C2=A0 =C2=A0 =C2=A0 if an "ACKNOWLEDGED" property is p= resent.=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 N= OT 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 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. =C2=A0 =C2=A0

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


There is a computed trigger time that corresponds to each occurrence.=C2=A0 Does that clarify?


<mglt>
yes.=C2=A0
</mglt>=C2=A0


[ ... ]

9.=C2=A0 Security Considerations

=C2=A0 =C2=A0VALARMs, if not monitored properly, can be used to &= quot;spam" users 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 part= y (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 system.

<mglt>
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 =C2=A0is set in t= he future. Even with such control, it could also disable the repeat properties.=C2=A0


In order to do this via CalDAV, the attacker would have to have credentials to update the iCalendar resource.=C2=A0 If they have the user's credentials, they can do a lot more damage than just silencing alarms.


<mglt>
correct. I th= ink I was thinking locally at the time of the comment, but as you state, su= ch attacker may access far more interesting information.=C2=A0=C2=A0
<= div></mglt>=C2=A0


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.


I'm not sure I follow.





</mglt>

10.=C2=A0 Privacy Considerations

=C2=A0 =C2=A0Proximity VALARMs, if not used carefully, can leak a= user's past,
=C2=A0 =C2=A0present, or future location.=C2=A0 For instance, sto= ring an iCalendar
=C2=A0 =C2=A0resource containing proxmity VALARMs to a shared cal= endar on CalDAV
=C2=A0 =C2=A0server can expose to anyone that has access to that calendar the
=C2=A0 =C2=A0user's intent to leave from or arrive at a parti= cular location at
=C2=A0 =C2=A0some future time.=C2=A0 Furthermore, if a CalDAV cli= ent updates the shared
=C2=A0 =C2=A0iCalendar resource with an ACKNOWLEDGED property whe= n the alarm is
<mglt>
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=C2=A0the reason that is whether he is willing to ignore the alarm or going to the event itself.=C2=A0 Am I missing something ?
</mglt>


A proximity alarm would trigger when you arrive/leave a certain location.=C2=A0 If the user acknowledges the alarm, then they would leak WHEN they where at that location.=C2=A0 I'm open to new sugg= ested text.


<mglt>
Seems fine. I= think I mis-interpreted the proximity alarm.
</mglt>=C2=A0=

=C2=A0 =C2=A0triggered, will leak the exact date and time that= the user left from
=C2=A0 =C2=A0or arrived at the location.=C2=A0 Therefore, CalDAV = clients that implement
=C2=A0 =C2=A0proximity alarms SHOULD give users the option of sto= ring and/or
=C2=A0 =C2=A0acknowledging the alarms on the local device only an= d not storing the
=C2=A0 =C2=A0alarm and/or acknowledgment on a remote server.



On Wed, Jun 10, 2020 at 8:32 AM Bron Gondwana <brong@fastmailteam.com> wrote:
Obviously, that date came and went and I got sidetracked with other things.=C2=A0 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 feedb= ack 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, s= o you have until Wednesday 13 May to review and respond to this document.

Cheers,

Bron.

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


_______________________________________________
calsify mailing list


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


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


--
Daniel Migault
Ericsson

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

--=20
Kenneth Murchison
Senior Software Developer
Fastmail US LLC


--
Daniel Migault
Ericsson
--00000000000098f09405abc12087-- From nobody Fri Jul 31 11:48: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 073DE3A00E5 for ; Fri, 31 Jul 2020 11:48:37 -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 cR5UaquVHorG for ; Fri, 31 Jul 2020 11:48:35 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 2F4393A0044 for ; Fri, 31 Jul 2020 11:48:35 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id j23so9978589vsq.7 for ; Fri, 31 Jul 2020 11:48:35 -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=lzCHBp/DOisV5GfwoIQeC3OQutpqyNUH2/XjFmqwzY0=; b=gzL3YxJ+dYeMYiQIZjbMxvgNLNlJ6NwJLEGee8zZG2IRA8dsnHK6sdiOw30ZPB68hH xwIFgy3+ImIMog8JCIkOLoOOzYrgS/2SNttipzztTerIjEg28sukZF7pMf5mUigtdvpn i79rImSZkdM1tjfgRTF56bGK9oi+R3+V1bijTJotBYry7sTmUzwokWoptUn6RQnzF3E5 RpOqkKwEsJinRnnsUMOZS2HVH7Uk6HOwcRwRj6K67sIQ2frM21DH7mRjXA9OUh5tmKpu kTgxEFUUjl6xfFLBE6aOCB34gV9vuAGCxiOAeO69vXcXgaXKnFyJygfzQ6XmVN2uzT2P aljw== 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=lzCHBp/DOisV5GfwoIQeC3OQutpqyNUH2/XjFmqwzY0=; b=AsVWIRJHANo3RAdzApz54eIcxhcH/5Dmrjrpio0RJk+e1T1Or4eqUdJ1NHss8Ni68f qRWF1B/dAtk8FcOX5Asi8wnKXkkLjZCIWecH9O5OnCY/2FG1+3kgiJESivcPAfHGzl/R shcUXxRdDrXpXRoNFZ87AvHOC2wCcDk+PRCSKI6oeRpl3HczvlU7FPp7R/mprTErngVs edpycNNA7NcUseRfhsiDY5EPonfAwuQ+joXVyJfkcwwVPHsi3FpEzMGov3blFHPL4wcG 25HaKM7vpaSl3bkGsg0HCAMp70uv2fakQXD9SVn0Dm1efDCQ0DfBrSDaERsxQaExzFcD iO1Q== X-Gm-Message-State: AOAM533sfi4NQB9DU6ToSI1GqDlT3GM1yXONoblBg9kc2HF0RRlDMQQj Ze/5Yo8ykOkUuKV8hEIFLLMY3ju49oEAhiwPWHE= X-Google-Smtp-Source: ABdhPJyAfuG1HVFQObWwwxqNdkjlJU4CajDhdnDnsmwAaAk6/MqPIMyYpVwBNv3fUBcw4hnMh3eIHXl+WwOrrkYdpnY= X-Received: by 2002:a67:f696:: with SMTP id n22mr4305484vso.169.1596221314267; Fri, 31 Jul 2020 11:48:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Fri, 31 Jul 2020 14:48:21 -0400 Message-ID: To: Cyrus Daboo Cc: Ken Murchison , Bron Gondwana , IETF-Calsify Content-Type: multipart/alternative; boundary="0000000000006b7d2f05abc13cf5" 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: Fri, 31 Jul 2020 18:48:37 -0000 --0000000000006b7d2f05abc13cf5 Content-Type: text/plain; charset="UTF-8" That is an interesting comment. I am not sure if it should be placed in the main body of the document or in the security consideration section. Yours, Daniel On Mon, Jul 13, 2020 at 3:33 PM Cyrus Daboo wrote: > Hi Ken, > > --On Mon, 13 Jul 2020 14:31:56 -0400 Ken Murchison > wrote: > > >> > >> 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. > >> > > > > > > The mechanism for "switching off" alarms on devices, is that each device > > should sync the iCalendar resource with the server just prior to firing > the > > alarm. If the VALARM contains an ACKNOWLEDGED property on/after the > > trigger time, then the device should not fire the alarm. > > Actually that is not the typical case. Certainly devices should pre-check > the ACKNOWLEDGED property before triggering the alarm, but in most cases > that will not be set. > > The typical case has alarms triggering simulataneously on all the devices > belonging to a user. Those will popup an alert on all devices. The user > then > acks the alert on one device. That device adds the ACKNOWLEDGED property > and > writes the event back to the server. The server then triggers a push > notification to the other devices. The other devices sync the changed > event. > The other devices spot the presence of the ACKNOWLEDGED property and > automatically dismiss the visual alert. > > It might be worth noting one operational consideration here: there is a > "stampeding herd effect" caused by this ack behavior. Specifically, in > enterprise enrvironments, meetings often occur at the start of an hour. > Those meetings can often involve multiple attendees, each of whom may > setup > their own alarm. So servers will get hammered with lots of requests when > the > alarms trigger and start to get ack'd by the users. That gets multipled by > the number of devices each user has, since those will receive a push > notification and then sync the ack changes from the server. > > In our enterprise system, we saw very large spikes in requests on the > hour, > a smaller spike at 45 mins past the hour, and further smaller spikes at 15 > mins and 30 mins past the hour. There were typically large spikes at 9 > am/10 > am/11 am, smaller at 12 pm/1 pm (lunch time), then bigger again at 2 pm/3 > pm, and tailing off after that. These were all traced to the alarm ack > behavior . In our case, the client defaults to setting up alarms 15 mins > before a meeting (though many people change that to occur at the time of > the > meeting) - hence the noticeable spike at 45 mins past the hour. That, > combined with meetings that start on the half-hour, give rise to the > pattern > we saw. > > I am not sure if this issue should be described in the spec, but it was > definitely a performance/scaleability issue that had to be accounted for. > > > For disconnected devices, there is no solution that I'm aware of. > > Correct. The user would have to manually dismiss UI alerts on all > disconnected devices. > > -- > Cyrus Daboo > -- Daniel Migault Ericsson --0000000000006b7d2f05abc13cf5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That=C2=A0is an interesting=C2=A0comment. I am not sure if= it should=C2=A0be placed in=C2=A0the main body of the document or in the s= ecurity consideration section.=C2=A0

Yours,=C2=A0
<= div>Daniel
=C2=A0

On Mon, Jul 13, 2020 at 3:33 PM Cyrus Dabo= o <cyrus@daboo.name> wrote:
Hi Ken,

--On Mon, 13 Jul 2020 14:31:56 -0400 Ken Murchison <murch@fastmail.com>
wrote:

>> <mglt>
>> It is probably due to my lake of expertise, but I have the impress= ion
>> 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<= br> >> 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 sy= nch
>> the calendar objects. I am wondering if most systems have a push >> mechanism to "switch off" the alarms on the other device= s.
>> </mglt>
>
>
> The mechanism for "switching off" alarms on devices, is that= each device
> should sync the iCalendar resource with the server just prior to firin= g the
> alarm.=C2=A0 If the VALARM contains an ACKNOWLEDGED property on/after = the
> trigger time, then the device should not fire the alarm.

Actually that is not the typical case. Certainly devices should pre-check <= br> the ACKNOWLEDGED property before triggering the alarm, but in most cases that will not be set.

The typical case has alarms triggering simulataneously on all the devices <= br> belonging to a user. Those will popup an alert on all devices. The user the= n
acks the alert on one device. That device adds the ACKNOWLEDGED property an= d
writes the event back to the server. The server then triggers a push
notification to the other devices. The other devices sync the changed event= .
The other devices spot the presence of the ACKNOWLEDGED property and
automatically dismiss the visual alert.

It might be worth noting one operational consideration here: there is a "stampeding herd effect" caused by this ack behavior. Specificall= y, in
enterprise enrvironments, meetings often occur at the start of an hour. Those meetings can often involve multiple attendees, each of whom may setup=
their own alarm. So servers will get hammered with lots of requests when th= e
alarms trigger and start to get ack'd by the users. That gets multipled= by
the number of devices each user has, since those will receive a push
notification and then sync the ack changes from the server.

In our enterprise system, we saw very large spikes in requests on the hour,=
a smaller spike at 45 mins past the hour, and further smaller spikes at 15 =
mins and 30 mins past the hour. There were typically large spikes at 9 am/1= 0
am/11 am, smaller at 12 pm/1 pm (lunch time), then bigger again at 2 pm/3 <= br> pm, and tailing off after that. These were all traced to the alarm ack
behavior . In our case, the client defaults to setting up alarms 15 mins before a meeting (though many people change that to occur at the time of th= e
meeting) - hence the noticeable spike at 45 mins past the hour. That,
combined with meetings that start on the half-hour, give rise to the patter= n
we saw.

I am not sure if this issue should be described in the spec, but it was definitely a performance/scaleability issue that had to be accounted for.
> For disconnected devices, there is no solution that I'm aware of.<= br>
Correct. The user would have to manually dismiss UI alerts on all
disconnected devices.

--
Cyrus Daboo


--
Daniel Migault
Ericsson
--0000000000006b7d2f05abc13cf5--