From nobody Thu Apr 8 06:10:30 2021 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 319AC3A1754; Thu, 8 Apr 2021 06:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmailteam.com header.b=Om8dAKF2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=h/YQZs7I 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 GakfbCJxYJv6; Thu, 8 Apr 2021 06:10:19 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83BD63A1764; Thu, 8 Apr 2021 06:10:16 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 7B2381388; Thu, 8 Apr 2021 09:10:14 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Thu, 08 Apr 2021 09:10:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=GUDYZbmJIpF5/w2i8a+6DvUa4h0IBy+5jJKJeBF yKbg=; b=Om8dAKF2GixkU8aaR/glzQ8FTsg0gxuD2CfKJr5rwLhvSi6gSG/14GG uciJ3qg6k5vgWpkL8XQtSDaDZwJk+EgjE63W9ljLhrHCTecePMQevCfgpXjDphQX GSJ/ZQ++FdmcQlBjvTUnEqsECZFFCyLwJeg4XH3+JXXprBaZ7CMFx+rVkRJs8UDT KNeI29wyI5vwek+0fuNnjFWD/0H1/aLmntNar2s96ahQGzsClTMRuJ/tJxHtqXJ3 5I2Tj1sPcCDSc5uvdaUgbTWuVvDQorxvODJSJr8oh8JNNBjlDwFYYuH02fj+95tL SdkDSAvMd+n1IttIs+TcPYDfwU0gvgw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=GUDYZbmJIpF5/w2i8a+6DvUa4h0IB y+5jJKJeBFyKbg=; b=h/YQZs7I/h+SWGhl8oOvCV3Vb75E/i0ofRXLvxrSByR8G 5CzTlFmYkyHuz/CGEoeXrrD8VUstVv/eiT5U6knUOU/ry1BQ+7Y/UyUQQ0RsDAWm ccYf6lEfOVA36IAxU+tQW0uxhtf47ceY1d8DZQe7r2LudUMnMsc4GiMdhnOS02pu vnkw0IxUu5CrJTE+RgF+SrHqCyglQY+1KaKvqFGOuITCMAOI/YzDGkbsYlPnUMxN 1dRl8rzi4abnd7kXtERHr32lrRA5Cb0Pvob0NorgWM1/wcctRaQOx5g9AoAr0WR3 J4oSc+Eq0QcQdLT7IyJnD3Y6Z6C63C9Fo6ThwpkUw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudejledgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvteetieeviefhge eitdegiefgudevleehgfffleegleeuhefhiedtleegtdffgeenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C34CF260005F; Thu, 8 Apr 2021 09:10:13 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249 Mime-Version: 1.0 Message-Id: Date: Thu, 08 Apr 2021 23:09:52 +1000 From: "Bron Gondwana" To: jmap@ietf.org, calsify@ietf.org Content-Type: multipart/alternative; boundary=f4f2fb4ea77d4475a2f772dc9be1dd9e Archived-At: Subject: [calsify] Interim meeting for JMAP and CALEXT combined with CalConnect 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, 08 Apr 2021 13:10:29 -0000 --f4f2fb4ea77d4475a2f772dc9be1dd9e Content-Type: text/plain Hi All, We have a single session at CalConnect for discussing both JMAP and CALEXT drafts which are related to CalConnect work. It's at 3am New York time, convenient for European early risers and very much for Australians. Not actually my first choice of time, but it's what we got given on the agenda. Let me know if there's anything you want put on the agenda specifically, otherwise I'll be running through the minutes of the past meetings and picking out the interesting work. Cheers, Bron. --f4f2fb4ea77d4475a2f772dc9be1dd9e Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,

We have a single session at CalConn= ect for discussing both JMAP and CALEXT drafts which are related to CalC= onnect work.  It's at 3am New York time, convenient for European ea= rly risers and very much for Australians.  Not actually my first ch= oice of time, but it's what we got given on the agenda.

L= et me know if there's anything you want put on the agenda specifically, = otherwise I'll be running through the minutes of the past meetings and p= icking out the interesting work.

Cheers,

Bron.




=


--f4f2fb4ea77d4475a2f772dc9be1dd9e-- From nobody Thu Apr 8 06:14:12 2021 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 99F5D3A1710; Thu, 8 Apr 2021 06:14:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161788764851.9488.8883772177602064918@ietfa.amsl.com> Date: Thu, 08 Apr 2021 06:14:08 -0700 Archived-At: Subject: [calsify] Calendaring Extensions (calext) WG Virtual Meeting: 2021-04-15 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, 08 Apr 2021 13:14:09 -0000 The Calendaring Extensions (calext) WG will hold a virtual interim meeting on 2021-04-15 from 03:00 to 04:30 America/New_York (07:00 to 08:30 UTC). Agenda: Discuss CalConnect sourced drafts which are now being worked on in the CALEXT and JMAP working groups at IETF. This meeting is held in conjunction with the CalConnect conference - and this session is open to all and free to attend. Information about remote participation: https://us02web.zoom.us/j/87289389671?pwd=eUtNRlZka0wwNGxjRWVxQlNTSzRVQT09 (Meeting ID: 872 8938 9671, Passcode: 892201) From nobody Mon Apr 12 21:44:33 2021 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 18E903A150B; Mon, 12 Apr 2021 21:44:32 -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.27.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <161828907203.15543.90945804825533715@ietfa.amsl.com> Date: Mon, 12 Apr 2021 21:44:32 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-icalendar-series-03.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, 13 Apr 2021 04:44:32 -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-03.txt Pages : 28 Date : 2021-04-12 Abstract: This document 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 is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-calext-icalendar-series-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-icalendar-series-03 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 Apr 15 19:47:15 2021 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 D63FB3A0FE7 for ; Thu, 15 Apr 2021 19:47:13 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 VzL4kDzuCWwU for ; Thu, 15 Apr 2021 19:47:09 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 5280C3A0FE5 for ; Thu, 15 Apr 2021 19:47:09 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id d23so15449294qko.12 for ; Thu, 15 Apr 2021 19:47:09 -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=9HgxBvai/Okxg8asXuKfUV/VJAoFyfEHUKZXLWksggI=; b=r4NOWwwII3d9cCeTQ7dL/XHnkmS1s4G4Te7Teh4oZCbZzUrpiFwobQb+9GzRhPwcZe VyK6PX5hnk6TmqzpVJqSiWJb0wOcOc2ZpdfX43412di+msHSozqk/bBucqTbCfSbSyyQ fspZ+55s5xn8BLy1iiAcUHzgvWyYdNeawhTW1ZLuR+PEnCYE13oUGQ5D3llXbojloRP5 OIvvYlbgZeDS7OeE3EBjx6k7Ag4xQnMkLZSPoAOQeId4tyJZ3/QbwjCluaMWlYizkDEw ju8go1Ql0loNyx0mA27zgFZgaOt0Lut199iHzH6Ef3tX2vv57I1ZsJ8BGKJa1ZOAO7fg ahrg== 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=9HgxBvai/Okxg8asXuKfUV/VJAoFyfEHUKZXLWksggI=; b=L1TAJ+H9SpeSu1H0iX14KoYRo8WA9Iz7zDHL/L+eCptsWT4HimXSX8IYpUP8cdXz09 ZJcLc27Qvn149Yc0/1H/mXXUhGX9JkX64A+0ZfVPSc+WbwO6x/e5kS9gTMT1UZC+d7nt TsPfDMJnVuQyzAzGgeKsqAEbn7Vcnas+wxlQ7VRdVgH5/42M7++eZ8zAZk1l5+GB2yjR DQnjcNOvap5cRplMj7gm4fVyKhQbYF37Zf3/nX9zchJURNSC6jBIR+PrZoF/0L7h2b8m Z2Q0KWccclAetunrp0LlV3QO5sgfi1dZl6zDJdHG46WljU1a/NtcY1SXKOUS6R5rt1Ly j8Ow== X-Gm-Message-State: AOAM533zskRRfncVUhRTon5OvcmyQsZUU9QmbnjWFbs/QyD1DUz5WSe5 dSqlhudk+C5mMarBi9yJ4z6MjRLeics= X-Google-Smtp-Source: ABdhPJxoU98mdkr1hh95RaFGrsPMCt0Z9pIgVcBOTUI5tFEvdAaWE2KSSJjEnjq7LIy4E9R9hejHNQ== X-Received: by 2002:ae9:f70d:: with SMTP id s13mr6567931qkg.346.1618541227448; Thu, 15 Apr 2021 19:47:07 -0700 (PDT) Received: from MacBook-Pro-2019.local (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id a4sm2985645qta.19.2021.04.15.19.47.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Apr 2021 19:47:06 -0700 (PDT) To: Bron Gondwana , calsify@ietf.org References: <662a9902-ca69-4627-b9b0-e3ccecd643d1@dogfood.fastmail.com> From: Michael Douglass Message-ID: <8f4213c9-3348-0c58-7322-2039b1e93b9c@gmail.com> Date: Thu, 15 Apr 2021 22:47:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <662a9902-ca69-4627-b9b0-e3ccecd643d1@dogfood.fastmail.com> Content-Type: multipart/alternative; boundary="------------BC1937555A9E45BEBE616FDC" Content-Language: en-US Archived-At: Subject: Re: [calsify] Review: draft-ietf-calext-ical-relations-05 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, 16 Apr 2021 02:47:14 -0000 This is a multi-part message in MIME format. --------------BC1937555A9E45BEBE616FDC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Looking through the spec and messages i realized I'd missed a couple of these. All are now dealt with. You also asked if I'd checked for alignment with jscalendar. There is in fact a misalignment. jscalendar defines the relation type "first" for which there is no equivalent in iCalendar. I have added that to the version 7 I'm working on. jscalendar does not define "sibling" but does define "next". The text in the icalendar-jscalendar mapping document suggests these are the closest match. We could strengthen that language and state that "SIBLING" and "next" are equivalent. There is a slight semantic difference - next seems to imply that some order matters while sibling doesn't. I could add "NEXT" to the relations draft but then we have to deal with "SIBLING". I prefer strengthening the language. On 8/3/20 19:52, Bron Gondwana wrote: > Hi Mike, > > Thanks for uploading the latest ical relations.  Here's a quick review > of a couple of tiny changes needed! > > And I need you to confirm that there's no IPR that you're aware of :) > > Thanks, > > Bron. > > *REVIEW: > * > > *Abstract: > * > > nits complains: > > ** The abstract seems to contain references ([RFC5545]), which it > shouldn't. Please replace those with straight textual mentions of the > documents in question. > > Please change it not to be a reference in the Abstract (it's OK to > have a reference in the Introduction) > > *1.4 Link* > > See [I-D.daboo-caldav-attachments] > > Please update this reference to be RFC8607. > > *7.1. Concept* > > There's a bug in the example: > > SCONCEPT:http://example.com/event-types/sports > CONCEPT:http://example.com/event-types/arts/music > CONCEPT:http://example.com/task-types/delivery > > Please remove the leading 'S'! > > ... > > I think that's everything I can see :) > > Cheers, > > Bron. > > -- >   Bron Gondwana, CEO, Fastmail Pty Ltd >   brong@fastmailteam.com > > --------------BC1937555A9E45BEBE616FDC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Looking through the spec and messages i realized I'd missed a couple of these. All are now dealt with.

