From nobody Sun May 3 18:36: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 14FC23A0AFC for ; Sun, 3 May 2020 18:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 pN3Wj8_aEzxv for ; Sun, 3 May 2020 18:36:19 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 0631C3A0AFB for ; Sun, 3 May 2020 18:36:18 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id m5so9789618ilj.10 for ; Sun, 03 May 2020 18:36:18 -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=QwgeEnnHxQuqxazH3eGPoD8ASgtqJwCJQLDj1qMOlAI=; b=ggrdx8gMBOWERpUngL18fre+LDuH3ln+Z1UEg0v7BZWIV8KJqokpDxuFcNQ5Foes7v AljDgVW3z43tY6B24L/NYi6DWu7THvjiNB2BkfwK4l4hvI4SdNtqxgb5BnXoUzHnc0Lj guUS3PRXV1QS3YJBIDy85RZahdVLpj8ZQvOVgnp69cB2zdOQsedKZu97LFvQp6xf5Hch kyFoIwPLF/u9kcrDDk5/QJ5B3iQlM3D3973QlCsosOFgiRCOyHF82VYRoENXzCvrpjsZ 2WSd3vJOgASHhxzbTtBXWQkwArXvdcsa/FD+ggUiyUmPTfXGEy788DtuFSwkqzLQgxAy 5RpA== 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=QwgeEnnHxQuqxazH3eGPoD8ASgtqJwCJQLDj1qMOlAI=; b=G0q70pf+ArI6dp1DPQqetVbkTYaP5I22qnXlbNSavBPP+7/Yxtv6Gn9xuIULyc5OaQ TY1PFhODqTW9l/6PDjFforPOhN6MHqxo4mYfp+jdLhXK1V9stF3iPoS+Cg3jMmzfbeLx /Wu8SBGK4V3qzIb3GZ97Da01S7pIlEOYrvC9T1lhV2UETqd/PuJBqvH6XVQtDKi/Liiy zwqueDIeDmWTXiVjQIGYy0sgdQBnrftbuw7+sEHSj5yOvygHWNA855Eqyn9Tc4yvs3ny fkF/FkawsQlbxrNCtFi8XO3qwGVm5C8RVwNObJaMHkYH+P3s/Ynd/1peMpUMKPYfAzNm Tvow== X-Gm-Message-State: AGi0PubV8cS8VtfRDNUP/ubXmfZjE9xTNtvQd9OJpYL+9SwoUf3tU3NJ BrkQSdzWkO0S2kLBV7iHgJp1yZz8DVM= X-Google-Smtp-Source: APiQypK4drWEdKuD0gkaNKsHeU+Z1RFL8hkm9SCLHqKhgL2hsSH7PxHKLJcwUNO1HStpmRDc0PVw+g== X-Received: by 2002:a92:c687:: with SMTP id o7mr14557326ilg.260.1588556177745; Sun, 03 May 2020 18:36: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 i20sm3249055ioj.14.2020.05.03.18.36.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 03 May 2020 18:36:17 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: Date: Sun, 3 May 2020 21:36:16 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.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 COMMENT 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, 04 May 2020 01:36:20 -0000 Did we have any resolution to this? comments is only specified for timezone rules. It needs to be valid for all or some indication of how to handle them needs to be provided. I understand there is an issue in 5545 with COMMENT in scheduling e.g. is a comment meant only for the organizer? That could be tightened up i guess. Still I need somewhere to put a COMMENT From nobody Mon May 4 11:15:56 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 286F83A11B1; Mon, 4 May 2020 11:15:54 -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 bDAiQwZeVya3; Mon, 4 May 2020 11:15:51 -0700 (PDT) Received: from mail-vk1-xa30.google.com (mail-vk1-xa30.google.com [IPv6:2607:f8b0:4864:20::a30]) (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 C229B3A1187; Mon, 4 May 2020 11:15:50 -0700 (PDT) Received: by mail-vk1-xa30.google.com with SMTP id j1so30823vkc.2; Mon, 04 May 2020 11:15:50 -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; bh=rq1XqkyOde4cWcpzMBHpbZmHLhdTcE9aQAoLHtlp7es=; b=Q4g8CAB3NviCsJ2g4lBrJhvJdtOcXpsRFLES3KNm94d6fB/KixkHtEfRQT7B6DSTsy i5SxQzeH3OvFlpwyWGC3mhZJl2c1fG4jDn8h3lIHHWHRHjnP5i8k61OxDazF5yCIxl9i GzmuDImZBX8UY22UHGJU0cOXWe6GZhBKwF3TkONyDOyQql8wImKzEJsCCDdwA9BWHPJb diu3i+ecI1hqfw7JRzqUtiHoM3uzSWX4MKSA9DXkZWfxtmwDjSV7uqnzqZJUH8EpNNUx cjHRhIrNbUxPzp1yy2/Ep0H2s9RopFCqDyHFnOXvzv4vO3TkL1yXWFlJQl3lfUAHkNJU QvXA== 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; bh=rq1XqkyOde4cWcpzMBHpbZmHLhdTcE9aQAoLHtlp7es=; b=Pxj0UslkSxYm3A81wfPlb42bcdzh7W8Em034FmlhkPpoERsTUgMhoAMHa/29jUM2Pk plG4Zo336CjbNfv0O/XY+ypyDvPXq2eDRfX457DWel+34lNBXYEyPwFWXhKNdzpFPBsE pMEkT5fzLVRskRxx4gvwM7GwpHaN85Ys5C6lKNtG+4kHNi82ZIPky8nTa87K4dMbNZBW sSA5HtoMHCEOvUD1wUxdBrZj6utH23WWpxEolChhNN/dB3EQvx4rlUr/LLKw2IqKQRcW zgJ/QY5VFcXwnWsgjfjTZTD+zWg7BGtg0tvYAZ0H5/oBSKNZwwxYkgUCjQBSWJRJU9ev qrUA== X-Gm-Message-State: AGi0PuZgVWe3XWJBcbUrdUnHEGD6WyAV4BB+YuFqw+zEnkFJI//Lv2zB UKENwPF5Sb3zKBh/B9wxW0QL+jGWUGphUKN76pi+XBVG X-Google-Smtp-Source: APiQypJR6p0dTWUbWhBusbj4IiWxpe7h029zOZlFdmzO9idkaoSA23mbBMWSxcaDFCarXVYeX0Fiuq/ps0VTtTodX0Q= X-Received: by 2002:a1f:938f:: with SMTP id v137mr515513vkd.55.1588616149431; Mon, 04 May 2020 11:15:49 -0700 (PDT) MIME-Version: 1.0 References: <158857581528.28405.17372040856513106617@ietfa.amsl.com> In-Reply-To: <158857581528.28405.17372040856513106617@ietfa.amsl.com> From: Daniel Migault Date: Mon, 4 May 2020 14:15:38 -0400 Message-ID: To: curdle , tm-rid@ietf.org, IETF-Calsify , Ace Wg , tzdist-bis@ietf.org Content-Type: multipart/alternative; boundary="0000000000004578dd05a4d6850b" Archived-At: Subject: [calsify] Fwd: Reminder: Survey on planning for possible online IETF meetings 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, 04 May 2020 18:15:55 -0000 --0000000000004578dd05a4d6850b Content-Type: text/plain; charset="UTF-8" Hi, The IETF Executive Director and leadership need community input on how to handle virtual meetings. Please feel free to complete the survey. Thanks, Daniel ---------- Forwarded message --------- From: IETF Executive Director Date: Mon, May 4, 2020 at 3:04 AM Subject: Reminder: Survey on planning for possible online IETF meetings To: IETF Announcement List This is a reminder that we need the IETF community to help us plan for the possibility that one or more upcoming IETF meetings in 2020 and possibly 2021 may not be able to go ahead in person. You can help us with this by filling out the following survey: https://www.surveymonkey.com/r/5328FFJ So far we have 114 responses and we would ideally like 500 or more. The survey contains the following pages and will take 15-20 minutes to complete: 1. Welcome 2. Online IETF 107 and the subsequent virtual interims 3. Replacing a cancelled in-person meeting 4. Online meeting format and timezone 5. Replicating humming 6. Replicating the hallway environment 7. Fees 8. Thanks and anything else We run the survey in anonymous mode which means that we only see data that you explicitly provide. Thank you in advance for your help. -- Alissa Cooper, IETF Chair Jay Daley, IETF Executive Director Colin Perkins, IRTF Chair _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- Daniel Migault Ericsson --0000000000004578dd05a4d6850b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

The IETF Executive Direc= tor and leadership need community input on how to handle virtual meetings. = Please feel free to complete the=C2=A0 survey.

Thanks,
Daniel

---------- Forwarded message ---------<= br>From: IETF Executive Dir= ector <exec-director@ietf.org>
Date: Mon, May 4, 2020 at 3:0= 4 AM
Subject: Reminder: Survey on planning for possible online IETF meet= ings
To: IETF Announcement List <ietf-announce@ietf.org>


This is a reminder th= at we need the IETF community to help us plan for the possibility that one = or more upcoming IETF meetings in 2020 and possibly 2021 may not be able to= go ahead in person.=C2=A0 You can help us with this by filling out the fol= lowing survey:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.surveymonkey.com/r/532= 8FFJ

So far we have 114 responses and we would ideally like 500 or more.

The survey contains the following pages and will take 15-20 minutes to comp= lete:

1. Welcome
2. Online IETF 107 and the subsequent virtual interims
3. Replacing a cancelled in-person meeting
4. Online meeting format and timezone
5. Replicating humming
6. Replicating the hallway environment
7. Fees
8. Thanks and anything else

We run the survey in anonymous mode which means that we only see data that = you explicitly provide.

Thank you in advance for your help.

--
Alissa Cooper, IETF Chair
Jay Daley, IETF Executive Director
Colin Perkins, IRTF Chair

_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce


--
Dani= el Migault
Ericsson
--0000000000004578dd05a4d6850b-- From nobody Mon May 4 19:10:08 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 216C63A1365 for ; Mon, 4 May 2020 19:10:07 -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 TK1qt3BiGaQ8 for ; Mon, 4 May 2020 19:10:05 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 3697F3A1369 for ; Mon, 4 May 2020 19:10:05 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id q10so861471ile.0 for ; Mon, 04 May 2020 19:10:05 -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=Cq+/V2xlDlYPBGyg7Imyj06beglE/x/bs1+URWFHjCY=; b=WBbm3TW3IdFPIA1h1ni9tG0yYjph/xjdlw5l891Kk+0oxnwTDAU+4IEBcnRRYdHf4z SEVr9cLBOhjyxORk3uDObuthFlWRgbx9KpMVg0rOFpjHwpeXbydc9+AbJizNA8OlD9R4 wOPoiFlbgeFq8TilBCU9pSm94kBy6XZuuI/kq4o9Ijl65jEaBzZSRxetFZtYp3eD5pKq UfCbOkKxwZravjacGgBUdf1tnAQ9UzoEdpxwsErLVUG13UfC/dxNf2Eq+x5UbdgsDwCH dZ7+oLx693jaq87srgjp3maUJfTc++wWKTog2Lu1FOlXmk+GsUW4fbdu4WvLoeFmUWM0 fnGg== 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=Cq+/V2xlDlYPBGyg7Imyj06beglE/x/bs1+URWFHjCY=; b=beDeGFFAr8155Nxw+4N+fMjLVzll3IOgQaQSsGQilWyJh6Fmvoi6F7o964GWfrU8jt x1Uukkt8w60o+thsdTElHyis5+0mRVjhqH07CwG0V7VioAJ6GyczqJ1bC2wEZF6FXOdS gksxpr7RexTpx/wg8/qIZ02LrgxoAkI6xVMo35o0SVwYiz2hII1qKykIjI+ZSgoaT10+ O279pkTjskH1N84HgnL1SrtHQi2WLn6hZEpAl8+504RMpbKZcfTR+PmihZxOg4VGMO7s DN3GgApbJBJv19upXGkAQ7h5W/S41I5J8TW8hDgpgutRYD8wRWp8HXjPNUUMXvbXlskY /NXQ== X-Gm-Message-State: AGi0PuaOHq5B5CdY+uTonfg0dzMGcJrCUY+WJ+1aygh8tEKoGSunvjSV oIRPZxxM9OYkK5QhOJKFANfyiF91Vqs= X-Google-Smtp-Source: APiQypLQW1ja9/ot3RAC4efG/oWNOA4ZA4OzuI2DCNr7GM0c0wd4jL7B76rQECTlsuzROV2ajEsWwQ== X-Received: by 2002:a92:9e11:: with SMTP id q17mr1451640ili.137.1588644604316; Mon, 04 May 2020 19:10:04 -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 z21sm603842iog.31.2020.05.04.19.10.03 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 May 2020 19:10:03 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <31e786cd-20ae-354d-38fd-7f4137d52a9e@gmail.com> Date: Mon, 4 May 2020 22:10:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.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 priority property 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, 05 May 2020 02:10:07 -0000 In the spec this is in the scheduling and sharing section - I don't think it's explicitly either. Somebody might set it for non-scheduled or unshared events. It's also probably useful to include the 5545 text about how to represent as high/medium/low From nobody Tue May 5 23:12:50 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5B23A02BB for ; Tue, 5 May 2020 23:12:47 -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=gIbAiHZZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eyCSdHUh 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 6McA6bkFu5H6 for ; Tue, 5 May 2020 23:12:45 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E93E3A017E for ; Tue, 5 May 2020 23:12:45 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B425D5C0356 for ; Wed, 6 May 2020 02:12:44 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Wed, 06 May 2020 02:12:44 -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=Z3znBtT BLkGvZdoIRwyskZHTVHqpsE6S3x4JgcIfRDY=; b=gIbAiHZZZtVkFYv85bd71Z2 u366UVv0KwhJJpVREntt6G746/MS076/CcocFSJ4C86FLm8XwjbgbMEeSul2PoML M2nDC0LzlVOpVKTjq8+3epQH0WUsluDxtrwuF/GUoDWLmrVCc+EIC+zLTLZqAv6Z dGCX/A75HyvYBrWloM4eGGAzyArRKzol+0MANzDZHSZKLhu9JvB6njhjf8qJJOHs Y3rj9gSyXuFFEWYEwfjLUyszYVY8qZuHU+7OiIIgHTExcqu7Bv4rAUC7gKQBgpnY +3aX67+463L8qEqbkmpTl6bffNrArCixFcTZpx1tLQUWbZuA53gR1SrrZNFOwiQ= = 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=Z3znBt TBLkGvZdoIRwyskZHTVHqpsE6S3x4JgcIfRDY=; b=eyCSdHUhciUr0DoCqZLHl+ JTzC1vl1mNF7oyHB+tBZirk/m+Iz/onv6eUOD8tNbkLN/bevfdBBXSo/HvAMdloc 6Ign+g7njbkxSv/yjVFKOPSciMgkWAFNkOgYUohZ/5OnioIllFwesxmaE7tC0eer 4oey6uMgxAWGzWhG5u/oviZZ8WzbHfroXNXvnjU29qjYWSVST40fyP2pzjMCkmNX sdD4wgCh8GZsz/+q9DtFX18ntSq77yUTV+9Nca3NAoXNrnbsbsZepIQ4vi2zQYrg WbQwHEdSsbmWgvWSCTpGJT/FjMHTAyscDsLH4HRTvkWDf8wHTyXi5fCPDfXBr0fw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeejgddufedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvedvtedvudelke fhgefhteeftedtlefhheefveffveelkedutdduffeiveejvefhnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 54116180264; Wed, 6 May 2020 02:12:44 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmfuture-20200505v2 Mime-Version: 1.0 Message-Id: <5ca2a366-a144-489f-ab93-6cbd90fdb7a9@beta.fastmail.com> In-Reply-To: <31e786cd-20ae-354d-38fd-7f4137d52a9e@gmail.com> References: <31e786cd-20ae-354d-38fd-7f4137d52a9e@gmail.com> Date: Wed, 06 May 2020 16:12:44 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=7d8d4d4e25a24291ac3d110504f8d030 Archived-At: Subject: Re: [calsify] jscalendar priority property 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, 06 May 2020 06:12:48 -0000 --7d8d4d4e25a24291ac3d110504f8d030 Content-Type: text/plain On Tue, 5 May 2020, at 12:10, Michael Douglass wrote: > In the spec this is in the scheduling and sharing section - I don't > think it's explicitly either. Somebody might set it for non-scheduled or > unshared events. Maybe, but it's primary use is for scheduling (e.g. VAVAILABILITY). The section headings are just there to help guide you to the properties you need; I think it's fine where it is. > It's also probably useful to include the 5545 text about how to > represent as high/medium/low Maybe. This text looks like it was legacy at the time of 5545; who is it for now? More broadly, mapping from a different system is surely going to depend on what the priority levels were used for in that system and how they will be used in the new one; I don't think this text is particularly useful. Neil. --7d8d4d4e25a24291ac3d110504f8d030 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, 5 May 2= 020, at 12:10, Michael Douglass wrote:
In the spec this is in the scheduling and sh= aring section - I don't 
think it's explicitly either= . Somebody might set it for non-scheduled or 
unshare= d events.

Maybe, but it's prim= ary use is for scheduling (e.g. VAVAILABILITY). The section headings are= just there to help guide you to the properties you need; I think it's f= ine where it is.

It's also probably useful to include the 5545 text = about how to 
represent as high/medium/low
<= /blockquote>

Maybe. This text looks like it was legac= y at the time of 5545; who is it for now? More broadly, mapping from a d= ifferent system is surely going to depend on what the priority levels we= re used for in that system and how they will be used in the new one; I d= on't think this text is particularly useful.

Neil.
--7d8d4d4e25a24291ac3d110504f8d030-- From nobody Tue May 5 23:34: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 579B63A0816 for ; Tue, 5 May 2020 23:34:38 -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=tv9KTVUz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kJ6mmucX 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 bfCuZObINbok for ; Tue, 5 May 2020 23:34:33 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BA6F3A07BD for ; Tue, 5 May 2020 23:34:32 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 878A85C0280 for ; Wed, 6 May 2020 02:34:31 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Wed, 06 May 2020 02:34:31 -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=e4cOJOn s8iesmJRjJNNvPuzBSL1eAY1cxK15ujHlqdM=; b=tv9KTVUzpI8dCEq4PztQmzL 8Hpd92kCvOoAjl1hmir0jq3AFKrKuwDxWyoyTCmaM4zORoZ2VyhtSddTYgS5TYRL FUDN3AOc3/5kl326v1+nldl28VlwXLYWOcwrTEBUSmUA5vb6iUa+AdZGAwF6rG3s 2pTwYme41iWtebI0UmbBNd+jSOfiYdKAP/qbPX9CampvC49NvbMU5c2Bqq06+KI9 aIuatIMb9QqEIEHp0WOC1xody/o2cRlPrjhf1nQoNJD0qxgdc9ymEaqyfPslEJs/ kxsbzEuGcoWamhXSp3YZz0nwx/8kwgtR0MwUgNxHTALI5pgrRuHMROWLCsfZHzA= = 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=e4cOJO ns8iesmJRjJNNvPuzBSL1eAY1cxK15ujHlqdM=; b=kJ6mmucXoCpuC5j8Gf5ISV JnW5U9bY3tmEzLOoyDEEPNxi5i/tHYLilEAzXHRWX62NGVblVAIkIlJ8Bq+wR0JJ 2B8o2EvKgeKSM2aCxvPk0Nd9OzrHjCrU7AD0asusjyeEpCHY6pCYWp6MYBWrHZmr o3OLrxTBe5foKU8gnDKaYVgskP/Nva1X6BVavRpG8awff7EmPjz/kw4Q2oUEZuCC 7e1dU5EMDgzY3oUGOzj+MtC3cDe5Mw30BUAIdUytj2UbKqDWy1I3Z7u9PJeMT6WG OeXL68YNHh6U1WAnzaoJmrcX+YKBdOeshGMyPN81ofYWVwgj+o/MGQ3B8T7QHv1w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeejgddufeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvedvtedvudelke fhgefhteeftedtlefhheefveffveelkedutdduffeiveejvefhnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4903D180274; Wed, 6 May 2020 02:34:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmfuture-20200505v2 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 06 May 2020 16:34:30 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=c2eefa951c43474880715085d14fad29 Archived-At: Subject: Re: [calsify] jscalendar and COMMENT 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, 06 May 2020 06:34:45 -0000 --c2eefa951c43474880715085d14fad29 Content-Type: text/plain On Mon, 4 May 2020, at 11:36, Michael Douglass wrote: > I need somewhere to put a COMMENT We can add a simple plain text comment property; I'll do that. Note, we also have the participationComment property in the Participant object to store the comment you received in the last RSVP response. Neil. --c2eefa951c43474880715085d14fad29 Content-Type: text/html
On Mon, 4 May 2020, at 11:36, Michael Douglass wrote:
I need somewhere to put a COMMENT

We can add a simple plain text comment property; I'll do that. Note, we also have the participationComment property in the Participant object to store the comment you received in the last RSVP response.

Neil.
--c2eefa951c43474880715085d14fad29-- From nobody Tue May 5 23:42: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 991483A05DE for ; Tue, 5 May 2020 23:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=fa7R2+L1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=z7gN34lV 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 CxD6-hNicpQ1 for ; Tue, 5 May 2020 23:42:18 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C15D3A05AC for ; Tue, 5 May 2020 23:42:18 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 752C75C0313 for ; Wed, 6 May 2020 02:42:17 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Wed, 06 May 2020 02:42:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=ZFIZqL+ eOsWetOMYm1eCJZNF4BvwEmZhL0QUw4tGV6s=; b=fa7R2+L14Z6mS+wDPTWm/m0 a/T/zXqIFCiLxf/+edUIBqmWy1mkAarCo/EapIaWdhcLDKZ7God03OFIhI3QkrZg n5s7mMDxeS96iCNrGEruCED4kv+B9PER9ea+/g9UwyLqlRtJFks/yAkY1lYa5iAZ mhfMWFkoCkFa0YdcbzKwUImgXVh/auAs5etqprsUZfZLTtzCczBwDtaBeZRQGJWA an1ML+R8kuhkld6b9HrWlXbsSInbQTsOwjaeiZOchH3Jqfab/lp7ChyKQRiL+7xa 3G2oH++LirxNyiBbRO/SZywI2uVPy1MvhtPtU4YHef345Ii/Bq1Ks/PUW1gs2HA= = 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=ZFIZqL +eOsWetOMYm1eCJZNF4BvwEmZhL0QUw4tGV6s=; b=z7gN34lVhhDY/JfARhofeV GyXg1TPljtdP/Rt8qbVIUIQqZlv6wdv+FGrjVmlrgIBO+UkNdN91Q+n1c+mZXA/+ GRErY85HVGaLEk+T+ItR2SDTJTWF4ogwiuCMepGGni+GUzJVV/jMtfzF9jrFEvJz Bw8FsomnISZ13QNoxg36zXy8qIwlMDvxn2vFuzyj14zMEuD8ds62Gp+TVsfmZg+4 AMQJ80K6wpuo2F14SpT+uFq+wLOUUrYC5RYoDJNK4XsLTKvGUp55p7yYPg6b7rum 9VNqf7FWACEF0idup5pookZpPnOhJbTZ1ONSAbKAChrUqMNSG3Q7i3EIbpihr0kg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeejgddufeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvedvtedvudelke fhgefhteeftedtlefhheefveffveelkedutdduffeiveejvefhnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2FC1F180278; Wed, 6 May 2020 02:42:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmfuture-20200505v2 Mime-Version: 1.0 Message-Id: <0da3183f-c757-47bb-81fc-638e4bc45f68@beta.fastmail.com> In-Reply-To: References: Date: Wed, 06 May 2020 16:42:16 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=c367b2dfc816421fb37caf81eb0ef5aa Archived-At: Subject: Re: [calsify] jscalendar and COMMENT 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, 06 May 2020 06:42:20 -0000 --c367b2dfc816421fb37caf81eb0ef5aa Content-Type: text/plain On Wed, 6 May 2020, at 16:34, Neil Jenkins wrote: > We can add a simple plain text comment property; I'll do that. Note, we also have the participationComment property in the Participant object to store the comment you received in the last RSVP response. Now I context switch this a bit more back into my memory: the intention was that you would put your comment directly in your Participant object when sending an RSVP (so if you had an iCalendar with METHOD=REPLY and a COMMENT, you would put that comment in the participant object of the CU sending the reply). Is there anywhere else this is really used? Because otherwise I think this just needs to go into the iCalendar mapping document. Neil. --c367b2dfc816421fb37caf81eb0ef5aa Content-Type: text/html
On Wed, 6 May 2020, at 16:34, Neil Jenkins wrote:
We can add a simple plain text comment property; I'll do that. Note, we also have the participationComment property in the Participant object to store the comment you received in the last RSVP response.

Now I context switch this a bit more back into my memory: the intention was that you would put your comment directly in your Participant object when sending an RSVP (so if you had an iCalendar with METHOD=REPLY and a COMMENT, you would put that comment in the participant object of the CU sending the reply). Is there anywhere else this is really used? Because otherwise I think this just needs to go into the iCalendar mapping document.

Neil.
--c367b2dfc816421fb37caf81eb0ef5aa-- From nobody Tue May 5 23:57: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 55AEF3A074D for ; Tue, 5 May 2020 23:57:55 -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=PV0KSwKI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UnV1lO6K 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 jM4-vM8TQCES for ; Tue, 5 May 2020 23:57:51 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14FCE3A0768 for ; Tue, 5 May 2020 23:57:51 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 63DE35C02B6 for ; Wed, 6 May 2020 02:57:50 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute7.internal (MEProxy); Wed, 06 May 2020 02:57:50 -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=KJWv2/e GzukGL9JAbaJenZTTsuNlW1xTYz58IaIqes4=; b=PV0KSwKIzkgluVboKl92T91 mIE0JHyxdlMPLIUZwaBS5RqDpXhMljW5svlDWadtvOslYaJIdMWfoH9FvjxcF0yO /uMm9XjQ2LkM2eHhAyPgLylSMP6cM/QcbjRVYxgX5pRxoaTac2/4Qj59CaPnN2Ms O77ImASjDOxryxPE+pdGyzRiNBRdTpjFq0uNepioGgZe+ZNCOJIlr4adgiToMOMi Iyb44JZ/dqc6+/Lha1YrV/EmSXfPns93/rlk+obM+MbEYQTgV5AlRdPZKxxuu0+j TGhBnej1Gv/bWxSxU7x2eQsghiAOWHBQXf6wI3cDqGA8GeA1tdaNny/ldKi2fUg= = 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=KJWv2/ eGzukGL9JAbaJenZTTsuNlW1xTYz58IaIqes4=; b=UnV1lO6KRwnI+lySghM32Z Hl6Dvyrn+cAeJsr4LHcPJLpN1TJWZe6gGVL5UTNcoiWmfLx7sB97MHiKoSPc5CXb rwS3xxDD/qsl3UYXYXTvZzlQ2DJK9rV0WQgWeiChfaR6HqXmgKDXY0uaEOOJfY1E WKLlzFCh2m2DnSyk9Nvg52bfnrt0MiCKZ5YcmigBKM2XgPATAGjUS7JWL2P2NzUr xRj11kDq7avb61NrL54J4bUeFbsDR4qMj/0i7tdB7NnYfWDjkzTuDAmx/VYh3QTm qJud27uD81kuZJFUyPHG4M/HmQnWlPzP5l7Y1kgj7dk+cIpKTRQEahZ0gEAVFc4A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrjeejgddufeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepheeguedvtd ekhfetgfeufefgvdeuteegfeefleehvddugeejjefhteeugfevveeinecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0C44B180281; Wed, 6 May 2020 02:57:50 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmfuture-20200505v2 Mime-Version: 1.0 Message-Id: <1d5e3573-ccb4-47d6-b18a-c44559e97596@www.fastmail.com> In-Reply-To: References: Date: Wed, 06 May 2020 08:57:29 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=395b08194efc4b5fbbf1922ed52e4d8e Archived-At: Subject: Re: [calsify] jscalendar and COMMENT 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, 06 May 2020 06:57:56 -0000 --395b08194efc4b5fbbf1922ed52e4d8e Content-Type: text/plain On Wed, May 6, 2020, at 8:34 AM, Neil Jenkins wrote: > On Mon, 4 May 2020, at 11:36, Michael Douglass wrote: >> I need somewhere to put a COMMENT > > We can add a simple plain text comment property; I'll do that. RFC 5545 allows for multiple COMMENT properties per calendar object. The TimeZone in the JSCalendar defines the comments properties as an array of String. I think we should do the same for JSEvent and JSTask (probably also for JSGroup). Cheers, Robert --395b08194efc4b5fbbf1922ed52e4d8e Content-Type: text/html
On Wed, May 6, 2020, at 8:34 AM, Neil Jenkins wrote:
On Mon, 4 May 2020, at 11:36, Michael Douglass wrote:
I need somewhere to put a COMMENT

We can add a simple plain text comment property; I'll do that.

RFC 5545 allows for multiple COMMENT properties per calendar object. The TimeZone in the JSCalendar defines the comments properties as an array of String. I think we should do the same for JSEvent and JSTask (probably also for JSGroup).

Cheers,
Robert

--395b08194efc4b5fbbf1922ed52e4d8e-- From nobody Thu May 7 19:14:06 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 4F2443A0C0C for ; Thu, 7 May 2020 19:14:04 -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 DTjehy8f6ZQV for ; Thu, 7 May 2020 19:14:00 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 C99A23A0C05 for ; Thu, 7 May 2020 19:14:00 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id e9so310614iok.9 for ; Thu, 07 May 2020 19:14:00 -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=az0zDtFl1+Q1q9QkLu+GWZgKQ15B3MW4eJIUW0nlqV4=; b=fHWMrczVNAK1gMdz9T/Zf+0VCUNkvzODO8iw5vhn5Wdybc0pcf6GB8FF17duNAspFo BckFpgszYQOhzu/UxbJx3cHHqPT2j5SnHbzKo4uprqMhUF/Wr6FWMNd+KUGiNN2wz1ZZ eAY+2Qi9nPpLnyWvVAP8vVV1suXTZq/5gg/fJYDXkRHiXDn6/x/M99ZYftE4PsBHhQa/ Nvtr+h2NoY0yOjZr8lyck6WCRYWq8OCW5YV8JcZGUV8gUD8IypRGPZkk9YlYm06GKqz+ nJiR0VSN7JDuxNHSWexzJOE82PyJbh66YAa6U5N2z0mEEMSSnocL++w9dYFS4JcOfuMv lkNw== 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=az0zDtFl1+Q1q9QkLu+GWZgKQ15B3MW4eJIUW0nlqV4=; b=W1Lz+r+DO9FOOe7laFwazN1IJX3vtzhOi6eHSXCV0fRr6wLv8V7FIeSo9HEpYl0Yvb zwqYoBtow0hoQaGXPoRUfg7Xp+vEojTBFk3xRh8A8q+1emyEYDQcLN7KszUMLXD44J+5 Xb1u/DfB+gJ2tEkVJhLQqDbSTRhJDTHl4+lwc/gsPcs4CytI+ZXhEXmI4EDA7c5xT/w4 AX6uznt4Pa0as/nYeWxaX3w/aOSnWLpwe7yvKczYo5bBVpbgUqwv2mb1lKG4ESWgsGNW lvbftKnrKWVD6yAbB1oz2eiDtusqAxU7wE5sMlUIeHiOFU8f0azp0RKf3+9DChOStooz ZNkw== X-Gm-Message-State: AGi0PuY/LgoZck1Tmyru66kcQBP4s5LGOAyWJGZiQ788tg0lxcfRXbPI iCQrE9CWehCmfnDqRuA0V+ifuxGCc8o= X-Google-Smtp-Source: APiQypL2WohbP/v05gB03SSdvERgdL+2REhGRocqNtKbPklR2FW0K2C+TGGjWRaKpDT3OCWPxgkBHQ== X-Received: by 2002:a05:6602:d:: with SMTP id b13mr375777ioa.176.1588904039419; Thu, 07 May 2020 19:13:59 -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 l13sm76759ilo.46.2020.05.07.19.13.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 May 2020 19:13:58 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <3044ad0c-6b65-7ad8-456c-ed3a76cf110e@gmail.com> Date: Thu, 7 May 2020 22:13:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------DA27F0DA4F3292C202261E30" Content-Language: en-US Archived-At: Subject: [calsify] jscalendar - participants and contacts 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, 08 May 2020 02:14:05 -0000 This is a multi-part message in MIME format. --------------DA27F0DA4F3292C202261E30 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit To try to summarize... My concerns with this are: 1. There's no obvious place at the moment to put contacts 2. After 10 years with eventpub I'd like to ensure that jscalendar is compatible with that draft. After much discussion we'd come to state we are in now - a PARTICIPANT component that can represent people/groups etc that participate in the event - not necessarily attendees, cold be spectators, coaches, scenery shifters, piano tuners. This reflects some practice I'd seen and which others had been emulating through x-properties and such. The eventpub participant doesn't try to take on all the features of attendees simply for backwards compatibility. For attendees a PARTICIPANT component provides additional data but clients not aware of the PARTICIPANT will continue to work. I'm ok with treating the jscalendar "roles" as equivalent to the eventpub PARTICIPANT-TYPE but it also seems closer in some ways to the jscalendar "kind". I do think we could use the linkids as a way of referring to e.g. a vcard to provide more detail. In both jscalendar and eventpub we need a plain text property to hold simple plaintext values - e.g a phone number. Eventpub already has the DESCRIPTION property - could we add that to jscalendar participant? With that in place - not only could we map the current CONTACT property but also be compatible with the eventpub PARTICIPANT component. In passing - Robert suggested just making some of these a simple link - eventpub already went through that iteration and it was soundly rejected -  key calendar properties should not be represented as just linked data was the argument. Some examples (from 5545): CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234 ... "participants": { ... "dG9tQGZvb2Jhci5xlLmNvbQ": { "@type": "Participant", "roles": { "contact": true }, "description": "Jim Dolittle, ABC Industries, +1-919-555-1234" }, ... } CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\, c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\, +1-919-555-1234 ... "participants": { ... "dG9tQGZvb2Jhci5xlLmNvbQ": { "@type": "Participant", "roles": { "contact": true }, "linkIds": { "dG9tQGZvb2Jhci5xlLmNvbQl1": true }, "description": "Jim Dolittle, ABC Industries, +1-919-555-1234" }, ... }, "links": { "dG9tQGZvb2Jhci5xlLmNvbQl1": { "@type": "Link", "href": "ldap://example.com:6666/o=ABC%20Industries,c=US???(cn=Jim%20Dolittle)", "rel": "what?"  } } CONTACT;ALTREP="http://example.com/pdi/jdoe.vcf":Jim Dolittle\, ABC Industries\, +1-919-555-1234 Much the same but needs a different "rel" --------------DA27F0DA4F3292C202261E30 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

To try to summarize...

My concerns with this are:

1. There's no obvious place at the moment to put contacts

2. After 10 years with eventpub I'd like to ensure that jscalendar is compatible with that draft.

After much discussion we'd come to state we are in now - a PARTICIPANT component that can represent people/groups etc that participate in the event - not necessarily attendees, cold be spectators, coaches, scenery shifters, piano tuners.

This reflects some practice I'd seen and which others had been emulating through x-properties and such.

The eventpub participant doesn't try to take on all the features of attendees simply for backwards compatibility. For attendees a PARTICIPANT component provides additional data but clients not aware of the PARTICIPANT will continue to work.

I'm ok with treating the jscalendar "roles" as equivalent to the eventpub PARTICIPANT-TYPE but it also seems closer in some ways to the jscalendar "kind".

I do think we could use the linkids as a way of referring to e.g. a vcard to provide more detail. In both jscalendar and eventpub we need a plain text property to hold simple plaintext values - e.g a phone number. Eventpub already has the DESCRIPTION property - could we add that to jscalendar participant?

With that in place - not only could we map the current CONTACT property but also be compatible with the eventpub PARTICIPANT component.

In passing - Robert suggested just making some of these a simple link - eventpub already went through that iteration and it was soundly rejected -  key calendar properties should not be represented as just linked data was the argument.

Some examples (from 5545):

CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234

...
"participants": {
...
  "dG9tQGZvb2Jhci5xlLmNvbQ": {
         "@type": "Participant",
         "roles": {
           "contact": true
         },
	"description": "Jim Dolittle, ABC Industries, +1-919-555-1234"
       },
...
}


CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\,
 c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\,
 +1-919-555-1234

...
"participants": {
...
  "dG9tQGZvb2Jhci5xlLmNvbQ": {
         "@type": "Participant",
         "roles": {
           "contact": true
         },
        "linkIds": {
	     "dG9tQGZvb2Jhci5xlLmNvbQl1": true
	}, 
	"description": "Jim Dolittle, ABC Industries, +1-919-555-1234"
       },
...
},
"links": {
	"dG9tQGZvb2Jhci5xlLmNvbQl1": {
            "@type": "Link",
	    "href": "ldap://example.com:6666/o=ABC%20Industries,c=US???(cn=Jim%20Dolittle)",
	    "rel": "what?"
	 }
}


CONTACT;ALTREP="http://example.com/pdi/jdoe.vcf":Jim
 Dolittle\, ABC Industries\, +1-919-555-1234

Much the same but needs a different "rel"







--------------DA27F0DA4F3292C202261E30-- From nobody Fri May 8 02:19: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 619263A092E for ; Fri, 8 May 2020 02:19:25 -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, HTML_MESSAGE=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=NOXN9gLT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cU4AcvDk 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 saC7tG8b7srr for ; Fri, 8 May 2020 02:19:22 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0843A0933 for ; Fri, 8 May 2020 02:19:22 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id C752F83F for ; Fri, 8 May 2020 05:19:21 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute7.internal (MEProxy); Fri, 08 May 2020 05:19:21 -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=/MRZtRm N/XS8Il+ScdJicrAxLHpLRyBKETE73a5061U=; b=NOXN9gLT98E4hYAQu8Lz4Iw JsX0YiQUHijV+zTTEayXNjLLpOqyjfIblGhzFMb/ueN8nz3Hh7a+/6cHKvgqidHP 6MjRc54gv1FcymT5gY9WewOhalXe8SX1sZAykTmsDGazLS75fwOfZOgc5QyZrtkg tLzykxP6qj8P7E4HTJUVAHHiul9f+2ZKuXPS4VEJd4fWcZ1tWZTn6Qt5Rmohwh+c hKsXrgUSTVNR8sF4bEmlynijNzAc+y1CDsgQ7XkCJUBhF3biGJ6kuoBFnYk5BsvP QE8+bJ5hi5BWgXV2n32ILisfxhMeZNjMBMs+tlLJghtyXk0ZYaiwKiaRL97kgUQ= = 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=/MRZtR mN/XS8Il+ScdJicrAxLHpLRyBKETE73a5061U=; b=cU4AcvDkal8r4tYimJISC9 OtoxrHyl11LdKxbeEOllSGoD/RbXrJdb7EnS+awHDcewzfHJZburbnXU4/I7ByCN eoTp287Jj9EPwVKujDm7QFR1l8pYhSvuW/jWH2HD3ZFaxHUNxfDOdQg2b9k8u10J pLZIGQpfRAJVaU2jHoHhM6dhWBxTsNs6AOF14sKYw2wHBAVl98FD9kPKyyXW3DiN L4lxxS1I0DYvLy2N74sQfZQz3E4KQ1vJLhbsHtmHLI8w3RQSOCdvJDOoqP3D3ZTD 3i9R71zQeAtwh9zqiQmTTk1xNH4konLMMjc/1weePaB4S+JgojqVWY01AoUjv0wg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkedvgddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedutdeviefhve ejfeegkefhteelgffgudehfefgieegueetueevvdelvedvjefgkeenucffohhmrghinhep vgigrghmphhlvgdrtghomhdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrghilhhtvggrmhdr tghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0D7E418056B; Fri, 8 May 2020 05:19:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1 Mime-Version: 1.0 Message-Id: <372a7846-0bcd-4bc2-9130-44b49ebcd493@www.fastmail.com> In-Reply-To: <3044ad0c-6b65-7ad8-456c-ed3a76cf110e@gmail.com> References: <3044ad0c-6b65-7ad8-456c-ed3a76cf110e@gmail.com> Date: Fri, 08 May 2020 11:19:00 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=f691bffff02e4bd1beff26e8b138c675 Archived-At: Subject: Re: [calsify] jscalendar - participants and contacts 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, 08 May 2020 09:19:26 -0000 --f691bffff02e4bd1beff26e8b138c675 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, May 8, 2020, at 4:13 AM, Michael Douglass wrote: > I do think we could use the linkids as a way of referring to e.g. a vc= ard to provide more detail. In both jscalendar and eventpub we need a pl= ain text property to hold simple plaintext values - e.g a phone number. = Eventpub already has the DESCRIPTION property - could we add that to jsc= alendar participant? Right. So this would require to: - add a description property to Participant - add "contact" to the IANA JSCalendar Enum Registry for Participant rol= es - add "contact" to the IANA Link Relations Registry This sounds OK for me. Probably Neil wants to chime in. An iCalendar CONTACT property is allowed to either have a free text valu= e or a URI. If its value is a valid URI then it must map in JSCalendar t= o a Link (e.g. a Participant description must not contain only a URI). > CONTACT;ALTREP=3D"ldap://example.com:6666/o=3DABC%20Industries\, c=3DUS???(cn=3DJim%20Dolittle)" :Jim Dolittle\, ABC Industries\, +1-919-555-1234 [...] "links": { "dG9tQGZvb2Jhci5xlLmNvbQl1": { "@type": "Link", "href": "ldap://example.com:6666/o=3DABC%20Industries,c=3DUS???(cn=3D= Jim%20Dolittle)", "rel": "what?" =C2=A0} } CONTACT;ALTREP=3D"http://example.com/pdi/jdoe.vcf":Jim Dolittle\, ABC Industries\, +1-919-555-1234 >=20 > Much the same but needs a different "rel" Why would the rel be different? In you example I see that the ALTREP par= ameters have different URI schemes (and the data most likely different m= edia types). But RFC8288 states in section 2.1 [1]: "Relation types are = not to be confused with media types [RFC2046]; they do not identify the = format of the representation that results when the link is dereferenced.= " [1] https://datatracker.ietf.org/doc/html/rfc8288#section-2.1 --f691bffff02e4bd1beff26e8b138c675 Content-Type: text/html
On Fri, May 8, 2020, at 4:13 AM, Michael Douglass wrote:

I do think we could use the linkids as a way of referring to e.g. a vcard to provide more detail. In both jscalendar and eventpub we need a plain text property to hold simple plaintext values - e.g a phone number. Eventpub already has the DESCRIPTION property - could we add that to jscalendar participant?


Right. So this would require to:

- add a description property to Participant
- add "contact" to the IANA JSCalendar Enum Registry for Participant roles
- add "contact" to the IANA Link Relations Registry

This sounds OK for me. Probably Neil wants to chime in.

An iCalendar CONTACT property is allowed to either have a free text value or a URI. If its value is a valid URI then it must map in JSCalendar to a Link (e.g. a Participant description must not contain only a URI).


CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\,
 c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\,
 +1-919-555-1234

[...]

"links": {
	"dG9tQGZvb2Jhci5xlLmNvbQl1": {
            "@type": "Link",
	    "href": "ldap://example.com:6666/o=ABC%20Industries,c=US???(cn=Jim%20Dolittle)",
	    "rel": "what?"
	 }
}


CONTACT;ALTREP="http://example.com/pdi/jdoe.vcf":Jim
 Dolittle\, ABC Industries\, +1-919-555-1234

Much the same but needs a different "rel"


Why would the rel be different? In you example I see that the ALTREP parameters have different URI schemes (and the data most likely different media types). But RFC8288 states in section 2.1 [1]: "Relation types are not to be confused with media types [RFC2046]; they do not identify the format of the representation that results when the link is dereferenced."


--f691bffff02e4bd1beff26e8b138c675-- From nobody Fri May 8 18:21:37 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 BD8123A0484 for ; Fri, 8 May 2020 18:19:51 -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, RCVD_IN_DNSWL_BLOCKED=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 7jbp7Qugg2aJ for ; Fri, 8 May 2020 18:19:50 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 5C34C3A0418 for ; Fri, 8 May 2020 18:19:50 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id y26so3712966ioj.2 for ; Fri, 08 May 2020 18:19:50 -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=fNuuePuOFkqDoAs9GbKTlmjIa2BaczWyvafMYi2OAO0=; b=IhfqFhR++P+ev50gwqCS52KocWXKrBw5diV2ra4QydVQpbM4vpWIr+yCBilxvgVqLH 06H/EZ83PQHFkyUyF+IQYtsXCS+VgLdfzgxLo429bDh0brDHUYk9MgOtTNzNmy9h6qRA hlMB+AgI38s9oTl+QPIeNCN4IBzZdf10EkcNqRC9bkBoBpUyk0YfonG9wevbZZdDdXdZ wZiG0ucMgNhdfdr02NzSYFhZfisdxMdfCys92cqaFsxXh/jdQBso6yyzPeEE9M9zjSwA oSsDKauLCny5VTUnIq004nvURCJIkr6U3YrxrpCOLD9sG6ARR5IkvUtqTs63TNZTTYvb 8rhw== 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=fNuuePuOFkqDoAs9GbKTlmjIa2BaczWyvafMYi2OAO0=; b=GU172SPAoIP6lkmndYE1s8PY7jAIm8rHC8UbHSqPtQ3mjurmEqkfZasSpolRUGDx8c 4GXk9fUGZmNzrYIWZbup64PzGM8o/qEPYtU0qVtEw7PpLHXOvfI02Vu/pVrshJdc9F2u 88a32J/azD/VEzpycpBu+K7N/UWUABFxXOYEmkPZ8mVRMofXqoVIhNlJEdq1A36OReQZ W6JmQAuXqUCPDf7pHRUg5Igyy1zWw1RB/Zw8b6cZqoNKHzf4XOBsw19lPD0MbbMRPo/C jHfXGkFhH+lor11lzVhyTqMWN+t/5DnRs+9yoNNvqlwrR/QgeqjU8nfd5KzL+kJ+oh1D dCcw== X-Gm-Message-State: AGi0PubyDXOaBbupcb0ROhkgTxV3ycqa+4Mq5JFCyZ1eH3Dwa+GYenXK RkR+l3TkYwzp2P8xFWwHapcM46UyIg4= X-Google-Smtp-Source: APiQypLo0qfz4khcL9z0rdXBCKXkdcIgcjVrlKprAiEl5D6Qwh6NrckSVoy78yUe0xrqDqBH3160WQ== X-Received: by 2002:a02:694f:: with SMTP id e76mr3314321jac.37.1588987188778; Fri, 08 May 2020 18:19:48 -0700 (PDT) Received: from MacBook-Pro-2019.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id u83sm1580585ili.17.2020.05.08.18.19.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 May 2020 18:19:48 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <64ecea3f-5373-ed92-4c38-42edf8393f8e@gmail.com> Date: Fri, 8 May 2020 21:19:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------90D049C4A76F64F46E14CE88" Content-Language: en-US Archived-At: Subject: [calsify] JSGroup/entries 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: Sat, 09 May 2020 01:19:52 -0000 This is a multi-part message in MIME format. --------------90D049C4A76F64F46E14CE88 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit The spec says in section 5.3.1 - for entries Type: "String[JSTask|JSEvent]" (mandatory). A collection of group members. This is represented as a map of the "uid" property value to the JSCalendar object member having that uid. Implementations MUST ignore entries of unknown type. What if somebody is sending an attendee a bunch of instances - currently the case if somebody is attending only some of the meetings? The uid is the same in each case. I guess there are ways round this - e.g. manufacturing a fake master - but it seems simpler to send the attendee the full instance(s). --------------90D049C4A76F64F46E14CE88 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

The spec says in section 5.3.1 - for entries

   Type: "String[JSTask|JSEvent]" (mandatory).

   A collection of group members.  This is represented as a map of the
   "uid" property value to the JSCalendar object member having that uid.
   Implementations MUST ignore entries of unknown type.

What if somebody is sending an attendee a bunch of instances - currently the case if somebody is attending only some of the meetings?

The uid is the same in each case.

I guess there are ways round this - e.g. manufacturing a fake master - but it seems simpler to send the attendee the full instance(s).


--------------90D049C4A76F64F46E14CE88-- From nobody Sat May 9 21:02:19 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 60CBA3A041A for ; Sat, 9 May 2020 21:02:10 -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 zBCbShFLtYmG for ; Sat, 9 May 2020 21:02:06 -0700 (PDT) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 399F03A0418 for ; Sat, 9 May 2020 21:02:06 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id q10so5275232ile.0 for ; Sat, 09 May 2020 21:02: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=ekuSlPoBWkkJ9JzJqoyt6bM2m0RjLvD71idllkoIEqI=; b=d1T9ah9wOFRYv8H7miAyY7K2r3JSvL/p6MPDScW/QnR55GfvHxWl2V3FdZPjJBCpNp X88I0wYIp1SyHj4GzDsKwgAq9RzD0r0BLCSdoECzw/D7SbI9FRjuTAGXplL38ntAWpbA 2DUYxnwT+VCkXaqopWigRPFTGILIrO1NoytCDqFXf02PWlZFZhcjE/urfxCd48PR8PKp kbXUni8n4MJqHadXb3ZgDLmG24ZZidtv065D+Zw7GUfefTKdHNxnDj3bHVNP97guL4pB iIU9NPrUsmk1tpK4sznCH3t6suLMYzhWmhseaMI5M5gE2tLGKb6db4IL1GBkDrHmlz9R 4Quw== 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=ekuSlPoBWkkJ9JzJqoyt6bM2m0RjLvD71idllkoIEqI=; b=HUM78oQu3edIHQXZIAfESqs/tch/yCYKvJjjWlS6phMCxrwNcYOQ5qOQoReLIIW//G Qi9Ex81YniQbQGM2k+Z+GNOIo1Ph0lB2Wc1rCkcFnzUSqLcpo+7YqzKULL38z8rQqaDH XWd3FpOAnsGC9alPFeWT2bzViojCLwg8v4sHvWPGYXX8Wfi/efId7Bq7sGaSjYpxxl7+ gvnfnlYfoV8cj2EbMCkUfqy6PJBLaIsGasihw0tgX4NvZ5CAIJlyl2zd1bJVjMlPLDRO P5XIkFLQuzpL9dZoMeDtADA60InO0rNKPwh5fsYDuLKQuvU7gFzfv40X+j1CBYe6hUnH bKOw== X-Gm-Message-State: AGi0PuZNj99PWHbgSkdqfpIITv+GQ9eyeHjc/TGIzItbVlg+84czmLs3 6hEO6XSVJ6b5GzewqASgscAZmoms32A= X-Google-Smtp-Source: APiQypK/eWuYyq0Rd6y8QbOYAG8K5bEiSNZ7cM7C52JuyA8NR/DZCwSKcYiY7XXQNRi69as6nfTZJg== X-Received: by 2002:a92:3652:: with SMTP id d18mr10151168ilf.212.1589083325145; Sat, 09 May 2020 21:02:05 -0700 (PDT) Received: from MacBook-Pro-2019.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id q78sm1668916ilb.25.2020.05.09.21.02.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 May 2020 21:02:04 -0700 (PDT) To: Robert Stepanek , calsify@ietf.org References: <3044ad0c-6b65-7ad8-456c-ed3a76cf110e@gmail.com> <372a7846-0bcd-4bc2-9130-44b49ebcd493@www.fastmail.com> From: Michael Douglass Message-ID: Date: Sun, 10 May 2020 00:02:03 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <372a7846-0bcd-4bc2-9130-44b49ebcd493@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------DA9AC9F2131D6BF0FA0158DD" Content-Language: en-US Archived-At: Subject: Re: [calsify] jscalendar - participants and contacts 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, 10 May 2020 04:02:11 -0000 This is a multi-part message in MIME format. --------------DA9AC9F2131D6BF0FA0158DD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/8/20 05:19, Robert Stepanek wrote: > On Fri, May 8, 2020, at 4:13 AM, Michael Douglass wrote: >> >> I do think we could use the linkids as a way of referring to e.g. a >> vcard to provide more detail. In both jscalendar and eventpub we need >> a plain text property to hold simple plaintext values - e.g a phone >> number. Eventpub already has the DESCRIPTION property - could we add >> that to jscalendar participant? >> > > Right. So this would require to: > > - add a description property to Participant > - add "contact" to the IANA JSCalendar Enum Registry for Participant roles > - add "contact" to the IANA Link Relations Registry > > This sounds OK for me. Probably Neil wants to chime in. > > An iCalendar CONTACT property is allowed to either have a free text > value or a URI. If its value is a valid URI then it must map in > JSCalendar to a Link (e.g. a Participant description must not contain > only a URI). No - the only valid value is a TEXT value. It does say: The property value consists of textual contact information. An alternative representation for the property value can also be specified that refers to a URI pointing to an alternate form, such as a vCard [RFC2426 ], for the contact information. It's referring there to the ALTREP parameter which I handled in the examples by use of a link > > >> CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\, c=US???(cn=Jim%20Dolittle)" :Jim Dolittle\, ABC Industries\, >> +1-919-555-1234 >> >> [...] >> >> "links": { >> "dG9tQGZvb2Jhci5xlLmNvbQl1": { >> "@type": "Link", >> "href":"ldap://example.com:6666/o=ABC%20Industries,c=US???(cn=Jim%20Dolittle)" , >> "rel": "what?" >>  } >> } >> >> >> CONTACT;ALTREP="http://example.com/pdi/jdoe.vcf" :Jim >> Dolittle\, ABC Industries\, +1-919-555-1234 >> >> Much the same but needs a different "rel" >> > > Why would the rel be different? In you example I see that the ALTREP > parameters have different URI schemes (and the data most likely > different media types). But RFC8288 states in section 2.1 [1]: > "Relation types are not to be confused with media types [RFC2046]; > they do not identify the format of the representation that results > when the link is dereferenced." Ok - I'll buy that - but should the rel be "contact"? It's an alternative representation of the property. Can we just call it "alternativeRepresentation". Which does lead to what do we do with ALTREP elsewhere - DESCRIPTION can have one. > > [1] https://datatracker.ietf.org/doc/html/rfc8288#section-2.1 > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------DA9AC9F2131D6BF0FA0158DD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 5/8/20 05:19, Robert Stepanek wrote:
On Fri, May 8, 2020, at 4:13 AM, Michael Douglass wrote:

I do think we could use the linkids as a way of referring to e.g. a vcard to provide more detail. In both jscalendar and eventpub we need a plain text property to hold simple plaintext values - e.g a phone number. Eventpub already has the DESCRIPTION property - could we add that to jscalendar participant?


Right. So this would require to:

- add a description property to Participant
- add "contact" to the IANA JSCalendar Enum Registry for Participant roles
- add "contact" to the IANA Link Relations Registry

This sounds OK for me. Probably Neil wants to chime in.

An iCalendar CONTACT property is allowed to either have a free text value or a URI. If its value is a valid URI then it must map in JSCalendar to a Link (e.g. a Participant description must not contain only a URI).

No - the only valid value is a TEXT value. It does say:

      The property value consists of textual contact
      information.  An alternative representation for the property value
      can also be specified that refers to a URI pointing to an
      alternate form, such as a vCard [RFC2426], for the contact
      information.

It's referring there to the ALTREP parameter which I handled in the examples by use of a link



CONTACT;ALTREP="ldap://example.com:6666/o=ABC%20Industries\,
 c=US???(cn=Jim%20Dolittle)":Jim Dolittle\, ABC Industries\,
 +1-919-555-1234

[...]

"links": {
	"dG9tQGZvb2Jhci5xlLmNvbQl1": {
            "@type": "Link",
	    "href": "ldap://example.com:6666/o=ABC%20Industries,c=US???(cn=Jim%20Dolittle)",
	    "rel": "what?"
	 }
}


CONTACT;ALTREP="http://example.com/pdi/jdoe.vcf":Jim
 Dolittle\, ABC Industries\, +1-919-555-1234

Much the same but needs a different "rel"


Why would the rel be different? In you example I see that the ALTREP parameters have different URI schemes (and the data most likely different media types). But RFC8288 states in section 2.1 [1]: "Relation types are not to be confused with media types [RFC2046]; they do not identify the format of the representation that results when the link is dereferenced."

Ok - I'll buy that - but should the rel be "contact"? It's an alternative representation of the property. Can we just call it "alternativeRepresentation".

Which does lead to what do we do with ALTREP elsewhere - DESCRIPTION can have one.




_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------DA9AC9F2131D6BF0FA0158DD-- From nobody Sun May 10 21:10:43 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFCE3A005F for ; Sun, 10 May 2020 21:10:40 -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, HTML_MESSAGE=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=M88EQWbG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=egqz7P4v 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 k-AiQXfP6olg for ; Sun, 10 May 2020 21:10:38 -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 396233A005D for ; Sun, 10 May 2020 21:10:37 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 23C4C476 for ; Mon, 11 May 2020 00:10:37 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 11 May 2020 00:10:37 -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=iinJV4A lekLvFYSO3WoJxZMobKvsetLLVTdpIpyhmBY=; b=M88EQWbGXCkV903CRIWCl39 NY8Pehv9i2OEZ2rAH0TgmndbrpqXN30S6PS2M7i38VVKISwLr//8Vrc5DvnYfRJE GleS7uyLxKauyA4P4N2eWjyd8t9kfljXHTPgBYA58AmgaG4sy2KFrLgdUOP1Zpje CWb+ras8jbLAIHLH7hvi7zYaiF7LtwrK9Uuj2kM5ntSuTyR72k38Hw7KnGm4ucyN v8RERQul/DDOGS484wTcEQe+hgDvCoV04Q87KxNooqq3E+Tps/1XGquoZUXfUJll 54qpcrLn6Kd6rcOz93h9qM07m/8nYX7nEBe6C4O44/7YCFjcZNgOMyegAHyhAAw= = 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=iinJV4 AlekLvFYSO3WoJxZMobKvsetLLVTdpIpyhmBY=; b=egqz7P4vLNWMVRSPH0WKOi lnLo66pcQsRz7Znj9Z0piUwJCkCrKGLqqVMQ++JGJYpKPFyC6xh/4RYRB72Jf+7R 2HDdStWEXuud9jepwcn+w/6SuzBWAUFHI+oO4jFsajDP8EeK9OeVvmeDyzjpXtDZ 3x49GK0ETV+t8jsGuGMmBcYTduePRuJIrmlGCZh/Je5AOvVy+98yEAwLAZyChIpN C5biEKx9XmqSsZtNd817gbXm8HfHjZZ4ZsZ81x876EcDL6RvU6a8CYuMzIbVI7c+ WXPdwRF/PSNK6eM0nFJjFRLPgeEltkGzIf8wWHKo3an5ZXjaz/LftREz8KvyhCbw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkeelgdejkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevvdetvdduleekhf eghfetfeettdelhfehfeevffevleekuddtudffieevjeevhfenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6AE711800E6; Mon, 11 May 2020 00:10:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1 Mime-Version: 1.0 Message-Id: <8bae264b-3e74-4193-bdfa-95d8c8c027a8@beta.fastmail.com> In-Reply-To: <64ecea3f-5373-ed92-4c38-42edf8393f8e@gmail.com> References: <64ecea3f-5373-ed92-4c38-42edf8393f8e@gmail.com> Date: Mon, 11 May 2020 14:10:36 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=c6f7d2f5ccc64786bfcf1aa28873c057 Archived-At: Subject: Re: [calsify] JSGroup/entries 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, 11 May 2020 04:10:41 -0000 --c6f7d2f5ccc64786bfcf1aa28873c057 Content-Type: text/plain On Sat, 9 May 2020, at 11:19, Michael Douglass wrote: > The spec says in section 5.3.1 - for entries > Type: "String[JSTask|JSEvent]" (mandatory). Agreed, I've changed this to `(JSTask|JSEvent)[]` (just an array of objects instead of a map). You could have members with the same UID but different recurrence ids. Neil. --c6f7d2f5ccc64786bfcf1aa28873c057 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Sat, 9 May 2= 020, at 11:19, Michael Douglass wrote:

The spec says in section 5.3.1 - for entries

   Type: "S=
tring[JSTask|JSEvent]" (mandatory).

Agreed, I've changed this to (JSTask|JSEvent)[]<= /code> (just an array of objects instead of a map). You could have membe= rs with the same UID but different recurrence ids.

Neil.
--c6f7d2f5ccc64786bfcf1aa28873c057-- From nobody Sun May 10 21:39:40 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 BCC273A0783 for ; Sun, 10 May 2020 21:39:37 -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, HTML_MESSAGE=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=ix8oRdu/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kzces9Dp 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 vjFIUNkkoVoy for ; Sun, 10 May 2020 21:39:36 -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 453BF3A077A for ; Sun, 10 May 2020 21:39:36 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id E0B82421 for ; Mon, 11 May 2020 00:39:33 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 11 May 2020 00:39:34 -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=mpgux7s Od9R2icwVJqArj2Mn1iVn4irehWDg3QulICE=; b=ix8oRdu/GxDGRrjSJ9Vv3fe xrEcHsvyZ1a9ZJUqHjJYYSxVC4cZd34QADicbmxKW2MBRE3+n+yy5nZTYxrjgeBf 2kC0RNiO8SY9ftuGz11MKRG6CAqwpBKWBvx44iMnasNgDCSkGiQ5CUZn4ipdz9CC Pw7TVPRQA6nW++v7kMF7yTwq1YnN6OgnmSkXtV1SviMIlU1K52y/WUc7e/EARQbJ F7zQvscRiZriuVk0Nt5jlanGxSv77P4aHZqrspGsGQpbj9aR8rjC8Ge0LWZfd+Tp QB0CXqL9kN9PnP1bXtjksqzrqvu4UC/SpuQQnluV583kYZKgxLjbnNtf+ie+SNg= = 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=mpgux7 sOd9R2icwVJqArj2Mn1iVn4irehWDg3QulICE=; b=kzces9DpI5gWM1XrgTcNS2 Je8EvhVrh3Dxc1kscP56NnULRRV42ruzWeFDFRFE7mjCogNLuS3Mfs9qIwG8zN5z hT3xAFTfgsuQkHVCXjNwRbb+YvCh4P2Fr21jb3XUip/SpOLFkcqhBlVAy0bO20qI vtph6S6pyT/UDENey55f1iYlOEUB1qSryekySrUJQ8BDWO8SieNIgJpPE8j9ekGM 7aZD08UIpCIgTp06lV9zvVmsConhTjJk1Il6Bu64bYY5KMZid0T3vk7lFX9qI6To 9R9Hoq945Y/xuKhD6HKhWMK5MAqCol8ObaP2fjt2dpjKaYXsSoo/So7UJNvSx/BA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkeelgdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevvdetvdduleekhf eghfetfeettdelhfehfeevffevleekuddtudffieevjeevhfenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1713C1800E6; Mon, 11 May 2020 00:39:33 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1 Mime-Version: 1.0 Message-Id: <12c868c1-14a3-4370-8457-7a03be253181@beta.fastmail.com> In-Reply-To: <1d5e3573-ccb4-47d6-b18a-c44559e97596@www.fastmail.com> References: <1d5e3573-ccb4-47d6-b18a-c44559e97596@www.fastmail.com> Date: Mon, 11 May 2020 14:39:06 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=c2f3f304591147c19f2c9b191db51dd6 Archived-At: Subject: Re: [calsify] jscalendar and COMMENT 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, 11 May 2020 04:39:39 -0000 --c2f3f304591147c19f2c9b191db51dd6 Content-Type: text/plain On Wed, 6 May 2020, at 16:57, Robert Stepanek wrote: > RFC 5545 allows for multiple COMMENT properties per calendar object. The TimeZone in the JSCalendar defines the comments properties as an array of String. I think we should do the same for JSEvent and JSTask (probably also for JSGroup). I don't really understand what the semantics of multiple comments are meant to be; the only thing I can assume is that in iCalendar they were meant to be read in the context of the raw source file (e.g. you put the COMMENT just before DTSTART because you want to make a comment about the start time), but that's nuts because there's no way a client can represent that, and nobody does all their calendaring by just reading and writing raw source files: which goes back to my point, how is this actually being used at the moment? The goal with JSCalendar has always been to be a useful understandable data model first, 1:1 translation with 5545 second. What I don't want to do is make the new format worse just so you can map something weird that isn't really used from iCalendar. Neil. --c2f3f304591147c19f2c9b191db51dd6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, 6 = May 2020, at 16:57, Robert Stepanek wrote:
RFC 5545 allows for multiple COMMENT pro= perties per calendar object. The TimeZone in the JSCalendar defines the = comments properties as an array of String. I think we should do the same= for JSEvent and JSTask (probably also for JSGroup).

I don't really understand what the semantics of m= ultiple comments are meant to be; the only thing I can assume is that in= iCalendar they were meant to be read in the context of the raw source f= ile (e.g. you put the COMMENT just before DTSTART because you want to ma= ke a comment about the start time), but that's nuts because there's no w= ay a client can represent that, and nobody does all their calendaring by= just reading and writing raw source files: which goes back to my point,= how is this actually being used at the moment? The goal with JSCalendar= has always been to be a useful understandable data model first, 1:1 tra= nslation with 5545 second. What I don't want to do is make the new forma= t worse just so you can map something weird that isn't really used from = iCalendar.

Neil.
--c2f3f304591147c19f2c9b191db51dd6-- From nobody Sun May 10 21:43:13 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 B16813A0771 for ; Sun, 10 May 2020 21:43:11 -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, HTML_MESSAGE=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=hr768UeS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sH24RTc5 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 7p0ZZqDgxXxN for ; Sun, 10 May 2020 21:43:09 -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 D242C3A076F for ; Sun, 10 May 2020 21:43:09 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 37E2A43E for ; Mon, 11 May 2020 00:43:09 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 11 May 2020 00:43:09 -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=2IJQ4N+ 4ufSXD7WCSh0yBpuFRdTuXACWxEko73/YP7M=; b=hr768UeSxrrDTFuL/1H0XIf 4pQy8ns6j0YnfTZEddryV6dJaBvpSDqAxXpTgZu0naEORfI9awgA5IU3Tbe/ibuE CugymN1F7e0NprIaBJ+rfzrQaIjCVcZD9AZNbn9TYb5xwCnTz2Yf1QGDh1ZOEPEg l69Idl1pIiq2niRZAIL53puMSieeYNe1+2+FiIJ6jhPTrafWqatzblVmnk097/VN JuB4H6GHhaDGhcAjJVJgHHeTmMsRXrdNrfcaxfEpn5qx2gum9cKqHUwAER3awa3C 0s+Xh6IHU5sGAuiGW4dEnFGqoRMsbPY3WqCoRZbpcfy1erLaGc31LmGm0p1p+Pg= = 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=2IJQ4N +4ufSXD7WCSh0yBpuFRdTuXACWxEko73/YP7M=; b=sH24RTc5CYkufZ/wwsJg6O ROa6lud5eXjKoWxR2p7SMhGDI3Ky9/22tJIyl9kLhyZhCoXxdiqb4RhRae8qLrYk ppKgWAhluxAY8dSnQyA/zoQcpd8wnWo8/f7qhVbrSc5KTb636iiO/bvL3ZPqu+BX afQNTYxyF6AwjISLJ2HfUr303hr4siTNf91GOGsRAvSii9NGTAhJXrja3aR2uhb4 5S462932eDtGQa+43LGtZ6S0+JAulCNfWKRrAnKA/sSxZmroqYl/1jvzzCU6R9o/ ZLq32WqguhkZWnc58+r5yR1ByKx3U60FxdachdbYgZswgslfbkgBz32zYq0F1aow == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkeelgdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevvdetvdduleekhf eghfetfeettdelhfehfeevffevleekuddtudffieevjeevhfenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B30581800EB; Mon, 11 May 2020 00:43:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <372a7846-0bcd-4bc2-9130-44b49ebcd493@www.fastmail.com> References: <3044ad0c-6b65-7ad8-456c-ed3a76cf110e@gmail.com> <372a7846-0bcd-4bc2-9130-44b49ebcd493@www.fastmail.com> Date: Mon, 11 May 2020 14:43:07 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=3105548a095c49be85467646bd139e08 Archived-At: Subject: Re: [calsify] jscalendar - participants and contacts 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, 11 May 2020 04:43:12 -0000 --3105548a095c49be85467646bd139e08 Content-Type: text/plain On Fri, 8 May 2020, at 19:19, Robert Stepanek wrote: > Right. So this would require to: > > - add a description property to Participant > - add "contact" to the IANA JSCalendar Enum Registry for Participant roles > - add "contact" to the IANA Link Relations Registry > > This sounds OK for me. Probably Neil wants to chime in. That sounds fine to me too. Neil. --3105548a095c49be85467646bd139e08 Content-Type: text/html
On Fri, 8 May 2020, at 19:19, Robert Stepanek wrote:
Right. So this would require to:

- add a description property to Participant
- add "contact" to the IANA JSCalendar Enum Registry for Participant roles
- add "contact" to the IANA Link Relations Registry

This sounds OK for me. Probably Neil wants to chime in.

That sounds fine to me too.

Neil.
--3105548a095c49be85467646bd139e08-- From nobody Sun May 10 22:06:31 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 754373A07BE for ; Sun, 10 May 2020 22:06: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, 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 JORgRKOaFvtT for ; Sun, 10 May 2020 22:06:24 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 5D5A43A07BC for ; Sun, 10 May 2020 22:06:24 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id w11so8206766iov.8 for ; Sun, 10 May 2020 22:06:24 -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=3gqQbrSFtN741c2//HEaDds9ZdapA4+Gkh1F/jHSNlY=; b=C4YBqEaSQV+FuBTv6oMFZBJM89UsRlBiJP1TmEJOxZQTL9jFIr3hF1+uYNMqrwOY0o 8LrfIoFtp1O84F6JPHzpJNOLCqByoVVVFja/lrA/Thit3pTl0iW8yEWSf+XcsIirx1hk ozMvm5/H0asJ5fv1+IRfmurKL51WzZPhRV3PysRdnDm7IbOr77IBzU/GagUdwfpAgIqO xalNOSuQa8SuNewhb67z2BbqPAZ1vbJUcy/Rl2dyWbuP/JQYvFQOSUl1gR8IJNUuqXtB DrB1gEnVILRUPO2FcSQDhADqAFJuWa9x5hppZA8li+5P9HAqIy+hTqD6pyyJrzbtRN6T /qBw== 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=3gqQbrSFtN741c2//HEaDds9ZdapA4+Gkh1F/jHSNlY=; b=ZDYwtVlFTiLyJeVyp+G5+eFPI+cBKwwUTavMZrT2XBDSkAQEJ1eUZcZQiJKvqYsfjx EPjKtz2QxER9rV5sDEPQnSOCmDyX18ulyKePgIgqsfL9RRjJEfPN6TgRCRllDZnQxANi yUOxRRk83Cjvw0Hqll2rA4ES90Z0EfwmxKV/hynz5Smoehf0dFHUhj1V0jxH/83w+ous UVdlm6H/urgbSuC2gvuMdk6hC21mycEyC0GSZlXmEaW5ArXy/FdE4louvFAzwS/cxn77 RM/DogOtS23Np6JarwBk21yCzNUsDzblCJWdtvv+eVwV2bZcEdurG3aQ7W3/httfcmuV FrBQ== X-Gm-Message-State: AGi0Pub9dET/QC749Ry1m2IV7P4y8EhFV0Jpgcl0Zakh9UDXJL8aRIED sWFr7KD/Lyn9AYBMq63Sqjd/wi0I92o= X-Google-Smtp-Source: APiQypL5YuL/sVxIj8QIbzGdqZCoXY23CJucT3TRPX6HGSSWbku6uPcXDdbwizTwh+0ryAqHNpA0ag== X-Received: by 2002:a05:6602:153:: with SMTP id v19mr13929584iot.127.1589173583244; Sun, 10 May 2020 22:06:23 -0700 (PDT) Received: from MacBook-Pro-2019.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id 15sm1372154iof.34.2020.05.10.22.06.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 May 2020 22:06:22 -0700 (PDT) To: calsify@ietf.org References: <1d5e3573-ccb4-47d6-b18a-c44559e97596@www.fastmail.com> <12c868c1-14a3-4370-8457-7a03be253181@beta.fastmail.com> From: Michael Douglass Message-ID: <3acad013-6eed-6117-d8c9-16ad944eadca@gmail.com> Date: Mon, 11 May 2020 01:06:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <12c868c1-14a3-4370-8457-7a03be253181@beta.fastmail.com> Content-Type: multipart/alternative; boundary="------------C1301F759391610FE86E6389" Content-Language: en-US Archived-At: Subject: Re: [calsify] jscalendar and COMMENT 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, 11 May 2020 05:06:28 -0000 This is a multi-part message in MIME format. --------------C1301F759391610FE86E6389 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit We're going to have to live with iCalendar and manage a reasonably seamless translation between icalendar and jscalendar if we want it used. Rather than try to determine who is using what in iCalendar - unless it is seriously broken - I think we should try to make that transition easy. I doubt comments were meant to be read in the raw file - the specs gives a clue - from 5546: An "Attendee" MAY include a message to the "Organizer" using the "COMMENT" property. For example, if the user indicates tentative acceptance and wants to let the "Organizer" know why, the reason can be expressed in the "COMMENT" property value. I agree this is probably not implemented by many but it's there and some people probably use it. If there's no good reason not to be compatible with 5545/6 we should be so. On 5/11/20 00:39, Neil Jenkins wrote: > On Wed, 6 May 2020, at 16:57, Robert Stepanek wrote: >> RFC 5545 allows for multiple COMMENT properties per calendar object. >> The TimeZone in the JSCalendar defines the comments properties as an >> array of String. I think we should do the same for JSEvent and JSTask >> (probably also for JSGroup). > > I don't really understand what the semantics of multiple comments are > meant to be; the only thing I can assume is that in iCalendar they > were meant to be read in the context of the raw source file (e.g. you > put the COMMENT just before DTSTART because you want to make a comment > about the start time), but that's nuts because there's no way a client > can represent that, and nobody does all their calendaring by just > reading and writing raw source files: which goes back to my point, how > is this actually being used at the moment? The goal with JSCalendar > has always been to be a useful understandable data model first, 1:1 > translation with 5545 second. What I don't want to do is make the new > format worse just so you can map something weird that isn't really > used from iCalendar. > > Neil. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------C1301F759391610FE86E6389 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit We're going to have to live with iCalendar and manage a reasonably seamless translation between icalendar and jscalendar if we want it used.

Rather than try to determine who is using what in iCalendar - unless it is seriously broken - I think we should try to make that transition easy.

I doubt comments were meant to be read in the raw file - the specs gives a clue - from 5546:

   An "Attendee" MAY include a message to the "Organizer" using the
   "COMMENT" property.  For example, if the user indicates tentative
   acceptance and wants to let the "Organizer" know why, the reason can
   be expressed in the "COMMENT" property value.

I agree this is probably not implemented by many but it's there and some people probably use it.

If there's no good reason not to be compatible with 5545/6 we should be so.


On 5/11/20 00:39, Neil Jenkins wrote:
On Wed, 6 May 2020, at 16:57, Robert Stepanek wrote:
RFC 5545 allows for multiple COMMENT properties per calendar object. The TimeZone in the JSCalendar defines the comments properties as an array of String. I think we should do the same for JSEvent and JSTask (probably also for JSGroup).

I don't really understand what the semantics of multiple comments are meant to be; the only thing I can assume is that in iCalendar they were meant to be read in the context of the raw source file (e.g. you put the COMMENT just before DTSTART because you want to make a comment about the start time), but that's nuts because there's no way a client can represent that, and nobody does all their calendaring by just reading and writing raw source files: which goes back to my point, how is this actually being used at the moment? The goal with JSCalendar has always been to be a useful understandable data model first, 1:1 translation with 5545 second. What I don't want to do is make the new format worse just so you can map something weird that isn't really used from iCalendar.

Neil.

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------C1301F759391610FE86E6389-- From nobody Sun May 10 22:46:44 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 881AB3A07EA for ; Sun, 10 May 2020 22:46:41 -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=r8lZ1HJo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VmBwMtO8 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 NqoQI2tijR9h for ; Sun, 10 May 2020 22:46:34 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C011F3A07E9 for ; Sun, 10 May 2020 22:46:34 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id A61A3460 for ; Mon, 11 May 2020 01:46:33 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 11 May 2020 01:46:33 -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=IfITkht vIxiGIApMzkRqqBF8gDBaYcXGBhRQ6GjyS2w=; b=r8lZ1HJofq81Kac6DIqSPF7 YXNh7kMmdYoOkl90mAzFcoVUZaEARl4kFfJsaNzUehHHQjuHucydFeiXh3kKLTXv oj3p749/7mbmEmJK0eacn4nbaRwqnQKYuWF1s/J9GNkOk0VVq+zvy0za1ano48mC 61cY/zl4MxJBOYHA/YXfagT/UjSAdbq6BBgVDss08sSQtYOA/2APZUSX315KmJls wZgfj2ftdV6PPaL2s27gDRsA45BJKr5xLigme6o1/vUkKqQVd6jZ6BH14pkiuFYn /9IBzmIK3eF5JOdp55Yd+QMFZnBxS8UK8glE92Io7+e23sVA75G3J7ne0ZI4w3w= = 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=IfITkh tvIxiGIApMzkRqqBF8gDBaYcXGBhRQ6GjyS2w=; b=VmBwMtO8KxzfTw71c9FX55 sj49ZxPoP+l23qXwGsDFiP8dlwYT3KX7Seky4MsZmR6st+hX/wIBHRMtK7QDlsb6 t5BNjo9qxBLQIRFvdDb/81mCpqJZfm4VU+uS6xmwRaA4vWG3OFhG0jBdyFf1WqhA 7UoFS/hu3NsGde63kXy+oiO3qF30ZqVOcs27FGwDxFKzYIEUELYZjaF20t1syTNe kMfa/KUNctU4uFEZDDqz8VE8s34sRfk8x3KtLDJztUwvL2+xyOjuhJCqT0NjnaBq 9zq9XE5dErKLkFiT96dB9aFaQJXSLsC7sXqzenUrSfOWUcMO6MwQm4DdxSBHUDAg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrkeelgdeljecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeehuefhudejtdeive ekvdfhfffgleeflefhfeekhefhkeelkefhfeeufeevffejieenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DC4B71800E6; Mon, 11 May 2020 01:46:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1 Mime-Version: 1.0 Message-Id: <4d1b8d07-ca2b-4a5b-bda5-2465c6e915f7@beta.fastmail.com> In-Reply-To: <3acad013-6eed-6117-d8c9-16ad944eadca@gmail.com> References: <1d5e3573-ccb4-47d6-b18a-c44559e97596@www.fastmail.com> <12c868c1-14a3-4370-8457-7a03be253181@beta.fastmail.com> <3acad013-6eed-6117-d8c9-16ad944eadca@gmail.com> Date: Mon, 11 May 2020 15:46:32 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=a2bb0e6935e44917a29bebd4ab3fee7c Archived-At: Subject: Re: [calsify] jscalendar and COMMENT 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, 11 May 2020 05:46:42 -0000 --a2bb0e6935e44917a29bebd4ab3fee7c Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, 11 May 2020, at 15:06, Michael Douglass wrote: > If there's no good reason not to be compatible with 5545/6 we should b= e so. Sure. My issue is that if we the authors can't explain how it's meant to= be used, the chance of it being used in an interoperable way are close = to none anyway. > I doubt comments were meant to be read in the raw file - the specs giv= es a clue - from 5546: > the reason can be expressed in the "COMMENT" property value. The use of "the" instead of "a" would indicate this author also would be= surprised to see multiple COMMENT values. My suggestion was to keep it single valued (because that at least makes = more sense to me: it's a message attached to the event =E2=80=93 if you = were to use iMIP it's probably the same value you'd put in the email bod= y itself). You can map multiple in from iCalendar by concatenating with = one or two new lines in between =E2=80=93 but it's slightly lossy, you w= ouldn't be able to tell it was multiple COMMENT values when mapping back= to iCalendar. Alternatively we can make it an array of values so it maps more cleanly,= but then I think it will be more difficult to explain and cause more co= mplexity pain for implementors in the future (they never want to use mor= e than one value, but now always have to handle the possibility it could= be multi-valued). Neil. --a2bb0e6935e44917a29bebd4ab3fee7c Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mon, 11= May 2020, at 15:06, Michael Douglass wrote:
If there's no good reason not to be com= patible with 5545/6 we should be so.

Sure. My i= ssue is that if we the authors can't explain how it's meant to be used, = the chance of it being used in an interoperable way are close to none an= yway.

I doubt comments were meant to be read in the raw file - the specs gives a clue - from 5546:
   the reason can be expressed in the "COMMENT" property value.

The use of "the" instead of "a" would= indicate this author also would be surprised to see multiple COMMENT va= lues.

My suggestion was to keep it single v= alued (because that at least makes more sense to me: it's a message atta= ched to the event =E2=80=93 if you were to use iMIP it's probably the sa= me value you'd put in the email body itself). You can map multiple in fr= om iCalendar by concatenating with one or two new lines in between =E2=80= =93 but it's slightly lossy, you wouldn't be able to tell it was multipl= e COMMENT values when mapping back to iCalendar.

Alternatively we can make it an array of values so it maps more cl= eanly, but then I think it will be more difficult to explain and cause m= ore complexity pain for implementors in the future (they never want to u= se more than one value, but now always have to handle the possibility it= could be multi-valued).

Neil.
--a2bb0e6935e44917a29bebd4ab3fee7c-- From nobody Mon May 11 01:33:11 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 C815F3A090D for ; Mon, 11 May 2020 01:33:03 -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=THL2AJK2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=H9QK2+wT 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 Tzd67Us1gtF4 for ; Mon, 11 May 2020 01:33:00 -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 220173A0909 for ; Mon, 11 May 2020 01:32:59 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 11B6A5C00AF for ; Mon, 11 May 2020 04:32:59 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute7.internal (MEProxy); Mon, 11 May 2020 04:32:59 -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=ihQbbRn 0+WAztZF9a7Rm5XyWj0rcHtrpJyxPfN30Zuw=; b=THL2AJK2R7EpotXVCrtszV6 Ru8fizat1+tGNTVH/y1LNfX18xVnmzZS8JxWs4aeuocrmTGgRzAPNUl3FFPhFXFM yWvdgF0jQNM5BKr9Uv8CqHXFTcjw70bsCvSh5U4KPCxzJXnIgeM+BUSt76JOkERw /1nPpYAnelh7XGRLbWXzBUuMv5d8lKirwYoPFVnY1uqKFq8ytnyTjmg2ojeOabjy R65nc4XO7AgcK2fvrez1o7r1EGw88jNMkMsB9MrL5oEojsk9RtkQcm2y6nkv3elQ xH1YdcuUu4WHMrURY8MarmRmnViaDLW8GVBbWlkQLeXeXFsYLM25WppxH9nihIw= = 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=ihQbbR n0+WAztZF9a7Rm5XyWj0rcHtrpJyxPfN30Zuw=; b=H9QK2+wTljXckAGFHAEGoC yfte1UL85dAFQj2GhXfpnxOZnWITVCcOmKjVUilZJhg5WU3/z3hO9pNipFGhzP38 sb6LSGDwMToZZnElA4T3+HfBOE5r/JztcKsfepZORT1NwXFphlfOeWY2VsUxkwix z2fQaljEnmR4TAxJVNyn60zri2VkN1XLZaH2StLTbSlejVrb2NAQO4fXiAq+6N8t QcHKEB7q2rhYZsplGdhcyU1AO24TVSrPOrL/PNiVzfN+gqJm5ptTY4B94GB5B/yh dpJC6y/c+as2fjpDLjKk2LdEf/6z+iTgYsIJj4v4g3nM31Uq0zHDE+z6qiw1HQiA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrledtucetufdoteggodetrfdotffvucfrrh hofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtderreerre dtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthhosehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepheeguedvtdekhfetgf eufefgvdeuteegfeefleehvddugeejjefhteeugfevveeinecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrghilhhtvg grmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A0B321800EB; Mon, 11 May 2020 04:32:58 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1 Mime-Version: 1.0 Message-Id: <1a3c700c-3632-4f54-8ad0-777763ac460d@www.fastmail.com> In-Reply-To: <0acd2f76-cfbc-e43c-cb74-9577faa99528@gmail.com> References: <0acd2f76-cfbc-e43c-cb74-9577faa99528@gmail.com> Date: Mon, 11 May 2020 10:32:38 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=eca28e4dae594ee39b052f6d135cf97b Archived-At: Subject: Re: [calsify] jscalendar-icalendar mapping - vtimezone 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, 11 May 2020 08:33:08 -0000 --eca28e4dae594ee39b052f6d135cf97b Content-Type: text/plain On Sat, Apr 11, 2020, at 9:39 PM, Michael Douglass wrote: > Could we simply allow a timezones property as another alternative in > JSGroup? I've updated the draft accordingly. Custom time zone identifiers in a JSEvent may be defined both in the event and the embedding group. Conflicts of the same timezone id are resolved by the event timeZones property overruling the group definition. Cheers, Robert --eca28e4dae594ee39b052f6d135cf97b Content-Type: text/html
On Sat, Apr 11, 2020, at 9:39 PM, Michael Douglass wrote:
Could we simply allow a timezones property as another alternative in 
JSGroup?

I've updated the draft accordingly. Custom time zone identifiers in a JSEvent may be defined both in the event and the embedding group. Conflicts of the same timezone id are resolved by the event timeZones property overruling the group definition.

Cheers,
Robert

--eca28e4dae594ee39b052f6d135cf97b-- From nobody Mon May 11 01:41:10 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A203A0927 for ; Mon, 11 May 2020 01:41:08 -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=MbHRkHFk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WTFoB0JB 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 YTyEyVbB7nnJ for ; Mon, 11 May 2020 01:41:05 -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 5D9213A0924 for ; Mon, 11 May 2020 01:41:05 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 68D435C00AB for ; Mon, 11 May 2020 04:41:04 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute7.internal (MEProxy); Mon, 11 May 2020 04:41:04 -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=kI575ea JsMSmc411rdTiEoYK8K8yeI40vCBNHM2+2vo=; b=MbHRkHFkWQBzglVMuzergp1 hQa4mvqN1ynBubOzhZV+OIOL8ofDq+6cChVwDDRlWQMjraBLY3/1Aw2xS16fqDm/ xUhgROgf0/hOiv+5J4E29OvYQ4o4YGOLdaRhVcVuV8yqqQYgnTBN4vju6QDpf2Z1 Is4fm29b3WKtnHZ1mVVzoJMUtUS/TlrQwQv1fdLN5OA1i3qARxz+C9wQJuToqfGX 2GGSQRqQfSpbYapq3LJ7HJdzhEYXs0OAD2MOZm74ZbE1VsNIQyVmY2wjXSgI4dD/ aA2lkebTuLUHre7Rw3ZppwwAM4XFxJ14Iq7AfKsIBGDJtBkLIuH1+kW0APgv5hw= = 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=kI575e aJsMSmc411rdTiEoYK8K8yeI40vCBNHM2+2vo=; b=WTFoB0JBNwCyugOLzhH/Ks wAFYFaPt6OkSaQkZUYYwvnsmNGspH296O0Ay6Ut1kOHYhowNswBqadnrnOrTTsre dZiIEtvkXkwL71y2NGO9350l6QL50eDvTkqerM1LCuSYrckjmUI8NmY0mtDICgSX O4fRS8vqkPyo048bLHbgE8jOjmBm6qfSf+B7GL8VNM1iDFPOJIwNZtettslrqk8D rErSQlF3lnFOLV8Qned/350FdMn6C4gMbsDpivmYRLCxxd37s2ICHyU9t6nvJFUo GeRYsFnFg8W9/dUpEnjZEV/Gu4LwkhIUgLs5TNoiyXiWwTgvdoUVkRqBfvhsnBOQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrledtgddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeethfffffekue ekveelleeglefhgeefjeeugeetkeejkefgtdfhheehvdehhedvhfenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomheprhhsthhosehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DED671800EB; Mon, 11 May 2020 04:41:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <2bac5257-fe7e-a306-0a6f-583533e0fe41@gmail.com> References: <2bac5257-fe7e-a306-0a6f-583533e0fe41@gmail.com> Date: Mon, 11 May 2020 10:40:42 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=4240de593f654b728c0021a5f9a7d95d Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar-26 - section 3.1 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, 11 May 2020 08:41:09 -0000 --4240de593f654b728c0021a5f9a7d95d Content-Type: text/plain On Sat, Apr 11, 2020, at 9:54 PM, Michael Douglass wrote: > I would be inclined to either delete > (for example, the CalDAV protocol [RFC4791 ] requires octet equivalence of the encoded calendar object to determine ETag equivalence) Agreed and done. Cheers, Robert --4240de593f654b728c0021a5f9a7d95d Content-Type: text/html
On Sat, Apr 11, 2020, at 9:54 PM, Michael Douglass wrote:

I would be inclined to either delete

 (for
   example, the CalDAV protocol [RFC4791] requires octet equivalence of
   the encoded calendar object to determine ETag equivalence)

Agreed and done.

Cheers,
Robert

--4240de593f654b728c0021a5f9a7d95d-- From nobody Tue May 12 13:44:56 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 987F83A0AD5 for ; Tue, 12 May 2020 13:44:54 -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, 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 CqkT28fg8Ohn for ; Tue, 12 May 2020 13:44:53 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 28D093A0AD0 for ; Tue, 12 May 2020 13:44:53 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id j3so1508853ilk.11 for ; Tue, 12 May 2020 13:44:52 -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=is4i5Pu5m63D1Doc9Riyp/SV8y6By7O2qANFh09IC5k=; b=FcXwgpJvCEzAKaDSzBmd977cY6H+up26fdfqjX5HkANKYqoZek3ubMAlKbPPpJg6eV VxmXxGyk3JX+FQg4A7G7omNk44dQyvv0CaLCLzN96m+pH0fGy+5gkMEMZD3YD38D7NmQ D2AtfOHpr3d4Q+H4xHDrmDhHiegubtQp6XhV60dVCc8HHZl9cbtMsSqhHzYZWbg5erKS UNj7ezXlvKVrs+U6G7uT0aGmFVszC3tcARuvrvVfv/Thuu7VBJ9GiYllKk9LYL6t2uyU i1gI3Zg7LQ5MOr6V9/sk8P5aUMiBY5JZUcMdhA3IWNb52Yq9AbJ9MU6A0PfzW/kOB+UP 452A== 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=is4i5Pu5m63D1Doc9Riyp/SV8y6By7O2qANFh09IC5k=; b=T7L+qut56e9W5z0K+Sxq8aUZo8prqG+fi2Q8xFjohF3bgMDxBzkPp/dhyUV6PYgQMe hL2OzdcWFVCGVwsnBEusMiLqi0WsQeD8MBZlv/6oM2xvNBXHalAHsz456+o9osjwDk2m uUBmQSk7xRAsKlRcNfyWdTTMFp0SZXWhIwVfhnnP+SBvgR52fL6KEoERv6tjzRYtdikB jYtgH40MtM1Ui+kQiFA9t1uutIjFuLIh5Dvxn9hBwF+jkrh5X7Jho9pIYbTSjCWLsWIo XoGAp/Jh2UVlA/T7M/UhAIbvTgsIyz1+mcXIJbPuyVANw7WRIt/PVVa2L2opmP8mvQf2 aXzg== X-Gm-Message-State: AGi0Pub8Ey27sCbuilirDbbf1Qp2fnceP2gZEc0JvCh8nyiMhPqID7HJ 0/sH/6Zl/c0qA1DlwqeJEor1nP+fd7U= X-Google-Smtp-Source: APiQypL9xjTCwCjc9RYPRvXH6THqPbp2UBT2hXe81azV6F0Eggv2d/mpoALUNG9wTp5U4BYM2HcQKw== X-Received: by 2002:a92:1d5b:: with SMTP id d88mr23697286ild.111.1589316292161; Tue, 12 May 2020 13:44:52 -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 x22sm846565ill.9.2020.05.12.13.44.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 13:44:51 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> Date: Tue, 12 May 2020 16:44:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [calsify] JSCalendar and EXRULE 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, 12 May 2020 20:44:55 -0000 I believe we should support this and I think it's only a minor change to the spec. I didn't agree with the deprecation of EXRULEs - there are a whole bunch of cases that are easily handled - just because UIs choose not to support it isn't that much of an argument. Try this article from 2008 for one https://blog.jonudell.net/2008/08/28/specifying-exceptions-to-recurring-calendar-events/ And this would be solved https://webapps.stackexchange.com/questions/136598/google-calendar-weekly-recurring-event-except-last-week-of-month My suggestion is to add the "excluded" property to the recurrence rule to flag it as an exrule.   "recurrenceRules" : [{       "@type" : "RecurrenceRule",      "excluded": true,      ...     }], From nobody Tue May 12 13:56: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 DD6F03A0B88 for ; Tue, 12 May 2020 13:56:23 -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, 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=fastmail.com header.b=HK+hGXQd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kiULKB0s 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 C8vwN2-1pbpR for ; Tue, 12 May 2020 13:56: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 43D9B3A0B74 for ; Tue, 12 May 2020 13:56:22 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 8616D7B4 for ; Tue, 12 May 2020 16:56:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 12 May 2020 16:56:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=fm2; bh=a uB5Lsy6Zd4Puveyf/xDzkU57F8BJr7LrhLP82cgkio=; b=HK+hGXQds6Rt0fso6 t8dtfnkHE1sHuMvpyK/oWlFKCLYPPXo97uQrJwnIVTrwbvBo1wgNyhXS5NJgLM/G pggWy+YNEFxytCldx39+9irnE4LtPpbdQ8p5Im0gU4t6zhRVcD62ijXy9R1nDUFQ VZYxwc4HRmjFq6ZBNRPlS6+F3gpNB8fpGPuHeh2c/eLqkxV1cAKZmueRh7fQbPFp HtXy3KxlUZ5lbhPr76TwQk1BUUnCgLkKEdZvYmuCYTc9CRhn1tLn/86TrQmDZiax XTCQ6wZzx+7hVfVX1apgylBZRAqlYnFLePjvdVSF76EqOcESWA1GK4I/uzBRl5RL z/kig== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=auB5Lsy6Zd4Puveyf/xDzkU57F8BJr7LrhLP82cgk io=; b=kiULKB0sa4TjwuJfsM77M3oMz3SLR1Z1n9gscWjoW4ti2nMIUz3SE3/35 b08UttanYhGiBD0wHQC0PJVECEWgPKQR2O4NAiDwtT04c4GhiPsXDEckuMnp6pGN NW58lXbVXVcpwv8ANyzJiTV9WQCJM0Loa7Li10GQnDWapVvCI7JxR8rHr1XrOLjt JpXO6tH91RGIaVP5hVfhHXnxLi3tkuxQHlNk7CKlOYz0pApnLpAX1TmezeRYrJoG cnH8cLdisdaV4ocagf2NCvRdt5tFdQTKhru75T2RZ93PN28uw5CplUxRli1e/Yyh cDXqkvEyjUptx23OwoB39PXs+iWNA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrledvgdduhedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgr shhtmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpefggfeufeegudeijeeltdehvd euueffleekgfdulefhvdfhueegudfgfeejffelteenucffohhmrghinhepjhhonhhuuggv lhhlrdhnvghtpdhsthgrtghkvgigtghhrghnghgvrdgtohhmpdhivghtfhdrohhrghenuc fkphepjeegrdejjedrkeehrddvhedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm 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 DCDA230662DB for ; Tue, 12 May 2020 16:56:20 -0400 (EDT) To: calsify@ietf.org References: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> From: Ken Murchison Message-ID: Date: Tue, 12 May 2020 16:56:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar and EXRULE 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, 12 May 2020 20:56:24 -0000 I'd also be in favor of adding EXRULEs, but I might name the property "exception", since EXRULE is described as Exception Rule in RFC 2445, but its not a strong preference. Hmm. On 5/12/20 4:44 PM, Michael Douglass wrote: > I believe we should support this and I think it's only a minor change > to the spec. > > I didn't agree with the deprecation of EXRULEs - there are a whole > bunch of cases that are easily handled - just because UIs choose not > to support it isn't that much of an argument. > > Try this article from 2008 for one > > https://blog.jonudell.net/2008/08/28/specifying-exceptions-to-recurring-calendar-events/ > > > And this would be solved > > https://webapps.stackexchange.com/questions/136598/google-calendar-weekly-recurring-event-except-last-week-of-month > > > My suggestion is to add the "excluded" property to the recurrence rule > to flag it as an exrule. > >   "recurrenceRules" : [{ >       "@type" : "RecurrenceRule", > >      "excluded": true, > >      ... >     }], > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Kenneth Murchison Senior Software Developer Fastmail US LLC From nobody Tue May 12 18:50: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 8E2543A0B5B for ; Tue, 12 May 2020 18:50:30 -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, 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 eJQAswHtr7NK for ; Tue, 12 May 2020 18:50:29 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 1A26E3A0B30 for ; Tue, 12 May 2020 18:50:28 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id w6so14421791ilg.1 for ; Tue, 12 May 2020 18:50:28 -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=ApXEajo51Zctz3eCX8q+JCpxwdZshHmdplc+1tdUVpk=; b=J7y03B53ToFwZzfu27Enu4J58dzZVbT61X12Gs7H29NW/NDdik9sDRm4ljirIXgxm/ 1a/crzMgF5LqS1Rml4Q5Nj4kuhtTpFdf76kqMwwMoM2gUkaX2DMq98APPKxbKC22xFqq +w7JOvergvPhK6cY8bN8HYMzHJGPTTCFINkdb9rCJLyx0ZzyoTyqV0RBGdVHGn9PsdVP HqoGzsumvNSe5yEcgfngdyQtjphjbAQ4JQQ2oRtra2AkQuYTNOPZONEgOcC6kUUeYsz+ NMuw3piIyGPr/8yQb/boYnOj3qdvxQ7PV/9e7BIaHdZOsn4z1L5qT5C8Ut/Q7yNZBpuO UV6g== 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=ApXEajo51Zctz3eCX8q+JCpxwdZshHmdplc+1tdUVpk=; b=MLcwJmOtxNYEF3fimHoU93jhZrmXjIYRz3xlup7hXZ+DRhWdAGUDPaaJxDG9tSCPXn rrAaQZMd6ILResn+BAEEfCOAiPYwP92TTbl4bB85kaGPL4fA2IoPrl2cwti6HZa5e2U2 X1UNXCQkaJzrZ/2+yqz3F3oEepth4EjwZEvBuVnOTQOxPMzYDsev2fx1p0ASQNWo4gx4 idkXPNw2c/shQESKB7/HHrwBSNHouXRP1YrhhZzW81UlhntT5Rek3PosRF7YmoyZ47u4 moF2aar+Wjz7LlVeIqu58CszmNsx5+drSyIeTz4i8J9v6TgAk5QQdsI2AuPL5s5HEBXJ inrA== X-Gm-Message-State: AGi0PuYmG3qGePEgdDvEi0VvDpZtUIg5OX8SHCVcm+dWPqr28ItDLQxv sUHuad0lygxO2XyMtrhzSCzKtB+NbOY= X-Google-Smtp-Source: APiQypJWDAU8u/P5J+IvQErm0hsE99nBKy2PNW6zFlzxr/KqP16X8LoWN+qXx5UDPgfj+rbl6TTR0A== X-Received: by 2002:a92:c911:: with SMTP id t17mr25476687ilp.229.1589334627727; Tue, 12 May 2020 18:50:27 -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 r1sm7239688ilg.61.2020.05.12.18.50.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 18:50:27 -0700 (PDT) To: calsify@ietf.org References: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> From: Michael Douglass Message-ID: <17fd5d99-91b2-09be-a906-a4f7f2d8afc6@gmail.com> Date: Tue, 12 May 2020 21:50:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 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] JSCalendar and EXRULE 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, 13 May 2020 01:50:31 -0000 On 5/12/20 16:56, Ken Murchison wrote: > I'd also be in favor of adding EXRULEs, but I might name the property > "exception", since EXRULE is described as Exception Rule in RFC 2445, > but its not a strong preference. I suggested "excluded" because it's already defined for an exdate. I'd be as happy to see them added as a separate property altogether. I guess it's also possible to just have another property altogether "exceptionRules" and maybe that's clearer. > > > Hmm. > > On 5/12/20 4:44 PM, Michael Douglass wrote: >> I believe we should support this and I think it's only a minor change >> to the spec. >> >> I didn't agree with the deprecation of EXRULEs - there are a whole >> bunch of cases that are easily handled - just because UIs choose not >> to support it isn't that much of an argument. >> >> Try this article from 2008 for one >> >> https://blog.jonudell.net/2008/08/28/specifying-exceptions-to-recurring-calendar-events/ >> >> >> And this would be solved >> >> https://webapps.stackexchange.com/questions/136598/google-calendar-weekly-recurring-event-except-last-week-of-month >> >> >> My suggestion is to add the "excluded" property to the recurrence >> rule to flag it as an exrule. >> >>   "recurrenceRules" : [{ >>       "@type" : "RecurrenceRule", >> >>      "excluded": true, >> >>      ... >>     }], >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > From nobody Sun May 17 05:18:04 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E5D3A103F for ; Sun, 17 May 2020 05:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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=ePmzFDdX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rUwKRvdd 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 QeJEhFOrgbGT for ; Sun, 17 May 2020 05:18:01 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FFEA3A103E for ; Sun, 17 May 2020 05:18:01 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 39FF05C0073 for ; Sun, 17 May 2020 08:18:00 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Sun, 17 May 2020 08:18:00 -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=6oxk8s0Y+bf9ewmDOmvcC9TIC/KNe+y+R1uiIcg ZnVc=; b=ePmzFDdXC1lXhxU7xqyWxzcUr3SAWMFO2Y4OEYrRFUQF5xz/4djfSHp VohBHH6iuAcxqM1xOfCMyZ/irnKtOfuFPMwnthJeu4CE6becLyjE8UPAxb0AdDyz htA1Ink57CCu2Al4PBQgmfuJcVWHqgDM+XCHLt2L0g0NvnWCmO59nWK2ghO4fhnF IitbAHoIH75ncR6cprnXWlDHlzrOnEN/qSn4ZyLVa+P5i6MsYvfIkAY0O8XDGB2v JCYHHZetaba6tkvpzdcR8TKfiZYddzk5AoCYUb6pYCs5fufXGdD2vFjvrffzqrNe OAjeAhbMn6iGRqQkP0Y57wRo9xdJFfg== 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=6oxk8s0Y+bf9ewmDOmvcC9TIC/KNe +y+R1uiIcgZnVc=; b=rUwKRvddJxxYPXNon9CVwsQ/SRrO59gvhP3ABieE94Xv4 Fq5I+m0xW97BlcfkL7a9h0suQM043nDOYuoHwI6kLCKWonCmcpz9czo65buyHuhl Qu4z16IPKUv3EfCCrkXqhR2KYvL/lW1NfA2Y5DRhzfhblVZNbyLggo/3ZTQQnm7A ckdbg+oeIXKVNAgsCqaV7s/XUm8Zu+qqodu2/r8T56ZDOfCEK0TsldDO0gFroGrd OIhrbP8mHyVnJsj+Ap7xuPjQFw/9jJrlRyNZv9fgSP7Jyj8RZN83aP824OMLjphl tR4PsQhFBbluiq/ATETDVxRRrraPZRYku+Mn8aKcw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddtfedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvteetieeviefhge eitdegiefgudevleehgfffleegleeuhefhiedtleegtdffgeenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C78CD180091; Sun, 17 May 2020 08:17:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1 Mime-Version: 1.0 Message-Id: <4ee8107e-0ed5-4168-9831-f084f5739d5c@dogfood.fastmail.com> Date: Sun, 17 May 2020 22:17:38 +1000 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=5db003d63bde4c5b83bf3bc6052b07fa Archived-At: Subject: [calsify] Upcoming interim meeting on June 18th 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, 17 May 2020 12:18:02 -0000 --5db003d63bde4c5b83bf3bc6052b07fa Content-Type: text/plain Hi All, I've requested a virtual interim meeting at 13:00 UTC for an hour on Thursday, June 18th. This is in conjunction with CalConnect as part of their virtual meeting in order to get crossover attendance. The topic of discussion will be the current drafts - I doubt we'll be adding any new work! Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --5db003d63bde4c5b83bf3bc6052b07fa Content-Type: text/html
Hi All,

I've requested a virtual interim meeting at 13:00 UTC for an hour on Thursday, June 18th.  This is in conjunction with CalConnect as part of their virtual meeting in order to get crossover attendance.  The topic of discussion will be the current drafts - I doubt we'll be adding any new work!

Cheers,

Bron.

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


--5db003d63bde4c5b83bf3bc6052b07fa-- From nobody Mon May 18 07:02:15 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 7EBBC3A0C78; Mon, 18 May 2020 07:02:04 -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: 6.130.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158981052448.23524.5426408464024172710@ietfa.amsl.com> Date: Mon, 18 May 2020 07:02:04 -0700 Archived-At: Subject: [calsify] Calendaring Extensions (calext) WG Virtual Meeting: 2020-06-18 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, 18 May 2020 14:02:11 -0000 The Calendaring Extensions (calext) Working Group will hold a virtual interim meeting on 2020-06-18 from 23:00 to 00:00 Australia/Melbourne (13:00 to 14:00 UTC). Agenda: Joint session with CalConnect We will be discussing the existing drafts and updating milestones. Information about remote participation: https://zoom.us/j/4574164360 or dial in by phone, see https://zoom.us/zoomconference for local numbers From nobody Mon May 18 11:46:07 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 956FB3A0D68 for ; Mon, 18 May 2020 11:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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, RCVD_IN_DNSWL_BLOCKED=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 YwOzmDc52sBw for ; Mon, 18 May 2020 11:45:57 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (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 0309A3A0B86 for ; Mon, 18 May 2020 11:45:56 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id e8so10878515ilm.7 for ; Mon, 18 May 2020 11:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=iTjkjwUKuK9q07ZaedPQC4WlRn47U0jKQ9v4pmSAThk=; b=n6p13bS+OYjhbfchixvgxwq5WGQu1aldTKssX+qSvaaZgOmhsSz+fLN8IQHktMTk/h SnXwoKt+sDbc0+hXydVP4RSdWfE+dYlQrkUTmgNg1b/Y29uI9nZW7UhlUmN5A2zBG0g3 tkBS+BMyuAOdJFv+pD16IUMXpVup2m4rEC6rzupOVL8SBB8r4BNA7toz+nwKm7su5tqw 0LrtCJQMc+RXze2BrHtpT2vu3t7iDqS/u5VznV86/0aMbwmPgj457CBmfeGg/+304xAV YNG/88Ph0sYcMMd1WMqmryj1LRG+TevQBVAdyxZ8p7aKOgKf0YUKHp0tu1NhRMTjr9bu HMBg== 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=iTjkjwUKuK9q07ZaedPQC4WlRn47U0jKQ9v4pmSAThk=; b=lr045G6f1KSFOMXOZ3UXpMfeejJulcK13dDzLd0mh6YF3k8S6Pqu8ZFxeMShmnfPSx SWRF+uJjvdiSYEG+nL+j6J/b+X//kjiAClRVhT+zbmBSSURDq+MVv9HVcRAVvHqrxUpx Cn6V/JxBXtscDIow1taMu2j4V7SDzTJupdyD072be5FlThKleU4TY/hKyElCOPailDpH hfl7x7YlzUMRSz6P/SdS8PN1sPuzmdcUeO/p/q4ZrMUxkOeY87vva0u7Lk+b0vBFgJKS FLSeBidymoT2CFrWtmXHJiO/e0aHIMc8jn2zTLPEVC+EP/soYBYt90SZeQxfbxpEqytY Vo+A== X-Gm-Message-State: AOAM533nT6rVok2d1K+QeMTIqqelR8iBssnK4BiksM8IOAmfLX6zEXOz IF9NWlkTpAvwxbEFLgAjZIcKKiEvtaA= X-Google-Smtp-Source: ABdhPJzhmKKA0HR0+jjHp7Gie60VIECSxFuQpApgncyNmliUmM4XZHp4FyQe0tESTb8yTRrSAoh2TQ== X-Received: by 2002:a92:507:: with SMTP id q7mr16960141ile.150.1589827555805; Mon, 18 May 2020 11:45:55 -0700 (PDT) Received: from MacBook-Pro-2019.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id s22sm5088749ilk.50.2020.05.18.11.45.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 May 2020 11:45:55 -0700 (PDT) To: Calsify From: Michael Douglass Message-ID: Date: Mon, 18 May 2020 14:45:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------DDAC8C1BB97365A7E619B59C" Content-Language: en-US Archived-At: Subject: [calsify] jscalendar - vendor specific extensions 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, 18 May 2020 18:46:05 -0000 This is a multi-part message in MIME format. --------------DDAC8C1BB97365A7E619B59C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit We have: 3.2. Vendor-specific Property Extensions and Values Vendors MAY add additional properties to the calendar object to support their custom features. The names of these properties MUST be prefixed with a domain name controlled by the vendor to avoid conflict, e.g., "example.com/customprop". Some JSCalendar properties allow vendor-specific value extensions. Such vendor-specific values MUST be prefixed with a domain name controlled by the vendor, e.g., "example.com/customrel". Vendors are strongly encouraged to register any new property values or extensions that are useful to other systems as well, rather than use a vendor-specific prefix. Should that last paragraph say more? Would anybody be able to register an extension that doesn't have an associated RFC? --------------DDAC8C1BB97365A7E619B59C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

We have:

3.2.  Vendor-specific Property Extensions and Values

   Vendors MAY add additional properties to the calendar object to
   support their custom features.  The names of these properties MUST be
   prefixed with a domain name controlled by the vendor to avoid
   conflict, e.g., "example.com/customprop".

   Some JSCalendar properties allow vendor-specific value extensions.
   Such vendor-specific values MUST be prefixed with a domain name
   controlled by the vendor, e.g., "example.com/customrel".

   Vendors are strongly encouraged to register any new property values
   or extensions that are useful to other systems as well, rather than
   use a vendor-specific prefix.

Should that last paragraph say more? Would anybody be able to register an extension that doesn't have an associated RFC?


--------------DDAC8C1BB97365A7E619B59C-- From nobody Thu May 21 02:35:08 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 E39F33A0B5E for ; Thu, 21 May 2020 02:35:05 -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=UpMPza3E; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KTlsBLoe 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 0o9B32LlNtXG for ; Thu, 21 May 2020 02:35:04 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F3B3A0B5B for ; Thu, 21 May 2020 02:35:04 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 2ACCAA26 for ; Thu, 21 May 2020 05:35:04 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Thu, 21 May 2020 05:35:04 -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=kinlsHQ kv4CfCisWe+XK2a79JHkKHxPVfCJFpexXDQI=; b=UpMPza3EHRSeatn0ukLGYtP LWcTSZEcdvDjnYWxg+klg00PxR6twHEORynDdU0+I8JGHrzajwx/LGOaWFV4ArDW qcwnEXdz6rIQS6uTWNFKhZ9BJTEHxpSiLVz5bi852uucgZAfCLgzPL1g3lbbblN3 XrMKb1lBR3sBPmq0rSpDk3D2N/A+QVR8rrw+4CmE+ADQ4bjgEs1ywWhP7oTOj8t8 mPwOsrBQUIV43Kepo9QFOyflU5ftyWRzhyWtTZKlopeM5Q00gfLsr8KbOPIvCRnh kRxUKd9s9mZ7OapNUvdNLl3FhTf22oZ1XVQpuOaqaBdIluS9tFH2DeGbrtBlBfQ= = 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=kinlsH Qkv4CfCisWe+XK2a79JHkKHxPVfCJFpexXDQI=; b=KTlsBLoeWHzbcaiFhVnj1t tOXO5YGPsxXjO/T0/iOELC+7QULGkAv/8F9XsHob9JkU4Pfu348P+NFb+o3aAXOG Tx6H7xNlQwLbbgAhYAyHYEhCpO/EBTsEU0SW7v2sSX7lNW+5uIdvI1jfmXE8tnJj J58ZgX5fEztIejraC54LV7K2/bWrVSQN5CGpRlCG1ewPEHpYJa9U9KgXtJk1m2wY WUuoxOrYUER1sAwvHrnpOYFuaXQyqUfjrL3AUzUO6QRbX9wMCDOx46YHN3NQ1FjK 8k3IfCZMNobp1MvHGIf/r0blkKAlGrRDHuygDIpKDRcU6MI442Mzyb6+b+jDCuog == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudduuddgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepvedvtedvudelke fhgefhteeftedtlefhheefveffveelkedutdduffeiveejvefhnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrih hlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7714B180091; Thu, 21 May 2020 05:35:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-487-g38013f6-fm-20200519.001-g38013f6c Mime-Version: 1.0 Message-Id: <48c80490-ddf3-44ff-a9f9-d5ca39b5a331@beta.fastmail.com> In-Reply-To: References: Date: Thu, 21 May 2020 19:35:01 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=d83c943fa5af40b8b503e6e2b65126cb Archived-At: Subject: Re: [calsify] jscalendar - vendor specific extensions 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, 21 May 2020 09:35:06 -0000 --d83c943fa5af40b8b503e6e2b65126cb Content-Type: text/plain On Tue, 19 May 2020, at 04:45, Michael Douglass wrote: > Should that last paragraph say more? Would anybody be able to register an extension that doesn't have an associated RFC? I think this is all covered in the IANA section. Short answer: no, you don't need a full RFC, just sufficient permanent documentation for interoperability. Neil. --d83c943fa5af40b8b503e6e2b65126cb Content-Type: text/html
On Tue, 19 May 2020, at 04:45, Michael Douglass wrote:
Should that last paragraph say more? Would anybody be able to register an extension that doesn't have an associated RFC?

I think this is all covered in the IANA section. Short answer: no, you don't need a full RFC, just sufficient permanent documentation for interoperability.

Neil.
--d83c943fa5af40b8b503e6e2b65126cb-- From nobody Fri May 22 00:11:37 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 340373A0CAF for ; Fri, 22 May 2020 00:11:35 -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=cqCwBmwQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BPobs0oI 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 0HnrPDv-0PZ7 for ; Fri, 22 May 2020 00:11:33 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6A783A0C5F for ; Fri, 22 May 2020 00:11:33 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 74A1E2BC for ; Fri, 22 May 2020 03:11:32 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Fri, 22 May 2020 03:11:32 -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=qIiXCj2 QT6p7GpH8BrJR0upMKwN8dnvHviBS97+o6Aw=; b=cqCwBmwQPB2nEQM49RJPuoE Xh1kAtTgD3hlkitClM+Lfd22KyB7QHHDU2pOZlqIYEoBGUp6vZgQ4slz7r/2dxwe lEbbyPS9OB9zUF04pZ1XORfi+P60CII6AWIMGV6rao2SfSsR0FnH4QnPVhsD8NWj v/MhchnvAuyz82RVX4sFZrqBmJ77qhcLozn0c+g94vgyYz2n1B/G8bacpLcNE5oE JZWmCAnkRnFXY9xZxhVfqydufA1RuYkRMZcTGn0SUNHru+ViLUYZVdIF61kaDSoB rjrU2w9H+znSlq+VIu95M5P1FL3ItLecQ7NIHqcB0NzwQrGUPnhNgJWDrw4/DVQ= = 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=qIiXCj 2QT6p7GpH8BrJR0upMKwN8dnvHviBS97+o6Aw=; b=BPobs0oI+K0vDuxIRPiltc Cf38KPah6DOJAa5lztUA4Pey6Vyo2+GgK7f2larRX1eHKty49bUJ8rGsDTWrfrdF KUF0+Xog7/qJ0kwLVlHowzamxxq6SP+M4Xq23NBPoqU2NQZGsjZDQu43x/h99RQL pt3KzjlgNlL6wHjx7eXLqFsp/RXO9wM90drh/zfxxBnAH1wrV7YoPVVSoufWLnqg zC0oFzq+uz+I4Hc+dmkaSrvuZKZu9IVkL8OnmkrMb74ak5m4/Ig1S4lhL5Wc9CHs qq5hXgXkjRhrODdNctduVUio3aRJ+LnzwpjJ6U+WpxwcMgJMTFFqDmFNs9mA1ymQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudduvddguddugecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeevvdetvddule ekhfeghfetfeettdelhfehfeevffevleekuddtudffieevjeevhfenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B9E82180097; Fri, 22 May 2020 03:11:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-487-g38013f6-fm-20200519.001-g38013f6c Mime-Version: 1.0 Message-Id: In-Reply-To: <17fd5d99-91b2-09be-a906-a4f7f2d8afc6@gmail.com> References: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> <17fd5d99-91b2-09be-a906-a4f7f2d8afc6@gmail.com> Date: Fri, 22 May 2020 17:11:22 +1000 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=d83d3373882542cebb2432dbac72ce10 Archived-At: Subject: Re: [calsify] JSCalendar and EXRULE 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, 22 May 2020 07:11:35 -0000 --d83d3373882542cebb2432dbac72ce10 Content-Type: text/plain On Wed, 13 May 2020, at 11:50, Michael Douglass wrote: > I guess it's also possible to just have another property altogether > "exceptionRules" and maybe that's clearer. Yes, if we do this I think a separate property make much more sense, and "exceptionRules" sounds like a reasonable choice for its name. I guess this is fine; if you don't support it and receive an object with it set, it's just like if you get multiple recurrence rules and don't support that, or a recurrence property you don't support (e.g. you might not support non-Gregorian recurrences); in any of these cases you would just have to communicate to the user that you don't support expanding the recurrences for this event. Neil. --d83d3373882542cebb2432dbac72ce10 Content-Type: text/html
On Wed, 13 May 2020, at 11:50, Michael Douglass wrote:
I guess it's also possible to just have another property altogether 
"exceptionRules" and maybe that's clearer.

Yes, if we do this I think a separate property make much more sense, and "exceptionRules" sounds like a reasonable choice for its name. I guess this is fine; if you don't support it and receive an object with it set, it's just like if you get multiple recurrence rules and don't support that, or a recurrence property you don't support (e.g. you might not support non-Gregorian recurrences); in any of these cases you would just have to communicate to the user that you don't support expanding the recurrences for this event.

Neil.
--d83d3373882542cebb2432dbac72ce10-- From nobody Fri May 22 00:26:40 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 CDE1A3A0F30 for ; Fri, 22 May 2020 00:26:38 -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=TzPxbZcT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rCoYkcVI 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 Of2m7IsNEK2z for ; Fri, 22 May 2020 00:26:37 -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 C219D3A0EEE for ; Fri, 22 May 2020 00:26:37 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 0843B5C00FB for ; Fri, 22 May 2020 03:26:37 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute7.internal (MEProxy); Fri, 22 May 2020 03:26:37 -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=Q46qJ3n pir7PFw/CaVgKDMmXOq+Sa5tdnFHUq1WvgXA=; b=TzPxbZcTam5NP7vVaJmTJJP Vg/JWqowKqbZUpCCeleEKVSqOVCwn2j3isUJYc4Eh3k74S6VSHoMwbh5o14jFMyy wMLqrPv8ShQK9759Dwly1bNCg6Yg3LiUSHTyAwTVNG7UXqjfx/02ZuhCPftSUnhb bejmBLzKIrdALvIe0072nauK6o5azV90tD9vEVmx7eI3c58WKPKU1vV2oJ1W3SQ7 UsfcRBTqeHVz072TM7n9X4l2nNXzgspD4E6o0MohJ8WQzO/p4f0AXoVenmwReG2y l57alsOKoLdRmo43CQ5f33WUufUNuaWTN20hyzRaMKNedtuTKV80XcI2GZkMLPQ= = 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=Q46qJ3 npir7PFw/CaVgKDMmXOq+Sa5tdnFHUq1WvgXA=; b=rCoYkcVIDHVH4LrM37Vg9T kMUNc6RJefKPmjXkRBELKQWbe9KQXNHbIaMXbLq6X+12TyUdufmmbZETxhtj3yep cdWGFVh4Bvkv9woqHp0dHjLeDLQffzMntAdu9g+Wl7YjJKNO5Vni+klaGY9sP8uG BjnV/GBZgcQpxKpNmym8PhjDDH8nv7GSfvn6uhaIEBKmcfRTF12iVl3iie3Zb7lY 9VZO218/XoxLvpa1DQdN2rn+RQ/aszOwh51nYGEh/nGpSALj5aV5ZbJ8V1TUr513 MGpihfO4sPRKFTZypA9Pj+lwKCBFA67rWf0tfykc7P0Knt3UXokmISiU0R2fMWfg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudduvddgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshht ohesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeehgeeuvd dtkefhtefgueefgfdvueetgeeffeelhedvudegjeejhfetuefgveevieenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmh grihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B4646180097; Fri, 22 May 2020 03:26:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-487-g38013f6-fm-20200519.001-g38013f6c Mime-Version: 1.0 Message-Id: <987d6aa6-a4d7-4ebf-9129-e87d7fcd6256@www.fastmail.com> In-Reply-To: References: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> <17fd5d99-91b2-09be-a906-a4f7f2d8afc6@gmail.com> Date: Fri, 22 May 2020 09:26:16 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=c0d75faf61d94543a9f18ab22a328b22 Archived-At: Subject: Re: [calsify] JSCalendar and EXRULE 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, 22 May 2020 07:26:39 -0000 --c0d75faf61d94543a9f18ab22a328b22 Content-Type: text/plain On Fri, May 22, 2020, at 9:11 AM, Neil Jenkins wrote: > On Wed, 13 May 2020, at 11:50, Michael Douglass wrote: >> I guess it's also possible to just have another property altogether >> "exceptionRules" and maybe that's clearer. > > Yes, if we do this I think a separate property make much more sense, and "exceptionRules" sounds like a reasonable choice for its name. In the TC-CALENDAR call of this week we preferred "excludedRecurrenceRules" (or "excludedRules"). We already use "excluded" in recurrenceOverrides for EXDATE, so the naming would be consistent. Cheers, Robert --c0d75faf61d94543a9f18ab22a328b22 Content-Type: text/html
On Fri, May 22, 2020, at 9:11 AM, Neil Jenkins wrote:
On Wed, 13 May 2020, at 11:50, Michael Douglass wrote:
I guess it's also possible to just have another property altogether 
"exceptionRules" and maybe that's clearer.

Yes, if we do this I think a separate property make much more sense, and "exceptionRules" sounds like a reasonable choice for its name.

In the TC-CALENDAR call of this week we preferred "excludedRecurrenceRules" (or "excludedRules"). We already use "excluded" in recurrenceOverrides for EXDATE, so the naming would be consistent.

Cheers,
Robert

--c0d75faf61d94543a9f18ab22a328b22-- From nobody Sat May 23 02:34:30 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 C41143A0AB3 for ; Sat, 23 May 2020 02:34: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=vcJ9TAcE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dnfwUxKF 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 SI3Qf3e_X7aO for ; Sat, 23 May 2020 02:34:25 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B533A0AB2 for ; Sat, 23 May 2020 02:34:25 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 24E745C007B for ; Sat, 23 May 2020 05:34:23 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute7.internal (MEProxy); Sat, 23 May 2020 05:34:23 -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=w+8ftSk a11vBawFC26zSYZ/84gdARyjzZlwvlVZNjYI=; b=vcJ9TAcEW1dETgWJMKWQ0Ae PEEpyKFjvHQ6xyhVbhYI6jlUqumnVkXvPNw+1S6pm0xMNacOFyDTy6S8YK3FJ0/k b4t+JEejps3NRWcAKdkoN1zauAZ9Db7XE815dKfM/T9WlEVqnHySfTMe3hJOBdQt cRCm5u2ibe/N5qOn7sBR4qlYb3AzwPcoWPek9ujydiWqwsaJlv2+QjdunraaBkDk L15NDJ2X84hjHsOnpDrzqJtgE8PWGIwPk1vXGoEBLuGCtoE2s3O1XTMRk4zcnt3N a0uevcSclictW8tTnKpFULxHoI+dB5j2mH5zTlMhhaD/+k98S+J05vmPA+3c53g= = 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=w+8ftS ka11vBawFC26zSYZ/84gdARyjzZlwvlVZNjYI=; b=dnfwUxKFQjDKE1h4iZRJZa r+RzUptNmtskpizccsZQG+WYiXLorSNFkl480t7ja3zG+1Ty3L5nBkjtVI+AE0Ki MweSH5Z1XtO+ULEmhb0NB0IQwqt2mnuhB5uoV8DgINXHvvFbqnRwP7ooed9Inh3A BHNETz8bPTDO13GAc0VJbHAybukbERVTfc4Jl74H1SF/B2633WS4EhfXpo5f3+R7 lJMrDcxpxRvHXTp6VgOyubDc6qg98ufjilCx19BdjqYOAiCJkhZBli052zPVWweA j9gUOFC23/U+bY2rWcf1QXtRUfdIp2446NS7jjAMEwItFpg1wyo0bBvyh1etwigA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudduhedgudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnheptefhffffke eukeevleelgeelhfegfeejueegteekjeekgfdthfehhedvheehvdfhnecuffhomhgrihhn pehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A89E6180096; Sat, 23 May 2020 05:34:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-488-g9249dd4-fm-20200522.001-g9249dd48 Mime-Version: 1.0 Message-Id: <299506d2-2806-40eb-97a4-17a305fae75c@www.fastmail.com> In-Reply-To: <987d6aa6-a4d7-4ebf-9129-e87d7fcd6256@www.fastmail.com> References: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> <17fd5d99-91b2-09be-a906-a4f7f2d8afc6@gmail.com> <987d6aa6-a4d7-4ebf-9129-e87d7fcd6256@www.fastmail.com> Date: Sat, 23 May 2020 11:34:02 +0200 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=4b504d3e9b5c4160a8896d571185bbac Archived-At: Subject: Re: [calsify] JSCalendar and EXRULE 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: Sat, 23 May 2020 09:34:28 -0000 --4b504d3e9b5c4160a8896d571185bbac Content-Type: text/plain On Fri, May 22, 2020, at 9:26 AM, Robert Stepanek wrote: > On Fri, May 22, 2020, at 9:11 AM, Neil Jenkins wrote: >> On Wed, 13 May 2020, at 11:50, Michael Douglass wrote: >>> I guess it's also possible to just have another property altogether >>> "exceptionRules" and maybe that's clearer. >> >> Yes, if we do this I think a separate property make much more sense, and "exceptionRules" sounds like a reasonable choice for its name. > > In the TC-CALENDAR call of this week we preferred "excludedRecurrenceRules" (or "excludedRules"). We already use "excluded" in recurrenceOverrides for EXDATE, so the naming would be consistent. I'm not sure I got the EXRULE semantics right: RFC 2245 defines for EXRULE [1]: "The final recurrence set is generated by gathering all of the start date/times generated by any of the specified "RRULE" and "RDATE" properties, and excluding any start date/times which fall within the union of start date/times generated by any specified "EXRULE" and "EXDATE" properties." This seems to imply that the DTSTART of a recurrence instance, rather than its RECURRENCE-ID must be considered in relation to EXRULE? If so, then any time zone differences between overridden recurrence instance start times and EXRULE instances must be considered? Also, is a recurrence instance excluded if its DTSTART falls in the time range of the start and end time of an excluded recurrence instance? Or is only the exact start time relevant? Thanks, Robert [1] https://tools.ietf.org/html/rfc2445#section-4.8.5.2 --4b504d3e9b5c4160a8896d571185bbac Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Fri, Ma= y 22, 2020, at 9:26 AM, Robert Stepanek wrote:
On Fri, May 22, 2020, at 9:11 AM, Ne= il Jenkins wrote:
On Wed, 13 May 2020, at 11:50, Michael Douglass wrote:
I guess it's also possible to just have another property altogether 
"exceptionRules" and maybe that's clearer.

Yes, if we do this I think a separate property make much more sense, and "exceptionRules" sounds like a reasonable choice for its name.

In the TC-CALENDAR call of this week we preferred "excl= udedRecurrenceRules" (or "excludedRules"). We already use "excluded" in = recurrenceOverrides for EXDATE, so the naming would be consistent.

I'm not sure I got the EXRULE seman= tics right:

RFC 2245 defines for EXRULE [1]= : "The final recurrence set is generated by gathering all of the start d= ate/times generated by any of the specified "RRULE" and "RDATE" properti= es, and excluding any start date/times which fall within the union of st= art date/times generated by any specified "EXRULE" and "EXDATE" properti= es."

This seems to imply that the DTSTART o= f a recurrence instance, rather than its RECURRENCE-ID must be considere= d in relation to EXRULE?

If so, then any ti= me zone differences between overridden recurrence instance start times a= nd EXRULE instances must be considered? Also, is a recurrence instance e= xcluded if its DTSTART falls in the time range of the start and end time= of an excluded recurrence instance? Or is only the exact start time rel= evant?

Thanks,
Robert


--4b504d3e9b5c4160a8896d571185bbac-- From nobody Sat May 23 15:44:13 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 B33973A0F24 for ; Sat, 23 May 2020 15:44:10 -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 WNQV8Txs8zhj for ; Sat, 23 May 2020 15:44:08 -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 BEF2B3A0F20 for ; Sat, 23 May 2020 15:44:08 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id w3so8898290qkb.6 for ; Sat, 23 May 2020 15:44:08 -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=xCou53HQokfBCpRR7yLMfVtkLibyZRwUvMEIW//JxtM=; b=kP/4YoUrTaeBs85Pp6WqyMBwhQpp6FMQZWvwjsvmM/wJQ/p53QKBgL5641KJRTvOVd Wgig+MviPgJiUdsFziFrJSnORgdhqHgBfWxdt0NKZdrEXcp8YlgtC0+ydpin0MjSg9as 7pARQsnKlI7NpINOATGdQGrP36+2RhPZt6ej/00mCRCM9IOMqp6DgDZNfSkAYSJejkE2 Pwn9cszIOZEJFzPG09cfYKfJjInn3YHZAy8S5hePPsRq2yLFtL5hY9kt3qgNvI2gPld8 oBWQUI6RGn7Lb2eBEPwR4X55evQK01wV4/0S8N0Qmpj3AaMgo3kpTWJW19JSE/yzmTaY FQmg== 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=xCou53HQokfBCpRR7yLMfVtkLibyZRwUvMEIW//JxtM=; b=W2v9OLRL7BLpVxj1J/gX1+fh8jq2vUcvDv46O4FC3Agac5vjhkwuMY+p+XRHSRe1LE NFsmILlSgYWJky3uUxBAnvgu5htrHLYs+IsKVwyiKIvN1uEhltaff5HesNFwZu0Uioox ymWdqeVoWJkN9jHZACsvncuSr/mXisrBPNRo/egrTrfWHjaJs/YSZz75LC0Nwcqb5a2o QSCxi+/7/cDWwBBZ2RNbIt5zoDytBjd4/bsu6YkwC8jSD27HLsi+BX6xnOWiA6RrGfpR ctlEW7LRGpHjym4ziv3tFA/EErO3JYP+CahYeZy5/+vx42JlygCCQNrEdc170AZ5PYlS X1oA== X-Gm-Message-State: AOAM533ej6YvhrhK8tls3bFoGF4+T2eJ+i4bojtHm/H/iG59eMElxrNB zOl3IEcd7ZMQq+uGkko6KuQQaCWu X-Google-Smtp-Source: ABdhPJwV3psZNQFkwGjplmLPDqn1fj3H6zLt1PTv/WSvJA1H0ZoG6gau9ICqvk09xAkI4wHsWAj93Q== X-Received: by 2002:a37:7246:: with SMTP id n67mr11538441qkc.303.1590273847381; Sat, 23 May 2020 15:44:07 -0700 (PDT) Received: from MacBook-Pro-2019.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id q34sm1563436qtd.89.2020.05.23.15.44.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 May 2020 15:44:06 -0700 (PDT) To: Robert Stepanek , calsify@ietf.org References: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> <17fd5d99-91b2-09be-a906-a4f7f2d8afc6@gmail.com> <987d6aa6-a4d7-4ebf-9129-e87d7fcd6256@www.fastmail.com> <299506d2-2806-40eb-97a4-17a305fae75c@www.fastmail.com> From: Michael Douglass Message-ID: <1e7c6994-5783-72fd-1e93-e378e4a42f49@gmail.com> Date: Sat, 23 May 2020 18:44:05 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <299506d2-2806-40eb-97a4-17a305fae75c@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------A79366743B9D81B604F65AFA" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar and EXRULE 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: Sat, 23 May 2020 22:44:11 -0000 This is a multi-part message in MIME format. --------------A79366743B9D81B604F65AFA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 5/23/20 05:34, Robert Stepanek wrote: > On Fri, May 22, 2020, at 9:26 AM, Robert Stepanek wrote: >> On Fri, May 22, 2020, at 9:11 AM, Neil Jenkins wrote: >>> On Wed, 13 May 2020, at 11:50, Michael Douglass wrote: >>>> I guess it's also possible to just have another property altogether >>>> "exceptionRules" and maybe that's clearer. >>> >>> Yes, if we do this I think a separate property make much more sense, >>> and "exceptionRules" sounds like a reasonable choice for its name. >> >> In the TC-CALENDAR call of this week we preferred >> "excludedRecurrenceRules" (or "excludedRules"). We already use >> "excluded" in recurrenceOverrides for EXDATE, so the naming would be >> consistent. > > I'm not sure I got the EXRULE semantics right: > > RFC 2245 defines for EXRULE [1]: "The final recurrence set is > generated by gathering all of the start date/times generated by any of > the specified "RRULE" and "RDATE" properties, and excluding any start > date/times which fall within the union of start date/times generated > by any specified "EXRULE" and "EXDATE" properties." > > This seems to imply that the DTSTART of a recurrence instance, rather > than its RECURRENCE-ID must be considered in relation to EXRULE? > > If so, then any time zone differences between overridden recurrence > instance start times and EXRULE instances must be considered? Also, is > a recurrence instance excluded if its DTSTART falls in the time range > of the start and end time of an excluded recurrence instance? Or is > only the exact start time relevant? I guess this is another instance of the confusing text around recurrences. What we are calculating or excluding are recurrence-ids and i think the text might have been better specified that way? For an instance that isn't overridden the start is the same as the recurrence-id. An override can change the date/time or zone but that's true for RRULE > > > Thanks, > Robert > > [1] https://tools.ietf.org/html/rfc2445#section-4.8.5.2 > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------A79366743B9D81B604F65AFA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 5/23/20 05:34, Robert Stepanek wrote:
On Fri, May 22, 2020, at 9:26 AM, Robert Stepanek wrote:
On Fri, May 22, 2020, at 9:11 AM, Neil Jenkins wrote:
On Wed, 13 May 2020, at 11:50, Michael Douglass wrote:
I guess it's also possible to just have another property altogether 
"exceptionRules" and maybe that's clearer.

Yes, if we do this I think a separate property make much more sense, and "exceptionRules" sounds like a reasonable choice for its name.

In the TC-CALENDAR call of this week we preferred "excludedRecurrenceRules" (or "excludedRules"). We already use "excluded" in recurrenceOverrides for EXDATE, so the naming would be consistent.

I'm not sure I got the EXRULE semantics right:

RFC 2245 defines for EXRULE [1]: "The final recurrence set is generated by gathering all of the start date/times generated by any of the specified "RRULE" and "RDATE" properties, and excluding any start date/times which fall within the union of start date/times generated by any specified "EXRULE" and "EXDATE" properties."

This seems to imply that the DTSTART of a recurrence instance, rather than its RECURRENCE-ID must be considered in relation to EXRULE?

If so, then any time zone differences between overridden recurrence instance start times and EXRULE instances must be considered? Also, is a recurrence instance excluded if its DTSTART falls in the time range of the start and end time of an excluded recurrence instance? Or is only the exact start time relevant?

I guess this is another instance of the confusing text around recurrences. What we are calculating or excluding are recurrence-ids and i think the text might have been better specified that way?

For an instance that isn't overridden the start is the same as the recurrence-id.

An override can change the date/time or zone but that's true for RRULE



Thanks,
Robert

 


_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------A79366743B9D81B604F65AFA-- From nobody Sun May 24 02:15:10 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C63D3A0061 for ; Sun, 24 May 2020 02:15:07 -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=kI5X0Ptv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zqbTP0v4 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 kndIpY72HIHQ for ; Sun, 24 May 2020 02:15:05 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80893A005D for ; Sun, 24 May 2020 02:15:04 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id B0FAA5C00B7; Sun, 24 May 2020 05:15:01 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute7.internal (MEProxy); Sun, 24 May 2020 05:15: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=fm2; bh=3ZpnwRu T5v18O6HmEL5HuxIri3qJzs6n0z91gY38rZk=; b=kI5X0Ptvl5iocF0wZKH/A2Y fZ6nt7214FnIGkjvB7ojIf090pH9FRv5vzHUfccQ83b041qlPhJOcA7Ke+yQ3rXA U5MINTbu79zOQ3wg9S40fRoBhuj6/nPRnznu5HupmXf7Q8RB4pLzFa+YQD3XHl2K pHM5WlkUo6qn6LCUPMY9A8S/FaOVlkDi8H86MmfsN9SaekDpiynWeAKT2+endrPp 8eDcGr7UlvEzRKCclEvNIaWxT6nc2oqI7jajbMvbXMrSje/huR3UjwM2vnQrs+Qz 8LVsrUP9wKoFMZ3Hony0EwuZINaOBe1275PoJu02oZ0KlGsJsaWr4sLCdHLY7Cg= = 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=3ZpnwR uT5v18O6HmEL5HuxIri3qJzs6n0z91gY38rZk=; b=zqbTP0v4EM96Mp8Eh3sdB6 b4UD+eh7st5HN9M3Ax7skmktDkrkDmCE7wRQ8CNHb7LcP9xzj/bm0OHh9wbTOTlB xQH+WLpAt3qL43XYHdfDzIbJ8U3mTZsu5z6KwaagCqD3mSt7UE531DCP5afUIcgg DsmifWWq23XIls93J2b+kqbWaHLwFe0UF8ee2s7xookT7kyJ1w3ddwGqgKm+wlsP zEdm2pSxmeG9JuCwpzp3zLCQxNJQaMTBuOUNrlbgFFrz+4YVNgkvpgvwFEiv1Iye Ns8jRbXv9TH85358K12H9sP3t7SEzXC1vwMaoTnYsMNSbJjkM/rmOZbJnrzFQ5Ww == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddukedgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdftohgs vghrthcuufhtvghprghnvghkfdcuoehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtoh hmqeenucggtffrrghtthgvrhhnpeehgeeuvddtkefhtefgueefgfdvueetgeeffeelhedv udegjeejhfetuefgveevieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3790B180091; Sun, 24 May 2020 05:15:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-488-g9249dd4-fm-20200522.001-g9249dd48 Mime-Version: 1.0 Message-Id: In-Reply-To: <1e7c6994-5783-72fd-1e93-e378e4a42f49@gmail.com> References: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> <17fd5d99-91b2-09be-a906-a4f7f2d8afc6@gmail.com> <987d6aa6-a4d7-4ebf-9129-e87d7fcd6256@www.fastmail.com> <299506d2-2806-40eb-97a4-17a305fae75c@www.fastmail.com> <1e7c6994-5783-72fd-1e93-e378e4a42f49@gmail.com> Date: Sun, 24 May 2020 11:14:41 +0200 From: "Robert Stepanek" To: "Michael Douglass" , calsify@ietf.org Content-Type: multipart/alternative; boundary=bcb9df6d501641c898816c1a1325f371 Archived-At: Subject: Re: [calsify] JSCalendar and EXRULE 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, 24 May 2020 09:15:08 -0000 --bcb9df6d501641c898816c1a1325f371 Content-Type: text/plain On Sun, May 24, 2020, at 12:44 AM, Michael Douglass wrote: > I guess this is another instance of the confusing text around recurrences. What we are calculating or excluding are recurrence-ids and i think the text might have been better specified that way? > For an instance that isn't overridden the start is the same as the recurrence-id. > An override can change the date/time or zone but that's true for RRULE OK, so an EXRULE excludes RECURRENCE-ID and RDATE, right? Cheers, Robert --bcb9df6d501641c898816c1a1325f371 Content-Type: text/html
On Sun, May 24, 2020, at 12:44 AM, Michael Douglass wrote:

I guess this is another instance of the confusing text around recurrences. What we are calculating or excluding are recurrence-ids and i think the text might have been better specified that way?

For an instance that isn't overridden the start is the same as the recurrence-id.

An override can change the date/time or zone but that's true for RRULE


OK, so an EXRULE excludes RECURRENCE-ID and RDATE, right?

Cheers,
Robert

--bcb9df6d501641c898816c1a1325f371-- From nobody Sun May 24 02:42: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 00CC73A0784 for ; Sun, 24 May 2020 02:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOFjgqQOjNMT for ; Sun, 24 May 2020 02:42:15 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ABC13A07BD for ; Sun, 24 May 2020 02:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9663; q=dns/txt; s=iport; t=1590313335; x=1591522935; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=dtbi5SZesJohOL4Rw2uj+OuyQfiB3QHeRbnjOSwkKxU=; b=d44awqYaJYq25d0/giWrDVvCb6OwkZ5FfHK3pN+l73Oro+cApPP5F587 vjYW0CVx0y1+1UDoVEh3yaN0egjUQ6dwElS4FoDw9Gply06BmtIHf0EG4 v9SnHLbT37b6pIdMh+3JSltJXFWzmg0opdVXWZLFoWRO/MMbPiwjC7uIx g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTBAC+QMpe/xbLJq1lHgEBCxIMgXw?= =?us-ascii?q?LgSVYgR5UASASLIQkiQGICol6iVyGFBSBaAsBAQEMAQEnCAQBAYN/RQKCQTU?= =?us-ascii?q?IDgIDAQELAQEFAQEBAgEFBG2FVgyFcgEBAQECASNWBQsLDgoqAgIhNgYTglt?= =?us-ascii?q?LAYJLAw4gD6sHdoEyhDoBCwGBCoJwDYIcBoE4jF6CAIERJxyCTT6CHkkEgUm?= =?us-ascii?q?DLjOCLQSORA8zo1ZKgl6CdIU1i1eEXB2QRog/hH2RM4kJgkyLUoINg0kCBAY?= =?us-ascii?q?FAhWBUwE3NoEgMxoIGxVlAYIKAQEyEiwSGA2QTBeDT4RZhX8/AzA3AgYBBwE?= =?us-ascii?q?BAwmNVwEB?= X-IronPort-AV: E=Sophos; i="5.73,429,1583193600"; d="scan'208,217"; a="26410346" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 May 2020 09:42:10 +0000 Received: from [10.61.168.109] ([10.61.168.109]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 04O9gASx009974 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 24 May 2020 09:42:10 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E39BDC18-BBCF-4BB6-9A98-D1754607AD03" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 24 May 2020 11:42:09 +0200 In-Reply-To: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> Cc: Calsify To: Michael Douglass References: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.168.109, [10.61.168.109] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [calsify] JSCalendar and EXRULE 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, 24 May 2020 09:42:19 -0000 --Apple-Mail=_E39BDC18-BBCF-4BB6-9A98-D1754607AD03 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi! > On 12 May 2020, at 22:44, Michael Douglass = wrote: >=20 > I believe we should support this and I think it's only a minor change = to the spec. >=20 > I didn't agree with the deprecation of EXRULEs - there are a whole = bunch of cases that are easily handled - just because UIs choose not to = support it isn't that much of an argument. Before you readd EXRULE or anything like it, it is probably worth = understanding why it was removed. There were several reasons: Almost nobody (nobody?) in the WG at the time said the they had = implemented it. I believe this is because the UI for EXRULE is not well = understood- see below. Everyone agreed that there was sufficient capability with EXDATE and = RRULE. It wasn=E2=80=99t perfect, but good enough. There were ambiguities in corner cases regarding DTSTART and the actual = recurrence set (I don=E2=80=99t recall the details here- someone might = want to check with Bernard, Cyrus, Reinhold, or Jonathan). We were aiming for a draft standard at the time, and anything not used = had to be pulled/deprecated. To me, there is a bigger concern: if you readd EXRULE and only some = people implement, then you will have inconsistent calendars, and some = people will show up to events that aren=E2=80=99t occurring, or worse = not attend or schedule events during that time. And so I would argue = that you should have a VERY strong use case and a very strong consensus = to do this, and that CalConnect be consulted. >=20 > Try this article from 2008 for one >=20 > = https://blog.jonudell.net/2008/08/28/specifying-exceptions-to-recurring-ca= lendar-events/ This case is handled by EXDATE, albeit not ad infinitum, as RRULE would = allow. And indeed this is how Bernard answered the question back in = 2008 when it was asked. How would you propose the UI be done for the = EXRULE case? I=E2=80=99m not saying that UI is the IETF=E2=80=99s = general concern, but there=E2=80=99s no point in adding the function if = people can=E2=80=99t reasonably take advantage of it. >=20 > And this would be solved >=20 > = https://webapps.stackexchange.com/questions/136598/google-calendar-weekly-= recurring-event-except-last-week-of-month The example given in StackExchange itself is solved with RRULE as = follows. RRULE:FREQ=3DMONTHLY;BYDAY=3D1MO,2MO,3MO,-2MO That is, the 1st, 2nd, 3rd and 2nd to the last Monday of the month. = This creates duplicate recurrences for months with only four Mondays, = but RFC 5545 explicitly states that one should delete such duplicates. = I note that Apple doesn=E2=80=99t provide a UI to create this rule, and = its display of the rule is a bit=E2=80=A6 off... but it generates the = recurrence set correctly. Apple=E2=80=99s very minor UI gaffe only = serves to reinforce my point about being conservative about adding back = capabilities. It=E2=80=99s hard enough for people to get the existing = ones right. I am not suggesting that you shouldn't add new capabilities, but be = careful in doing so. There really should be good value for real world = cases that are not well handled today. If you really want to go there, = let=E2=80=99s see how things work with non-Gregorian calendars where = months only recur occasionally ;-) Eliot --Apple-Mail=_E39BDC18-BBCF-4BB6-9A98-D1754607AD03 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi!

On 12 May 2020, at 22:44, Michael Douglass = <mikeadouglass@gmail.com> wrote:

I = believe we should support this and I think it's only a minor change to = the spec.

I didn't agree with the = deprecation of EXRULEs - there are a whole bunch of cases that are = easily handled - just because UIs choose not to support it isn't that = much of an argument.


Before you readd EXRULE or = anything like it, it is probably worth understanding why it was removed. =  There were several reasons:

  1. Almost nobody (nobody?) in the WG = at the time said the they had implemented it.  I believe this is = because the UI for EXRULE is not well understood- see below.
  2. Everyone agreed that there was sufficient capability with = EXDATE and RRULE.  It wasn=E2=80=99t perfect, but good = enough.
  3. There were ambiguities in corner cases = regarding DTSTART and the actual recurrence set (I don=E2=80=99t recall = the details here- someone might want to check with Bernard, Cyrus, = Reinhold, or Jonathan).
  4. We were aiming for a draft = standard at the time, and anything not used had to be = pulled/deprecated.

To me, =  there is a bigger concern: if you readd EXRULE and only some = people implement, then you will have inconsistent calendars, and some = people will show up to events that aren=E2=80=99t occurring, or worse = not attend or schedule events during that time.  And so I would = argue that you should have a VERY strong use case and a very strong = consensus to do this, and that CalConnect be consulted.



Try this = article from 2008 for one

https://blog.jonudell.net/2008/08/28/specifying-exceptions-to-r= ecurring-calendar-events/


This case is handled by EXDATE, albeit not ad = infinitum, as RRULE would allow.  And indeed this is how Bernard = answered the question back in 2008 when it was asked.  How would = you propose the UI be done for the EXRULE case?  I=E2=80=99m not = saying that UI is the IETF=E2=80=99s general concern, but there=E2=80=99s = no point in adding the function if people can=E2=80=99t reasonably take = advantage of it.



And this would be solved

https://webapps.stackexchange.com/questions/136598/google-calen= dar-weekly-recurring-event-except-last-week-of-month


The example = given in StackExchange itself is solved with RRULE as = follows.

RRULE:FREQ=3DMONTHLY;BYDAY=3D1MO,2MO,3MO,-2MO

That = is, the 1st, 2nd, 3rd and 2nd to the last Monday of the month. =  This creates duplicate recurrences for months with only four = Mondays, but RFC 5545 explicitly states that one should delete such = duplicates.  I note that Apple doesn=E2=80=99t provide a UI to = create this rule, and its display of the rule is a bit=E2=80=A6 off... = but it generates the recurrence set correctly.  Apple=E2=80=99s = very minor UI gaffe only serves to reinforce my point about being = conservative about adding back capabilities.  It=E2=80=99s hard = enough for people to get the existing ones right.

I am = not suggesting that you shouldn't add new capabilities, but be careful = in doing so.  There really should be good value for real world = cases that are not well handled today.  If you really want to go = there, let=E2=80=99s see how things work with non-Gregorian calendars = where months only recur occasionally ;-)

Eliot

= --Apple-Mail=_E39BDC18-BBCF-4BB6-9A98-D1754607AD03-- From nobody Sun May 24 03:24: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 C23133A041C for ; Sun, 24 May 2020 03:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQ2XN_9ZPK14 for ; Sun, 24 May 2020 03:24:21 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C763A03F7 for ; Sun, 24 May 2020 03:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3069; q=dns/txt; s=iport; t=1590315861; x=1591525461; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=5ln04xkHPbAqVqOl2cwNQNmiZ8d46aacfzw8GIYoRso=; b=Oe5Bhleb/acK35Q1jM3QxZWwXSBDKJjceYKqa1W+gF83ZZMimjdO5laX ckH+JbDtuq6KRkjkJ0/v4H4KhTs7xeTCnM56sVzb18iyqOyoAWK8ybbr+ 9f7rdrvRWutydItmP946uG1yzW22501+KMusncshM0viDlICJqJTfOddf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CiAADYSspe/xbLJq1lHQEBAQEJARI?= =?us-ascii?q?BBQUBgXUGAQsBgSRYgR5UASAShFCJAYdjk3uGFIF8CwEBAQwBAScIBAEBg39?= =?us-ascii?q?FAoJBNgcOAgMBAQsBAQUBAQECAQUEbYVWDIVzBiNWEAsEPgICVwaCbksBgnw?= =?us-ascii?q?PqnB2gTKEOgELAYEKhQ8GgTgBjF2CAIERJwwQgk0+gmcEhHczgi0EkSWiAYJ?= =?us-ascii?q?egnSFNZAzFgeQRo08mjyQK4NJAgQGBQIVgVkNJTaBIDMaCBsVZQGCPz0SGA2?= =?us-ascii?q?UMopYPwNnAgYBBwEBAwmNWgEB?= X-IronPort-AV: E=Sophos; i="5.73,429,1583193600"; d="scan'208,217"; a="26470900" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 May 2020 10:24:11 +0000 Received: from [10.61.168.109] ([10.61.168.109]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 04OAOBZu015759 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 24 May 2020 10:24:11 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_B2B2FB1E-9BED-4611-96AA-EFEB85E7925C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 24 May 2020 12:24:10 +0200 In-Reply-To: Cc: Michael Douglass , Calsify To: Eliot Lear References: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.168.109, [10.61.168.109] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [calsify] JSCalendar and EXRULE 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, 24 May 2020 10:24:23 -0000 --Apple-Mail=_B2B2FB1E-9BED-4611-96AA-EFEB85E7925C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just to follow up on one point: >>=20 >> And this would be solved >>=20 >> = https://webapps.stackexchange.com/questions/136598/google-calendar-weekly-= recurring-event-except-last-week-of-month = >=20 >=20 > The example given in StackExchange itself is solved with RRULE as = follows. >=20 > RRULE:FREQ=3DMONTHLY;BYDAY=3D1MO,2MO,3MO,-2MO >=20 > [=E2=80=A6] I note that Apple doesn=E2=80=99t provide a UI to create = this rule[=E2=80=A6] And neither does Google but it also handles the recurrence rule = correctly when it sees it. Eliot --Apple-Mail=_B2B2FB1E-9BED-4611-96AA-EFEB85E7925C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Just = to follow up on one point:


And this would be solved

https://webapps.stackexchange.com/questions/136598/google-calen= dar-weekly-recurring-event-except-last-week-of-month


The example given in StackExchange itself is = solved with RRULE as follows.

RRULE:FREQ=3DMONTHLY;BYDAY=3D1MO,2MO,3MO,-2MO

[=E2=80=A6= ]  I note that Apple doesn=E2=80=99t provide a UI to create this = rule[=E2=80=A6]

And neither does Google but it also handles the recurrence rule correctly when it = sees it.

Eliot

= --Apple-Mail=_B2B2FB1E-9BED-4611-96AA-EFEB85E7925C-- From nobody Sun May 24 09:31:41 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 D4E143A0BA4 for ; Sun, 24 May 2020 09:31:38 -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 FfwBedjLI3zW for ; Sun, 24 May 2020 09:31:36 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 9EFC93A0B9F for ; Sun, 24 May 2020 09:31:36 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id f189so15585848qkd.5 for ; Sun, 24 May 2020 09:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=VzRK+rJ1fuZif88527JU+CDBFhr7l0785nGwESyCLz0=; b=I9YO+CuDcxj5KzDHysUJ48aMTkLCxBgT9nrz3aYWjjUtS1D1zQ4soHBpoYIWXVwX0o YdAwHLLmEiovB1nqQtkNQCxb7PyWLMhFR7x6z1c3CTBf4zaW/wXiNS5PScCCuIlVmYhV F9qJRrYnNL7m6QJ9m5ccTQyBibvhsr0Il9zZWUXDNts1x1O7hYuSLLVlz31wl3d21lHb jx2rVWb4z+FOB9KQH51BKRPg9EZtnu52nO5V/BIclrgnUwB5FcRhEdV/Kqi7r5JW9/nn HkDwniEFou+M66dqyLzPH1eHUwQ2MHvZwNstD6c16DmVDlVTIJW1EsUEJ0CG5j023v4L 8IKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=VzRK+rJ1fuZif88527JU+CDBFhr7l0785nGwESyCLz0=; b=uOYYk+ZF/rk+jQgI3RXafqlUjXvvHys30Z7CgssMN4KVGZu9p5ZQ7oJD/7qUuoy9sp rH2RVSeLSJLjXGAstVxiofJvh7YU6U8JO/iw45GHeX9SfbY4xmoN/Jm7UBtjPg2bKb1d cJv1d3vJpsmPn8VgdTZ2h/bYFWcCRiwH7nj+0HqpW/eECxIumsE619M7SJYyfBVRvETw v7mXcUvhMl6H5X06XKVjblsI3S1QQk2gmnX9lqvqNDoSK2/n2L5ZJUwyrTEvRcG/Az9g 3sTyE+Qf0zGnYUy1GY926kOeVze/zXaKjpKCDU8gnUAmugOY8sCadI2ujBtzWx/vIogD DUIA== X-Gm-Message-State: AOAM533prLCN6R0ztK8NHooQ830J99tS7m4gg/4Dx4HuadW5xBjjQfJm OViQDnDd+JNUow2KqhvHkIiz5Jyo X-Google-Smtp-Source: ABdhPJy8kdrNFXu6vReCms+83WTmTkDcbPurBxU7o6/YoAXiVROkYNvZnhURftEITSaEtuEFud/2aw== X-Received: by 2002:a37:a8c1:: with SMTP id r184mr11539652qke.402.1590337895334; Sun, 24 May 2020 09:31:35 -0700 (PDT) Received: from MacBook-Pro-2019.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id f7sm12428544qtg.96.2020.05.24.09.31.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 May 2020 09:31:34 -0700 (PDT) To: Eliot Lear Cc: Calsify References: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> From: Michael Douglass Message-ID: <967f5a38-e93b-7b71-fd09-90b8422842ca@gmail.com> Date: Sun, 24 May 2020 12:31:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DF38B9F13A366BF0909FB0A3" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar and EXRULE 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, 24 May 2020 16:31:39 -0000 This is a multi-part message in MIME format. --------------DF38B9F13A366BF0909FB0A3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/24/20 05:42, Eliot Lear wrote: > Hi! > >> On 12 May 2020, at 22:44, Michael Douglass > > wrote: >> >> I believe we should support this and I think it's only a minor change >> to the spec. >> >> I didn't agree with the deprecation of EXRULEs - there are a whole >> bunch of cases that are easily handled - just because UIs choose not >> to support it isn't that much of an argument. > > > Before you readd EXRULE or anything like it, it is probably worth > understanding why it was removed.  There were several reasons: > > 1. Almost nobody (nobody?) in the WG at the time said the they had > implemented it.  I believe this is because the UI for EXRULE is > not well understood- see below. > 2. Everyone agreed that there was sufficient capability with EXDATE > and RRULE.  It wasn’t perfect, but good enough. > 3. There were ambiguities in corner cases regarding DTSTART and the > actual recurrence set (I don’t recall the details here- someone > might want to check with Bernard, Cyrus, Reinhold, or Jonathan). > 4. We were aiming for a draft standard at the time, and anything not > used had to be pulled/deprecated. > > > To me,  there is a bigger concern: if you readd EXRULE and only some > people implement, then you will have inconsistent calendars, and some > people will show up to events that aren’t occurring, or worse not > attend or schedule events during that time.  And so I would argue that > you should have a VERY strong use case and a very strong consensus to > do this, and that CalConnect be consulted. > There are at least 2 aspects to this: 1. Data representation and libraries to handle it 2. How to represent in UIs On the data representation and handling: At least some underlying libraries handle multiple rrules and exrules. There are many uses for calendar data outside of the corporate meeting world - the smart grid for example. If we want standards to be used widely they need to be useful. Then there's the UI implementation. If we want to make UI's the driver of the standard then we should pretty much gut rrule because most don't give you any more than a regularly repeating event for a few fixed periods. Your ui might let you enter an rrule but do we really expect anything other than a vanishingly small number of users to be able to construct a rule? It is possible to come up with a UI which handles all the complexities of recurrence rules - Bedework has one. My concern is that we confine a data representation to what is perceived to be used/useful - additionally the assumption is that the important use case is corporate meetings. > >> >> Try this article from 2008 for one >> >> https://blog.jonudell.net/2008/08/28/specifying-exceptions-to-recurring-calendar-events/ > > > This case is handled by EXDATE, albeit not ad infinitum, as RRULE > would allow.  And indeed this is how Bernard answered the question > back in 2008 when it was asked.  How would you propose the UI be done > for the EXRULE case?  I’m not saying that UI is the IETF’s general > concern, but there’s no point in adding the function if people can’t > reasonably take advantage of it. > > >> >> And this would be solved >> >> https://webapps.stackexchange.com/questions/136598/google-calendar-weekly-recurring-event-except-last-week-of-month > > > The example given in StackExchange itself is solved with RRULE as follows. > > RRULE:FREQ=MONTHLY;BYDAY=1MO,2MO,3MO,-2MO > > That is, the 1st, 2nd, 3rd and 2nd to the last Monday of the month. >  This creates duplicate recurrences for months with only four Mondays, > but RFC 5545 explicitly states that one should delete such duplicates. >  I note that Apple doesn’t provide a UI to create this rule, and its > display of the rule is a bit… off... but it generates the recurrence > set correctly.  Apple’s very minor UI gaffe only serves to reinforce > my point about being conservative about adding back capabilities. >  It’s hard enough for people to get the existing ones right. I think this reinforces my point. Or whose UI is going to set the standard? Should we remove these capabilities from recurrence rules because they are not in a UI? I would suggest that if we want to provide users with more useful recurrence UIs then multiple simple rrules and exrules are probably easier to understand - though again not providing the full set of possibilities. > > I am not suggesting that you shouldn't add new capabilities, but be > careful in doing so.  There really should be good value for real world > cases that are not well handled today.  If you really want to go > there, let’s see how things work with non-Gregorian calendars where > months only recur occasionally ;-) > > Eliot > --------------DF38B9F13A366BF0909FB0A3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 5/24/20 05:42, Eliot Lear wrote:
Hi!

On 12 May 2020, at 22:44, Michael Douglass <mikeadouglass@gmail.com> wrote:

I believe we should support this and I think it's only a minor change to the spec.

I didn't agree with the deprecation of EXRULEs - there are a whole bunch of cases that are easily handled - just because UIs choose not to support it isn't that much of an argument.


Before you readd EXRULE or anything like it, it is probably worth understanding why it was removed.  There were several reasons:

  1. Almost nobody (nobody?) in the WG at the time said the they had implemented it.  I believe this is because the UI for EXRULE is not well understood- see below.
  2. Everyone agreed that there was sufficient capability with EXDATE and RRULE.  It wasn’t perfect, but good enough.
  3. There were ambiguities in corner cases regarding DTSTART and the actual recurrence set (I don’t recall the details here- someone might want to check with Bernard, Cyrus, Reinhold, or Jonathan).
  4. We were aiming for a draft standard at the time, and anything not used had to be pulled/deprecated.

To me,  there is a bigger concern: if you readd EXRULE and only some people implement, then you will have inconsistent calendars, and some people will show up to events that aren’t occurring, or worse not attend or schedule events during that time.  And so I would argue that you should have a VERY strong use case and a very strong consensus to do this, and that CalConnect be consulted.

There are at least 2 aspects to this:

1. Data representation and libraries to handle it

2. How to represent in UIs

On the data representation and handling:

At least some underlying libraries handle multiple rrules and exrules. There are many uses for calendar data outside of the corporate meeting world - the smart grid for example. If we want standards to be used widely they need to be useful.

Then there's the UI implementation.

If we want to make UI's the driver of the standard then we should pretty much gut rrule because most don't give you any more than a regularly repeating event for a few fixed periods. Your ui might let you enter an rrule but do we really expect anything other than a vanishingly small number of users to be able to construct a rule?

It is possible to come up with a UI which handles all the complexities of recurrence rules - Bedework has one.

My concern is that we confine a data representation to what is perceived to be used/useful - additionally the assumption is that the important use case is corporate meetings.




This case is handled by EXDATE, albeit not ad infinitum, as RRULE would allow.  And indeed this is how Bernard answered the question back in 2008 when it was asked.  How would you propose the UI be done for the EXRULE case?  I’m not saying that UI is the IETF’s general concern, but there’s no point in adding the function if people can’t reasonably take advantage of it.




The example given in StackExchange itself is solved with RRULE as follows.

RRULE:FREQ=MONTHLY;BYDAY=1MO,2MO,3MO,-2MO

That is, the 1st, 2nd, 3rd and 2nd to the last Monday of the month.  This creates duplicate recurrences for months with only four Mondays, but RFC 5545 explicitly states that one should delete such duplicates.  I note that Apple doesn’t provide a UI to create this rule, and its display of the rule is a bit… off... but it generates the recurrence set correctly.  Apple’s very minor UI gaffe only serves to reinforce my point about being conservative about adding back capabilities.  It’s hard enough for people to get the existing ones right.

I think this reinforces my point. Or whose UI is going to set the standard? Should we remove these capabilities from recurrence rules because they are not in a UI?

I would suggest that if we want to provide users with more useful recurrence UIs then multiple simple rrules and exrules are probably easier to understand - though again not providing the full set of possibilities.



I am not suggesting that you shouldn't add new capabilities, but be careful in doing so.  There really should be good value for real world cases that are not well handled today.  If you really want to go there, let’s see how things work with non-Gregorian calendars where months only recur occasionally ;-)

Eliot

--------------DF38B9F13A366BF0909FB0A3-- From nobody Sun May 24 10:31:18 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5345E3A0C38 for ; Sun, 24 May 2020 10:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyJy7C3P4zxX for ; Sun, 24 May 2020 10:31:12 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1013A0C37 for ; Sun, 24 May 2020 10:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17332; q=dns/txt; s=iport; t=1590341472; x=1591551072; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=uTXHkkW/Wu3CQ3JRzzFRaht83ymkdmC2/vsZW3KeJR0=; b=bshAuKz0KiT+BIQQU1zjyhDEPCmPeDb4FyDd4lOIUf2D9FqH07wY6JdT xQspU4RuQ9sY2kT61E+EFSIjhV428wSwdVN2oCETDSHPgr6EAiaivmp9R M/iEmZE+QPjmwoLU19ZWBUdsCI3bfdmiQXqou4z9bxLgYVl2PPNxcioxi Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AQD2rspe/xbLJq1lHQEBAQEJARI?= =?us-ascii?q?BBQUBgXYFAQsBgXYGgR5UASASLIQkiQGICYl6iVyGKIFoCwEBAQwBAScIBAE?= =?us-ascii?q?Bg39FAoJBNwYOAgMBAQsBAQUBAQECAQUEbYVWDIVyAQEBAQIBI1YFCwsOCic?= =?us-ascii?q?DAgIhJREGE4JbSwGCSwMOIA+rB3aBMoQ6AQsBgQqCcw2CHAaBOAGMXYIAgRE?= =?us-ascii?q?nHIJNPoIeSQSBLRyDLjOCLQSORA4BM6MjM0qCXoJ0hTWLV4RcHZBGiD+EfZE?= =?us-ascii?q?ziQmCTItSgg2DSQIEBgUCFYFoIzaBIDMaCBsVZQGCCgEBMhIsEhgNkEwXg0+?= =?us-ascii?q?EWYV/PwMwNwIGAQcBAQMJjVsBAQ?= X-IronPort-AV: E=Sophos; i="5.73,430,1583193600"; d="scan'208,217"; a="26476905" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 May 2020 17:31:07 +0000 Received: from [10.61.168.109] ([10.61.168.109]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 04OHV6kK017330 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 24 May 2020 17:31:07 GMT From: Eliot Lear Message-Id: <0D0E33DD-A4F3-4FD0-888F-18E8CF167A93@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1435564F-00C9-4042-ACFC-7A3555D284BF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 24 May 2020 19:31:06 +0200 In-Reply-To: <967f5a38-e93b-7b71-fd09-90b8422842ca@gmail.com> Cc: Calsify To: Michael Douglass References: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> <967f5a38-e93b-7b71-fd09-90b8422842ca@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.168.109, [10.61.168.109] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [calsify] JSCalendar and EXRULE 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, 24 May 2020 17:31:16 -0000 --Apple-Mail=_1435564F-00C9-4042-ACFC-7A3555D284BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Doug To be clear, I am not saying, =E2=80=9CDon=E2=80=99t do this.=E2=80=9D = The conclusion I draw is that if you do this, before nailing it in the = standard you should bake it off to make sure that people can actually = use it. I should have said that in the first message. Eliot > On 24 May 2020, at 18:31, Michael Douglass = wrote: >=20 >=20 >=20 > On 5/24/20 05:42, Eliot Lear wrote: >> Hi! >>=20 >>> On 12 May 2020, at 22:44, Michael Douglass > wrote: >>>=20 >>> I believe we should support this and I think it's only a minor = change to the spec. >>>=20 >>> I didn't agree with the deprecation of EXRULEs - there are a whole = bunch of cases that are easily handled - just because UIs choose not to = support it isn't that much of an argument. >>=20 >>=20 >> Before you readd EXRULE or anything like it, it is probably worth = understanding why it was removed. There were several reasons: >>=20 >> Almost nobody (nobody?) in the WG at the time said the they had = implemented it. I believe this is because the UI for EXRULE is not well = understood- see below. >> Everyone agreed that there was sufficient capability with EXDATE and = RRULE. It wasn=E2=80=99t perfect, but good enough. >> There were ambiguities in corner cases regarding DTSTART and the = actual recurrence set (I don=E2=80=99t recall the details here- someone = might want to check with Bernard, Cyrus, Reinhold, or Jonathan). >> We were aiming for a draft standard at the time, and anything not = used had to be pulled/deprecated. >>=20 >> To me, there is a bigger concern: if you readd EXRULE and only some = people implement, then you will have inconsistent calendars, and some = people will show up to events that aren=E2=80=99t occurring, or worse = not attend or schedule events during that time. And so I would argue = that you should have a VERY strong use case and a very strong consensus = to do this, and that CalConnect be consulted. >>=20 > There are at least 2 aspects to this: >=20 > 1. Data representation and libraries to handle it >=20 > 2. How to represent in UIs >=20 > On the data representation and handling: >=20 > At least some underlying libraries handle multiple rrules and exrules. = There are many uses for calendar data outside of the corporate meeting = world - the smart grid for example. If we want standards to be used = widely they need to be useful. >=20 > Then there's the UI implementation. >=20 > If we want to make UI's the driver of the standard then we should = pretty much gut rrule because most don't give you any more than a = regularly repeating event for a few fixed periods. Your ui might let you = enter an rrule but do we really expect anything other than a vanishingly = small number of users to be able to construct a rule?=20 >=20 > It is possible to come up with a UI which handles all the complexities = of recurrence rules - Bedework has one. >=20 > My concern is that we confine a data representation to what is = perceived to be used/useful - additionally the assumption is that the = important use case is corporate meetings.=20 >=20 >>=20 >>>=20 >>> Try this article from 2008 for one >>>=20 >>> = https://blog.jonudell.net/2008/08/28/specifying-exceptions-to-recurring-ca= lendar-events/ = >>=20 >>=20 >> This case is handled by EXDATE, albeit not ad infinitum, as RRULE = would allow. And indeed this is how Bernard answered the question back = in 2008 when it was asked. How would you propose the UI be done for the = EXRULE case? I=E2=80=99m not saying that UI is the IETF=E2=80=99s = general concern, but there=E2=80=99s no point in adding the function if = people can=E2=80=99t reasonably take advantage of it. >>=20 >>=20 >>>=20 >>> And this would be solved >>>=20 >>> = https://webapps.stackexchange.com/questions/136598/google-calendar-weekly-= recurring-event-except-last-week-of-month = >>=20 >>=20 >> The example given in StackExchange itself is solved with RRULE as = follows. >>=20 >> RRULE:FREQ=3DMONTHLY;BYDAY=3D1MO,2MO,3MO,-2MO >>=20 >> That is, the 1st, 2nd, 3rd and 2nd to the last Monday of the month. = This creates duplicate recurrences for months with only four Mondays, = but RFC 5545 explicitly states that one should delete such duplicates. = I note that Apple doesn=E2=80=99t provide a UI to create this rule, and = its display of the rule is a bit=E2=80=A6 off... but it generates the = recurrence set correctly. Apple=E2=80=99s very minor UI gaffe only = serves to reinforce my point about being conservative about adding back = capabilities. It=E2=80=99s hard enough for people to get the existing = ones right. > I think this reinforces my point. Or whose UI is going to set the = standard? Should we remove these capabilities from recurrence rules = because they are not in a UI? >=20 > I would suggest that if we want to provide users with more useful = recurrence UIs then multiple simple rrules and exrules are probably = easier to understand - though again not providing the full set of = possibilities. >=20 >=20 >=20 >>=20 >> I am not suggesting that you shouldn't add new capabilities, but be = careful in doing so. There really should be good value for real world = cases that are not well handled today. If you really want to go there, = let=E2=80=99s see how things work with non-Gregorian calendars where = months only recur occasionally ;-) >>=20 >> Eliot >>=20 --Apple-Mail=_1435564F-00C9-4042-ACFC-7A3555D284BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Doug

To be clear, I = am not saying, =E2=80=9CDon=E2=80=99t do this.=E2=80=9D  The = conclusion I draw is that if you do this, before nailing it in the = standard you should bake it off to make sure that people can actually = use it.  I should have said that in the first message.

Eliot

On 24 May 2020, at 18:31, Michael Douglass <mikeadouglass@gmail.com> wrote:

=20


On 5/24/20 05:42, Eliot Lear = wrote:
=20 Hi!

On 12 May 2020, at 22:44, Michael Douglass = <mikeadouglass@gmail.com> wrote:

I believe we should support this and I think it's only a minor change to the spec.

I didn't agree with the deprecation of EXRULEs - there are a whole bunch of cases that are easily handled - just because UIs choose not to support it isn't that much of an argument.


Before you readd EXRULE or anything like it, it is = probably worth understanding why it was removed.  There were several reasons:

  1. Almost nobody (nobody?) in the WG at the time said the they had implemented it.  I believe this is = because the UI for EXRULE is not well understood- see below.
  2. Everyone agreed that there was sufficient capability with EXDATE and RRULE.  It wasn=E2=80=99t = perfect, but good enough.
  3. There were ambiguities in corner cases = regarding DTSTART and the actual recurrence set (I don=E2=80=99t = recall the details here- someone might want to check with Bernard, Cyrus, Reinhold, or Jonathan).
  4. We were aiming for a draft standard at the = time, and anything not used had to be pulled/deprecated.

To me,  there is a bigger concern: if you = readd EXRULE and only some people implement, then you will have inconsistent calendars, and some people will show up to events that aren=E2=80=99= t occurring, or worse not attend or schedule events during that time.  And so I would argue that you should have a VERY = strong use case and a very strong consensus to do this, and that CalConnect be consulted.

There are at least 2 aspects to = this:

1. Data representation and libraries to handle = it

2. How to represent in UIs

On the data representation and handling:

At least some underlying libraries handle multiple = rrules and exrules. There are many uses for calendar data outside of the corporate meeting world - the smart grid for example. If we want standards to be used widely they need to be useful.

Then there's the UI implementation.

If we want to make UI's the driver of the standard then we = should pretty much gut rrule because most don't give you any more than a regularly repeating event for a few fixed periods. Your ui might let you enter an rrule but do we really expect anything other than a vanishingly small number of users to be able to construct a rule?

It is possible to come up with a UI which handles = all the complexities of recurrence rules - Bedework has one.

My concern is that we confine a data representation to what = is perceived to be used/useful - additionally the assumption is that the important use case is corporate meetings.



Try this article from 2008 for one

https://blog.jonudell.net/2008/08/28/specifying-e= xceptions-to-recurring-calendar-events/


This case is handled by EXDATE, albeit not ad = infinitum, as RRULE would allow.  And indeed this is how Bernard = answered the question back in 2008 when it was asked.  How would = you propose the UI be done for the EXRULE case?  I=E2=80=99m = not saying that UI is the IETF=E2=80=99s general concern, but there=E2=80=99= s no point in adding the function if people can=E2=80=99t reasonably take = advantage of it.



And this would be solved

https://webapps.stackexchange.com/questions/13659= 8/google-calendar-weekly-recurring-event-except-last-week-of-month


The example given in StackExchange itself is = solved with RRULE as follows.

RRULE:FREQ=3DMONTHLY;BYDAY=3D1MO,2MO,3MO,-2MO

That is, the 1st, 2nd, = 3rd and 2nd to the last Monday of the month.  This = creates duplicate recurrences for months with only four Mondays, but RFC 5545 explicitly states that one should delete such duplicates.  I note that Apple doesn=E2=80=99t = provide a UI to create this rule, and its display of the rule is a bit=E2=80= =A6 off... but it generates the recurrence set correctly.  Apple=E2=80=99s very minor UI gaffe only serves to = reinforce my point about being conservative about adding back capabilities.  It=E2=80=99s hard enough for people to = get the existing ones right.

I think this reinforces my point. Or = whose UI is going to set the standard? Should we remove these capabilities from recurrence rules because they are not in a UI?

I would = suggest that if we want to provide users with more useful recurrence UIs then multiple simple rrules and exrules are probably easier to understand - though again not providing the full set of possibilities.



I am not suggesting that you shouldn't add new capabilities, but be careful in doing so.  There really should be good value for real world cases that are not well handled today.  If you really want to go there, let=E2=80=99s see how things work = with non-Gregorian calendars where months only recur occasionally ;-)

Eliot


= --Apple-Mail=_1435564F-00C9-4042-ACFC-7A3555D284BF-- From nobody Sun May 24 10:32: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 EF5A23A0C3A for ; Sun, 24 May 2020 10:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BIqiH8ilQaR for ; Sun, 24 May 2020 10:31:58 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DCAA3A0C39 for ; Sun, 24 May 2020 10:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16880; q=dns/txt; s=iport; t=1590341517; x=1591551117; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=yUTqo0jEf9UXXk4KO9c/4qSyKB8qB5Sx48IWs77ROws=; b=G1ol527C/wUt0Rxt5ynYW93Ylc+uTWH//wbHslNGqZdTZybsEE8544uz 551InI4e6aY+BHopKuu0HCDmxPCEOVEmOjsFgREDByNGKsxqerB/xlbVn sDFXYM1CPR0/vaXZQLabt6jqA7+Hlf0us9ZNr9+gsk+WSppnscLhyLY4L U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C4AAD2rspe/xbLJq1lHQEBAQEJARI?= =?us-ascii?q?BBQUBgXUGAQsBgXYGgR5UASASLIQkiQGHZCWJeolchhQUgWgLAQEBDAEBJwg?= =?us-ascii?q?EAQGDf0UCgkE2Bw4CAwEBCwEBBQEBAQIBBQRthVYMhXIBAQEBAgEjVgULCw4?= =?us-ascii?q?KJwMCAiElEQYTgltLAYJLAw4gD6sHdoEyhDoBCwGBCoJzDYIcBoE4AYxdggC?= =?us-ascii?q?BEScMEIJNPoIeSQSBSYMuM4ItBI5EDgEzoyMzSoJegnSFNYtXhFwdkEaIP4R?= =?us-ascii?q?9kTOJCYJMi1KCDYNJAgQGBQIVgVkDLzaBIDMaCBsVZQGCCgEBMhIsEhgNkEw?= =?us-ascii?q?Xg0+EWYV/PwMwNwIGAQcBAQMJjVsBAQ?= X-IronPort-AV: E=Sophos; i="5.73,430,1583193600"; d="scan'208,217"; a="26476907" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 May 2020 17:31:53 +0000 Received: from [10.61.168.109] ([10.61.168.109]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 04OHV6kL017330 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 24 May 2020 17:31:53 GMT From: Eliot Lear Message-Id: <77F94B9D-59B8-4417-B566-12B853CF2F4F@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_80A7611B-5AF9-4833-A92B-9D637C2FA11E" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sun, 24 May 2020 19:31:52 +0200 In-Reply-To: <967f5a38-e93b-7b71-fd09-90b8422842ca@gmail.com> Cc: Calsify To: Michael Douglass References: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> <967f5a38-e93b-7b71-fd09-90b8422842ca@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Outbound-SMTP-Client: 10.61.168.109, [10.61.168.109] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [calsify] JSCalendar and EXRULE 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, 24 May 2020 17:32:01 -0000 --Apple-Mail=_80A7611B-5AF9-4833-A92B-9D637C2FA11E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m sorry- my fingers ran faster than my brain. I meant Mike of = course. Eliot > On 24 May 2020, at 18:31, Michael Douglass = wrote: >=20 >=20 >=20 > On 5/24/20 05:42, Eliot Lear wrote: >> Hi! >>=20 >>> On 12 May 2020, at 22:44, Michael Douglass > wrote: >>>=20 >>> I believe we should support this and I think it's only a minor = change to the spec. >>>=20 >>> I didn't agree with the deprecation of EXRULEs - there are a whole = bunch of cases that are easily handled - just because UIs choose not to = support it isn't that much of an argument. >>=20 >>=20 >> Before you readd EXRULE or anything like it, it is probably worth = understanding why it was removed. There were several reasons: >>=20 >> Almost nobody (nobody?) in the WG at the time said the they had = implemented it. I believe this is because the UI for EXRULE is not well = understood- see below. >> Everyone agreed that there was sufficient capability with EXDATE and = RRULE. It wasn=E2=80=99t perfect, but good enough. >> There were ambiguities in corner cases regarding DTSTART and the = actual recurrence set (I don=E2=80=99t recall the details here- someone = might want to check with Bernard, Cyrus, Reinhold, or Jonathan). >> We were aiming for a draft standard at the time, and anything not = used had to be pulled/deprecated. >>=20 >> To me, there is a bigger concern: if you readd EXRULE and only some = people implement, then you will have inconsistent calendars, and some = people will show up to events that aren=E2=80=99t occurring, or worse = not attend or schedule events during that time. And so I would argue = that you should have a VERY strong use case and a very strong consensus = to do this, and that CalConnect be consulted. >>=20 > There are at least 2 aspects to this: >=20 > 1. Data representation and libraries to handle it >=20 > 2. How to represent in UIs >=20 > On the data representation and handling: >=20 > At least some underlying libraries handle multiple rrules and exrules. = There are many uses for calendar data outside of the corporate meeting = world - the smart grid for example. If we want standards to be used = widely they need to be useful. >=20 > Then there's the UI implementation. >=20 > If we want to make UI's the driver of the standard then we should = pretty much gut rrule because most don't give you any more than a = regularly repeating event for a few fixed periods. Your ui might let you = enter an rrule but do we really expect anything other than a vanishingly = small number of users to be able to construct a rule?=20 >=20 > It is possible to come up with a UI which handles all the complexities = of recurrence rules - Bedework has one. >=20 > My concern is that we confine a data representation to what is = perceived to be used/useful - additionally the assumption is that the = important use case is corporate meetings.=20 >=20 >>=20 >>>=20 >>> Try this article from 2008 for one >>>=20 >>> = https://blog.jonudell.net/2008/08/28/specifying-exceptions-to-recurring-ca= lendar-events/ = >>=20 >>=20 >> This case is handled by EXDATE, albeit not ad infinitum, as RRULE = would allow. And indeed this is how Bernard answered the question back = in 2008 when it was asked. How would you propose the UI be done for the = EXRULE case? I=E2=80=99m not saying that UI is the IETF=E2=80=99s = general concern, but there=E2=80=99s no point in adding the function if = people can=E2=80=99t reasonably take advantage of it. >>=20 >>=20 >>>=20 >>> And this would be solved >>>=20 >>> = https://webapps.stackexchange.com/questions/136598/google-calendar-weekly-= recurring-event-except-last-week-of-month = >>=20 >>=20 >> The example given in StackExchange itself is solved with RRULE as = follows. >>=20 >> RRULE:FREQ=3DMONTHLY;BYDAY=3D1MO,2MO,3MO,-2MO >>=20 >> That is, the 1st, 2nd, 3rd and 2nd to the last Monday of the month. = This creates duplicate recurrences for months with only four Mondays, = but RFC 5545 explicitly states that one should delete such duplicates. = I note that Apple doesn=E2=80=99t provide a UI to create this rule, and = its display of the rule is a bit=E2=80=A6 off... but it generates the = recurrence set correctly. Apple=E2=80=99s very minor UI gaffe only = serves to reinforce my point about being conservative about adding back = capabilities. It=E2=80=99s hard enough for people to get the existing = ones right. > I think this reinforces my point. Or whose UI is going to set the = standard? Should we remove these capabilities from recurrence rules = because they are not in a UI? >=20 > I would suggest that if we want to provide users with more useful = recurrence UIs then multiple simple rrules and exrules are probably = easier to understand - though again not providing the full set of = possibilities. >=20 >=20 >=20 >>=20 >> I am not suggesting that you shouldn't add new capabilities, but be = careful in doing so. There really should be good value for real world = cases that are not well handled today. If you really want to go there, = let=E2=80=99s see how things work with non-Gregorian calendars where = months only recur occasionally ;-) >>=20 >> Eliot >>=20 --Apple-Mail=_80A7611B-5AF9-4833-A92B-9D637C2FA11E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m sorry- my fingers ran faster than my brain.  I meant Mike of = course.

Eliot

On 24 May 2020, at 18:31, Michael Douglass = <mikeadouglass@gmail.com> wrote:

=20


On 5/24/20 05:42, Eliot Lear = wrote:
=20 Hi!

On 12 May 2020, at 22:44, Michael Douglass = <mikeadouglass@gmail.com> wrote:

I believe we should support this and I think it's only a minor change to the spec.

I didn't agree with the deprecation of EXRULEs - there are a whole bunch of cases that are easily handled - just because UIs choose not to support it isn't that much of an argument.


Before you readd EXRULE or anything like it, it is = probably worth understanding why it was removed.  There were several reasons:

  1. Almost nobody (nobody?) in the WG at the time said the they had implemented it.  I believe this is = because the UI for EXRULE is not well understood- see below.
  2. Everyone agreed that there was sufficient capability with EXDATE and RRULE.  It wasn=E2=80=99t = perfect, but good enough.
  3. There were ambiguities in corner cases = regarding DTSTART and the actual recurrence set (I don=E2=80=99t = recall the details here- someone might want to check with Bernard, Cyrus, Reinhold, or Jonathan).
  4. We were aiming for a draft standard at the = time, and anything not used had to be pulled/deprecated.

To me,  there is a bigger concern: if you = readd EXRULE and only some people implement, then you will have inconsistent calendars, and some people will show up to events that aren=E2=80=99= t occurring, or worse not attend or schedule events during that time.  And so I would argue that you should have a VERY = strong use case and a very strong consensus to do this, and that CalConnect be consulted.

There are at least 2 aspects to = this:

1. Data representation and libraries to handle = it

2. How to represent in UIs

On the data representation and handling:

At least some underlying libraries handle multiple = rrules and exrules. There are many uses for calendar data outside of the corporate meeting world - the smart grid for example. If we want standards to be used widely they need to be useful.

Then there's the UI implementation.

If we want to make UI's the driver of the standard then we = should pretty much gut rrule because most don't give you any more than a regularly repeating event for a few fixed periods. Your ui might let you enter an rrule but do we really expect anything other than a vanishingly small number of users to be able to construct a rule?

It is possible to come up with a UI which handles = all the complexities of recurrence rules - Bedework has one.

My concern is that we confine a data representation to what = is perceived to be used/useful - additionally the assumption is that the important use case is corporate meetings.



Try this article from 2008 for one

https://blog.jonudell.net/2008/08/28/specifying-e= xceptions-to-recurring-calendar-events/


This case is handled by EXDATE, albeit not ad = infinitum, as RRULE would allow.  And indeed this is how Bernard = answered the question back in 2008 when it was asked.  How would = you propose the UI be done for the EXRULE case?  I=E2=80=99m = not saying that UI is the IETF=E2=80=99s general concern, but there=E2=80=99= s no point in adding the function if people can=E2=80=99t reasonably take = advantage of it.



And this would be solved

https://webapps.stackexchange.com/questions/13659= 8/google-calendar-weekly-recurring-event-except-last-week-of-month


The example given in StackExchange itself is = solved with RRULE as follows.

RRULE:FREQ=3DMONTHLY;BYDAY=3D1MO,2MO,3MO,-2MO

That is, the 1st, 2nd, = 3rd and 2nd to the last Monday of the month.  This = creates duplicate recurrences for months with only four Mondays, but RFC 5545 explicitly states that one should delete such duplicates.  I note that Apple doesn=E2=80=99t = provide a UI to create this rule, and its display of the rule is a bit=E2=80= =A6 off... but it generates the recurrence set correctly.  Apple=E2=80=99s very minor UI gaffe only serves to = reinforce my point about being conservative about adding back capabilities.  It=E2=80=99s hard enough for people to = get the existing ones right.

I think this reinforces my point. Or = whose UI is going to set the standard? Should we remove these capabilities from recurrence rules because they are not in a UI?

I would = suggest that if we want to provide users with more useful recurrence UIs then multiple simple rrules and exrules are probably easier to understand - though again not providing the full set of possibilities.



I am not suggesting that you shouldn't add new capabilities, but be careful in doing so.  There really should be good value for real world cases that are not well handled today.  If you really want to go there, let=E2=80=99s see how things work = with non-Gregorian calendars where months only recur occasionally ;-)

Eliot


= --Apple-Mail=_80A7611B-5AF9-4833-A92B-9D637C2FA11E-- From nobody Mon May 25 10:43:44 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 B9B183A0C02 for ; Mon, 25 May 2020 10:43:40 -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 dVG53VKbOm6X for ; Mon, 25 May 2020 10:43:38 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 843813A0C01 for ; Mon, 25 May 2020 10:43:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 6F731301F8F402; Mon, 25 May 2020 13:43:37 -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 kgd2bQ4GXmI5; Mon, 25 May 2020 13:43:27 -0400 (EDT) Received: from 1.0.0.127.in-addr.arpa (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 1F133301F8F3EC; Mon, 25 May 2020 13:43:27 -0400 (EDT) Date: Mon, 25 May 2020 13:43:26 -0400 From: Cyrus Daboo To: Michael Douglass , Calsify Message-ID: <603a5af3-529f-4f8d-b52b-f8fde63f2da7@cyrus.local> In-Reply-To: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> References: <9b5dac13-d0d2-ce30-101e-6ef0c90f05ec@gmail.com> X-Mailer: Mulberry/5.0.0a1 (macOS/10.15.5) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1743 Archived-At: Subject: Re: [calsify] JSCalendar and EXRULE 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, 25 May 2020 17:43:42 -0000 Hi Michael, --On Tue, 12 May 2020 16:44:49 -0400 Michael Douglass wrote: > I believe we should support this and I think it's only a minor change to > the spec. > > I didn't agree with the deprecation of EXRULEs - there are a whole bunch of > cases that are easily handled - just because UIs choose not to support it > isn't that much of an argument. > > Try this article from 2008 for one > > https://blog.jonudell.net/2008/08/28/specifying-exceptions-to-recurring- > calendar-events/ Before putting EXRULE back in please think carefully about the actual set of use cases for recurring exclusions and see if there is a better way to do this. For example, one use case I have: don't have recurring meetings on holidays. How would one accomplish that? Well with just EXRULE that means copying a set of EXRULEs for every holiday pattern into every recurring event just in case they have an instance on a holiday. Clearly that is impractical. What other solutions could we come up with? Perhaps we have the idea of an "exclusion event" - one specified with an RRULE but marked as forcing an exclusion on any recurring or one-off event in the same time slot. Or perhaps that could better be done with an availability component (which could also then be tied to my regular calendar availability and made to auto-decline any invites on holidays). This is definitely a complex situation, but maybe there is an elegant solution. My point here is that I believe there are valid recurring exclusion use cases that have never been seriously considered because they would have been hard or impossible to do with EXRULEs. So we might be able to do something better than EXRULEs for JSCalendar. -- Cyrus Daboo From nobody Mon May 25 20:11:45 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 4D7133A0BA6; Mon, 25 May 2020 20:11:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: calext-chairs@ietf.org, calsify@ietf.org, mglt.ietf@gmail.com, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 7.1.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159046270256.17493.15351829889438330157@ietfa.amsl.com> Date: Mon, 25 May 2020 20:11:43 -0700 Archived-At: Subject: [calsify] calext - New Meeting Session Request 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: Tue, 26 May 2020 03:11:43 -0000 A new meeting session request has just been submitted by Daniel Migault, a Chair of the calext working group. --------------------------------------------------------- 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: Conflicts to Avoid: Chair Conflict: jmap extra ace drip People who must be present: Barry Leiba Daniel Migault Bron Gondwana Resources Requested: Special Requests: ---------------------------------------------------------