You also asked if I'd checked for alignment with jscalendar.

There is in fact a misalignment. jscalendar defines the relation type "first" for which there is no equivalent in iCalendar. I have added that to the version 7 I'm working on.

jscalendar does not define "sibling" but does define "next". The text in the icalendar-jscalendar mapping document suggests these are the closest match. We could strengthen that language and state that "SIBLING" and "next" are equivalent.

There is a slight semantic difference - next seems to imply that some order matters while sibling doesn't.

I could add "NEXT" to the relations draft but then we have to deal with "SIBLING".

I prefer strengthening the language.

On 8/3/20 19:52, Bron Gondwana wrote:
Hi Mike,

Thanks for uploading the latest ical relations.  Here's a quick review of a couple of tiny changes needed!

And I need you to confirm that there's no IPR that you're aware of :)

Thanks,

Bron.

REVIEW:

Abstract:

nits complains:

  ** The abstract seems to contain references ([RFC5545]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

Please change it not to be a reference in the Abstract (it's OK to have a reference in the Introduction)

1.4 Link

    See [I-D.daboo-caldav-attachments]

Please update this reference to be RFC8607.

7.1. Concept

There's a bug in the example:

     SCONCEPT:http://example.com/event-types/sports
     CONCEPT:http://example.com/event-types/arts/music
     CONCEPT:http://example.com/task-types/delivery

Please remove the leading 'S'!

...

I think that's everything I can see :)

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd


--------------BC1937555A9E45BEBE616FDC-- From nobody Thu Apr 15 19:57:10 2021 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 F36313A1048 for ; Thu, 15 Apr 2021 19:57:07 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 5r0gHj8-ggHf for ; Thu, 15 Apr 2021 19:57:03 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 609BD3A1050 for ; Thu, 15 Apr 2021 19:57:03 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id 130so13312414qkm.4 for ; Thu, 15 Apr 2021 19:57:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=EU3sNxVFvQgMbmjxj2nAtqbaCipLaKc9xsmmXZPv82Y=; b=qqEOvsMTfALtEE0c737Yuz/6epmAZHFyXpvXSatX6OTOyNVsaJr0C1yV2M1njkmMGv xu6xDb0Zk+FS+ETdjIsP9qU/jFUMgEA9/ZycmXtJ45WKtg3Jt01KJh4cJDl/O+jU97QN u5XHNxQpYDCaeqHCV/4k0+wLCvkHAO1xmhzyHTV7KfQJkycUi8kt6tUclu4woVKzdka/ rZDTMBV7bUN/yWvf/qSLJw/VwwKRNqEXkSHSeDGIZ0Nd6kUK8dHTlBNw9J2BhGEIxBqj YFYUXle1QiF9iZ3ldI0qDegUGNdDmj5ihqY6FpgHuG0bHqplf6Qvn75SyEAgxHuxjk4h Hxsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=EU3sNxVFvQgMbmjxj2nAtqbaCipLaKc9xsmmXZPv82Y=; b=Rjp/IL7H9N6zCBFuxSYAWs1QW7iTyxf6W+nliH0e9MpdGD/wLasqADEhk8D7nFgWGc MRiKSkePpW7ctXzgun7CIAC5YBbFiV59Ko/Vzjuv8Uvi8/odpZvh0MaM6+2/k9zMcEqQ 3IEHh/dOiiRMgav9LF92gPr7w4uVRT8TU4Rt/P2QtGG48dDc8oy7WdaFZbYS9qjOY+I2 0VrxJEGuElF4E8jjOWs3xw5aqpBD5uEmaLbk5QfFmSvrHxaewWRXHJOi4QpipGrSf2gT m6RfV/ClaXN10mYgPXrgijpyBq81xSCcfwZYqVfJIzN52GSNC64se9I1EfFptTombeRX B6hQ== X-Gm-Message-State: AOAM530mqQbBXhi9RxjnSYD5PU7umF8Y203eZresCqoSDm1tMjKjXREw 4HghrGD6hVu31YdCEmrL9d6nDri8sys= X-Google-Smtp-Source: ABdhPJxvZImCsjg04A38pL4YsTNAsoBuSkjrFXc8CDHxwD23dy1LKDac+O5rBxPVc55JkjIH9KPhfw== X-Received: by 2002:a05:620a:806:: with SMTP id s6mr6797866qks.57.1618541821514; Thu, 15 Apr 2021 19:57:01 -0700 (PDT) Received: from MacBook-Pro-2019.local (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id k26sm3411787qkg.120.2021.04.15.19.57.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 15 Apr 2021 19:57:00 -0700 (PDT) From: Michael Douglass To: Bron Gondwana , calsify@ietf.org References: <662a9902-ca69-4627-b9b0-e3ccecd643d1@dogfood.fastmail.com> <8f4213c9-3348-0c58-7322-2039b1e93b9c@gmail.com> Message-ID: Date: Thu, 15 Apr 2021 22:56:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <8f4213c9-3348-0c58-7322-2039b1e93b9c@gmail.com> Content-Type: multipart/alternative; boundary="------------5B33618B2FF24489D84EAF32" Content-Language: en-US Archived-At: Subject: Re: [calsify] Review: draft-ietf-calext-ical-relations-05 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, 16 Apr 2021 02:57:08 -0000 This is a multi-part message in MIME format. --------------5B33618B2FF24489D84EAF32 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 4/15/21 22:47, Michael Douglass wrote: > > Looking through the spec and messages i realized I'd missed a couple > of these. All are now dealt with. > > You also asked if I'd checked for alignment with jscalendar. > > There is in fact a misalignment. jscalendar defines the relation type > "first" for which there is no equivalent in iCalendar. I have added > that to the version 7 I'm working on. > > jscalendar does not define "sibling" but does define "next". The text > in the icalendar-jscalendar mapping document suggests these are the > closest match. We could strengthen that language and state that > "SIBLING" and "next" are equivalent. > > There is a slight semantic difference - next seems to imply that some > order matters while sibling doesn't. > > I could add "NEXT" to the relations draft but then we have to deal > with "SIBLING". > > I prefer strengthening the language. > And as I add the text I feel a little uneasy about that. "first" and "next" go together to provide an ordered list of components. "sibling" might be appropriate for more of a tree structure > On 8/3/20 19:52, Bron Gondwana wrote: >> Hi Mike, >> >> Thanks for uploading the latest ical relations.  Here's a quick >> review of a couple of tiny changes needed! >> >> And I need you to confirm that there's no IPR that you're aware of :) >> >> Thanks, >> >> Bron. >> >> *REVIEW: >> * >> >> *Abstract: >> * >> >> nits complains: >> >> ** The abstract seems to contain references ([RFC5545]), which it >> shouldn't. Please replace those with straight textual mentions of the >> documents in question. >> >> Please change it not to be a reference in the Abstract (it's OK to >> have a reference in the Introduction) >> >> *1.4 Link* >> >> See [I-D.daboo-caldav-attachments] >> >> Please update this reference to be RFC8607. >> >> *7.1. Concept* >> >> There's a bug in the example: >> >> SCONCEPT:http://example.com/event-types/sports >> CONCEPT:http://example.com/event-types/arts/music >> CONCEPT:http://example.com/task-types/delivery >> >> Please remove the leading 'S'! >> >> ... >> >> I think that's everything I can see :) >> >> Cheers, >> >> Bron. >> >> -- >>   Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >> >> --------------5B33618B2FF24489D84EAF32 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 4/15/21 22:47, Michael Douglass wrote:

Looking through the spec and messages i realized I'd missed a couple of these. All are now dealt with.

You also asked if I'd checked for alignment with jscalendar.

There is in fact a misalignment. jscalendar defines the relation type "first" for which there is no equivalent in iCalendar. I have added that to the version 7 I'm working on.

jscalendar does not define "sibling" but does define "next". The text in the icalendar-jscalendar mapping document suggests these are the closest match. We could strengthen that language and state that "SIBLING" and "next" are equivalent.

There is a slight semantic difference - next seems to imply that some order matters while sibling doesn't.

I could add "NEXT" to the relations draft but then we have to deal with "SIBLING".

I prefer strengthening the language.

And as I add the text I feel a little uneasy about that.

"first" and "next" go together to provide an ordered list of components.

"sibling" might be appropriate for more of a tree structure

On 8/3/20 19:52, Bron Gondwana wrote:
Hi Mike,

Thanks for uploading the latest ical relations.  Here's a quick review of a couple of tiny changes needed!

And I need you to confirm that there's no IPR that you're aware of :)

Thanks,

Bron.

REVIEW:

Abstract:

nits complains:

  ** The abstract seems to contain references ([RFC5545]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

Please change it not to be a reference in the Abstract (it's OK to have a reference in the Introduction)

1.4 Link

    See [I-D.daboo-caldav-attachments]

Please update this reference to be RFC8607.

7.1. Concept

There's a bug in the example:

     SCONCEPT:http://example.com/event-types/sports
     CONCEPT:http://example.com/event-types/arts/music
     CONCEPT:http://example.com/task-types/delivery

Please remove the leading 'S'!

...

I think that's everything I can see :)

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd


--------------5B33618B2FF24489D84EAF32-- From nobody Sat Apr 24 19:07:38 2021 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 93EE73A29D6 for ; Sat, 24 Apr 2021 19:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6EsTAcNqorl for ; Sat, 24 Apr 2021 19:07:33 -0700 (PDT) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 9D9D83A29D4 for ; Sat, 24 Apr 2021 19:07:33 -0700 (PDT) Received: by mail-qv1-xf32.google.com with SMTP id j3so25689607qvs.1 for ; Sat, 24 Apr 2021 19:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=CIUewVdH7vrduaxjbQs0tEUnO/UvCHg4udfs/B9UbRM=; b=N115IJsIspl99Rv9Nm68BM+PehxpZ1Ll6PFMH4vDfXk+AOD2ExEqUBdutBXMphEv79 gjiTaDB8+fXa3PbB0nYRCjBtjlDsDcO+W8GaYxzhgTNaXg6x45ti2GPhc/eQhUHsStpE gVk8MrgReQ3ctRmoYXNirh/14ShegLz4YGxl0ST+FvI+spR80VTC+yC9/FS/uYpmGWb3 lLccF4fKVSzcvEfUeVozplYXK5mQCIcUMaR0nc8VFu07cKqiGgmv9w4tXgGHYo55ngVA cPVd+2uyLpWCmend8Pcom1vckyl7FiqDQn8OOOFu5BqNNuvlKAj7beh0zjl5ilFIHZYV 2Wfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=CIUewVdH7vrduaxjbQs0tEUnO/UvCHg4udfs/B9UbRM=; b=CdwlollDUL8U0Xti0ShaKvLJ0A9xYdJg5B8l3wK4pQSZ+YBxAJk8TA2rdX6PQiJECq Lzz9rqN9rINiNYtPRourFaNIor3YFjqwfZuUacgBydUcjuBoV26cij3ASE95YhltvMmm xN/UUtra8gSxKzW+7vhOCLpiud1ZWgtGAMa2LLAr3l91YmM84x6RUkwLdzsNryS+IH2a vuDLbh4aX6d65jtLFTGX0R4WkO8KQXLZdOQY1N32kHzN47HbIg5lcwMQz8pezONy4LfC +pYze7v5Vya8qHHYCUT4QgXj5BcFkZtKRLgJ9Ywcr+Ug4kuNWeCcg1Hx9c3pyIhcGpcu oUjg== X-Gm-Message-State: AOAM5311w4qwoSiJyY8t8+Edj8wg/r+/G9d+4hDdKvrKxvvdIiuZIEYk XE53ZyJARmjoSJBwiVimk8XtoOHH2ZQ= X-Google-Smtp-Source: ABdhPJyD3b6xRMw5zPGbzI4CUUPu6YGohmjx+OW7xcX31gRsG7fnHuh8PcOdnO4HogPmMAaKVRe/pw== X-Received: by 2002:a0c:db82:: with SMTP id m2mr11410132qvk.37.1619316451302; Sat, 24 Apr 2021 19:07:31 -0700 (PDT) Received: from [192.168.1.149] (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id d10sm852451qki.122.2021.04.24.19.07.30 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 24 Apr 2021 19:07:30 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <0331f674-dc29-5795-c9d2-93efb0fcef61@gmail.com> Date: Sat, 24 Apr 2021 22:07:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------79E6E8C259A52B9DE7B4E10B" Content-Language: en-US Archived-At: Subject: [calsify] iCalendar Series draft 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: Sun, 25 Apr 2021 02:07:37 -0000 This is a multi-part message in MIME format. --------------79E6E8C259A52B9DE7B4E10B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit At the last joint call there were a few questions and proposals... *** Why standardize? *** One was something like "why standardize this -couldn't it just be a reimplementation of recurrences". I guess the flip reply is why standardize anything? More specifically though - how would a client store a series definition or transport it from one service to another? *** Why the new SRULE etc properties *** There's still the ongoing question of whether a series is just another form of a recurrence - i.e. why do we need to replicate the recurrence properties. I still feel the rules governing series should be distinct from those for recurrences. I have had cases where a series of recurrences makes sense (university tours comes to mind) and I don't want to prevent that possibility. To enlarge on the university tour (for prospective students). As I recall the tours were identical on each day they occurred - something like every hour. There was some sort of pattern to the actual days allocated for the tours. At the time I felt something like recurring recurrences would work. I don't see this is a significant complication. Simply duplicating the relevant properties with mostly the same semantics and value types. *** Template - not master *** This is a good idea I'd like to extend. I'm inclined to see this as something distinct from series - that is a template could be used for anything. Of course - for a template to be useful it needs some variable parts adn it may be enough to just list the properties that MUST be defined If we define a new TYPE and REQUIRED property we could have a template that looked like: BEGIN:VTEMPLATE TYPE:EVENT REQUIRED:DTSTART,DTEND|DURATION END:TEMPLATE Of course a template could be provided completely filled in and that could take the place of the series master, e.g. BEGIN:VTEMPLATE TYPE:EVENT DTSTART:20210315 DURATION:T1H SRULE:... END:TEMPLATE I see templates being useful for events that occur irregularly but with a consistent structure - e.g. we always have a group meeting for 1 hour with a known set of attendees but there's no particular pattern to when. *** Self-generation *** One part of the series draft is how many instances are generated ahead of time. This came from a discussion long ago. With many recurring events it doesn't make much sense to create an actual instance more than a few weeks in advance. Many room booking systems have a booking window of a few weeks and there's not much point in having attendees agree to attend more than a few weeks out anyway. I think this feature is really separate from series - it could just as well be applied to recurrences. *** Proposed changes *** 1. Come up with a separate draft defining templates. 2. Change the series draft to use a template rather than a master. 3. create a separate draft for the parts which define how to limit the generation of instances in advance. This would show how to apply it to recurrences and to series. --------------79E6E8C259A52B9DE7B4E10B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

At the last joint call there were a few questions and proposals...

*** Why standardize? ***

One was something like "why standardize this -couldn't it just be a reimplementation of recurrences".

I guess the flip reply is why standardize anything? More specifically though - how would a client store a series definition or transport it from one service to another? 

*** Why the new SRULE etc properties ***

There's still the ongoing question of whether a series is just another form of a recurrence - i.e. why do we need to replicate the recurrence properties. I still feel the rules governing series should be distinct from those for recurrences. I have had cases where a series of recurrences makes sense (university tours comes to mind) and I don't want to prevent that possibility.

To enlarge on the university tour (for prospective students). As I recall the tours were identical on each day they occurred - something like every hour. There was some sort of pattern to the actual days allocated for the tours. At the time I felt something like recurring recurrences would work.

I don't see this is a significant complication. Simply duplicating the relevant properties with mostly the same semantics and value types.

*** Template - not master ***

This is a good idea I'd like to extend. I'm inclined to see this as something distinct from series - that is a template could be used for anything.

Of course - for a template to be useful it needs some variable parts adn it may be enough to just list the properties that MUST be defined

If we define a new TYPE and REQUIRED property we could have a template that looked like:

BEGIN:VTEMPLATE
TYPE:EVENT
REQUIRED:DTSTART,DTEND|DURATION
<a bunch of properties>
END:TEMPLATE

Of course a template could be provided completely filled in and that could take the place of the series master, e.g.

BEGIN:VTEMPLATE
TYPE:EVENT
DTSTART:20210315
DURATION:T1H
SRULE:...
<a bunch of properties>
END:TEMPLATE

I see templates being useful for events that occur irregularly but with a consistent structure - e.g. we always have a group meeting for 1 hour with a known set of attendees but there's no particular pattern to when.

*** Self-generation ***

One part of the series draft is how many instances are generated ahead of time. This came from a discussion long ago. With many recurring events it doesn't make much sense to create an actual instance more than a few weeks in advance. Many room booking systems have a booking window of a few weeks and there's not much point in having attendees agree to attend more than a few weeks out anyway.

I think this feature is really separate from series - it could just as well be applied to recurrences.

*** Proposed changes ***

1. Come up with a separate draft defining templates.

2. Change the series draft to use a template rather than a master.

3. create a separate draft for the parts which define how to limit the generation of instances in advance. This would show how to apply it to recurrences and to series.




--------------79E6E8C259A52B9DE7B4E10B-- From nobody Mon Apr 26 17:20:46 2021 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 C537A3A371E for ; Mon, 26 Apr 2021 17:20:44 -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=comcast.net 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 3GHaV0v0cHPq for ; Mon, 26 Apr 2021 17:20:40 -0700 (PDT) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50BEB3A371B for ; Mon, 26 Apr 2021 17:20:40 -0700 (PDT) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-08v.sys.comcast.net with ESMTP id bBRdlEtJLArcZbBSwltc3D; Tue, 27 Apr 2021 00:20:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1619482838; bh=ElVH189YLESl+4StOE6wMJwaNtU0k57u3m+q0DYQjTs=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=b70I7o2IptcQKNcCKzEmulmCL31gXFM4/+2+Gze3e9RC0XW/s4+oUIxwSznlOPYEK aWd4FyqujYJikRzEokaE1Mh1IfDYzKCBwlrNHBqIft2985ItOTVx1tf1ehkSy7l4te WibMTYmCidoOhzHRiRnnQR9Q4ZOEx4soylmqmV5nHix0pRYG+sw0NvENXm9W/X5PB6 nmWAbxVzFnHcCNcUxgpfodGzlQ13sAIpcMpfbZgLUAPQFls1/5h1YYxwuY9rkIxwb5 9R8rN2/38gnNFOJqOoXBdeLdAVuCG3NFJd/3gWvbK89XJ1Vs0nOFvtITsUkxRvtg6v nBKs2leJrtc6Q== Received: from THARE ([98.192.130.240]) by resomta-po-05v.sys.comcast.net with ESMTPA id bBSvlO96laWL5bBSwlqbmf; Tue, 27 Apr 2021 00:20:38 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduledrvdduledgieefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvfhgjufffkfggtgfothesrgdtghepvddtjeenucfhrhhomhepfdfvihhmucfjrghrvgdfuceovfhimhfjrghrvgestghomhgtrghsthdrnhgvtheqnecuggftrfgrthhtvghrnhepgefggeetvddtgffgvdektdffjedtlefgtddutdekleekteeuheekkefffeevffdtnecukfhppeelkedrudelvddrudeftddrvdegtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopefvjfettffgpdhinhgvthepleekrdduledvrddufedtrddvgedtpdhmrghilhhfrhhomhepthhimhhhrghrvgestghomhgtrghsthdrnhgvthdprhgtphhtthhopegtrghlshhifhihsehivghtfhdrohhrghdprhgtphhtthhopehmihhkvggrughouhhglhgrshhssehgmhgrihhlrdgtohhm X-Xfinity-VMeta: sc=-100.00;st=legit From: "Tim Hare" To: "'Michael Douglass'" , "'Calsify'" References: <0331f674-dc29-5795-c9d2-93efb0fcef61@gmail.com> In-Reply-To: <0331f674-dc29-5795-c9d2-93efb0fcef61@gmail.com> Date: Mon, 26 Apr 2021 20:20:37 -0400 Message-ID: <029501d73afb$262ec2c0$728c4840$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0296_01D73AD9.9F21DDB0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHTFAo3hsSguYnNNEQqERO9h873WqrPw6Xw Content-Language: en-us Archived-At: Subject: Re: [calsify] iCalendar Series draft 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, 27 Apr 2021 00:20:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0296_01D73AD9.9F21DDB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =E2=80=9CI still feel the rules governing series should be distinct from = those for recurrences=E2=80=9D =E2=80=9CSimply duplicating the relevant properties with mostly the same = semantics and value types=E2=80=9D NOT a criticism, but a question: where and how would a series differ = from recurrence? If it doesn=E2=80=99t differ significantly, then the = cost of implementation may exceed the benefit. Tim Hare Interested Bystander, Non-Inc. =20 From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of Michael = Douglass Sent: Saturday, April 24, 2021 10:07 PM To: Calsify Subject: [calsify] iCalendar Series draft =20 At the last joint call there were a few questions and proposals... *** Why standardize? *** One was something like "why standardize this -couldn't it just be a = reimplementation of recurrences". I guess the flip reply is why standardize anything? More specifically = though - how would a client store a series definition or transport it = from one service to another?=20 *** Why the new SRULE etc properties *** There's still the ongoing question of whether a series is just another = form of a recurrence - i.e. why do we need to replicate the recurrence = properties. I still feel the rules governing series should be distinct = from those for recurrences. I have had cases where a series of = recurrences makes sense (university tours comes to mind) and I don't = want to prevent that possibility. To enlarge on the university tour (for prospective students). As I = recall the tours were identical on each day they occurred - something = like every hour. There was some sort of pattern to the actual days = allocated for the tours. At the time I felt something like recurring = recurrences would work. I don't see this is a significant complication. Simply duplicating the = relevant properties with mostly the same semantics and value types. *** Template - not master *** This is a good idea I'd like to extend. I'm inclined to see this as = something distinct from series - that is a template could be used for = anything. Of course - for a template to be useful it needs some variable parts adn = it may be enough to just list the properties that MUST be defined=20 If we define a new TYPE and REQUIRED property we could have a template = that looked like: BEGIN:VTEMPLATE TYPE:EVENT REQUIRED:DTSTART,DTEND|DURATION END:TEMPLATE Of course a template could be provided completely filled in and that = could take the place of the series master, e.g. BEGIN:VTEMPLATE TYPE:EVENT DTSTART:20210315 DURATION:T1H SRULE:... END:TEMPLATE I see templates being useful for events that occur irregularly but with = a consistent structure - e.g. we always have a group meeting for 1 hour = with a known set of attendees but there's no particular pattern to when. = *** Self-generation *** One part of the series draft is how many instances are generated ahead = of time. This came from a discussion long ago. With many recurring = events it doesn't make much sense to create an actual instance more than = a few weeks in advance. Many room booking systems have a booking window = of a few weeks and there's not much point in having attendees agree to = attend more than a few weeks out anyway. I think this feature is really separate from series - it could just as = well be applied to recurrences. *** Proposed changes *** 1. Come up with a separate draft defining templates.=20 2. Change the series draft to use a template rather than a master.=20 3. create a separate draft for the parts which define how to limit the = generation of instances in advance. This would show how to apply it to = recurrences and to series. =20 =20 =20 ------=_NextPart_000_0296_01D73AD9.9F21DDB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

=E2=80=9C= I still feel the rules = governing series should be distinct from those for = recurrences=E2=80=9D
=E2=80=9CSimply duplicating the relevant = properties with mostly the same semantics and value = types=E2=80=9D

NOT a criticism, but a question:=C2=A0 where and = how would a series differ from recurrence?=C2=A0 If it doesn=E2=80=99t = differ significantly, then the cost of implementation may exceed the = benefit.

Tim Hare
Interested Bystander, Non-Inc.

 

From:<= /b> = calsify [mailto:calsify-bounces@ietf.org] On Behalf Of Michael = Douglass
Sent: Saturday, April 24, 2021 10:07 PM
To: = Calsify <calsify@ietf.org>
Subject: [calsify] iCalendar = Series draft

 

At the last joint call there = were a few questions and proposals...

*** Why = standardize? ***

One was something like "why = standardize this -couldn't it just be a reimplementation of = recurrences".

I guess the flip reply is why = standardize anything? More specifically though - how would a client = store a series definition or transport it from one service to = another? 

*** Why the new SRULE etc properties = ***

There's still the ongoing question of whether a = series is just another form of a recurrence - i.e. why do we need to = replicate the recurrence properties. I still feel the rules governing = series should be distinct from those for recurrences. I have had cases = where a series of recurrences makes sense (university tours comes to = mind) and I don't want to prevent that possibility.

To = enlarge on the university tour (for prospective students). As I recall = the tours were identical on each day they occurred - something like = every hour. There was some sort of pattern to the actual days allocated = for the tours. At the time I felt something like recurring recurrences = would work.

I don't see this is a significant = complication. Simply duplicating the relevant properties with mostly the = same semantics and value types.

*** Template - not = master ***

This is a good idea I'd like to extend. I'm = inclined to see this as something distinct from series - that is a = template could be used for anything.

Of course - for a = template to be useful it needs some variable parts adn it may be enough = to just list the properties that MUST be defined

If we = define a new TYPE and REQUIRED property we could have a template that = looked = like:

BEGIN:VTEMPLATE
TYPE:EVENT<=
o:p>
REQUIRED:DTSTART,DTEND|DURATION
<a bunch of = properties>
END:TEMPLATE

Of = course a template could be provided completely filled in and that could = take the place of the series master, = e.g.

BEGIN:VTEMPLATE
TYPE:EVENT
DTSTART:20210315
DURATION:T1H
SRULE:...
<a bunch of =
properties>
END:TEMPLATE

I = see templates being useful for events that occur irregularly but with a = consistent structure - e.g. we always have a group meeting for 1 hour = with a known set of attendees but there's no particular pattern to when. =

*** Self-generation ***

One part of = the series draft is how many instances are generated ahead of time. This = came from a discussion long ago. With many recurring events it doesn't = make much sense to create an actual instance more than a few weeks in = advance. Many room booking systems have a booking window of a few weeks = and there's not much point in having attendees agree to attend more than = a few weeks out anyway.

I think this feature is really = separate from series - it could just as well be applied to = recurrences.

*** Proposed changes = ***

1. Come up with a separate draft defining = templates.

2. Change the series draft to use a = template rather than a master.

3. create a separate = draft for the parts which define how to limit the generation of = instances in advance. This would show how to apply it to recurrences and = to = series.

 

 

=  

------=_NextPart_000_0296_01D73AD9.9F21DDB0-- From nobody Mon Apr 26 21:17:13 2021 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 45C563A1685 for ; Mon, 26 Apr 2021 21:17:06 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Xi540vuII_tk for ; Mon, 26 Apr 2021 21:17:00 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 86E583A16B8 for ; Mon, 26 Apr 2021 21:16:55 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id t17so30372854qkg.4 for ; Mon, 26 Apr 2021 21:16:55 -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=xdeKcwN3+p5cYhNZFHXp3bwjgti7ZxfTUiOqKVY3XBI=; b=vHf8K8tMTyxxLFaQrl9R4dZLdwbepkxIpk01XTWNn7+qy3gnFXmPTCg7fqWLWQ2TGo LsbNayJnAm7njfPHStrdmmXqD+HGcFr74Wqbf+44SP79D3CCNaFjbVwMPcGnQ43/0dyQ Rguy7/xMGFbY6/ddchhcEGK+ZN81kULyOBS1+0sd7KIgJ4gAUNUIB57XVQOrKcNxP6sH O5xhhTedr3EIgE7NaMoPYMAViVzu+yWMMBg2lxmdOnFcqc4VZue6+ROU21WJJchm+rEQ drPKy1HLsFkfn1RRps9zWIVkU19n0vnPO+TzOuQpkEFWQXLAdTUPQOquJ+ioB+PjAdzo 1CxQ== 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=xdeKcwN3+p5cYhNZFHXp3bwjgti7ZxfTUiOqKVY3XBI=; b=dX5BtK9/nZsptL8TpCuSS1d/A4AxNytwipZGqRXuEpXAZT688In5JquOgyaKsNpBtz 0VkRwC4f+7dpAfBU4WAidAsXUex1lhJa9sZ0Jk9Y0tulPD4hPBLmxw3amdzIAzuU83LD roc8LKe+hvaQ/XO/UD135SMnd/8u0nZa9o79QvFzIR/fScUZBOmiC0fK6Jnl+1QD1AUF 7jkMh0Qn774njND1lhl/+9JxrEGM5aXIFHniLNwYKZkL/IgOrSJ4zutffCBzELmAqUvd 1WfRo26WxIBRWkRaMGvecIv4pSvwd74YP53EBlCtikX8k0Nla4A/3+pHOfHTeud96q21 fqbA== X-Gm-Message-State: AOAM530UCcKzPwQVDURBYRD1Y+Yov92FbTEjnipnnejX4a+Mj5DgLLwe sNLIBqw51XQNhyNTCE0DdeMdipIhe3Y= X-Google-Smtp-Source: ABdhPJxBfqK2EdRAt7aG/qoU6Dhw1hvWEzCdnNPlcXBib5KOBr1idyXaZlwhU0czjXSM49lusKoOGQ== X-Received: by 2002:a37:912:: with SMTP id 18mr20543280qkj.446.1619497013444; Mon, 26 Apr 2021 21:16:53 -0700 (PDT) Received: from MacBook-Pro-2019.local (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id d6sm13230436qtn.52.2021.04.26.21.16.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Apr 2021 21:16:52 -0700 (PDT) To: Tim Hare , 'Calsify' References: <0331f674-dc29-5795-c9d2-93efb0fcef61@gmail.com> <029501d73afb$262ec2c0$728c4840$@comcast.net> From: Michael Douglass Message-ID: Date: Tue, 27 Apr 2021 00:16:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <029501d73afb$262ec2c0$728c4840$@comcast.net> Content-Type: multipart/alternative; boundary="------------0B9C259DC9C374860FC6D36D" Content-Language: en-US Archived-At: Subject: Re: [calsify] iCalendar Series draft 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, 27 Apr 2021 04:17:12 -0000 This is a multi-part message in MIME format. --------------0B9C259DC9C374860FC6D36D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 4/26/21 20:20, Tim Hare wrote: > > “I still feel the rules governing series should be distinct from those > for recurrences” > “Simply duplicating the relevant properties with mostly the same > semantics and value types” > > NOT a criticism, but a question:  where and how would a series differ > from recurrence?  If it doesn’t differ significantly, then the cost of > implementation may exceed the benefit > Recurring events are treated as a single resource - that's how they are defined - all instances and the master have the same uid. Long running instances with many overrides get very large. Rather than try to redefine how recurrences are defined and handled - which is going to lead to all sorts of backward compatibility issues - I came up with a different approach - each instance looks like a separate event - apart from the present of the new relation which ties it back to the 'master'. Older clients - in fact most clients in the future - can treat them as regular events. This better matches what happens with public events for example - museums, art galleries etc have a series of events - lectures, public days etc, which occur regularly but each instance is different. Standard recurrences work fine until you start changing every instance. As for the cost of implementation - it's pretty low. > > Tim Hare > Interested Bystander, Non-Inc. > > *From:*calsify [mailto:calsify-bounces@ietf.org] *On Behalf Of > *Michael Douglass > *Sent:* Saturday, April 24, 2021 10:07 PM > *To:* Calsify > *Subject:* [calsify] iCalendar Series draft > > At the last joint call there were a few questions and proposals... > > *** Why standardize? *** > > One was something like "why standardize this -couldn't it just be a > reimplementation of recurrences". > > I guess the flip reply is why standardize anything? More specifically > though - how would a client store a series definition or transport it > from one service to another? > > *** Why the new SRULE etc properties *** > > There's still the ongoing question of whether a series is just another > form of a recurrence - i.e. why do we need to replicate the recurrence > properties. I still feel the rules governing series should be distinct > from those for recurrences. I have had cases where a series of > recurrences makes sense (university tours comes to mind) and I don't > want to prevent that possibility. > > To enlarge on the university tour (for prospective students). As I > recall the tours were identical on each day they occurred - something > like every hour. There was some sort of pattern to the actual days > allocated for the tours. At the time I felt something like recurring > recurrences would work. > > I don't see this is a significant complication. Simply duplicating the > relevant properties with mostly the same semantics and value types. > > *** Template - not master *** > > This is a good idea I'd like to extend. I'm inclined to see this as > something distinct from series - that is a template could be used for > anything. > > Of course - for a template to be useful it needs some variable parts > adn it may be enough to just list the properties that MUST be defined > > If we define a new TYPE and REQUIRED property we could have a template > that looked like: > > BEGIN:VTEMPLATE > TYPE:EVENT > REQUIRED:DTSTART,DTEND|DURATION > > END:TEMPLATE > > Of course a template could be provided completely filled in and that > could take the place of the series master, e.g. > > BEGIN:VTEMPLATE > TYPE:EVENT > DTSTART:20210315 > DURATION:T1H > SRULE:... > > END:TEMPLATE > > I see templates being useful for events that occur irregularly but > with a consistent structure - e.g. we always have a group meeting for > 1 hour with a known set of attendees but there's no particular pattern > to when. > > *** Self-generation *** > > One part of the series draft is how many instances are generated ahead > of time. This came from a discussion long ago. With many recurring > events it doesn't make much sense to create an actual instance more > than a few weeks in advance. Many room booking systems have a booking > window of a few weeks and there's not much point in having attendees > agree to attend more than a few weeks out anyway. > > I think this feature is really separate from series - it could just as > well be applied to recurrences. > > *** Proposed changes *** > > 1. Come up with a separate draft defining templates. > > 2. Change the series draft to use a template rather than a master. > > 3. create a separate draft for the parts which define how to limit the > generation of instances in advance. This would show how to apply it to > recurrences and to series. > --------------0B9C259DC9C374860FC6D36D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 4/26/21 20:20, Tim Hare wrote:

“I still feel the rules governing series should be distinct from those for recurrences”
“Simply duplicating the relevant properties with mostly the same semantics and value types”

NOT a criticism, but a question:  where and how would a series differ from recurrence?  If it doesn’t differ significantly, then the cost of implementation may exceed the benefit

Recurring events are treated as a single resource - that's how they are defined - all instances and the master have the same uid. Long running instances with many overrides get very large.

Rather than try to redefine how recurrences are defined and handled - which is going to lead to all sorts of backward compatibility issues - I came up with a different approach - each instance looks like a separate event - apart from the present of the new relation which ties it back to the 'master'. Older clients - in fact most clients in the future - can treat them as regular events.

This better matches what happens with public events for example - museums, art galleries etc have a series of events - lectures, public days etc, which occur regularly but each instance is different. Standard recurrences work fine until you start changing every instance.

As for the cost of implementation - it's pretty low.


Tim Hare
Interested Bystander, Non-Inc.

 

From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of Michael Douglass
Sent: Saturday, April 24, 2021 10:07 PM
To: Calsify <calsify@ietf.org>
Subject: [calsify] iCalendar Series draft

 

At the last joint call there were a few questions and proposals...

*** Why standardize? ***

One was something like "why standardize this -couldn't it just be a reimplementation of recurrences".

I guess the flip reply is why standardize anything? More specifically though - how would a client store a series definition or transport it from one service to another? 

*** Why the new SRULE etc properties ***

There's still the ongoing question of whether a series is just another form of a recurrence - i.e. why do we need to replicate the recurrence properties. I still feel the rules governing series should be distinct from those for recurrences. I have had cases where a series of recurrences makes sense (university tours comes to mind) and I don't want to prevent that possibility.

To enlarge on the university tour (for prospective students). As I recall the tours were identical on each day they occurred - something like every hour. There was some sort of pattern to the actual days allocated for the tours. At the time I felt something like recurring recurrences would work.

I don't see this is a significant complication. Simply duplicating the relevant properties with mostly the same semantics and value types.

*** Template - not master ***

This is a good idea I'd like to extend. I'm inclined to see this as something distinct from series - that is a template could be used for anything.

Of course - for a template to be useful it needs some variable parts adn it may be enough to just list the properties that MUST be defined

If we define a new TYPE and REQUIRED property we could have a template that looked like:

BEGIN:VTEMPLATE
TYPE:EVENT
REQUIRED:DTSTART,DTEND|DURATION
<a bunch of properties>
END:TEMPLATE

Of course a template could be provided completely filled in and that could take the place of the series master, e.g.

BEGIN:VTEMPLATE
TYPE:EVENT
DTSTART:20210315
DURATION:T1H
SRULE:...
<a bunch of properties>
END:TEMPLATE

I see templates being useful for events that occur irregularly but with a consistent structure - e.g. we always have a group meeting for 1 hour with a known set of attendees but there's no particular pattern to when.

*** Self-generation ***

One part of the series draft is how many instances are generated ahead of time. This came from a discussion long ago. With many recurring events it doesn't make much sense to create an actual instance more than a few weeks in advance. Many room booking systems have a booking window of a few weeks and there's not much point in having attendees agree to attend more than a few weeks out anyway.

I think this feature is really separate from series - it could just as well be applied to recurrences.

*** Proposed changes ***

1. Come up with a separate draft defining templates.

2. Change the series draft to use a template rather than a master.

3. create a separate draft for the parts which define how to limit the generation of instances in advance. This would show how to apply it to recurrences and to series.

 

 

 

--------------0B9C259DC9C374860FC6D36D-- From nobody Mon Apr 26 22:06:43 2021 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 8D7CE3A0AF9 for ; Mon, 26 Apr 2021 22:06:41 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=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 N7KJSA_j3bRI for ; Mon, 26 Apr 2021 22:06:37 -0700 (PDT) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 08C8B3A0AF4 for ; Mon, 26 Apr 2021 22:06:36 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id ef17so22776882qvb.0 for ; Mon, 26 Apr 2021 22:06:36 -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-transfer-encoding:content-language; bh=XLMMZTmsoIF8jWOyWPP3dNzOzpJGH1ey2K/kCQ6ct8U=; b=dhW8Qf/3/lhD3llCgA07DHKriqDQDHb/nIwkhY7owZ7Ba87uUqWbUjG0Nnsi/JflUl 0fZAUG4aV/1O1qgx2SRyJzEQGhk7Pu2HWaBMLVMO8O6U4Wv/i6cwtDtA/wvIBqYaouQH dMbhWekngiBJ1dCl5KGsZqKuFymzbhfzrOMPhNdOaxrjHzeiwIqbgywma4Ok027tqnUY igV2fjeulxkI5T88i3OH/gKTFKQ4VaCu+Rnmr0/LpdJoaN+pbV/8Uopw/EDYJKBKpLaP BCo4y390ipC1QhUktXNwAqov14NM5ujTT342AfCNJV1mqsuQ4Al0YKxzW4k7N6PQ4H2H Pkdg== 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-transfer-encoding :content-language; bh=XLMMZTmsoIF8jWOyWPP3dNzOzpJGH1ey2K/kCQ6ct8U=; b=ssNbVTav6rUS0viU4XLZjozo2aKZJLBceuybALJSRtEmMdkz1Two777wprBpZP/t5J tyqlT23XCgV4dmNGdD/8oU71M2jjkQsffBZhyZv92yfvnbla2JrI1/Dz+DnoD7J6TmMK Bo5n4xg/YBCPirjXMYnYqqVU1ac4gh5z31y+nNfARrsdHZ3ceuQ0He3vJ67EAaulKFKS n6Fh67SlD3SxRMVBC8EkAI757r51uLLKXUbxCBz/LwXFBSxlJ1IfygOb8yYGteKmQk1r 29fXAlN1lm/q04daf5+2oDd5TqUiF0BMgEDZTrb03ekVXFkwDpzzQ0ZxR8GBlNTINHLw fReA== X-Gm-Message-State: AOAM532IPYyuzAgBFCW+vOsxl4mNjvMy1mIYYMAUDsLGiEG+7df16Vp6 xrg9/gzDW/OMHzIxRW8qQZR1DLvUWg0= X-Google-Smtp-Source: ABdhPJyoeC1wqbkuxJFyYuuUjXSA/4JHgHKpvkOmCOwlXQeZdH8n5KFO3fDgXJ5tlVlXUEm86B4GCA== X-Received: by 2002:ad4:4c49:: with SMTP id cs9mr14454232qvb.43.1619499993978; Mon, 26 Apr 2021 22:06:33 -0700 (PDT) Received: from MacBook-Pro-2019.local (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id b3sm2188683qkd.29.2021.04.26.22.06.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Apr 2021 22:06:33 -0700 (PDT) To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , calsify@ietf.org References: <161221753429.6318.13830461705241642805@ietfa.amsl.com> From: Michael Douglass Message-ID: <86071c1f-7d86-82c0-3a85-097c9eb454b5@gmail.com> Date: Tue, 27 Apr 2021 01:06:32 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-subscription-upgrade-03.txt 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, 27 Apr 2021 05:06:42 -0000 Sorry - looks like I missed this... On 2/22/21 13:03, Дилян Палаузов wrote: > Hello, > > my messages to calsify@ietf.org about draft-ietf-calext-subscription- > upgrade from 6th October 2020 are not tackled yet. > > These were also not addressed in draft-ietf-calext-subscription- > upgrade-03 . > > I am against introducing STATUS:DELETED, as I do not see how it dяffers > from STATUS:CANCELLED. They are different: STATUS;DELETED is equivalent to a 404 status - the event simply doesn't exist. In the context of this draft it means it was actually deleted from the server since the last time we checked. What a client chooses to do at that point is up to the client. STATUS:CANCELLED is just that - the event is still out there, it's been marked as cancelled and should be displayed to the user as such. A STATUS:CANCELLED event will reappear if it's changed in any way. A STATUS;DELETED will (should) never reappear - it's gone. Certainly a client may choose to display a deleted event as cancelled but that's a different issue.. Also the 'client' may not be displaying anything - it may be an aggregator passing events along. It needs to know that an event is gone. > > About draft-ietf-calext-subscription-upgrade-03: > > Section 2 Introduction: > >> The only available option for updating that resource is the usual > HTTP polling of cached resources using Etags. > > Is Last-Modified interchangeable with ETags? I guess I should just remove the reference to Etags. CalDAV only references ETags. Last-Modified might be an options in other protocols. > >> The use of subscription upgtafe may help reduce > typo. fixed. > > 4.2. Deletions > What purpose does delivering skeletons, empty deleted items? To provide a valid parseable component. Stripping out all the possibly large properties reduces the size > >> The receiving client is free to remove the entity or update it's > STATUS property. > It's → Its. Fixed > > 5.1. Redefined Status property > This section is not adjusted for the DELETED value: the included > examples have no added value. And I'm not sure now if I should have done this as a full redefinition. I think the text should have been more along the lines of just defining a new value. I can add an example as well. > > 8.2. subscribe-caldav >> for example to determine if sync-report is supported. > Please spell DAV:sync-collection report, as the report is not called > literally “sync-report”. Done > >> The URL MAY include some form of token to allow write access to the > targeted collection. The client must check it's permissions to > determine whether or not it has been granted write access. > > I do not get this “token may be included” part. Can you provide > example what this is supposed to mean? It's entirely up to the server- it may wish to provide a unique token as part of the url - given the following section this may not be necessary. > It's → its. Done > > 8.4. subscribe-webdav-sync > Does it require authentication or not? What is the opposite option? It only supports DAV:sync-collection but that doesn't preclude a challenge for authentication. > > I propose: > - determine using OPTIONS call, whether WebDAV/CalDAV are supported > - comminucate over GET whether authentication is > necessary/optional/disabled. Some services choose to place their subscriptions on a different service to their caldav service. An OPTIONS call would not reveal any possible alternative. The point of this spec is to allow service providers to redirect clients to any other service that provides a better protocol. For example the subscribed collection may be stored as a static file updated periodically by the service. I'm not sure what you mean by using GET. Some services only challenge when an operation is attempted that REQUIRES authentication - e.g. a PUT. I don't agree with that approach but it's out there. The downside of that approach is that queries may return different results before and after authentication. This spec allows the service to provide the location of an authenticated end-point if it differs from the unauthenticated one. We could provide some sort of capabilities document but that's a whole other spec. https://tools.ietf.org/html/draft-douglass-server-info-03 > > Greetings > Дилян > > On Mon, 2021-02-01 at 14:12 -0800, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Calendaring Extensions WG of the IETF. >> >>         Title           : Calendar subscription upgrades >>         Author          : Michael Douglass >>         Filename        : draft-ietf-calext-subscription-upgrade-03.txt >>         Pages           : 15 >>         Date            : 2021-02-01 >> >> Abstract: >>    This specification updates [RFC5545] to add the value DELETED to the >>    STATUS property. >> >>    This specification also updates [RFC7240] to add the subscribe- >>    enhanced-get and limit preferences. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-calext-subscription-upgrade/ >> >> There is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-ietf-calext-subscription-upgrade-03.html >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-subscription-upgrade-03 >> >> >> 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/ >> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Wed Apr 28 23:26:20 2021 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 1EF8E3A3224 for ; Wed, 28 Apr 2021 23:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.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=oAfK0We7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Igl25s0q 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 bKrO27vFFVzl for ; Wed, 28 Apr 2021 23:26:12 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACCD83A3228 for ; Wed, 28 Apr 2021 23:26:12 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8019F5C00F9 for ; Thu, 29 Apr 2021 02:26:11 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Thu, 29 Apr 2021 02:26:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=Tz7SbG/ zkz0xFdeIvIPaUs85+W5JAbv459cahRoUHf4=; b=oAfK0We7QdF69XUMFt1lyN6 R+/qoBGB3EpRSFIPwtR7pHR11SfuzKd6lEjp3iQLtLxZcimDkY9nYl0/SeecTPzv qaH4JylteNgb4FvWguqOrYKjxdDlDHqtWj0UImcTw9zLOCH7fqu1KXbp3KuwiNyp PS9nHWzWAMbLqHSBDfZkMwsdmhfY9QA8PuuyhCbgJLa90y5yvfhb3jpb5r+ZsR1b 6z1z9OvAJLePG/stH3EjX72Rk+nTohNHqO1O4tOKlW7Yc9gOWURY8vmu2p1iyL1+ 6E6PZqMpaoc94dXuIJYCw2Fx2hjRk2jpP3QIgJ0+0ZlQX26/lUh8T0/lq2B1tpA= = 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=fm2; bh=Tz7SbG /zkz0xFdeIvIPaUs85+W5JAbv459cahRoUHf4=; b=Igl25s0qzJPBMMSLiPZ9un Jq1OrgFr2arkvg/HkN/erZIgTPvEa2UrH6YgHGgHZYsZVFijG81jZr7u19/9MMne F0WHUa/hqNedUVzJqKXVo2DmJv4jo5Q+umyj4wHQorJcojdhQtJmtFz3qHnku1bZ gA1QM8VTVASrU+PYD605FaRPd1owDrdf/+ur3vr2ua+I+tdddkxVJrc4pG/C0vGm uyWVtIvUO80KvFXaZcDwRbPjrE88wZUuor1IRTyc0KCTufHp9d2vGh3lnsgG4Vqe x94zz2y3NzuT12IU98mgWfDMsnCArRho92V+EpLwNleNMWS0q4VHtmO2PODVAxjQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddvfedguddtiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevvdetvddule ekhfeghfetfeettdelhfehfeevffevleekuddtudffieevjeevhfenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1CAB5260005F; Thu, 29 Apr 2021 02:26:11 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-417-gd9086194d0-fm-20210426.001-gd9086194 Mime-Version: 1.0 Message-Id: In-Reply-To: <0331f674-dc29-5795-c9d2-93efb0fcef61@gmail.com> References: <0331f674-dc29-5795-c9d2-93efb0fcef61@gmail.com> Date: Thu, 29 Apr 2021 16:26:10 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=89b7c385d04a4fb38d71cb02afe169a4 Archived-At: Subject: Re: [calsify] iCalendar Series draft 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, 29 Apr 2021 06:26:18 -0000 --89b7c385d04a4fb38d71cb02afe169a4 Content-Type: text/plain On Sun, 25 Apr 2021, at 12:07, Michael Douglass wrote: > *** Why standardize? *** It was a bit more specific than that. I was concerned that to me the current proposal: * Doesn't seem todo enough to be really interoperable. It doesn't define who generates the events and when. Generation is an action rather than a data, so this really needs to be a CalDAV/JMAP Calendars extension, not just a data format extension. * Is overly complicated in the data representation. Reproducing all the recurrence properties as SRULE etc. seemed needlessly complicated to me. And using one of the events as both an event and the template for generation seemed a mix of concerns. I like the idea though. I think it could work like this: * We define a property (e.g. `seriesId`) for events generated in a series. Clients that understand this will know that these events are related. Clients that don't can happily ignore it. * Series are generated on a server. We define a CalDAV extension for servers to advertise that support this. * To configure series generation, you store a new component type (e.g. VTEMPLATE) into a calendar. This can contain the same properties as a VEVENT, so we don't need to define many new ones: just the ones about generation. Clients that don't support the extension will just ignore these components so won't interfere, but will still allow users to read and edit the generated instances perfectly (which are just regular VEVENTs). * The new properties we need would be just to configure how many instances to generate in advance (either by date, e.g. two weeks in advance, or by number, e.g. max 2 events from now). If you don't add any of these properties, you still have a template that could be manually used in clients that support templates. * The server would generate the events by doing the normal recurrence rule expansion, but strip the recurrence properties from the VEVENT output; they would be regular standalone events, with their own UID. Other than that all properties in the VTEMPLATE would be copied over. I think that's most of it. Neil. --89b7c385d04a4fb38d71cb02afe169a4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Sun, 25= Apr 2021, at 12:07, Michael Douglass wrote:
*** Why standardize? ***

It was a bit more specific than that. I was concerned that to me = the current proposal:
  • Doesn't seem todo enough to be re= ally interoperable. It doesn't define who generates the events and when.= Generation is an action rather than a data, so this really needs to be = a CalDAV/JMAP Calendars extension, not just a data format extension.
    =
  • Is overly complicated in the data representation. Reproducing a= ll the recurrence properties as SRULE etc. seemed needlessly complicated= to me. And using one of the events as both an event and the template fo= r generation seemed a mix of concerns.
I like the idea= though.  I think it could work like this:
  • We defi= ne a property (e.g. seriesId) for events genera= ted in a series. Clients that understand this will know that these event= s are related. Clients that don't can happily ignore it.
  • Ser= ies are generated on a server. We define a CalDAV extension for servers = to advertise that support this.
  • To configure series generati= on, you store a new component type (e.g. VTEMPLATE) into a calendar. Thi= s can contain the same properties as a VEVENT, so we don't need to defin= e many new ones: just the ones about generation. Clients that don't supp= ort the extension will just ignore these components so won't interfere, = but will still allow users to read and edit the generated instances perf= ectly (which are just regular VEVENTs).
  • The new properties w= e need would be just to configure how many instances to generate in adva= nce (either by date, e.g. two weeks in advance, or by number, e.g. max 2= events from now). If you don't add any of these properties, you still h= ave a template that could be manually used in clients that support templ= ates.
  • The server would generate the events by doing the norm= al recurrence rule expansion, but strip the recurrence properties from t= he VEVENT output; they would be regular standalone events, with their ow= n UID. Other than that all properties in the VTEMPLATE would be copied o= ver.

I think that's most of it.

Neil.
--89b7c385d04a4fb38d71cb02afe169a4--