From nobody Thu Feb 6 16:03:34 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 8B00A12011B; Thu, 6 Feb 2020 16:03:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: brong@fastmailteam.com, barryleiba@computer.org, calsify@ietf.org, calext-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158103381144.5042.14528589874244287501.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2020 16:03:31 -0800 Archived-At: Subject: [calsify] calext - New Interim Meeting Request X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 00:03:32 -0000 A new interim meeting request has just been submitted by Bron Gondwana. This request requires approval by the Area Director of the Applications and Real-Time Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-calext-01 --------------------------------------------------------- Working Group Name: Calendaring Extensions Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana City: Nottingham Country: GB Session 1: Date: 2020-04-21 Start Time: 16:00 Europe/London Duration: 01:30 Remote Participation Information: https://zoom.us/j/4574164360 or dial in by phone, see https://zoom.us/zoomconference for local numbers Agenda Note: --------------------------------------------------------- From nobody Fri Feb 7 08:40:08 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 CB1DF12006D; Fri, 7 Feb 2020 08:40:05 -0800 (PST) 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.117.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158109360562.11769.2991538957355286041@ietfa.amsl.com> Date: Fri, 07 Feb 2020 08:40:05 -0800 Archived-At: Subject: [calsify] Calendaring Extensions (calext) WG Interim Meeting: 2020-04-21 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 16:40:06 -0000 The Calendaring Extensions (calext) Working Group will hold an interim meeting on 2020-04-21 from 16:00 to 17:30 Europe/London. Meeting Location: Nottingham, GB Agenda: Specific details TBA closer to the date, however we will be covering existing drafts as well as anything which has come up during first 2 days of the CalConnect meeting: https://www.calconnect.org/events/calconnect-xlvii-april-20-24-2020 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 Feb 17 18:31:45 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 1638312083F for ; Mon, 17 Feb 2020 04:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=X+c0Hazi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VMH0pXdi 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 eRHSPDiISGHz for ; Mon, 17 Feb 2020 04:11:36 -0800 (PST) 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 0DAA012002F for ; Mon, 17 Feb 2020 04:11:36 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EE3BE21EF0; Mon, 17 Feb 2020 07:11:32 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 17 Feb 2020 07:11:32 -0500 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=154rWcS q3Uai1JLWe8mJfUIFbu1NZOQx80L0dvAckcg=; b=X+c0Hazi7NJ1B3F48tkZ5FM igcX9VxGND+hu/fqWsT22VxM7jYFOMZ+k3F531oyb93qLja5K7KC1cM7FbWUQU3Y CUCK7xq552nvjIUPM+nc0W311sHtqlYzwupiQik6sUK+zlhST+lAmn4UoTK43uD3 yhhy56bguksGXXrUfBuRfPHIuvjDXqeGCn3iY67fJEMmPgNlqBWCKIZfDQHOA4HF W/FCvnQjjnCxBs4wWzGM0XEmDNh0JNFJZ3vDrx28ifJbFKXAAZOiCX9r7RxHohtq Bqlie5UC4Icev/ufp2u/kV7IRt7j4vrpU1clZFC8mxfb7c85NwIXKiM4hj0slEQ= = 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=154rWc Sq3Uai1JLWe8mJfUIFbu1NZOQx80L0dvAckcg=; b=VMH0pXdijSDmNgM4KCYNyy 15AEpJWnM5X/if4YTxyNhRrTw1QDWjklKRBP94q3DPN4DHKuNNvmQMQoij6t5a3y 3jWkZAeZnkisSWkjR7x6bTAwD5PrtJrHqrQM1RCfj202srgoHYQyDJgN+dyF1pZY ye6QgQnAbb/WrfJNn+mbxwq/gLEyBNu1Jvbn0HxATCLN5J1dGtupbAlBKW5MIiML 8Co9ZyV3ExeyT7de9tOO/4oEwfkdQMyCbT9RMv/zkJrZZwZTqt6YCnBZe7UABH7F zhcOTMTOtvVBUSvs9ZjGNNmQrrgaLpJ+pKir6DS2OTVYrIqpjCm0p6kvAhI1NHog == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrjeeigdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtoh hm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 98261180091; Mon, 17 Feb 2020 07:11:32 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-871-gf1112c6-fmnext-20200202v1 Mime-Version: 1.0 Message-Id: <550081ad-8976-4887-b25d-87d88a3a8d86@dogfood.fastmail.com> In-Reply-To: References: <6d0fa1f3-5dbe-d4df-821f-a0bddb61546b@gmail.com> <3d216646-0235-0af4-b9ad-1401eea482c4@gmail.com> <7f83a966-d1e9-464e-acd2-45bb7fd05107@beta.fastmail.com> <98a0f7ca-213d-4be0-9b0c-310dad70c0ab@gmail.com> <595e1efa-97a0-4373-8d5f-d4e5e05a1838@dogfood.fastmail.com> <601a4ef3-d922-71e0-ab4b-8e539ed3f7ae@gmail.com> <669b29a4-1734-4ea1-9ac9-33e590d91762@dogfood.fastmail.com> <07d3a19b-5198-e9fa-acbf-94c5161e11fb@gmail.com> <322a91d4-3246-49df-a1c4-628a59cf5304@dogfood.fastmail.com> <052a9cd1-f2a2-416d-9eda-3971ae2acee2@www.fastmail.com> <8999255e-e6b7-409c-9228-fb4fd0ed396b@beta.fastmail.com> Date: Mon, 17 Feb 2020 23:11:29 +1100 From: "Bron Gondwana" To: "Daniel Migault" , "calsify@ietf.org" Content-Type: multipart/alternative; boundary=d99f6e3dcb18455483e6cf3e557f04c6 Archived-At: Subject: Re: [calsify] WGLC JSCalendar X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2020 12:11:38 -0000 --d99f6e3dcb18455483e6cf3e557f04c6 Content-Type: text/plain Hi Daniel, Hopefully we're good to go now. It would be good to have this one on its way by Vancouver so we can focus on JMAP Calendars over in the JMAP group. Cheers, Bron. On Fri, Jan 17, 2020, at 23:43, Daniel Migault wrote: > The IANA is looking for one more clarification with the IESG. There are following this and I am expecting this to be done next week. As far as I know, this is the only this that retain us from pushing right now. > > Yours, > Daniel > > *From:* calsify *On Behalf Of *Bron Gondwana > *Sent:* Thursday, January 16, 2020 11:46 PM > *To:* calsify@ietf.org > *Subject:* Re: [calsify] WGLC JSCalendar > > Hi Daniel, > > Is there anything else blocking this going to IESG? > > Thanks, > > Bron. > > On Mon, Dec 2, 2019, at 19:48, Robert Stepanek wrote: >> On Mon, Nov 4, 2019, at 12:31 AM, Neil Jenkins wrote: >>> On Mon, 4 Nov 2019, at 08:40, Daniel Migault wrote: >>>> 1) IPR >>>> Could each author confirmed that any and all appropriate IPR >>>> disclosures required for full conformance with the provisions of BCP 78 >>>> and BCP 79 have already been filed. >>> >>> Confirmed from me. >> >> Confirmed from me as well. >> >> Cheers, >> Robert >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >> > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --d99f6e3dcb18455483e6cf3e557f04c6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Daniel,

Hopefully we're good to go now.  It would be good to have this= one on its way by Vancouver so we can focus on JMAP Calendars over in t= he JMAP group.

Cheers,

Bron.

=
On Fri, Jan 17, 2020, at 23:43, Daniel Migault wrote:

The IANA is looking for one more clarification with the I= ESG. There are following this and I am expecting this to be done next we= ek. As far as I know, this is the only this that retain us from pushing = right now.

 

Yours,

Daniel

 

From: calsify <calsify-bounces@i= etf.org> On Behalf Of Bron Gondwana
Sent: Thursday, January 16, 2020 11:46 PM
To: calsify@= ietf.org
Subject: Re: [calsify] WGLC JSCalendar

 

<= p class=3D"qt-MsoNormal">Hi Daniel,
<= /p>

 <= /span>

Is = there anything else blocking this going to IESG?

 

Thanks,<= /span>


Bron.

 

On Mon, Dec 2, 2019, at 19:48, Robert Stepanek wrote:

<= div>

On Mon, Nov 4, 2019, at 12:31 AM, Neil Jen= kins wrote:

On Mon, 4 Nov 20= 19, at 08:40, Daniel Migault wrote:

1) IPR

C= ould each author confirmed that any and all appropriate IPR

disclosures required for full conformanc= e with the provisions of BCP 78

and BCP 79 have already been filed.

 

Confirmed from me.

 

Co= nfirmed from me as well.

&nb= sp;

Cheers,

Robert

 

______________= _________________________________

calsify mailing list

<= a href=3D"mailto:calsify@ietf.org">calsify@ietf.org

https://www.ietf.org/mailman/listinfo/calsify

<= /div>

 

 

--
=

  Bron Gondwana, CEO, Fast= mail Pty Ltd

=

 

 


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

--d99f6e3dcb18455483e6cf3e557f04c6-- From nobody Tue Feb 18 02:08:08 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 EC993120131; Tue, 18 Feb 2020 02:07:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <158202047879.14010.7141970156399540594@ietfa.amsl.com> Date: Tue, 18 Feb 2020 02:07:58 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-23.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 10:07:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : JSCalendar: A JSON representation of calendar data Authors : Neil Jenkins Robert Stepanek Filename : draft-ietf-calext-jscalendar-23.txt Pages : 75 Date : 2020-02-18 Abstract: This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative, and over time successor to, the widely deployed iCalendar data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCal format, it is not a direct mapping from iCalendar and expands semantics where appropriate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-23 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-23 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 18 06:16:33 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 6963812010C; Tue, 18 Feb 2020 06:16:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Daniel Migault , daniel.migaultf@ericsson.com, iesg-secretary@ietf.org, calsify@ietf.org, calext-chairs@ietf.org Message-ID: <158203538630.14126.12366170152808926237.idtracker@ietfa.amsl.com> Date: Tue, 18 Feb 2020 06:16:26 -0800 Archived-At: Subject: [calsify] Publication has been requested for draft-ietf-calext-jscalendar-23 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, 18 Feb 2020 14:16:27 -0000 Daniel Migault has requested publication of draft-ietf-calext-jscalendar-23 as Proposed Standard on behalf of the CALEXT working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ From nobody Tue Feb 18 11:44:52 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 44A4B120815 for ; Tue, 18 Feb 2020 11:44:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.com header.b=YV1eATCX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LnUfxsxc 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 CAPxraQMtwxX for ; Tue, 18 Feb 2020 11:44:49 -0800 (PST) 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 A6548120802 for ; Tue, 18 Feb 2020 11:44:49 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C6DCE220F8 for ; Tue, 18 Feb 2020 14:44:48 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 18 Feb 2020 14:44:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= from:subject:to:message-id:date:mime-version:content-type :content-transfer-encoding; s=fm2; bh=rANjVlnyUIgKg3GV8HcEPxNStH z1dnT1a2hQMd1vu/4=; b=YV1eATCX5pV/UARYUbihGL4Ex4QIuWUOef9zcoL5NJ 7DpiWbrbxHQQHGIZBjxW1p62FrfaSr8VMDyv7Q68dAPJnadpiv0I1NMYd3uJT90E 37QcvtnelJThSb9SiCBJrMDSsLk9DRXxQvMdJIHi80z+ZBlvlZlcEdOB3ESxrbiB 4d6nya+X5lKS/F1Po0GxCXAA8FElYKUKv9zFwXfpf1ol4Jq0k94KhaHb1NYVEt2o PRNH+e7bo+Mvcp1TeAm6NzRamMSbRgGAZv9snK1ilh0sPxiiM/5HblWPN05Peq43 I0V6zk6yZV/6z8Ce7ddoAk2ugaimkaYhJlo7WVgxvSOQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=rANjVl nyUIgKg3GV8HcEPxNStHz1dnT1a2hQMd1vu/4=; b=LnUfxsxc5oAc4gkJKORsfN TOmufeG6dyvIFedmfevgR8J77TccimkU6HNnBIZqhpqkxSE0B8OtEUIuZmO3QdUl NSjosdvm0sF+4fXJAmgkMciS5Bdqc/gow5tF5wNop1t0EdUziD2KtOVXsrBggdp8 KYbRIv2sqYPxwg8A6vJw5qNwfvGlws/nzTlD91QANtCi3oCpXNpnNcXU4K3V+cX+ SEhcqrSMzzqlHR4kRp6yFUGWsSscL6grUkfXKzOSjP6wLKMWGgrgjB9roU2Qbvky MZK7PW8oUk0UsMKbE03t9bka7VSo+NK8tzZ7BTxw/9r5RIMNz44U1mW6Del1Kaxw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrjeekgdduvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhuffvohfkffgfgggtgfesthekre dttdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehfrghs thhmrghilhdrtghomheqnecukfhppeejgedrjeejrdekhedrvdehtdenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhm rghilhdrtghomh X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 683B63280063 for ; Tue, 18 Feb 2020 14:44:48 -0500 (EST) From: Ken Murchison To: calsify Organization: FastMail US LLC Message-ID: <7397defc-9743-806a-5227-988c72873dea@fastmail.com> Date: Tue, 18 Feb 2020 14:44:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 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] draft-ietf-calext-jscalendar-23 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, 18 Feb 2020 19:44:51 -0000 A few editorial nits: 4.3.2.1, item 2, applying skip, item 1:  I suggest adding a comma between "given year" and "increment it" as I think it makes 4.4.2: "Specifies how this property..." -> "Specifies how the calendar object..."         Also, is there a particular reason the busy-unavailable and busy-tentative values from 5545 have been excluded? Can I assume that the reason that a property that could be represented as an array of items (e.g. roles) is instead represented as an object with key=true items is that arrays can't be patched but items CAN be removed from an object with a patch setting key=false?  Whether this is the case or not, should this design decision be discussed somewhere? -- Ken Murchison Cyrus Development Team Fastmail US LLC From nobody Tue Feb 18 22:58:53 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CDA12006F; Tue, 18 Feb 2020 22:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.892 X-Spam-Level: X-Spam-Status: No, score=0.892 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TO_NO_BRKTS_PCNT=2.292] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOvyW3PmCE9R; Tue, 18 Feb 2020 22:58:49 -0800 (PST) Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) (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 683B312001A; Tue, 18 Feb 2020 22:58:46 -0800 (PST) Received: by mail-il1-f176.google.com with SMTP id p8so19622209iln.12; Tue, 18 Feb 2020 22:58:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=ksu20sUTQWB870gyM3+UvXUdCii4ycNybLruC67rGvk=; b=ueJE7xL54Dw+wm33fNcGDbJfUPkYuePti86xjV02k/e3oqdGmBweyJzXLG6Hma74MZ VvFPTK8fNOOCsmJLyVorIm8xjbbypJoQVYOw5laj/dHDkxeYcOQdF+3nbCqi8dMoqEBc 98ts0p5dQd3I433wyUe7dNKsecap3dOepWIEYZkkuUsErXKHegb6IeUetf7wKYfId0cg u2RE3bo/rlQhtwV5gQrMuKofFGoU7AGL6sIy4LEhN21+oMWZDYhqz9qli9qGVat1zNUw SWOt3yCvdzY6phri9rgkhVOkm3h3zE+2jpDGEms4SLvO2ujGVQ2BL2C+sReUp/eQv1Gb y+rA== X-Gm-Message-State: APjAAAWmYJjtkfai0uPutA5R2ooD/QLdLunJcgcD9AU7NiEfZB44NSir ZrFgAa/guOihFxYBiY89U6w/jStmvDrLBE0mPNanOt8lDt8= X-Google-Smtp-Source: APXvYqyUSnfmpd0qeuExBw+FCbkza9VekHsfvTlV2OecPRyRxhBcn/mwgBUe7XGqfHRP+9kb7gptYsdp9FlfsNyW5MA= X-Received: by 2002:a92:9885:: with SMTP id a5mr23306621ill.107.1582095524395; Tue, 18 Feb 2020 22:58:44 -0800 (PST) MIME-Version: 1.0 From: Barry Leiba Date: Tue, 18 Feb 2020 22:58:33 -0800 Message-ID: To: draft-ietf-calext-jscalendar.all@ietf.org Cc: calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [calsify] AD review of draft-ietf-calext-jscalendar-23 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, 19 Feb 2020 06:58:52 -0000 Thanks for the work on this document. I have a long list of comments, many of which are just editorial, but a number of which are substantive. Because of the length of the list, I=E2=80=99d rather we deal with all of them before moving the document into last call, so please digest this list, address what you can directly, and chat with me about the others. Throughout: =E2=80=9Ci.e.=E2=80=9D and =E2=80=9Ce.g.=E2=80=9D each needs a = comma after it, always. Throughout: Please use =E2=80=9Cmedia type=E2=80=9D instead of =E2=80=9CMIM= E type=E2=80=9D. =E2=80=94 Abstract =E2=80=94 It aims to be an alternative, and over time successor to, the widely deployed iCalendar data format and to be unambiguous, extendable and simple to process. =E2=80=A8Some misplaced commas here. NEW It aims to be an alternative and, over time, a successor to the widely deployed iCalendar data format, and to be unambiguous, extendable, and simple to process. END =E2=80=A8 In contrast to the JSON-based jCal format, it is not a direct mapping from iCalendar and expands semantics where appropriate. I would be clearer about what it *is*, rather than just saying what it isn=E2=80=99t. Maybe something like this (tweak accordingly): NEW In contrast to the jCal format, which is also JSON-based, JSCalendar is not a direct mapping from iCalendar, but defines the data model afresh and expands semantics where appropriate. END =E2=80=94 Section 1 =E2=80=94 o The attributes of the calendar entry represented must be described as a simple key-value pair. Simple events are simple to represent, complex events can be modelled accurately. Number agreement: =E2=80=9Cas simple key-value pairs=E2=80=9D (multiple att= ributes) The second sentence is a comma splice; either change the comma to a semicolon or put =E2=80=9Cand=E2=80=9D after the comma. o The data model should avoid ambiguities and make it difficult to make mistakes during implementation. Is =E2=80=9Cdifficult=E2=80=9D really the right word? Or maybe =E2=80=9Cle= ss likely=E2=80=9D? =E2=80=A8 and drop widely unused, obsolete or redundant =E2=80=9CWidely=E2=80=9D doesn=E2=80=99t seem apt with a negative such as = =E2=80=9Cunused=E2=80=9D (sort of like how something can be =E2=80=9Ctwice as often used=E2=80=9D, but not = =E2=80=9Ctwice as often unused=E2=80=9D). I would say =E2=80=9Cseldom-used=E2=80=9D (and I w= ould add the Oxford comma, as I did in the Abstract and would do throughout the document, but I=E2=80=99m not going to push that nor mention it again). should be easy with most common iCalendar files but is not guaranteed with the full specification. What does =E2=80=9Cnot guaranteed with the full specification=E2=80=9D mean= ? can you maybe rephrase it? o Extensions, such as new properties and components, MUST NOT lead to requiring an update to this document. I think it=E2=80=99s impossible to guarantee that at a =E2=80=9CMUST NOT=E2= =80=9D level. maybe, =E2=80=9Cgenerally do not require updates to this document.=E2=80=9D =E2=80=94 Section 1.1 =E2=80=94 For example, iCalendar defines various formats for local times, UTC time and dates, which confuses new users and often leads to implementation errors. Other sources for errors are the requirement for custom time zone definitions within a single calendar component, as well as the iCalendar format itself; the latter causing interoperability issues due to misuse of CR LF terminated strings, line continuations and subtle differences between iCalendar parsers. The definition of recurrence rules is ambiguous and has resulted in differing understandings even between experienced calendar developers. OK, I said I wouldn=E2=80=99t mention it again, but here=E2=80=99s an examp= le of where something is actually made harder to read by not including the Oxford comma: I read item 1, =E2=80=9Clocal times=E2=80=9D, then item 2, =E2=80=9C= time and dates=E2=80=9D, then started looking for item 3. Um. But in general, I think the paragraph is clunky and would benefit from being structured as a list. Does this look reasonable?: NEW Sources of implementation errors include the following: - iCalendar defines various formats for local times, UTC time, and dates= . - iCalendar requires custom time zone definitions within a single calendar component. - iCalendar=E2=80=99s definition of recurrence rules is ambiguous and ha= s resulted in differing understandings even between experienced calendar develope= rs. - The iCalendar format itself causes interoperability issues due to misu= se of CRLF-terminated strings, line continuations, and subtle differences among iCalendar parsers. END In recent years, many new products and services have appeared that wish to use a JSON representation of calendar data within their API. Number agreement: =E2=80=9Cwithin their APIs.=E2=80=9D JSCalendar is intended to meet this demand for JSON-formatted calendar data, and to provide a standard, elegant representation as an alternative to new proprietary formats. The IESG is going to complain about saying what you intend, rather than what you=E2=80=99re doing, and they will definitely push back on marketing-sounding things such as claims of elegance. I also find =E2=80=9Cthis demand=E2=80=9D to lack a clear antecedent. =E2=80=A8NEW JSCalendar meets the demand for JSON-formatted calendar data that is free of such known problems and provides a standard representation as an alternative to the proprietary formats. END =E2=80=94 Section 1.2 =E2=80=94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Please use the new BCP 14 boilerplate and add a normative reference to RFC8= 174. =E2=80=94 Section 1.3 =E2=80=94 Other types may also be given, with their representation defined elsewhere in this document. Number agreement: =E2=80=9Cwith their representations defined=E2=80=9D =E2=80=94 Section 1.4.2 =E2=80=94 Where "UnsignedInt" is given as a data type, it means an "Int" where the value MUST be in the range 0 <=3D value <=3D 2^53-1. Why is there a MUST here, but not in 1.4.1. I suggest defining these two (Int and UnsignedInt) consistently. I don=E2=80=99t much care whether = you use MUST or not, though I would opt for not, so: NEW Where =E2=80=9CUnsignedInt" is given as a data type, it means an integer= in the range 0 <=3D value <=3D 2^53-1, represented as a JSON "Number". END =E2=80=94 Section 1.4.3 =E2=80=94 In common notation, it should be of the form "YYYY-MM-DDTHH:MM:SSZ". =E2=80=A6which doesn=E2=80=99t allow for fractional seconds, which are allo= wed if they=E2=80=99re non-zero. I=E2=80=99m just noting that; I=E2=80=99m not su= re it should be fixed. =E2=80=94 Section 1.4.4 =E2=80=94 Instead, they occur in every time zone at the same wall-clock time (as opposed to the same instant point in time). I found myself momentarily unsure abnout this sentence. I suggest a slight rewording that I think is slightly (just slightly) clearer): NEW Instead, they occur in each time zone at the given wall-clock time (as opposed to the same instant point in time). =E2=80=A8END =E2=80=A8=E2=80=94 Section 1.4.6 =E2=80=94 signed-duration =3D (["+"] / "-") duration I guess this works. I think this is a bit cleaner. No?: NEW signed-duration =3D ["+" / "-"] duration END (I passed the original by a colleague as a check, and he kept looking at it with varying puzzled expressions before he agreed that he understood it. Let=E2=80=99s not make people work that hard.) =E2=80=94 Section 1.4.7 =E2=80=94 characters from the "URL and Filename Safe" base64 alphabet, as defined in Section 5 of [RFC4648] For absolute, 100% clarity I suggest << "URL and Filename Safe" base64url alphabet >>. Ids need not be unique between different objects. =E2=80=9Camong=E2=80=9D, rather than =E2=80=9Cbetween=E2=80=9D (the latter = implies only two). For example, two JSEvent objects MAY use the same ids in their respective "links" properties. While the BCP 14 =E2=80=9CMAY=E2=80=9D here is arguably not wrong, I think = the intent here isn=E2=80=99t to say what choice is allowed, but to alert the implemen= ter about what could happen. So I=E2=80=99d make it =E2=80=9Cmay=E2=80=9D (or = =E2=80=9Cmight=E2=80=9D). This does not imply any semantic connection between the two. You give two scenarios with two instances in each, so =E2=80=9Cbetween the two=E2=80=9D seems odd. I would simply say, =E2=80=9CThese situations do n= ot imply any semantic connections among the objects.=E2=80=9D The keys are a path in a subset of [RFC6901] JSON pointer format, with an implicit leading "/" (i.e. prefix each key with "/" before applying the JSON pointer evaluation algorithm). =E2=80=9CThe keys are a path=E2=80=9D? There=E2=80=99s at least a number p= roblem here, but I find the whole sentence to be hard to follow. Do you mean this?: NEW Each key is a path represented in a subset of JSON pointer format [RFC6901]. The paths have an implicit leading "/", so each key is prefixed with "/" before applying the JSON pointer evaluation algorithm. END 1. The pointer MUST NOT reference inside an array (i.e. it MUST NOT insert/delete from an array; the array MUST be replaced in its entirety instead). I don=E2=80=99t see any value in =E2=80=9CMUST NOT reference inside an arra= y=E2=80=9D, and there=E2=80=99s a reason that you then clarify it. Just let the clearer version stand alone: NEW 1. The pointer MUST NOT insert/delete values from an array; the array MUST be replaced in its entirety instead. END 3. There MUST NOT be two patches in the PatchObject where the pointer of one is the prefix of the pointer of the other, e.g. "alerts/foo/offset" and "alerts". Is =E2=80=9Cthe=E2=80=9D correct in =E2=80=9Cthe prefix=E2=80=9D, or do you= mean =E2=80=9Ca prefix=E2=80=9D? Are "alerts/foo/offset" and "alerts/foo" allowed together? o null: Remove the property from the patched object. If not present in the parent, this a no-op. What=E2=80=99s the subject of the second sentence? Is it the pointer, the property, the patched object? It=E2=80=99s unclear; please say it explicit= ly, =E2=80=9CIf is not present=E2=80=9D. o Anything else: The value to set for this property (this may be a replacement or addition to the object being patched). The structure of this bullet should be parallel to that of the first bullet: as the first bullet is an instruction, so should this be: NEW o Anything else: Set the value for the property to this value (this may be a replacement or addition to the object being patched). END Implementations MUST reject a PatchObject if any of its patches are invalid. It=E2=80=99s worth being explicit here: NEW Implementations MUST reject in its entirety a PatchObject if any of its patches is invalid. Implementations MUST NOT apply partial patches. END =E2=80=94 Section 1.4.9 =E2=80=94 By default, time zones in JSCalendar are identified by their name in the IANA Time Zone Database [TZDB], and the zone rules of the respective zone record apply. Number agreement: =E2=80=9Cby their names=E2=80=9D and =E2=80=9Czone record= s=E2=80=9D Implementations MAY embed the definition of custom time zones in the "timeZones" property (see Section 4.7.2). Number agreement: =E2=80=9Cdefinitions=E2=80=9D =E2=80=94 Section 1.4.10 =E2=80=94 The object that defines this relation is the linking object, the other object is the linked object. This is a comma splice. Either change the comma to a semicolon or put =E2=80=9Cwhile=E2=80=9D after it (or =E2=80=9Cand=E2=80=9D, but I prefer = =E2=80=9Cwhile=E2=80=9D here). Keys in the set MUST be one of the following values, or specified in the property definition where the Relation object is used, or an IANA-registered value, or a vendor-specific value: I suggest naming the IANA registry from which the key name has to come. Same comment in other places in the document where you say =E2=80=9CIANA-registered value=E2=80=9D. * "child": The linked object is a subpart of the linking object. * "parent": The linking object is part of the overall linked object. I don=E2=80=99t understand the definition of =E2=80=9Cparent=E2=80=9D. Wou= ldn=E2=80=99t a proper definition be parallel to the definition of =E2=80=9Cchild=E2=80=9D, like t= his?: NEW * "parent": The linking object is a subpart of the linkied object. END Note, the Relation object only has one property (except @type); it is specified as an object with a single property to allow for extension in the future. Do you mean, =E2=80=9Cspecified as an array with a single property=E2=80=9D= , or some such? Or maybe this?: NEW Note: the =E2=80=9Crelation=E2=80=9D array only contains one property; i= t is specified as an array to allow for extension in the future. END =E2=80=94 Section 2.2 =E2=80=94 A JSTask may start and be due at certain points in time, may take some estimated time to complete and may recur; none of which is required. This notably differs from JSEvent (Section 2.1) which is required to start at a certain point in time and typically takes some non-zero duration to complete. 1. The semicolon is incorrect, and should be a comma. 2. In the second sentence, =E2=80=9Cwhich is=E2=80=9D needs a comma before = it. 3. Why is that description of JSEvent here, and not in Section 2.1? =E2=80=94 Section 3.1 =E2=80=94 types, but normalization of these types is inherently protocol and scheme-specific, depending on the use-case This needs a hyphen on =E2=80=9Cprotocol-=E2=80=9C (it=E2=80=99s short for = =E2=80=9Cprotocol-specific=E2=80=9D). calendar exchange protocol or defined by another RFC. I would say =E2=80=9Cdefined elsewhere=E2=80=9D, or =E2=80=9Cdefined in ano= ther document=E2=80=9D: it might not be in an RFC. =E2=80=94 Section 3.2 =E2=80=94 Some JSCalendar properties allow vendor-specific value extensions. If so, vendor-specific values MUST be prefixed with a domain name controlled by the vendor, e.g. "example.com/customrel". There=E2=80=99s no =E2=80=9Cif so=E2=80=9D about it: it=E2=80=99s a fact. = Maybe you want to say, =E2=80=9CSuch vendor-specific values MUST=E2=80=A6=E2=80=9D =E2=80=94 Section 4.1.2 =E2=80=94 [RFC4122] describes a range of established algorithms to generate universally unique identifiers (UUID), and the random or pseudo-random version is recommended. I suggest using more specific reference to 4122, and recommending with the BCP 14 key word: NEW [RFC4122] describes a range of established algorithms to generate universally unique identifiers (UUID). UUID version 4, described in Section 4.4 of [RFC4122], is RECOMMENDED. END =E2=80=94 Section 4.1.4 =E2=80=94 For example, it is not to be used to further the understanding of non-standard properties. Just a suggestion here: I would specifically note that this hurts interoperability, something such as this: NEW For example, it is not to be used to further the understanding of non-standard properties, a practice that is knows to cause long-term interoperability problems. END =E2=80=94 Section 4.1.6 =E2=80=94 As this is mandatory (and =E2=80=9Ccreated=E2=80=9D is not), what is the va= lue of this property if the object has not been modified? Is it the initial creation date/time? The text should be clear. =E2=80=94 Section 4.2.3 =E2=80=94 They MAY define parameters and the "charset" parameter value MUST be "utf-8", =E2=80=9Cdefine=E2=80=9D? Do you maybe mean =E2=80=9Cinclude=E2=80=9D? =E2=80=94 Section 4.2.4 =E2=80=94 Indicates the time is not important to display to the user when rendering this calendar object, for example an event that conceptually occurs all day or across multiple days, such as "New Year's Day" or "Italy Vacation". This is spliced, and also is long and awkward. I suggest this: NEW Indicates that the time is not important to display to the user when rendering this calendar object. An example of this is an event that conceptually occurs all day or across multiple days, such as "New Year's Day" or "Italy Vacation". END =E2=80=94 Section 4.2.5 =E2=80=94 This MUST be either one of the following values, =E2=80=9CEither=E2=80=9D is one of two, and there are more than two here. = Just remove =E2=80=9Ceither=E2=80=9D. I also don=E2=80=99t understand what it means for a JSCalendar object to st= art or end at a particular location. Does it mean that the event or task described occurs at the location? Where does =E2=80=9Cstart=E2=80=9D and = =E2=80=9Cend=E2=80=9D come in? Are we talking about things that can move, so they might start one place and end at another? So what happens if the event doesn=E2=80=99t move? Do we set both =E2=80=9Cstart=E2=80=9D and =E2=80=9Cend=E2=80=9D to = the same location? Why is there no way to specify intermediate locations? Can you explain this better? A set of link ids for links to alternate representations of this Make it =E2=80=9Calternative=E2=80=9D (as you do in the next paragraph). This MUST be omitted if none (rather than an empty set). Make it, =E2=80=9CIf there are no links, this MUST be omitted (rather than specified as an empty set).=E2=80=9D =E2=80=94 Section 4.2.7 =E2=80=94 This MAY be a "data:" URL You might want a citation to RFC 2397 here. Links with a rel of "describedby" SHOULD be considered by the client to be an alternate representation of the description. =E2=80=9Calternative=E2=80=9D Links with a rel of "icon" SHOULD be considered by the client to be an image that it MAY use when presenting the calendar data to a user. I=E2=80=99m a bit confused by the SHOULD/MAY. If the image is not used whe= n presenting to the user, is there any other thing that SHOULD be done with it? "rel" property MUST be set to "icon". The value MUST be either Again, remove =E2=80=9Ceither=E2=80=9D. * "badge": an image inline with the title of the object. I don=E2=80=99t understand what =E2=80=9Can image inline with the title=E2= =80=9D means. Do you mean, =E2=80=9Can image meant to be displayed along with the title=E2= =80=9D? Or something else? =E2=80=94 Section 4.2.11 =E2=80=94 value is a case-insensitive color name taken from the set of names It doesn=E2=80=99t make sense to say =E2=80=9Ccase-insensitive=E2=80=9D unl= ess you=E2=80=99re talking about a comparison. Do you mean to say that it=E2=80=99s a lower-case representation? An upper-case representation? Something else? =E2=80=94 Section 4.3 =E2=80=94 Some events and tasks occur at regular, or indeed irregular, intervals. If you keep =E2=80=9Cindeed=E2=80=9D, it needs commas both before and after= it. Better, just remove the word; it adds nothing. And the commas after =E2=80=9Cregular=E2=80=9D and =E2=80=9Cirregular=E2=80=9D are both unnecess= ary. Rather than having to copy the data for every occurrence, you can instead have a master event with a recurrence rule While I don=E2=80=99t object to your using =E2=80=9Cyou=E2=80=9D here, it= =E2=80=99s striking that you use =E2=80=9Cyou=E2=80=9D exactly twice in the document (the other is in 4.= 3.2.1 bullet 2.1), so this is a style deviation. Do as you see fit with that information. =E2=80=94 Section 4.3.2 =E2=80=94 If the task defines neither a "start" nor "due" date-time, its "recurrenceRules" property value MUST be null. Or absent? This MUST be either a CLDR-registered calendar system name, or a non-standard, experimental calendar system name prefixed with the characters "x-". 1. CLDR? Please define and include a reference citation. 2. See RFC 6648 and tell me why we should still have =E2=80=9Cx-=E2=80=9C h= ere. =E2=80=94 Section 4.3.2.1 =E2=80=94 the first day of the next month (if skip =3D=3D "forward") or th= e last day of the current month (if skip =3D=3D "backward"). In the previous bullet you say << (if skip is "backward=E2=80=9D) >>, and I suggest you write these that way as well. Consistency. (Similar comment for << if skip =3D=3D "omit" >> a few bullets down.) =E2=80=94 Section 4.4.1 =E2=80=94 The priority is specified as an integer in the range 0 to 9. A value of 0 specifies an undefined priority. A value of 1 is the highest priority. A value of 2 is the second highest priority. Subsequent numbers specify a decreasing ordinal priority. A value of 9 is the lowest priority. What happens whenb priority 0 is mixed with other priority values? =E2=80=94 Section 4.4.4 =E2=80=94 The value is a URI to use that method. There=E2=80=99s no antecedent to =E2=80=9Cthat=E2=80=9D. I think it should= be, =E2=80=9CThe value is a URI for the method specified in the key.=E2=80=9D (Same comment for Sect= ion 4.4.5.) property MUST be omitted if no method is defined (rather than an empty object). =E2=80=9Crather than being specified as an empty object=E2=80=9D. (Same co= mment for Section 4.4.5.) o "other": The organizer is identified by this URI but the method how to submit the RSVP is undefined. Poor English here; make it, =E2=80=9Cthe method for submitting the response= is undefined.=E2=80=9D (Same comment for Section 4.4.5.) * "resource": a non-human resource, e.g. a projector * "location": a physical location involved in the calendar object that needs to be scheduled, e.g. a conference room. I would argue that a location is a non-human resource. I suggest switching the order and clarifying it, thus: NEW * "location": a physical location that needs to be scheduled, such as a conference room. * "resource": a non-human resource other than a location, such as a projector END =E2=80=94 Secton 4.4.5 =E2=80=94 This MUST be omitted if none (rather than an empty set). I=E2=80=99ve mentioned this enough times that you should know how to fix th= is and all other similar sentences. object, which caused this participant to be invited due to their membership of the group(s). =E2=80=9Cmembership in the group(s).=E2=80=9D =E2=80=94 Section 4.5.2 =E2=80=94 o trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger" (mandatory) This is a manner of specifying this sort of thing that has not been used before. You=E2=80=99ve always been using a defined type. Here (and i= n other items below) you appear to be using specific strings with no explanation about what the =E2=80=9C|=E2=80=9D means. There=E2=80=99s an i= nconsistency here that I=E2=80=99d like to see fixed or clearly explained. Defines when to trigger the alert. New types may be defined in future RFCs. =E2=80=9Cfuture documents=E2=80=9D or =E2=80=9Cfuture specifications=E2=80= =9D, and similarly for other instances of =E2=80=9Cfuture RFC=E2=80=9D. The Relation object SHOULD set the "parent" relation type, but MAY be empty. These are contradictory: if it SHOULD be non-empty, then it=E2=80=99s not correct that it MAY be empty. =E2=80=94 Section 4.7.2 =E2=80=94 Maps identifiers of custom time zones to their time zone definition. Number agreement: =E2=80=9Cdefinitions=E2=80=9D =E2=80=94 Section 6.8 =E2=80=94 a virtual location. Fans can see a live convert on premises or =E2=80=9Cconcert=E2=80=9D ? "description": "Music Bowl, Central Park, New York", "coordinates": "geo:40.7829,73.9654" Should this maybe be << geo:40.7829,-73.9654 >> =E2=80=94 Section 7 =E2=80=94 The transmission of such information must be careful to protect it from possible threats, such as eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle attacks. =E2=80=9Cmust be done carefully=E2=80=9D =E2=80=94 Section 7.1 =E2=80=94 It is not always possible to tell this through static analysis of the rule, so implementations MUST be careful to avoid getting stuck in an infinite loop, or otherwise exhausting resources, searching for the next occurrence. Number agreement: =E2=80=9Cinfinite loops=E2=80=9D Also, =E2=80=9Cexhausting resources while searching=E2=80=9D =E2=80=94 Section 8.1 =E2=80=94 Person & email address to contact for further information: calext@ietf.org The address is incorrect; it should be calsify, not calext. =E2=80=94 Section 8.2.3 =E2=80=94 This preferably takes the form of an RFC, but for simple definitions a description in the registry may be sufficient. I=E2=80=99ve had a conversation with IANA about this. The operative bit he= re is whether "a description in the registry" could serve as the "specification". I don't think we'd accept that. It's supposed to be, according to BCP 26, a "permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible." While what you put in the registry can be considered permanent, and it's certainly readily available and public, it's a bit of a stretch. And it's hard to imagine that a sentence or two in a registry could be "sufficient detail". I'd say that some document, however brief, that's external to IANA is required. Before a period of 30 days has passed, the DE will either approve or deny the registration request and publish a notice of the decision to the Calext WG mailing list or its successor, as well as inform IANA. IANA has expected response times, and specifying this stuff in RFCs is not a good idea. I=E2=80=99d suggest tagging this for IANA review and gett= ing agreement with IANA about what we should say here. If the DE does not respond within 30 days, the registrant may request the IESG take action to process the request in a timely manner. This part definitely needs to go. People can always take complaints to the IESG, and we shouldn=E2=80=99t be saying that here. The IESG may reassign responsibility for a JSCalendar property. The most common case of this will be to enable changes to be made to a registration where the author of the registration has died, moved out of contact, or is otherwise unable to make changes that are important to the community. And similarly for this; please strike it. =E2=80=94 Section 8.2.5 =E2=80=94 The property name MUST NOT already be registered for any of the objects listed in Context. What does =E2=80=9Clisted in Context=E2=80=9D mean? Can you explain this i= n the document? =E2=80=94 Section 8.4.1 =E2=80=94 o Experts: The initial list of experts for Expert Review of updates to the subregistry. Hm, are you actually proposing that registrations provide their own lists of experts, rather than having them appointed by the IESG? I don=E2=80=99t think that=E2=80=99s going to work. We probably need to have= a discussion about the intent here, so please initiate that by explaining to me what you=E2=80=99re looking for. =E2=80=94 Section 10 =E2=80=94 It=E2=80=99s not acceptable that all references are informative: there are clearly normative references here, and you=E2=80=99ll have to go through an= d sort out which ones are normative (which ones are for material that=E2=80= =99s necessary for understanding this document. At the very least, the references for BCP 14, JSON, JSON Pointer, and things such as that will be normative. --=20 Barry From nobody Wed Feb 19 15:32:22 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 872EF120802; Wed, 19 Feb 2020 15:32:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=googlemail.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 ejaSSY97f6Fc; Wed, 19 Feb 2020 15:32:18 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 7FB09120052; Wed, 19 Feb 2020 15:32:18 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id b17so99719wmb.0; Wed, 19 Feb 2020 15:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Jp2xm9jH6nMOkjKVn1X/xtE3RsGOhS2TbDLnibvoPVs=; b=hLZXwkYOVzl1Ssj30PibYFSDeRm/gQTcc9AvxrKX/vytWkhNKHmDV88o9u9AEw/Cpl 6zMLSznz6Tx25rwjmzxNSCn4PBZMxe88lsytyEOQEj1DF0Wx9MRbPpdwAdkcRW9EAaSK Qpt3/L526qEWCwpY1B7CU1/7O9yN1LC1gLG7NwBHxQ9jODN6egYB04uQyk3t+NVk2QWI CaklazUIuA84qxA6B5f2qyhLlgKEaHLSktJUsxL38xnOss5zHYNmSMTSK+R8f5FrI3f9 oFU2zSGwq4wxBsDA6feP/zChgl+Q42QrkuCxW4TDwAOdT6OQ/5zYyG+GJw6x+uk4LYac 6KvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Jp2xm9jH6nMOkjKVn1X/xtE3RsGOhS2TbDLnibvoPVs=; b=eDWkrKNpw7VOOLxjZClZFVQLlDskC2LH164n/vj+JJJJTA+J6tIwmSOMK+4U9xMspF JadkLiXWTK+7YOH0vrGRoE8YtTEa4DMmuThtWEukV4RaZFIAbn96y+sP5btxS8NY6l69 ib9vRhN8QwUeNKxh7cLsiHZPwtmHd1mCKwTiTWa1eA56eWJrip2QKNYLzgK80/MdpGoN zsVhUjbmlSoenTCXrLWLe5hNQu2A2K5W0B9C+8yC2MeG9gPqhSPLHrrzQgechbInkkbz d+F2UziHBHaKc2exSs+W/Royahn1gmTQ6MDC1ZzZJ0vW0Iivme8mrzNDYaXUzne9IelZ j0Bg== X-Gm-Message-State: APjAAAVIpvwkpJuzenNwkEYQlSMLOO3BuD5OTHoWa74HJqtt1W6cYxRM 95D8d7I/q4nAFO2k6+0vkocJ3mF1EHA= X-Google-Smtp-Source: APXvYqxgt/Wk/iWqUt925XW0WPjChr30POZwQCkcts6X7wTc4bD4+R65apMDZkWzmSZ36IYeEL+yKw== X-Received: by 2002:a05:600c:230d:: with SMTP id 13mr144146wmo.13.1582155136910; Wed, 19 Feb 2020 15:32:16 -0800 (PST) Received: from [192.168.1.107] (ppp-46-244-248-223.dynamic.mnet-online.de. [46.244.248.223]) by smtp.gmail.com with ESMTPSA id c9sm1812766wrq.44.2020.02.19.15.32.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Feb 2020 15:32:16 -0800 (PST) From: Michael H Deckers X-Google-Original-From: Michael H Deckers To: Barry Leiba , draft-ietf-calext-jscalendar.all@ietf.org Cc: calsify@ietf.org References: Message-ID: <3bfc7bbf-7ca2-afaa-8829-0f9f02670cb4@googlemail.com> Date: Wed, 19 Feb 2020 23:32:12 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.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] AD review of draft-ietf-calext-jscalendar-23 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, 19 Feb 2020 23:32:21 -0000 On 2020-02-19 06:58, Barry Leiba wrote: > 
— Section 1.4.6 — > > signed-duration = (["+"] / "-") duration > > I guess this works. I think this is a bit cleaner. No?: > > NEW > signed-duration = ["+" / "-"] duration > END > > (I passed the original by a colleague as a check, and he kept looking > at it with varying puzzled expressions before he agreed that he > understood it. Let’s not make people work that hard.)    I beg to disagree. The syntax       (["+"] / "-") duration    makes it clear that a sign may precede a duration, and that    the default sign (if none is explicit) is "+". The proposed    syntax       ["+"  / "-"] duration    does not make the default clear.    Actually, the following text lists the two    alternatives as in the former syntax rule, so I do    not expect difficulties in understanding.    Michael Deckers. From nobody Wed Feb 19 15:35: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 CF044120819; Wed, 19 Feb 2020 15:35:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pb2LZim5Cvvb; Wed, 19 Feb 2020 15:35:26 -0800 (PST) Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) (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 82FBC120802; Wed, 19 Feb 2020 15:35:26 -0800 (PST) Received: by mail-io1-f66.google.com with SMTP id i11so2542775ioi.12; Wed, 19 Feb 2020 15:35:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kyUhRz+9zeUCa0JXC8WiQA7G9NLXszPet6NDaMFZizk=; b=HP0H0m+jPKjB2EZzyvJLivnh+puRIATH5jzpg+bvqZxP2DCnbS1W4R59lrECMVdrt2 xr92lQLI4AQLWK1NeGI7u4TLR+/P2mVqPsJgY80ZDRcE7OjiiFnJn+3y6LxrVGMpwflX HPlaP2mHP55Uh0D5ucU4p2PP1wM6OnIE6vFgk/BGNP0x/9oKl2bsk8CMaNk9rG7Uxo2F WQeBKRu66l4LfsnrDiesCSzFGUy4oMVuUs0diXPC7rpM3SB4aeGAKX13CAWw4+G4mkDr 5lcrnyVyeH2iTxclkudAWqy84HkULzKzzfk7TKHF93yzRkG0GJ1FK1zqejiOVuewOt5x L5Zg== X-Gm-Message-State: APjAAAWLnKm8aldDXYZkmoRAikMDMhTvpDCEuXt35B/KrH/ssMA3E+PI DOSvnCrXVcE4s9eZ0PrjHgT61mEwaXVyHXcGQmeGVVaT X-Google-Smtp-Source: APXvYqye9JjJpsa+2GEwpuqz2cIlepLd9wckJBOJs2hviZ8pkhAzqjsjdRUwHHl9PJhY7s0avjiKXEi3D/eowSq5VGo= X-Received: by 2002:a02:aa11:: with SMTP id r17mr22823247jam.88.1582155325508; Wed, 19 Feb 2020 15:35:25 -0800 (PST) MIME-Version: 1.0 References: <3bfc7bbf-7ca2-afaa-8829-0f9f02670cb4@googlemail.com> In-Reply-To: <3bfc7bbf-7ca2-afaa-8829-0f9f02670cb4@googlemail.com> From: Barry Leiba Date: Wed, 19 Feb 2020 15:35:14 -0800 Message-ID: To: Michael H Deckers Cc: draft-ietf-calext-jscalendar.all@ietf.org, calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-jscalendar-23 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, 19 Feb 2020 23:35:28 -0000 I'm not going to hold out and block things on this point, so if the working group really want to stay with the harder-to-follow version I'll step aside. But I do feel that using an alternative structure where one alternative is optional and the other is not... is really unnecessarily confusing. The text certainly make the default clear, and keep in mind that ABNF is not intended to convey such things as defaults. Barry On Wed, Feb 19, 2020 at 3:32 PM Michael H Deckers wrote: > > > On 2020-02-19 06:58, Barry Leiba wrote: > > > > > =E2=80=94 Section 1.4.6 =E2=80=94 > > > > signed-duration =3D (["+"] / "-") duration > > > > I guess this works. I think this is a bit cleaner. No?: > > > > NEW > > signed-duration =3D ["+" / "-"] duration > > END > > > > (I passed the original by a colleague as a check, and he kept looking > > at it with varying puzzled expressions before he agreed that he > > understood it. Let=E2=80=99s not make people work that hard.) > > > > I beg to disagree. The syntax > > (["+"] / "-") duration > > makes it clear that a sign may precede a duration, and that > the default sign (if none is explicit) is "+". The proposed > syntax > > ["+" / "-"] duration > > does not make the default clear. > > Actually, the following text lists the two > alternatives as in the former syntax rule, so I do > not expect difficulties in understanding. > > Michael Deckers. > From nobody Wed Feb 19 15:42:55 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F95F12095F; Wed, 19 Feb 2020 15:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxeTI_a2KkQf; Wed, 19 Feb 2020 15:42:53 -0800 (PST) Received: from mail-io1-f65.google.com (mail-io1-f65.google.com [209.85.166.65]) (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 76567120908; Wed, 19 Feb 2020 15:42:53 -0800 (PST) Received: by mail-io1-f65.google.com with SMTP id c16so2596822ioh.6; Wed, 19 Feb 2020 15:42:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=CK8xzqNINvElFCAk/rGDBCtBexviGXegCeHLsu2rvn0=; b=qF0AhuO9+taoJQhjpO4Wa6PRnMrVhcYKQo5CDtWQyakOu6DcKbCKYaprYbh8sMuHan PK+IJIFebGTPBCjqyaFRopsc1fknP5kkUQGAFxgVmmwjZOX2YuSZDhT8HT8heBve9TEF QowhS/9nuF44a51F7RmiE+5EoSmGWgI7NfQl6ZpVLr6fLSxV+N9EAwOFhspFBhRFY3P2 7H9b8IbLhet8uuj2RzkDgGXgO8eQ+4rpeidGHL+4oXTXOEKzcpFMqCqC0hyxkODROTQA WOwXFNJa+VC9RGbwnuOmIuNoODzipgmyzlXnd/2sCWuCFUTrNzUIuHOTZie0IdxQJU6P q21A== X-Gm-Message-State: APjAAAViMMnpd2csY4sBYbOKcBhPSshFue7GCMvfuZY39cjH3oq+WTst hM+sn2Sf/SWsQk6mKAlHpc9ppg5cWb8qI6lhEXtwwY8f X-Google-Smtp-Source: APXvYqyPIIreN7ssOAAqRpb8FuFTrVWB3T/J9TMxs1Wm68uBz5hKMiPv3s3UJdnltkTF9vzvXvsihoTDXRNJ5n7DcEg= X-Received: by 2002:a05:6638:2b6:: with SMTP id d22mr23210654jaq.59.1582155772665; Wed, 19 Feb 2020 15:42:52 -0800 (PST) MIME-Version: 1.0 References: <3bfc7bbf-7ca2-afaa-8829-0f9f02670cb4@googlemail.com> In-Reply-To: From: Barry Leiba Date: Wed, 19 Feb 2020 15:42:41 -0800 Message-ID: To: Michael H Deckers Cc: draft-ietf-calext-jscalendar.all@ietf.org, calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-jscalendar-23 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, 19 Feb 2020 23:42:55 -0000 I'll add that I just passed it by Dave Crocker, as we're both in the same meeting, and his squints and grimaces about the existing construct matched mine. He agrees that you should change it. You now have one current AD and two former ones, one of whom is the editor of the ABNF spec, telling you that what you have there is not a good idea. Barry On Wed, Feb 19, 2020 at 3:35 PM Barry Leiba wrote= : > > I'm not going to hold out and block things on this point, so if the > working group really want to stay with the harder-to-follow version > I'll step aside. But I do feel that using an alternative structure > where one alternative is optional and the other is not... is really > unnecessarily confusing. The text certainly make the default clear, > and keep in mind that ABNF is not intended to convey such things as > defaults. > > Barry > > On Wed, Feb 19, 2020 at 3:32 PM Michael H Deckers > wrote: > > > > > > On 2020-02-19 06:58, Barry Leiba wrote: > > > > > > > > > =E2=80=94 Section 1.4.6 =E2=80=94 > > > > > > signed-duration =3D (["+"] / "-") duration > > > > > > I guess this works. I think this is a bit cleaner. No?: > > > > > > NEW > > > signed-duration =3D ["+" / "-"] duration > > > END > > > > > > (I passed the original by a colleague as a check, and he kept looking > > > at it with varying puzzled expressions before he agreed that he > > > understood it. Let=E2=80=99s not make people work that hard.) > > > > > > > > I beg to disagree. The syntax > > > > (["+"] / "-") duration > > > > makes it clear that a sign may precede a duration, and that > > the default sign (if none is explicit) is "+". The proposed > > syntax > > > > ["+" / "-"] duration > > > > does not make the default clear. > > > > Actually, the following text lists the two > > alternatives as in the former syntax rule, so I do > > not expect difficulties in understanding. > > > > Michael Deckers. > > From nobody Wed Feb 19 20:58: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 99775120143 for ; Wed, 19 Feb 2020 20:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=XdIStAOI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LI4BxACo 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 EY0byMHMwOp7 for ; Wed, 19 Feb 2020 20:58:29 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED811200D6 for ; Wed, 19 Feb 2020 20:58:28 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 2C25C6AA for ; Wed, 19 Feb 2020 23:58:28 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 19 Feb 2020 23:58:28 -0500 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=6WF4A5+ Br0wbSGbM7GkZotFm9+7D81+pWv0Yum13NGE=; b=XdIStAOIQbAeR+jIpLAH/zH V9QbZ+9JfDQsjsABOgAw8Mwws1/pTy2+cVkO0LD811KJczw0oeBVDFJl3xJnwb4V f+gF5srIEtd5UVSy31BDFfvcKJh+8nCkSxcPoW7HG4fSsz20bTDyphHX6qlI/xjx I2fsnRgp0g2fLXXW0ci9HkBf1XvapEtrynQL/rXMOcVjui+xL22U3/wnYL1AmFAe ZfrDGs6ta2QoUq0MiYn4aQF6PaqYRoL9qMqdTH9i8A6XvK1YpjhrFqJfN5RyWsai zJQ/tRzeOpXKVuSHQoDjD69jcfJLAJpWFGGti/zcZt5Nc+dBWIsCaHy0gD427FQ= = 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=6WF4A5 +Br0wbSGbM7GkZotFm9+7D81+pWv0Yum13NGE=; b=LI4BxACoLvF5cmgp1gLJ8Z RKvboZKpEuUuW7USUKSu4SAWmrPWBGrOwhTeXyLvWgXanVLX5Gp5Qd7xdF/XqYWG vpoSIEPsVX0PnzzBs5wTuW18/CulGTbli8Un0JLtMCvOBokGbk/6ekMooQ7Oa7QD T+oDeDB1cUVLPQQ9+hR7qcTwwlzZRSN+IiSAB7HSKqIeOIC345vbwew8Yipzw9o3 +9CsyvNHWv1I6qbRQJmH7nJswg9gMfqD0MFxck5OflzZgm84ymLfQOjG9dpo4nDT gbZpTuSOi6nE7BAUDl6g4h93Nrn0UnBesL9ngSQLu/03SYfEfSKsL3tbw08OROYQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkedugdejkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 81C16180091; Wed, 19 Feb 2020 23:58:27 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-947-gbed3ff6-fmnext-20200220v2 Mime-Version: 1.0 Message-Id: <3ad38f3d-cd48-4b41-b35f-38eb0e76cb65@beta.fastmail.com> In-Reply-To: <7397defc-9743-806a-5227-988c72873dea@fastmail.com> References: <7397defc-9743-806a-5227-988c72873dea@fastmail.com> Date: Thu, 20 Feb 2020 15:58:07 +1100 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=f37888fb83ee4600aa5950c73213dd30 Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar-23 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, 20 Feb 2020 04:58:31 -0000 --f37888fb83ee4600aa5950c73213dd30 Content-Type: text/plain On Wed, 19 Feb 2020, at 06:44, Ken Murchison wrote: > A few editorial nits: > > 4.3.2.1, item 2, applying skip, item 1: I suggest adding a comma > between "given year" and "increment it" as I think it makes > > 4.4.2: "Specifies how this property..." -> "Specifies how the calendar > object..." Thanks, I've made these changes. > Also, is there a particular reason the busy-unavailable and busy-tentative values from 5545 have been excluded? Yes, because these are only relevant in the FREEBUSY type, which JSCalendar does not attempt to represent (like it does not represent VJOURNAL). > Can I assume that the reason that a property that could be represented > as an array of items (e.g. roles) is instead represented as an object > with key=true items is that arrays can't be patched but items CAN be > removed from an object with a patch setting key=false? It's key == `null` to remove, but yes this is the reason behind it. Cheers, Neil. --f37888fb83ee4600aa5950c73213dd30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, 19 Feb = 2020, at 06:44, Ken Murchison wrote:
A few editorial nits:

4.3.2.= 1, item 2, applying skip, item 1:  I suggest adding a comma 
between "given year" and "increment it" as I think it makes=

4.4.2: "Specifies how this property..." -&= gt; "Specifies how the calendar 
object..."
=

Thanks, I've made these changes.
<= div>
Also, is there a = particular reason the busy-unavailable and busy-tentative values fr= om 5545 have been excluded?

Ye= s, because these are only relevant in the FREEBUSY type, which JSCalenda= r does not attempt to represent (like it does not represent VJOURNAL).

Can I assume= that the reason that a property that could be represented 
as an array of items (e.g. roles) is instead represented as an ob= ject 
with key=3Dtrue items is that arrays can't be p= atched but items CAN be 
removed from an object with = a patch setting key=3Dfalse?

I= t's key =3D=3D null to remove, but yes this is the reason behind i= t.

Cheers,
Neil.
--f37888fb83ee4600aa5950c73213dd30-- From nobody Wed Feb 19 21:17:30 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 D834B12022E; Wed, 19 Feb 2020 21:17:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <158217584878.17738.17733480954529491626@ietfa.amsl.com> Date: Wed, 19 Feb 2020 21:17:28 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-24.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 05:17:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : JSCalendar: A JSON representation of calendar data Authors : Neil Jenkins Robert Stepanek Filename : draft-ietf-calext-jscalendar-24.txt Pages : 77 Date : 2020-02-19 Abstract: This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format, and to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also JSON-based, JSCalendar is not a direct mapping from iCalendar, but defines the data model independently and expands semantics where appropriate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-24 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-24 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 19 21:29: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 2341312023E for ; Wed, 19 Feb 2020 21:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=l1MiUuea; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3lYD6mEA 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 WVjEw7HHRxgQ for ; Wed, 19 Feb 2020 21:29:38 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D19D1201E4 for ; Wed, 19 Feb 2020 21:29:37 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 401B6600 for ; Thu, 20 Feb 2020 00:29:37 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 20 Feb 2020 00:29:37 -0500 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=utXC9Bj +bxI7/UNKAPGDQPP4imBHeNk3TPnmqd9cwy8=; b=l1MiUueaI02XRZyZkHgN6GI 0Xa042uYBNx9RWZKWQSWgGmtOjy9hF9QdQkpD9ve4BYDRlrw4LiXv0XDvQyzpA92 DnbqE1/nStVGDedoOkEeKFnjC7ZELtRCIXPFXkUtQV4fdi2rnEQbhhH3SZfNzmlc lpQKwXIintnil7Y/dOZ47e9c5GluBp8FlbSAKA7SU6bqyya7De1uDbphlkxwzrBP 98jEorlcHKsUz45dWTCUeGg0pQNJJn+SxNdwk+3IgaDmfbmNJiiam79bYy4GJOSv kgXp03csdWbzVDSpwJdqpFrXroK/BGAuJBBBmGZmcWCL9N6XYorW3nVFFzfSQmA= = 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=utXC9B j+bxI7/UNKAPGDQPP4imBHeNk3TPnmqd9cwy8=; b=3lYD6mEAZFX1lpO4fecr7x N7jklGH+RzV8ci7y1SBR6aYQDtnJw16KObLi50ibTZFXEUquGBW/P+/JP3ygqz7V KKuVREn3IOvMyh3O/HcnBaofxsI9n8RRR/2alOsuOrGn2WIkT9i37ErrEhT2U8H4 xOd3CZD+hVpnC0lRoC/PxLDc+hH1ioi9U57Fh98+Ks+1TFBL8GucjYHN8S6zXizV TLAEBXtwZPpjnfh3WMiZ0JYGoWB1uykQ+GD2aSuY585kRwexnmmjwQlzjU/NqcBW 0e0tGQWMhrYHrKiEuLi0WANOKWNmmPVB04ASsL2ReymepwJvlI2mO+8brGY/Khig == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkedugdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepnhgvihhljhes fhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7F83B180091; Thu, 20 Feb 2020 00:29:36 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-947-gbed3ff6-fmnext-20200220v2 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 20 Feb 2020 16:29:15 +1100 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=23b3464adec342ce9d986d0c2efc90ab Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-jscalendar-23 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, 20 Feb 2020 05:29:41 -0000 --23b3464adec342ce9d986d0c2efc90ab Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Many thanks Barry for your detailed review and excellent suggestions. I = have updated the document with your suggested edits and published a new = version . R= emaining points discussed below. > =E2=80=94 Section 4.4.1 =E2=80=94 >=20 > The priority is specified as an integer in the range 0 to 9. A value > of 0 specifies an undefined priority. A value of 1 is the highest > priority. A value of 2 is the second highest priority. Subsequent > numbers specify a decreasing ordinal priority. A value of 9 is the > lowest priority. >=20 > What happens when priority 0 is mixed with other priority values? VAVAILABILITY (RFC7953) treats it the same as lowest priority (9), but I= could imagine in other systems you might treat it the same as highest p= riority. The current definition is to match with iCalendar as it did not= seem worth deviating here. > =E2=80=94 Section 4.5.2 =E2=80=94 >=20 > o trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger" > (mandatory) >=20 > This is a manner of specifying this sort of thing that has not been > used before. You=E2=80=99ve always been using a defined type. Here (an= d in > other items below) you appear to be using specific strings with no > explanation about what the =E2=80=9C|=E2=80=9D means. There=E2=80=99s = an inconsistency here > that I=E2=80=99d like to see fixed or clearly explained. I'm not sure exactly what you find inconsistent here. These *are* types,= not strings. The definitions of the OffsetTrigger, AbsoluteTrigger and = UnknownTrigger types are immediately below. As per the Type Signatures c= onventions specified in Section 1.3 , the =E2=80=9C|=E2=80=9D means alt= ernation: the value can be any one of these types. > =E2=80=94 Section 8.2.3 =E2=80=94 >=20 > This preferably takes the form of an RFC, but for simple definitions > a description in the registry may be sufficient. >=20 > I=E2=80=99ve had a conversation with IANA about this. The operative bi= t here > is whether "a description in the registry" could serve as the > "specification". I don't think we'd accept that. It's supposed to > be, according to BCP 26, a "permanent and readily available public > specification, in sufficient detail so that interoperability between > independent implementations is possible." While what you put in the > registry can be considered permanent, and it's certainly readily > available and public, it's a bit of a stretch. And it's hard to > imagine that a sentence or two in a registry could be "sufficient > detail". I'd say that some document, however brief, that's external > to IANA is required. The intention here was to reduce friction for people that want to add si= mple properties, to encourage registration rather than use of vendor-spe= cific values which tend to lead to less interoperability. I do think the= re are many simple properties where the entire description could trivial= ly fit in the registry and a document is overkill. Consider the title pr= operty for example, the entire definition is: * 4.2.1 . title * Type: "String" (optional, default: empty String). A short summary of the object. Pretending for a moment this wasn't in the initial spec, this would be r= egistered like so: *Property Name*: title *Property Type*: String *Property Context*: JSEvent, JSTask, JSGroup, Link *Reference or Description*: A short summary of the object. *Intended Use*: Common *Change Controller*: IETF Requiring a whole document for something like this just seems overkill t= o me, but I defer to IANA and your judgement on this; what would you sug= gest we do? > =E2=80=94 Section 8.4.1 =E2=80=94 >=20 > o Experts: The initial list of experts for Expert Review of updates > to the subregistry. >=20 > Hm, are you actually proposing that registrations provide their own > lists of experts, rather than having them appointed by the IESG? I > don=E2=80=99t think that=E2=80=99s going to work. We probably need to = have a > discussion about the intent here, so please initiate that by > explaining to me what you=E2=80=99re looking for. Suppose a new enum-type property is registered that is not IETF controll= ed, then a new enum subregistry will be created and the designated exper= ts need to be given for that subregistry, hence its inclusion in the tem= plate. Does that make sense? Cheers, Neil. --23b3464adec342ce9d986d0c2efc90ab Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Many thank= s Barry for your detailed review and excellent suggestions. I have updat= ed the document with your suggested edits and published a new version. Remaining points discussed below.

=E2=80=94 Section 4.4.1 =E2=80=94

=
   The priority is specified as an integer in the r= ange 0 to 9.  A value
   of 0 specifies an = undefined priority.  A value of 1 is the highest
&nbs= p;  priority.  A value of 2 is the second highest priority.&nb= sp; Subsequent
   numbers specify a decreasing o= rdinal priority.  A value of 9 is the
   lo= west priority.

What happens when priority 0= is mixed with other priority values?

VAVAILABILITY (RFC7953) treats it the same as lowest priority (9= ), but I could imagine in other systems you might treat it the same as h= ighest priority. The current definition is to match with iCalendar as it= did not seem worth deviating here.

=E2=80=94 Section 4.5.2 =E2=80=94

<= /div>
   o  trigger: "OffsetTrigger|AbsoluteTrigger|U= nknownTrigger"
      (mandatory)<= br>

This is a manner of specifying this sort of= thing that has not been
used before.  You=E2=80=99ve= always been using a defined type.  Here (and in
othe= r items below) you appear to be using specific strings with no
=
explanation about what the =E2=80=9C|=E2=80=9D means.  There=E2= =80=99s an inconsistency here
that I=E2=80=99d like to see= fixed or clearly explained.


=E2=80=94 Secti= on 8.2.3 =E2=80=94

   This prefer= ably takes the form of an RFC, but for simple definitions
=    a description in the registry may be sufficient.
<= div>
I=E2=80=99ve had a conversation with IANA about this.=   The operative bit here
is whether "a description in= the registry" could serve as the
"specification".  I= don't think we'd accept that.  It's supposed to
be, = according to BCP 26, a "permanent and readily available public
=
specification, in sufficient detail so that interoperability betwee= n
independent implementations is possible."  While wh= at you put in the
registry can be considered permanent, an= d it's certainly readily
available and public, it's a bit = of a stretch. And it's hard to
imagine that a sentence or = two in a registry could be "sufficient
detail".  I'd = say that some document, however brief, that's external
to = IANA is required.

The intentio= n here was to reduce friction for people that want to add simple propert= ies, to encourage registration rather than use of vendor-specific values= which tend to lead to less interoperability. I do think there are many = simple properties where the entire description could trivially fit in th= e registry and a document is overkill. Consider the title property for e= xample, the entire definition is:

4.2.1.  title

   Type: "String" (optional, default: empty String).

   A short summary of the object.

Pre= tending for a moment this wasn't in the initial spec, this would be regi= stered like so:

Property Name: title=
Property Type: String
Property Co= ntext: JSEvent, JSTask, JSGroup, Link
Reference or= Description: A short summary of the object.
Intend= ed Use: Common
Change Controller: IETF

Requiring a whole document for something like this = just seems overkill to me, but I defer to IANA and your judgement on thi= s; what would you suggest we do?

=E2=80=94 Section 8.4.1 =E2=80=94

   o  Experts: The initial list of experts for Exp= ert Review of updates
      to th= e subregistry.

Hm, are you actually proposi= ng that registrations provide their own
lists of experts, = rather than having them appointed by the IESG?  I
don= =E2=80=99t think that=E2=80=99s going to work.  We probably need to= have a
discussion about the intent here, so please initia= te that by
explaining to me what you=E2=80=99re looking fo= r.

Suppose a new enum-type pro= perty is registered that is not IETF controlled, then a new enum subregi= stry will be created and the designated experts need to be given for tha= t subregistry, hence its inclusion in the template. Does that make sense= ?

Cheers,
Neil.
--23b3464adec342ce9d986d0c2efc90ab-- From nobody Wed Feb 19 22:33:42 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 A6CFE12022E; Wed, 19 Feb 2020 22:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8F9kVjVXMnR6; Wed, 19 Feb 2020 22:33:34 -0800 (PST) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (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 7A33B1200D6; Wed, 19 Feb 2020 22:33:34 -0800 (PST) Received: by mail-io1-f54.google.com with SMTP id x1so3432472iop.7; Wed, 19 Feb 2020 22:33:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EN2FNuEQiommnJWQ0en/iNySWNNAp6XB7nlqoeBN80Y=; b=WQ2AImJWWyrrt63lsiaE3icLiG9fd3QBloBop8Y/BuBrNUaEuIrZecaiIdf3DDlTwe aMf81JOWKTqilfc4FaJ/0ymW+pcxR/5gul6KTGLYCbiIqQ48stM4lB4XmICnpxeLYo8x iWHk66KMjCHnBb2P3drBms0Ed73DWY1uwTmTRSzjNCNWE0sda81+G0RlhJAg8es6mmQG R2v4Cp+iUyc9o6v3Pnx6e1C4O28Qe/UZWtsfBTvUTKY4sb4VuDDndnSOcZUFaT86x7qL oDy7R2HrZeI5IJlrTZ/Hm0Mqx/yrrnZHoPWw4S9Abj59ddC0oiUeSYPOESLoOv78heMI E7Og== X-Gm-Message-State: APjAAAWj+yy03obUFsYV61fMalVyEZiNI0cysWXoAhzWkKs+HVJ7Smxu Kk51MmDOYIcdjObwKG0cH63q5zYOYmLopXXze6NHYJgH X-Google-Smtp-Source: APXvYqzhIXmsTcO35v2n4orQhiaOG509iAiTpeA6AOnUhJ1iSgnuUJsM6+6rlM8tCjqu+qTSYsKZ1eFOF9pIDGPi34o= X-Received: by 2002:a05:6638:2b6:: with SMTP id d22mr24190752jaq.59.1582180412880; Wed, 19 Feb 2020 22:33:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Wed, 19 Feb 2020 22:33:22 -0800 Message-ID: To: draft-ietf-calext-jscalendar.all@ietf.org Cc: calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-jscalendar-23 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, 20 Feb 2020 06:33:39 -0000 Thanks for posting version -24. I'll give that a look over as soon as I can, and then get last call started on it. Barry On Tue, Feb 18, 2020 at 10:58 PM Barry Leiba wrot= e: > > Thanks for the work on this document. I have a long list of comments, > many of which are just editorial, but a number of which are > substantive. Because of the length of the list, I=E2=80=99d rather we de= al > with all of them before moving the document into last call, so please > digest this list, address what you can directly, and chat with me > about the others. > > Throughout: =E2=80=9Ci.e.=E2=80=9D and =E2=80=9Ce.g.=E2=80=9D each needs = a comma after it, always. > > Throughout: Please use =E2=80=9Cmedia type=E2=80=9D instead of =E2=80=9CM= IME type=E2=80=9D. > > =E2=80=94 Abstract =E2=80=94 > > It aims to be an > alternative, and over time successor to, the widely deployed > iCalendar data format and to be unambiguous, extendable and simple to > process. > > Some misplaced commas here. > > NEW > It aims to be an > alternative and, over time, a successor to the widely deployed > iCalendar data format, and to be unambiguous, extendable, and simple > to process. > END > > In contrast to the JSON-based jCal format, it is not a > direct mapping from iCalendar and expands semantics where > appropriate. > > I would be clearer about what it *is*, rather than just saying what it > isn=E2=80=99t. Maybe something like this (tweak accordingly): > > NEW > In contrast to the jCal format, which is also JSON-based, JSCalendar > is not a direct mapping from iCalendar, but defines the data model > afresh and expands semantics where appropriate. > END > > =E2=80=94 Section 1 =E2=80=94 > > o The attributes of the calendar entry represented must be described > as a simple key-value pair. Simple events are simple to > represent, complex events can be modelled accurately. > > Number agreement: =E2=80=9Cas simple key-value pairs=E2=80=9D (multiple a= ttributes) > The second sentence is a comma splice; either change the comma to a > semicolon or put =E2=80=9Cand=E2=80=9D after the comma. > > o The data model should avoid ambiguities and make it difficult to > make mistakes during implementation. > > Is =E2=80=9Cdifficult=E2=80=9D really the right word? Or maybe =E2=80=9C= less likely=E2=80=9D? > > and drop widely unused, obsolete or redundant > > =E2=80=9CWidely=E2=80=9D doesn=E2=80=99t seem apt with a negative such as= =E2=80=9Cunused=E2=80=9D (sort of > like how something can be =E2=80=9Ctwice as often used=E2=80=9D, but not = =E2=80=9Ctwice as > often unused=E2=80=9D). I would say =E2=80=9Cseldom-used=E2=80=9D (and I= would add the Oxford > comma, as I did in the Abstract and would do throughout the document, > but I=E2=80=99m not going to push that nor mention it again). > > should be easy with most common iCalendar files but is not > guaranteed with the full specification. > > What does =E2=80=9Cnot guaranteed with the full specification=E2=80=9D me= an? can you > maybe rephrase it? > > o Extensions, such as new properties and components, MUST NOT lead > to requiring an update to this document. > > I think it=E2=80=99s impossible to guarantee that at a =E2=80=9CMUST NOT= =E2=80=9D level. > maybe, =E2=80=9Cgenerally do not require updates to this document.=E2=80= =9D > > =E2=80=94 Section 1.1 =E2=80=94 > > For example, iCalendar defines various formats for local times, UTC > time and dates, which confuses new users and often leads to > implementation errors. Other sources for errors are the requirement > for custom time zone definitions within a single calendar component, > as well as the iCalendar format itself; the latter causing > interoperability issues due to misuse of CR LF terminated strings, > line continuations and subtle differences between iCalendar parsers. > The definition of recurrence rules is ambiguous and has resulted in > differing understandings even between experienced calendar > developers. > > OK, I said I wouldn=E2=80=99t mention it again, but here=E2=80=99s an exa= mple of where > something is actually made harder to read by not including the Oxford > comma: I read item 1, =E2=80=9Clocal times=E2=80=9D, then item 2, =E2=80= =9Ctime and dates=E2=80=9D, > then started looking for item 3. Um. But in general, I think the > paragraph is clunky and would benefit from being structured as a list. > Does this look reasonable?: > > NEW > Sources of implementation errors include the following: > > - iCalendar defines various formats for local times, UTC time, and dat= es. > > - iCalendar requires custom time zone definitions within a single > calendar component. > > - iCalendar=E2=80=99s definition of recurrence rules is ambiguous and = has resulted > in differing understandings even between experienced calendar develo= pers. > > - The iCalendar format itself causes interoperability issues due to mi= suse > of CRLF-terminated strings, line continuations, and subtle differenc= es > among iCalendar parsers. > END > > In recent years, many new products and services have appeared that > wish to use a JSON representation of calendar data within their API. > > Number agreement: =E2=80=9Cwithin their APIs.=E2=80=9D > > JSCalendar is intended > to meet this demand for JSON-formatted calendar data, and to provide > a standard, elegant representation as an alternative to new > proprietary formats. > > The IESG is going to complain about saying what you intend, rather > than what you=E2=80=99re doing, and they will definitely push back on > marketing-sounding things such as claims of elegance. I also find > =E2=80=9Cthis demand=E2=80=9D to lack a clear antecedent. > > NEW > JSCalendar meets the demand for JSON-formatted calendar data that is > free of such known problems and provides a standard representation > as an alternative to the proprietary formats. > END > > =E2=80=94 Section 1.2 =E2=80=94 > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > Please use the new BCP 14 boilerplate and add a normative reference to RF= C8174. > > =E2=80=94 Section 1.3 =E2=80=94 > > Other types may also be given, with their representation defined > elsewhere in this document. > > Number agreement: =E2=80=9Cwith their representations defined=E2=80=9D > > =E2=80=94 Section 1.4.2 =E2=80=94 > > Where "UnsignedInt" is given as a data type, it means an "Int" where > the value MUST be in the range 0 <=3D value <=3D 2^53-1. > > Why is there a MUST here, but not in 1.4.1. I suggest defining these > two (Int and UnsignedInt) consistently. I don=E2=80=99t much care whethe= r you > use MUST or not, though I would opt for not, so: > > NEW > Where =E2=80=9CUnsignedInt" is given as a data type, it means an integ= er in > the range 0 <=3D value <=3D 2^53-1, represented as a JSON "Number". > END > > =E2=80=94 Section 1.4.3 =E2=80=94 > > In common notation, it should be of the form "YYYY-MM-DDTHH:MM:SSZ". > > =E2=80=A6which doesn=E2=80=99t allow for fractional seconds, which are al= lowed if > they=E2=80=99re non-zero. I=E2=80=99m just noting that; I=E2=80=99m not = sure it should be > fixed. > > =E2=80=94 Section 1.4.4 =E2=80=94 > > Instead, they occur in > every time zone at the same wall-clock time (as opposed to the same > instant point in time). > > I found myself momentarily unsure abnout this sentence. I suggest a > slight rewording that I think is slightly (just slightly) clearer): > > NEW > Instead, they occur in > each time zone at the given wall-clock time (as opposed to the same > instant point in time). > END > > =E2=80=94 Section 1.4.6 =E2=80=94 > > signed-duration =3D (["+"] / "-") duration > > I guess this works. I think this is a bit cleaner. No?: > > NEW > signed-duration =3D ["+" / "-"] duration > END > > (I passed the original by a colleague as a check, and he kept looking > at it with varying puzzled expressions before he agreed that he > understood it. Let=E2=80=99s not make people work that hard.) > > =E2=80=94 Section 1.4.7 =E2=80=94 > > characters from the "URL and Filename Safe" base64 alphabet, as > defined in Section 5 of [RFC4648] > > For absolute, 100% clarity I suggest << "URL and Filename Safe" > base64url alphabet >>. > > Ids need not be unique > between different objects. > > =E2=80=9Camong=E2=80=9D, rather than =E2=80=9Cbetween=E2=80=9D (the latte= r implies only two). > > For example, two JSEvent objects MAY use > the same ids in their respective "links" properties. > > While the BCP 14 =E2=80=9CMAY=E2=80=9D here is arguably not wrong, I thin= k the intent > here isn=E2=80=99t to say what choice is allowed, but to alert the implem= enter > about what could happen. So I=E2=80=99d make it =E2=80=9Cmay=E2=80=9D (o= r =E2=80=9Cmight=E2=80=9D). > > This does not imply any semantic connection > between the two. > > You give two scenarios with two instances in each, so =E2=80=9Cbetween th= e > two=E2=80=9D seems odd. I would simply say, =E2=80=9CThese situations do= not imply > any semantic connections among the objects.=E2=80=9D > > The keys are a path in a subset of > [RFC6901] JSON pointer format, with an implicit leading "/" (i.e. > prefix each key with "/" before applying the JSON pointer evaluation > algorithm). > > =E2=80=9CThe keys are a path=E2=80=9D? There=E2=80=99s at least a number= problem here, but I > find the whole sentence to be hard to follow. Do you mean this?: > > NEW > Each key is a path represented in a subset of > JSON pointer format [RFC6901]. The paths have an implicit leading "/"= , > so each key is prefixed with "/" before applying the JSON pointer > evaluation algorithm. > END > > 1. The pointer MUST NOT reference inside an array (i.e. it MUST NOT > insert/delete from an array; the array MUST be replaced in its > entirety instead). > > I don=E2=80=99t see any value in =E2=80=9CMUST NOT reference inside an ar= ray=E2=80=9D, and > there=E2=80=99s a reason that you then clarify it. Just let the clearer > version stand alone: > > NEW > 1. The pointer MUST NOT > insert/delete values from an array; the array MUST be replaced in > its entirety instead. > END > > 3. There MUST NOT be two patches in the PatchObject where the > pointer of one is the prefix of the pointer of the other, e.g. > "alerts/foo/offset" and "alerts". > > Is =E2=80=9Cthe=E2=80=9D correct in =E2=80=9Cthe prefix=E2=80=9D, or do y= ou mean =E2=80=9Ca prefix=E2=80=9D? Are > "alerts/foo/offset" and "alerts/foo" allowed together? > > o null: Remove the property from the patched object. If not present > in the parent, this a no-op. > > What=E2=80=99s the subject of the second sentence? Is it the pointer, th= e > property, the patched object? It=E2=80=99s unclear; please say it explic= itly, > =E2=80=9CIf is not present=E2=80=9D. > > o Anything else: The value to set for this property (this may be a > replacement or addition to the object being patched). > > The structure of this bullet should be parallel to that of the first > bullet: as the first bullet is an instruction, so should this be: > > NEW > o Anything else: Set the value for the property to this value (this > may be a replacement or addition to the object being patched). > END > > Implementations MUST reject a PatchObject if any of its patches are > invalid. > > It=E2=80=99s worth being explicit here: > > NEW > Implementations MUST reject in its entirety a PatchObject if any of > its patches is invalid. Implementations MUST NOT apply partial patche= s. > END > > =E2=80=94 Section 1.4.9 =E2=80=94 > > By default, time zones in JSCalendar are identified by their name in > the IANA Time Zone Database [TZDB], and the zone rules of the > respective zone record apply. > > Number agreement: =E2=80=9Cby their names=E2=80=9D and =E2=80=9Czone reco= rds=E2=80=9D > > Implementations MAY embed the definition of custom time zones in the > "timeZones" property (see Section 4.7.2). > > Number agreement: =E2=80=9Cdefinitions=E2=80=9D > > =E2=80=94 Section 1.4.10 =E2=80=94 > > The object that defines this > relation is the linking object, the other object is the linked > object. > > This is a comma splice. Either change the comma to a semicolon or put > =E2=80=9Cwhile=E2=80=9D after it (or =E2=80=9Cand=E2=80=9D, but I prefer = =E2=80=9Cwhile=E2=80=9D here). > > Keys in the set MUST be one of the following values, or specified > in the property definition where the Relation object is used, or > an IANA-registered value, or a vendor-specific value: > > I suggest naming the IANA registry from which the key name has to > come. Same comment in other places in the document where you say > =E2=80=9CIANA-registered value=E2=80=9D. > > * "child": The linked object is a subpart of the linking object. > > * "parent": The linking object is part of the overall linked > object. > > I don=E2=80=99t understand the definition of =E2=80=9Cparent=E2=80=9D. W= ouldn=E2=80=99t a proper > definition be parallel to the definition of =E2=80=9Cchild=E2=80=9D, like= this?: > > NEW > * "parent": The linking object is a subpart of the linkied object. > END > > Note, the Relation object only has one property (except @type); it is > specified as an object with a single property to allow for extension > in the future. > > Do you mean, =E2=80=9Cspecified as an array with a single property=E2=80= =9D, or some > such? Or maybe this?: > > NEW > Note: the =E2=80=9Crelation=E2=80=9D array only contains one property;= it is specified > as an array to allow for extension in the future. > END > > =E2=80=94 Section 2.2 =E2=80=94 > > A JSTask may start and be due at certain points in time, may take > some estimated time to complete and may recur; none of which is > required. This notably differs from JSEvent (Section 2.1) which is > required to start at a certain point in time and typically takes some > non-zero duration to complete. > > 1. The semicolon is incorrect, and should be a comma. > > 2. In the second sentence, =E2=80=9Cwhich is=E2=80=9D needs a comma befor= e it. > > 3. Why is that description of JSEvent here, and not in Section 2.1? > > =E2=80=94 Section 3.1 =E2=80=94 > > types, but normalization of these types is inherently protocol and > scheme-specific, depending on the use-case > > This needs a hyphen on =E2=80=9Cprotocol-=E2=80=9C (it=E2=80=99s short fo= r =E2=80=9Cprotocol-specific=E2=80=9D). > > calendar exchange protocol or defined by another RFC. > > I would say =E2=80=9Cdefined elsewhere=E2=80=9D, or =E2=80=9Cdefined in a= nother document=E2=80=9D: it > might not be in an RFC. > > =E2=80=94 Section 3.2 =E2=80=94 > > Some JSCalendar properties allow vendor-specific value extensions. > If so, vendor-specific values MUST be prefixed with a domain name > controlled by the vendor, e.g. "example.com/customrel". > > There=E2=80=99s no =E2=80=9Cif so=E2=80=9D about it: it=E2=80=99s a fact.= Maybe you want to say, > =E2=80=9CSuch vendor-specific values MUST=E2=80=A6=E2=80=9D > > =E2=80=94 Section 4.1.2 =E2=80=94 > > [RFC4122] describes a range of > established algorithms to generate universally unique identifiers > (UUID), and the random or pseudo-random version is recommended. > > I suggest using more specific reference to 4122, and recommending with > the BCP 14 key word: > > NEW > [RFC4122] describes a range of > established algorithms to generate universally unique identifiers > (UUID). UUID version 4, described in Section 4.4 of [RFC4122], > is RECOMMENDED. > END > > =E2=80=94 Section 4.1.4 =E2=80=94 > > For example, it is not to be used to further the understanding of > non-standard properties. > > Just a suggestion here: I would specifically note that this hurts > interoperability, something such as this: > > NEW > For example, it is not to be used to further the understanding of > non-standard properties, a practice that is knows to cause long-term > interoperability problems. > END > > =E2=80=94 Section 4.1.6 =E2=80=94 > As this is mandatory (and =E2=80=9Ccreated=E2=80=9D is not), what is the = value of this > property if the object has not been modified? Is it the initial > creation date/time? The text should be clear. > > =E2=80=94 Section 4.2.3 =E2=80=94 > > They MAY > define parameters and the "charset" parameter value MUST be "utf-8", > > =E2=80=9Cdefine=E2=80=9D? Do you maybe mean =E2=80=9Cinclude=E2=80=9D? > > =E2=80=94 Section 4.2.4 =E2=80=94 > > Indicates the time is not important to display to the user when > rendering this calendar object, for example an event that > conceptually occurs all day or across multiple days, such as "New > Year's Day" or "Italy Vacation". > > This is spliced, and also is long and awkward. I suggest this: > > NEW > Indicates that the time is not important to display to the user when > rendering this calendar object. An example of this is an event that > conceptually occurs all day or across multiple days, such as "New > Year's Day" or "Italy Vacation". > END > > =E2=80=94 Section 4.2.5 =E2=80=94 > > This MUST be either one of the following values, > > =E2=80=9CEither=E2=80=9D is one of two, and there are more than two here.= Just remove =E2=80=9Ceither=E2=80=9D. > > I also don=E2=80=99t understand what it means for a JSCalendar object to = start > or end at a particular location. Does it mean that the event or task > described occurs at the location? Where does =E2=80=9Cstart=E2=80=9D and= =E2=80=9Cend=E2=80=9D come > in? Are we talking about things that can move, so they might start > one place and end at another? So what happens if the event doesn=E2=80= =99t > move? Do we set both =E2=80=9Cstart=E2=80=9D and =E2=80=9Cend=E2=80=9D t= o the same location? Why is > there no way to specify intermediate locations? > > Can you explain this better? > > A set of link ids for links to alternate representations of this > > Make it =E2=80=9Calternative=E2=80=9D (as you do in the next paragraph). > > This MUST be omitted > if none (rather than an empty set). > > Make it, =E2=80=9CIf there are no links, this MUST be omitted (rather tha= n > specified as an empty set).=E2=80=9D > > =E2=80=94 Section 4.2.7 =E2=80=94 > > This MAY be a "data:" URL > > You might want a citation to RFC 2397 here. > > Links with a rel of "describedby" SHOULD be considered by the > client to be an alternate representation of the description. > > =E2=80=9Calternative=E2=80=9D > > Links with a rel of "icon" SHOULD be considered by the client to > be an image that it MAY use when presenting the calendar data to a > user. > > I=E2=80=99m a bit confused by the SHOULD/MAY. If the image is not used w= hen > presenting to the user, is there any other thing that SHOULD be done > with it? > > "rel" property MUST be set to "icon". The value MUST be either > > Again, remove =E2=80=9Ceither=E2=80=9D. > > * "badge": an image inline with the title of the object. > > I don=E2=80=99t understand what =E2=80=9Can image inline with the title= =E2=80=9D means. Do > you mean, =E2=80=9Can image meant to be displayed along with the title=E2= =80=9D? Or > something else? > > =E2=80=94 Section 4.2.11 =E2=80=94 > > value is a case-insensitive color name taken from the set of names > > It doesn=E2=80=99t make sense to say =E2=80=9Ccase-insensitive=E2=80=9D u= nless you=E2=80=99re talking > about a comparison. Do you mean to say that it=E2=80=99s a lower-case > representation? An upper-case representation? Something else? > > =E2=80=94 Section 4.3 =E2=80=94 > > Some events and tasks occur at regular, or indeed irregular, > intervals. > > If you keep =E2=80=9Cindeed=E2=80=9D, it needs commas both before and aft= er it. > Better, just remove the word; it adds nothing. And the commas after > =E2=80=9Cregular=E2=80=9D and =E2=80=9Cirregular=E2=80=9D are both unnece= ssary. > > Rather than having to copy the data for every occurrence, > you can instead have a master event with a recurrence rule > > While I don=E2=80=99t object to your using =E2=80=9Cyou=E2=80=9D here, it= =E2=80=99s striking that you > use =E2=80=9Cyou=E2=80=9D exactly twice in the document (the other is in = 4.3.2.1 > bullet 2.1), so this is a style deviation. Do as you see fit with > that information. > > =E2=80=94 Section 4.3.2 =E2=80=94 > > If the task defines neither a "start" nor "due" date-time, > its "recurrenceRules" property value MUST be null. > > Or absent? > > This MUST be either a CLDR-registered calendar system > name, or a non-standard, experimental calendar system name > prefixed with the characters "x-". > > 1. CLDR? Please define and include a reference citation. > > 2. See RFC 6648 and tell me why we should still have =E2=80=9Cx-=E2=80=9C= here. > > =E2=80=94 Section 4.3.2.1 =E2=80=94 > > the first day of the next month (if skip =3D=3D "forward") or = the > last day of the current month (if skip =3D=3D "backward"). > > In the previous bullet you say << (if skip is "backward=E2=80=9D) >>, and= I > suggest you write these that way as well. Consistency. (Similar > comment for << if skip =3D=3D "omit" >> a few bullets down.) > > =E2=80=94 Section 4.4.1 =E2=80=94 > > The priority is specified as an integer in the range 0 to 9. A value > of 0 specifies an undefined priority. A value of 1 is the highest > priority. A value of 2 is the second highest priority. Subsequent > numbers specify a decreasing ordinal priority. A value of 9 is the > lowest priority. > > What happens whenb priority 0 is mixed with other priority values? > > =E2=80=94 Section 4.4.4 =E2=80=94 > > The value is a URI to use that > method. > > There=E2=80=99s no antecedent to =E2=80=9Cthat=E2=80=9D. I think it shou= ld be, =E2=80=9CThe value is > a URI for the method specified in the key.=E2=80=9D (Same comment for Se= ction > 4.4.5.) > > property MUST be omitted if no method is defined (rather than an > empty object). > > =E2=80=9Crather than being specified as an empty object=E2=80=9D. (Same = comment for > Section 4.4.5.) > > o "other": The organizer is identified by this URI but the method > how to submit the RSVP is undefined. > > Poor English here; make it, =E2=80=9Cthe method for submitting the respon= se is > undefined.=E2=80=9D (Same comment for Section 4.4.5.) > > * "resource": a non-human resource, e.g. a projector > > * "location": a physical location involved in the calendar object > that needs to be scheduled, e.g. a conference room. > > I would argue that a location is a non-human resource. I suggest > switching the order and clarifying it, thus: > > NEW > * "location": a physical location that needs to be scheduled, such > as a conference room. > > * "resource": a non-human resource other than a location, such as > a projector > END > > =E2=80=94 Secton 4.4.5 =E2=80=94 > > This MUST be omitted if none (rather than an empty set). > > I=E2=80=99ve mentioned this enough times that you should know how to fix = this > and all other similar sentences. > > object, which caused this participant to be invited due to their > membership of the group(s). > > =E2=80=9Cmembership in the group(s).=E2=80=9D > > =E2=80=94 Section 4.5.2 =E2=80=94 > > o trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger" > (mandatory) > > This is a manner of specifying this sort of thing that has not been > used before. You=E2=80=99ve always been using a defined type. Here (and= in > other items below) you appear to be using specific strings with no > explanation about what the =E2=80=9C|=E2=80=9D means. There=E2=80=99s an= inconsistency here > that I=E2=80=99d like to see fixed or clearly explained. > > Defines when to trigger the alert. New types may be defined in > future RFCs. > > =E2=80=9Cfuture documents=E2=80=9D or =E2=80=9Cfuture specifications=E2= =80=9D, and similarly for other > instances of =E2=80=9Cfuture RFC=E2=80=9D. > > The Relation object SHOULD set the "parent" relation type, but MAY > be empty. > > These are contradictory: if it SHOULD be non-empty, then it=E2=80=99s not > correct that it MAY be empty. > > =E2=80=94 Section 4.7.2 =E2=80=94 > > Maps identifiers of custom time zones to their time zone definition. > > Number agreement: =E2=80=9Cdefinitions=E2=80=9D > > =E2=80=94 Section 6.8 =E2=80=94 > > a virtual location. Fans can see a live convert on premises or > > =E2=80=9Cconcert=E2=80=9D ? > > "description": "Music Bowl, Central Park, New York", > "coordinates": "geo:40.7829,73.9654" > > Should this maybe be << geo:40.7829,-73.9654 >> > > =E2=80=94 Section 7 =E2=80=94 > > The transmission of such information must be careful to protect it > from possible threats, such as eavesdropping, replay, message > insertion, deletion, modification, and man-in-the-middle attacks. > > =E2=80=9Cmust be done carefully=E2=80=9D > > > =E2=80=94 Section 7.1 =E2=80=94 > > It is not always possible to tell this through static > analysis of the rule, so implementations MUST be careful to avoid > getting stuck in an infinite loop, or otherwise exhausting resources, > searching for the next occurrence. > > Number agreement: =E2=80=9Cinfinite loops=E2=80=9D > Also, =E2=80=9Cexhausting resources while searching=E2=80=9D > > =E2=80=94 Section 8.1 =E2=80=94 > > Person & email address to contact for further information: > calext@ietf.org > > The address is incorrect; it should be calsify, not calext. > > =E2=80=94 Section 8.2.3 =E2=80=94 > > This preferably takes the form of an RFC, but for simple definitions > a description in the registry may be sufficient. > > I=E2=80=99ve had a conversation with IANA about this. The operative bit = here > is whether "a description in the registry" could serve as the > "specification". I don't think we'd accept that. It's supposed to > be, according to BCP 26, a "permanent and readily available public > specification, in sufficient detail so that interoperability between > independent implementations is possible." While what you put in the > registry can be considered permanent, and it's certainly readily > available and public, it's a bit of a stretch. And it's hard to > imagine that a sentence or two in a registry could be "sufficient > detail". I'd say that some document, however brief, that's external > to IANA is required. > > Before a period of 30 days has passed, the DE will either approve or > deny the registration request and publish a notice of the decision to > the Calext WG mailing list or its successor, as well as inform IANA. > > IANA has expected response times, and specifying this stuff in RFCs is > not a good idea. I=E2=80=99d suggest tagging this for IANA review and ge= tting > agreement with IANA about what we should say here. > > If the DE does not respond within 30 days, the registrant may request > the IESG take action to process the request in a timely manner. > > This part definitely needs to go. People can always take complaints > to the IESG, and we shouldn=E2=80=99t be saying that here. > > The IESG may reassign responsibility for a JSCalendar property. The > most common case of this will be to enable changes to be made to a > registration where the author of the registration has died, moved out > of contact, or is otherwise unable to make changes that are important > to the community. > > And similarly for this; please strike it. > > =E2=80=94 Section 8.2.5 =E2=80=94 > > The property name MUST > NOT already be registered for any of the objects listed in > Context. > > What does =E2=80=9Clisted in Context=E2=80=9D mean? Can you explain this= in the document? > > =E2=80=94 Section 8.4.1 =E2=80=94 > > o Experts: The initial list of experts for Expert Review of updates > to the subregistry. > > Hm, are you actually proposing that registrations provide their own > lists of experts, rather than having them appointed by the IESG? I > don=E2=80=99t think that=E2=80=99s going to work. We probably need to ha= ve a > discussion about the intent here, so please initiate that by > explaining to me what you=E2=80=99re looking for. > > =E2=80=94 Section 10 =E2=80=94 > It=E2=80=99s not acceptable that all references are informative: there ar= e > clearly normative references here, and you=E2=80=99ll have to go through = and > sort out which ones are normative (which ones are for material that=E2=80= =99s > necessary for understanding this document. At the very least, the > references for BCP 14, JSON, JSON Pointer, and things such as that > will be normative. > > -- > Barry From nobody Sun Feb 23 14:25: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 7E78C3A10E2; Sun, 23 Feb 2020 14:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XndJ9Hk2SNsa; Sun, 23 Feb 2020 14:25:36 -0800 (PST) Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) (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 D79FD3A10E1; Sun, 23 Feb 2020 14:25:32 -0800 (PST) Received: by mail-io1-f53.google.com with SMTP id n21so8283209ioo.10; Sun, 23 Feb 2020 14:25:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=tnT4rvI2qIM/IaxYIuLurrKxCbEcAzyPd23TMZThBL8=; b=gOOfu474SPgmFXkCoeNp6lUnYdAbkSu6QGZF0GsvSTld16jNc53zm95Twq8cqLMs+u lTswX0vOtozIBHjS5KtidpbmsCFhtyn/C9HEMeY9bfgPQKmjuK4Ve60CIgyedguoXmhn OMzkoaaW7zJmgqRkWKtPON3eOcQpqKiCYaHzkBB/BzYTkLN21EET/S5dVT9zdc6tFaeO PbGdubVRWB+oPreMyBoWMTVSdGQhq56F/C/Jw/EvFqtNs8ilIGuQxUaJ5I0358EOlNIq 30ggL1HD1fhoHG59fXHByDT1HNmoyhhVMB6us32uYMDkUKL1UoflI9CizSruO4y21lg7 sdTA== X-Gm-Message-State: APjAAAUgfFC7CvqKjS/rkBnLV04tTdxY0HHMYaFvLYzD1E7QQy5x/ymx X73gP+UQGnnIhrPLN+SdsYDLYFyiQS8//KvdV3S86M+q X-Google-Smtp-Source: APXvYqy7JZobUvUx1OrYuVSJUVmuSj/YbPtvJ0fWdldJGUv+Tjp0XrpT0yVYe2ezq/J+iRIXggWRvz3546HDW4l7UR4= X-Received: by 2002:a02:a388:: with SMTP id y8mr47271022jak.70.1582496730858; Sun, 23 Feb 2020 14:25:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Barry Leiba Date: Sun, 23 Feb 2020 14:25:19 -0800 Message-ID: To: draft-ietf-calext-jscalendar.all@ietf.org Cc: calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-jscalendar-23 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, 23 Feb 2020 22:25:39 -0000 OK, I've had a look, and thanks very much for addressing almost all of my comments. There's one very small error in the changes: =E2=80=94 Section 4.4.4 =E2=80=94 o "other": The organizer is identified by this URI the method for submitting the response is undefined. In changing this, you cut the word =E2=80=9Cbut=E2=80=9D accidentally. =E2= =80=9Cbut the method=E2=80=9D ++++++++++++++++ And these comments that I had have not been addressed: =E2=80=94 Section 4.4.1 =E2=80=94 The priority is specified as an integer in the range 0 to 9. A value of 0 specifies an undefined priority. A value of 1 is the highest priority. A value of 2 is the second highest priority. Subsequent numbers specify a decreasing ordinal priority. A value of 9 is the lowest priority. What happens when priority 0 is mixed with other priority values? =E2=80=94 Section 4.5.2 =E2=80=94 o trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger" (mandatory) This is a manner of specifying this sort of thing that has not been used before. You=E2=80=99ve always been using a defined type. Here (and i= n other items below) you appear to be using specific strings with no explanation about what the =E2=80=9C|=E2=80=9D means. There=E2=80=99s an i= nconsistency here that I=E2=80=99d like to see fixed or clearly explained. =E2=80=94 Section 8.2.3 =E2=80=94 This preferably takes the form of an RFC, but for simple definitions a description in the registry may be sufficient. I=E2=80=99ve had a conversation with IANA about this. The operative bit he= re is whether "a description in the registry" could serve as the "specification". I don't think we'd accept that. It's supposed to be, according to BCP 26, a "permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible." While what you put in the registry can be considered permanent, and it's certainly readily available and public, it's a bit of a stretch. And it's hard to imagine that a sentence or two in a registry could be "sufficient detail". I'd say that some document, however brief, that's external to IANA is required. =E2=80=94 Section 8.4.1 =E2=80=94 o Experts: The initial list of experts for Expert Review of updates to the subregistry. Hm, are you actually proposing that registrations provide their own lists of experts, rather than having them appointed by the IESG? I don=E2=80=99t think that=E2=80=99s going to work. We probably need to have= a discussion about the intent here, so please initiate that by explaining to me what you=E2=80=99re looking for. ++++++++++++++++ I think we need to address all of these, and some might need a discussion, so let's please discuss them. I don't think that discussion has to delay last call, so I will request last call now. But let's please sort these out during the last call, and before we go to IESG Evaluation. Thanks, Barry On Wed, Feb 19, 2020 at 10:33 PM Barry Leiba wrot= e: > > Thanks for posting version -24. I'll give that a look over as soon as > I can, and then get last call started on it. > > Barry > > On Tue, Feb 18, 2020 at 10:58 PM Barry Leiba wr= ote: > > > > Thanks for the work on this document. I have a long list of comments, > > many of which are just editorial, but a number of which are > > substantive. Because of the length of the list, I=E2=80=99d rather we = deal > > with all of them before moving the document into last call, so please > > digest this list, address what you can directly, and chat with me > > about the others. > > > > Throughout: =E2=80=9Ci.e.=E2=80=9D and =E2=80=9Ce.g.=E2=80=9D each need= s a comma after it, always. > > > > Throughout: Please use =E2=80=9Cmedia type=E2=80=9D instead of =E2=80= =9CMIME type=E2=80=9D. > > > > =E2=80=94 Abstract =E2=80=94 > > > > It aims to be an > > alternative, and over time successor to, the widely deployed > > iCalendar data format and to be unambiguous, extendable and simple t= o > > process. > > > > Some misplaced commas here. > > > > NEW > > It aims to be an > > alternative and, over time, a successor to the widely deployed > > iCalendar data format, and to be unambiguous, extendable, and simple > > to process. > > END > > > > In contrast to the JSON-based jCal format, it is not a > > direct mapping from iCalendar and expands semantics where > > appropriate. > > > > I would be clearer about what it *is*, rather than just saying what it > > isn=E2=80=99t. Maybe something like this (tweak accordingly): > > > > NEW > > In contrast to the jCal format, which is also JSON-based, JSCalendar > > is not a direct mapping from iCalendar, but defines the data model > > afresh and expands semantics where appropriate. > > END > > > > =E2=80=94 Section 1 =E2=80=94 > > > > o The attributes of the calendar entry represented must be describe= d > > as a simple key-value pair. Simple events are simple to > > represent, complex events can be modelled accurately. > > > > Number agreement: =E2=80=9Cas simple key-value pairs=E2=80=9D (multiple= attributes) > > The second sentence is a comma splice; either change the comma to a > > semicolon or put =E2=80=9Cand=E2=80=9D after the comma. > > > > o The data model should avoid ambiguities and make it difficult to > > make mistakes during implementation. > > > > Is =E2=80=9Cdifficult=E2=80=9D really the right word? Or maybe =E2=80= =9Cless likely=E2=80=9D? > > > > and drop widely unused, obsolete or redundant > > > > =E2=80=9CWidely=E2=80=9D doesn=E2=80=99t seem apt with a negative such = as =E2=80=9Cunused=E2=80=9D (sort of > > like how something can be =E2=80=9Ctwice as often used=E2=80=9D, but no= t =E2=80=9Ctwice as > > often unused=E2=80=9D). I would say =E2=80=9Cseldom-used=E2=80=9D (and= I would add the Oxford > > comma, as I did in the Abstract and would do throughout the document, > > but I=E2=80=99m not going to push that nor mention it again). > > > > should be easy with most common iCalendar files but is not > > guaranteed with the full specification. > > > > What does =E2=80=9Cnot guaranteed with the full specification=E2=80=9D = mean? can you > > maybe rephrase it? > > > > o Extensions, such as new properties and components, MUST NOT lead > > to requiring an update to this document. > > > > I think it=E2=80=99s impossible to guarantee that at a =E2=80=9CMUST NO= T=E2=80=9D level. > > maybe, =E2=80=9Cgenerally do not require updates to this document.=E2= =80=9D > > > > =E2=80=94 Section 1.1 =E2=80=94 > > > > For example, iCalendar defines various formats for local times, UTC > > time and dates, which confuses new users and often leads to > > implementation errors. Other sources for errors are the requirement > > for custom time zone definitions within a single calendar component, > > as well as the iCalendar format itself; the latter causing > > interoperability issues due to misuse of CR LF terminated strings, > > line continuations and subtle differences between iCalendar parsers. > > The definition of recurrence rules is ambiguous and has resulted in > > differing understandings even between experienced calendar > > developers. > > > > OK, I said I wouldn=E2=80=99t mention it again, but here=E2=80=99s an e= xample of where > > something is actually made harder to read by not including the Oxford > > comma: I read item 1, =E2=80=9Clocal times=E2=80=9D, then item 2, =E2= =80=9Ctime and dates=E2=80=9D, > > then started looking for item 3. Um. But in general, I think the > > paragraph is clunky and would benefit from being structured as a list. > > Does this look reasonable?: > > > > NEW > > Sources of implementation errors include the following: > > > > - iCalendar defines various formats for local times, UTC time, and d= ates. > > > > - iCalendar requires custom time zone definitions within a single > > calendar component. > > > > - iCalendar=E2=80=99s definition of recurrence rules is ambiguous an= d has resulted > > in differing understandings even between experienced calendar deve= lopers. > > > > - The iCalendar format itself causes interoperability issues due to = misuse > > of CRLF-terminated strings, line continuations, and subtle differe= nces > > among iCalendar parsers. > > END > > > > In recent years, many new products and services have appeared that > > wish to use a JSON representation of calendar data within their API. > > > > Number agreement: =E2=80=9Cwithin their APIs.=E2=80=9D > > > > JSCalendar is intended > > to meet this demand for JSON-formatted calendar data, and to provide > > a standard, elegant representation as an alternative to new > > proprietary formats. > > > > The IESG is going to complain about saying what you intend, rather > > than what you=E2=80=99re doing, and they will definitely push back on > > marketing-sounding things such as claims of elegance. I also find > > =E2=80=9Cthis demand=E2=80=9D to lack a clear antecedent. > > > > NEW > > JSCalendar meets the demand for JSON-formatted calendar data that is > > free of such known problems and provides a standard representation > > as an alternative to the proprietary formats. > > END > > > > =E2=80=94 Section 1.2 =E2=80=94 > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in [RFC2119]. > > > > Please use the new BCP 14 boilerplate and add a normative reference to = RFC8174. > > > > =E2=80=94 Section 1.3 =E2=80=94 > > > > Other types may also be given, with their representation defined > > elsewhere in this document. > > > > Number agreement: =E2=80=9Cwith their representations defined=E2=80=9D > > > > =E2=80=94 Section 1.4.2 =E2=80=94 > > > > Where "UnsignedInt" is given as a data type, it means an "Int" where > > the value MUST be in the range 0 <=3D value <=3D 2^53-1. > > > > Why is there a MUST here, but not in 1.4.1. I suggest defining these > > two (Int and UnsignedInt) consistently. I don=E2=80=99t much care whet= her you > > use MUST or not, though I would opt for not, so: > > > > NEW > > Where =E2=80=9CUnsignedInt" is given as a data type, it means an int= eger in > > the range 0 <=3D value <=3D 2^53-1, represented as a JSON "Number". > > END > > > > =E2=80=94 Section 1.4.3 =E2=80=94 > > > > In common notation, it should be of the form "YYYY-MM-DDTHH:MM:SSZ". > > > > =E2=80=A6which doesn=E2=80=99t allow for fractional seconds, which are = allowed if > > they=E2=80=99re non-zero. I=E2=80=99m just noting that; I=E2=80=99m no= t sure it should be > > fixed. > > > > =E2=80=94 Section 1.4.4 =E2=80=94 > > > > Instead, they occur in > > every time zone at the same wall-clock time (as opposed to the same > > instant point in time). > > > > I found myself momentarily unsure abnout this sentence. I suggest a > > slight rewording that I think is slightly (just slightly) clearer): > > > > NEW > > Instead, they occur in > > each time zone at the given wall-clock time (as opposed to the same > > instant point in time). > > END > > > > =E2=80=94 Section 1.4.6 =E2=80=94 > > > > signed-duration =3D (["+"] / "-") duration > > > > I guess this works. I think this is a bit cleaner. No?: > > > > NEW > > signed-duration =3D ["+" / "-"] duration > > END > > > > (I passed the original by a colleague as a check, and he kept looking > > at it with varying puzzled expressions before he agreed that he > > understood it. Let=E2=80=99s not make people work that hard.) > > > > =E2=80=94 Section 1.4.7 =E2=80=94 > > > > characters from the "URL and Filename Safe" base64 alphabet, as > > defined in Section 5 of [RFC4648] > > > > For absolute, 100% clarity I suggest << "URL and Filename Safe" > > base64url alphabet >>. > > > > Ids need not be unique > > between different objects. > > > > =E2=80=9Camong=E2=80=9D, rather than =E2=80=9Cbetween=E2=80=9D (the lat= ter implies only two). > > > > For example, two JSEvent objects MAY use > > the same ids in their respective "links" properties. > > > > While the BCP 14 =E2=80=9CMAY=E2=80=9D here is arguably not wrong, I th= ink the intent > > here isn=E2=80=99t to say what choice is allowed, but to alert the impl= ementer > > about what could happen. So I=E2=80=99d make it =E2=80=9Cmay=E2=80=9D = (or =E2=80=9Cmight=E2=80=9D). > > > > This does not imply any semantic connection > > between the two. > > > > You give two scenarios with two instances in each, so =E2=80=9Cbetween = the > > two=E2=80=9D seems odd. I would simply say, =E2=80=9CThese situations = do not imply > > any semantic connections among the objects.=E2=80=9D > > > > The keys are a path in a subset of > > [RFC6901] JSON pointer format, with an implicit leading "/" (i.e. > > prefix each key with "/" before applying the JSON pointer evaluation > > algorithm). > > > > =E2=80=9CThe keys are a path=E2=80=9D? There=E2=80=99s at least a numb= er problem here, but I > > find the whole sentence to be hard to follow. Do you mean this?: > > > > NEW > > Each key is a path represented in a subset of > > JSON pointer format [RFC6901]. The paths have an implicit leading "= /", > > so each key is prefixed with "/" before applying the JSON pointer > > evaluation algorithm. > > END > > > > 1. The pointer MUST NOT reference inside an array (i.e. it MUST NOT > > insert/delete from an array; the array MUST be replaced in its > > entirety instead). > > > > I don=E2=80=99t see any value in =E2=80=9CMUST NOT reference inside an = array=E2=80=9D, and > > there=E2=80=99s a reason that you then clarify it. Just let the cleare= r > > version stand alone: > > > > NEW > > 1. The pointer MUST NOT > > insert/delete values from an array; the array MUST be replaced i= n > > its entirety instead. > > END > > > > 3. There MUST NOT be two patches in the PatchObject where the > > pointer of one is the prefix of the pointer of the other, e.g. > > "alerts/foo/offset" and "alerts". > > > > Is =E2=80=9Cthe=E2=80=9D correct in =E2=80=9Cthe prefix=E2=80=9D, or do= you mean =E2=80=9Ca prefix=E2=80=9D? Are > > "alerts/foo/offset" and "alerts/foo" allowed together? > > > > o null: Remove the property from the patched object. If not presen= t > > in the parent, this a no-op. > > > > What=E2=80=99s the subject of the second sentence? Is it the pointer, = the > > property, the patched object? It=E2=80=99s unclear; please say it expl= icitly, > > =E2=80=9CIf is not present=E2=80=9D. > > > > o Anything else: The value to set for this property (this may be a > > replacement or addition to the object being patched). > > > > The structure of this bullet should be parallel to that of the first > > bullet: as the first bullet is an instruction, so should this be: > > > > NEW > > o Anything else: Set the value for the property to this value (this > > may be a replacement or addition to the object being patched). > > END > > > > Implementations MUST reject a PatchObject if any of its patches are > > invalid. > > > > It=E2=80=99s worth being explicit here: > > > > NEW > > Implementations MUST reject in its entirety a PatchObject if any of > > its patches is invalid. Implementations MUST NOT apply partial patc= hes. > > END > > > > =E2=80=94 Section 1.4.9 =E2=80=94 > > > > By default, time zones in JSCalendar are identified by their name in > > the IANA Time Zone Database [TZDB], and the zone rules of the > > respective zone record apply. > > > > Number agreement: =E2=80=9Cby their names=E2=80=9D and =E2=80=9Czone re= cords=E2=80=9D > > > > Implementations MAY embed the definition of custom time zones in the > > "timeZones" property (see Section 4.7.2). > > > > Number agreement: =E2=80=9Cdefinitions=E2=80=9D > > > > =E2=80=94 Section 1.4.10 =E2=80=94 > > > > The object that defines this > > relation is the linking object, the other object is the linked > > object. > > > > This is a comma splice. Either change the comma to a semicolon or put > > =E2=80=9Cwhile=E2=80=9D after it (or =E2=80=9Cand=E2=80=9D, but I prefe= r =E2=80=9Cwhile=E2=80=9D here). > > > > Keys in the set MUST be one of the following values, or specified > > in the property definition where the Relation object is used, or > > an IANA-registered value, or a vendor-specific value: > > > > I suggest naming the IANA registry from which the key name has to > > come. Same comment in other places in the document where you say > > =E2=80=9CIANA-registered value=E2=80=9D. > > > > * "child": The linked object is a subpart of the linking object. > > > > * "parent": The linking object is part of the overall linked > > object. > > > > I don=E2=80=99t understand the definition of =E2=80=9Cparent=E2=80=9D. = Wouldn=E2=80=99t a proper > > definition be parallel to the definition of =E2=80=9Cchild=E2=80=9D, li= ke this?: > > > > NEW > > * "parent": The linking object is a subpart of the linkied objec= t. > > END > > > > Note, the Relation object only has one property (except @type); it i= s > > specified as an object with a single property to allow for extension > > in the future. > > > > Do you mean, =E2=80=9Cspecified as an array with a single property=E2= =80=9D, or some > > such? Or maybe this?: > > > > NEW > > Note: the =E2=80=9Crelation=E2=80=9D array only contains one propert= y; it is specified > > as an array to allow for extension in the future. > > END > > > > =E2=80=94 Section 2.2 =E2=80=94 > > > > A JSTask may start and be due at certain points in time, may take > > some estimated time to complete and may recur; none of which is > > required. This notably differs from JSEvent (Section 2.1) which is > > required to start at a certain point in time and typically takes som= e > > non-zero duration to complete. > > > > 1. The semicolon is incorrect, and should be a comma. > > > > 2. In the second sentence, =E2=80=9Cwhich is=E2=80=9D needs a comma bef= ore it. > > > > 3. Why is that description of JSEvent here, and not in Section 2.1? > > > > =E2=80=94 Section 3.1 =E2=80=94 > > > > types, but normalization of these types is inherently protocol an= d > > scheme-specific, depending on the use-case > > > > This needs a hyphen on =E2=80=9Cprotocol-=E2=80=9C (it=E2=80=99s short = for =E2=80=9Cprotocol-specific=E2=80=9D). > > > > calendar exchange protocol or defined by another RFC. > > > > I would say =E2=80=9Cdefined elsewhere=E2=80=9D, or =E2=80=9Cdefined in= another document=E2=80=9D: it > > might not be in an RFC. > > > > =E2=80=94 Section 3.2 =E2=80=94 > > > > Some JSCalendar properties allow vendor-specific value extensions. > > If so, vendor-specific values MUST be prefixed with a domain name > > controlled by the vendor, e.g. "example.com/customrel". > > > > There=E2=80=99s no =E2=80=9Cif so=E2=80=9D about it: it=E2=80=99s a fac= t. Maybe you want to say, > > =E2=80=9CSuch vendor-specific values MUST=E2=80=A6=E2=80=9D > > > > =E2=80=94 Section 4.1.2 =E2=80=94 > > > > [RFC4122] describes a range of > > established algorithms to generate universally unique identifiers > > (UUID), and the random or pseudo-random version is recommended. > > > > I suggest using more specific reference to 4122, and recommending with > > the BCP 14 key word: > > > > NEW > > [RFC4122] describes a range of > > established algorithms to generate universally unique identifiers > > (UUID). UUID version 4, described in Section 4.4 of [RFC4122], > > is RECOMMENDED. > > END > > > > =E2=80=94 Section 4.1.4 =E2=80=94 > > > > For example, it is not to be used to further the understanding of > > non-standard properties. > > > > Just a suggestion here: I would specifically note that this hurts > > interoperability, something such as this: > > > > NEW > > For example, it is not to be used to further the understanding of > > non-standard properties, a practice that is knows to cause long-term > > interoperability problems. > > END > > > > =E2=80=94 Section 4.1.6 =E2=80=94 > > As this is mandatory (and =E2=80=9Ccreated=E2=80=9D is not), what is th= e value of this > > property if the object has not been modified? Is it the initial > > creation date/time? The text should be clear. > > > > =E2=80=94 Section 4.2.3 =E2=80=94 > > > > They MAY > > define parameters and the "charset" parameter value MUST be "utf-8", > > > > =E2=80=9Cdefine=E2=80=9D? Do you maybe mean =E2=80=9Cinclude=E2=80=9D? > > > > =E2=80=94 Section 4.2.4 =E2=80=94 > > > > Indicates the time is not important to display to the user when > > rendering this calendar object, for example an event that > > conceptually occurs all day or across multiple days, such as "New > > Year's Day" or "Italy Vacation". > > > > This is spliced, and also is long and awkward. I suggest this: > > > > NEW > > Indicates that the time is not important to display to the user when > > rendering this calendar object. An example of this is an event that > > conceptually occurs all day or across multiple days, such as "New > > Year's Day" or "Italy Vacation". > > END > > > > =E2=80=94 Section 4.2.5 =E2=80=94 > > > > This MUST be either one of the following values, > > > > =E2=80=9CEither=E2=80=9D is one of two, and there are more than two her= e. Just remove =E2=80=9Ceither=E2=80=9D. > > > > I also don=E2=80=99t understand what it means for a JSCalendar object t= o start > > or end at a particular location. Does it mean that the event or task > > described occurs at the location? Where does =E2=80=9Cstart=E2=80=9D a= nd =E2=80=9Cend=E2=80=9D come > > in? Are we talking about things that can move, so they might start > > one place and end at another? So what happens if the event doesn=E2=80= =99t > > move? Do we set both =E2=80=9Cstart=E2=80=9D and =E2=80=9Cend=E2=80=9D= to the same location? Why is > > there no way to specify intermediate locations? > > > > Can you explain this better? > > > > A set of link ids for links to alternate representations of this > > > > Make it =E2=80=9Calternative=E2=80=9D (as you do in the next paragraph)= . > > > > This MUST be omitted > > if none (rather than an empty set). > > > > Make it, =E2=80=9CIf there are no links, this MUST be omitted (rather t= han > > specified as an empty set).=E2=80=9D > > > > =E2=80=94 Section 4.2.7 =E2=80=94 > > > > This MAY be a "data:" URL > > > > You might want a citation to RFC 2397 here. > > > > Links with a rel of "describedby" SHOULD be considered by the > > client to be an alternate representation of the description. > > > > =E2=80=9Calternative=E2=80=9D > > > > Links with a rel of "icon" SHOULD be considered by the client to > > be an image that it MAY use when presenting the calendar data to = a > > user. > > > > I=E2=80=99m a bit confused by the SHOULD/MAY. If the image is not used= when > > presenting to the user, is there any other thing that SHOULD be done > > with it? > > > > "rel" property MUST be set to "icon". The value MUST be either > > > > Again, remove =E2=80=9Ceither=E2=80=9D. > > > > * "badge": an image inline with the title of the object. > > > > I don=E2=80=99t understand what =E2=80=9Can image inline with the title= =E2=80=9D means. Do > > you mean, =E2=80=9Can image meant to be displayed along with the title= =E2=80=9D? Or > > something else? > > > > =E2=80=94 Section 4.2.11 =E2=80=94 > > > > value is a case-insensitive color name taken from the set of names > > > > It doesn=E2=80=99t make sense to say =E2=80=9Ccase-insensitive=E2=80=9D= unless you=E2=80=99re talking > > about a comparison. Do you mean to say that it=E2=80=99s a lower-case > > representation? An upper-case representation? Something else? > > > > =E2=80=94 Section 4.3 =E2=80=94 > > > > Some events and tasks occur at regular, or indeed irregular, > > intervals. > > > > If you keep =E2=80=9Cindeed=E2=80=9D, it needs commas both before and a= fter it. > > Better, just remove the word; it adds nothing. And the commas after > > =E2=80=9Cregular=E2=80=9D and =E2=80=9Cirregular=E2=80=9D are both unne= cessary. > > > > Rather than having to copy the data for every occurrence, > > you can instead have a master event with a recurrence rule > > > > While I don=E2=80=99t object to your using =E2=80=9Cyou=E2=80=9D here, = it=E2=80=99s striking that you > > use =E2=80=9Cyou=E2=80=9D exactly twice in the document (the other is i= n 4.3.2.1 > > bullet 2.1), so this is a style deviation. Do as you see fit with > > that information. > > > > =E2=80=94 Section 4.3.2 =E2=80=94 > > > > If the task defines neither a "start" nor "due" date-time, > > its "recurrenceRules" property value MUST be null. > > > > Or absent? > > > > This MUST be either a CLDR-registered calendar system > > name, or a non-standard, experimental calendar system name > > prefixed with the characters "x-". > > > > 1. CLDR? Please define and include a reference citation. > > > > 2. See RFC 6648 and tell me why we should still have =E2=80=9Cx-=E2=80= =9C here. > > > > =E2=80=94 Section 4.3.2.1 =E2=80=94 > > > > the first day of the next month (if skip =3D=3D "forward") o= r the > > last day of the current month (if skip =3D=3D "backward"). > > > > In the previous bullet you say << (if skip is "backward=E2=80=9D) >>, a= nd I > > suggest you write these that way as well. Consistency. (Similar > > comment for << if skip =3D=3D "omit" >> a few bullets down.) > > > > =E2=80=94 Section 4.4.1 =E2=80=94 > > > > The priority is specified as an integer in the range 0 to 9. A valu= e > > of 0 specifies an undefined priority. A value of 1 is the highest > > priority. A value of 2 is the second highest priority. Subsequent > > numbers specify a decreasing ordinal priority. A value of 9 is the > > lowest priority. > > > > What happens whenb priority 0 is mixed with other priority values? > > > > =E2=80=94 Section 4.4.4 =E2=80=94 > > > > The value is a URI to use that > > method. > > > > There=E2=80=99s no antecedent to =E2=80=9Cthat=E2=80=9D. I think it sh= ould be, =E2=80=9CThe value is > > a URI for the method specified in the key.=E2=80=9D (Same comment for = Section > > 4.4.5.) > > > > property MUST be omitted if no method is defined (rather than an > > empty object). > > > > =E2=80=9Crather than being specified as an empty object=E2=80=9D. (Sam= e comment for > > Section 4.4.5.) > > > > o "other": The organizer is identified by this URI but the method > > how to submit the RSVP is undefined. > > > > Poor English here; make it, =E2=80=9Cthe method for submitting the resp= onse is > > undefined.=E2=80=9D (Same comment for Section 4.4.5.) > > > > * "resource": a non-human resource, e.g. a projector > > > > * "location": a physical location involved in the calendar objec= t > > that needs to be scheduled, e.g. a conference room. > > > > I would argue that a location is a non-human resource. I suggest > > switching the order and clarifying it, thus: > > > > NEW > > * "location": a physical location that needs to be scheduled, su= ch > > as a conference room. > > > > * "resource": a non-human resource other than a location, such a= s > > a projector > > END > > > > =E2=80=94 Secton 4.4.5 =E2=80=94 > > > > This MUST be omitted if none (rather than an empty set). > > > > I=E2=80=99ve mentioned this enough times that you should know how to fi= x this > > and all other similar sentences. > > > > object, which caused this participant to be invited due to their > > membership of the group(s). > > > > =E2=80=9Cmembership in the group(s).=E2=80=9D > > > > =E2=80=94 Section 4.5.2 =E2=80=94 > > > > o trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger" > > (mandatory) > > > > This is a manner of specifying this sort of thing that has not been > > used before. You=E2=80=99ve always been using a defined type. Here (a= nd in > > other items below) you appear to be using specific strings with no > > explanation about what the =E2=80=9C|=E2=80=9D means. There=E2=80=99s = an inconsistency here > > that I=E2=80=99d like to see fixed or clearly explained. > > > > Defines when to trigger the alert. New types may be defined in > > future RFCs. > > > > =E2=80=9Cfuture documents=E2=80=9D or =E2=80=9Cfuture specifications=E2= =80=9D, and similarly for other > > instances of =E2=80=9Cfuture RFC=E2=80=9D. > > > > The Relation object SHOULD set the "parent" relation type, but MA= Y > > be empty. > > > > These are contradictory: if it SHOULD be non-empty, then it=E2=80=99s n= ot > > correct that it MAY be empty. > > > > =E2=80=94 Section 4.7.2 =E2=80=94 > > > > Maps identifiers of custom time zones to their time zone definition. > > > > Number agreement: =E2=80=9Cdefinitions=E2=80=9D > > > > =E2=80=94 Section 6.8 =E2=80=94 > > > > a virtual location. Fans can see a live convert on premises or > > > > =E2=80=9Cconcert=E2=80=9D ? > > > > "description": "Music Bowl, Central Park, New York", > > "coordinates": "geo:40.7829,73.9654" > > > > Should this maybe be << geo:40.7829,-73.9654 >> > > > > =E2=80=94 Section 7 =E2=80=94 > > > > The transmission of such information must be careful to protect it > > from possible threats, such as eavesdropping, replay, message > > insertion, deletion, modification, and man-in-the-middle attacks. > > > > =E2=80=9Cmust be done carefully=E2=80=9D > > > > > > =E2=80=94 Section 7.1 =E2=80=94 > > > > It is not always possible to tell this through static > > analysis of the rule, so implementations MUST be careful to avoid > > getting stuck in an infinite loop, or otherwise exhausting resources= , > > searching for the next occurrence. > > > > Number agreement: =E2=80=9Cinfinite loops=E2=80=9D > > Also, =E2=80=9Cexhausting resources while searching=E2=80=9D > > > > =E2=80=94 Section 8.1 =E2=80=94 > > > > Person & email address to contact for further information: > > calext@ietf.org > > > > The address is incorrect; it should be calsify, not calext. > > > > =E2=80=94 Section 8.2.3 =E2=80=94 > > > > This preferably takes the form of an RFC, but for simple definitions > > a description in the registry may be sufficient. > > > > I=E2=80=99ve had a conversation with IANA about this. The operative bi= t here > > is whether "a description in the registry" could serve as the > > "specification". I don't think we'd accept that. It's supposed to > > be, according to BCP 26, a "permanent and readily available public > > specification, in sufficient detail so that interoperability between > > independent implementations is possible." While what you put in the > > registry can be considered permanent, and it's certainly readily > > available and public, it's a bit of a stretch. And it's hard to > > imagine that a sentence or two in a registry could be "sufficient > > detail". I'd say that some document, however brief, that's external > > to IANA is required. > > > > Before a period of 30 days has passed, the DE will either approve or > > deny the registration request and publish a notice of the decision t= o > > the Calext WG mailing list or its successor, as well as inform IANA. > > > > IANA has expected response times, and specifying this stuff in RFCs is > > not a good idea. I=E2=80=99d suggest tagging this for IANA review and = getting > > agreement with IANA about what we should say here. > > > > If the DE does not respond within 30 days, the registrant may reques= t > > the IESG take action to process the request in a timely manner. > > > > This part definitely needs to go. People can always take complaints > > to the IESG, and we shouldn=E2=80=99t be saying that here. > > > > The IESG may reassign responsibility for a JSCalendar property. The > > most common case of this will be to enable changes to be made to a > > registration where the author of the registration has died, moved ou= t > > of contact, or is otherwise unable to make changes that are importan= t > > to the community. > > > > And similarly for this; please strike it. > > > > =E2=80=94 Section 8.2.5 =E2=80=94 > > > > The property name MUST > > NOT already be registered for any of the objects listed in > > Context. > > > > What does =E2=80=9Clisted in Context=E2=80=9D mean? Can you explain th= is in the document? > > > > =E2=80=94 Section 8.4.1 =E2=80=94 > > > > o Experts: The initial list of experts for Expert Review of updates > > to the subregistry. > > > > Hm, are you actually proposing that registrations provide their own > > lists of experts, rather than having them appointed by the IESG? I > > don=E2=80=99t think that=E2=80=99s going to work. We probably need to = have a > > discussion about the intent here, so please initiate that by > > explaining to me what you=E2=80=99re looking for. > > > > =E2=80=94 Section 10 =E2=80=94 > > It=E2=80=99s not acceptable that all references are informative: there = are > > clearly normative references here, and you=E2=80=99ll have to go throug= h and > > sort out which ones are normative (which ones are for material that=E2= =80=99s > > necessary for understanding this document. At the very least, the > > references for BCP 14, JSON, JSON Pointer, and things such as that > > will be normative. > > > > -- > > Barry From nobody Sun Feb 23 15:17:17 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF033A11B7; Sun, 23 Feb 2020 15:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.585 X-Spam-Level: X-Spam-Status: No, score=-0.585 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, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=G6idypvp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MuemKhIV 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 CeSItcknMXN3; Sun, 23 Feb 2020 15:17:12 -0800 (PST) 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 BAFAD3A11B6; Sun, 23 Feb 2020 15:17:12 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id C0F8150F; Sun, 23 Feb 2020 18:17:11 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 23 Feb 2020 18:17:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=9egC dXYttxjRoA/OEWkbgjY5RgNaRFB7T/vtNS4w7yw=; b=G6idypvpZCGMPKl9/vIS KpB+LGUoA/gSWxbe0KAPuDBF9E9UD8uGsYXNPODRbH5DJWvIIE1JFJuuzO9WaYNn KueDlbpk03xCWG3Bn/xy4XedUNn+uhCBT44RQC/xrmPaJnwgIW9zHk2WM4ZEwt4Y 14u6S+mA1P48RNmgPbYH5yL3+/JxohUy1UhwVFzyF9gHR+V0oiQpOV3Y73EKOPPO dI3wZITW12nNXzCqeF6uqQsjBzanUTafjXwM/ZYLgw/iPTg15mOmhNjtpugA/4kx 19MLC/9/o4i72jZB9Ye2a1ozmRT30U8pMYjhEQpKeQk3CaBEB8ung1Sg8Oz9AdAQ FQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=9egCdX YttxjRoA/OEWkbgjY5RgNaRFB7T/vtNS4w7yw=; b=MuemKhIVulrFbvHDAZWSLF Y02EYih5ls/KPawaW2lv6/gPEUZyHAOObPBYaJ4JJO4lse4PBsnVurNGDAL8G/0x F0NlLzY6Yo3vX9AwSpbhO5sd8bP2Vi6n9LomxSH4wjFD2LbcghjHD5kx+1cp+Sci HRD+muAm25kbPsVFrfWYMNxB0lC026rfaV39PYKTGF60Ab8aHoCJtKg06UcnSiWd Rm/mLZKtGdMtbFrQe64Ex8YxsP/1LybS6v9UX7OplEHuhPCOmTb0I3EQ53Q9+ITx 4+EKoL6/o0aiKY8IfMvUYiEh2Zjvh9kH8w/lAetF1prncsYlWUPbn9xj7K68G0eQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeelgddtlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B795E180091; Sun, 23 Feb 2020 18:17:10 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-947-gbed3ff6-fmnext-20200220v2 Mime-Version: 1.0 Message-Id: <0accc1d2-3f8e-4b52-b454-f944f836eeea@beta.fastmail.com> In-Reply-To: References: Date: Mon, 24 Feb 2020 10:16:03 +1100 From: "Neil Jenkins" To: "Barry Leiba" , draft-ietf-calext-jscalendar.all@ietf.org Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary=1c2ca05ae6464dc6900809f598a91023 Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-jscalendar-23 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, 23 Feb 2020 23:17:15 -0000 --1c2ca05ae6464dc6900809f598a91023 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Barry, > There's one very small error in the changes: Thanks, I'll fix that. > And these comments that I had have not been addressed: I commented on all of these in my reply to the calsify list a few days a= go. I presume you are not actually on that list; apologies, I didn't rea= lise that. I've copied them again below. > =E2=80=94 Section 4.4.1 =E2=80=94 >=20 > The priority is specified as an integer in the range 0 to 9. A value > of 0 specifies an undefined priority. A value of 1 is the highest > priority. A value of 2 is the second highest priority. Subsequent > numbers specify a decreasing ordinal priority. A value of 9 is the > lowest priority. >=20 > What happens when priority 0 is mixed with other priority values? VAVAILABILITY (RFC7953) treats it the same as lowest priority (9), but I= could imagine in other contexts you might treat it the same as highest = priority. The current definition is to match with iCalendar as it did no= t seem worth deviating here. > =E2=80=94 Section 4.5.2 =E2=80=94 >=20 > o trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger" > (mandatory) >=20 > This is a manner of specifying this sort of thing that has not been > used before. You=E2=80=99ve always been using a defined type. Here (an= d in > other items below) you appear to be using specific strings with no > explanation about what the =E2=80=9C|=E2=80=9D means. There=E2=80=99s = an inconsistency here > that I=E2=80=99d like to see fixed or clearly explained. I'm not sure exactly what you find inconsistent here. These *are* types,= not strings. The definitions of the OffsetTrigger, AbsoluteTrigger and = UnknownTrigger types are immediately below. As per the Type Signatures c= onventions specified in Section 1.3 , the =E2=80=9C|=E2=80=9D means alt= ernation: the value can be any one of these types.. > =E2=80=94 Section 8.2.3 =E2=80=94 >=20 > This preferably takes the form of an RFC, but for simple definitions > a description in the registry may be sufficient. >=20 > I=E2=80=99ve had a conversation with IANA about this. The operative bi= t here > is whether "a description in the registry" could serve as the > "specification". I don't think we'd accept that. It's supposed to > be, according to BCP 26, a "permanent and readily available public > specification, in sufficient detail so that interoperability between > independent implementations is possible." While what you put in the > registry can be considered permanent, and it's certainly readily > available and public, it's a bit of a stretch. And it's hard to > imagine that a sentence or two in a registry could be "sufficient > detail". I'd say that some document, however brief, that's external > to IANA is required. The intention here was to reduce friction for people that want to add si= mple properties, to encourage registration rather than use of vendor-spe= cific values which tend to lead to less interoperability. I do think the= re are many simple properties where the entire description could trivial= ly fit in the registry and a document is overkill. Consider the title pr= operty for example, the entire definition is: 4.2.1 . title Type: "String" (optional, default: empty String). A short summary of the object. Pretending for a moment this wasn't in the initial spec, this would be r= egistered like so: *Property Name*: title *Property Type*: String *Property Context*: JSEvent, JSTask, JSGroup, Link *Reference or Description*: A short summary of the object. *Intended Use*: Common *Change Controller*: IETF Requiring a whole document for something like this just seems overkill t= o me, but I defer to IANA and your judgement on this; what would you sug= gest we do? > =E2=80=94 Section 8.4.1 =E2=80=94 >=20 > o Experts: The initial list of experts for Expert Review of updates > to the subregistry. >=20 > Hm, are you actually proposing that registrations provide their own > lists of experts, rather than having them appointed by the IESG? I > don=E2=80=99t think that=E2=80=99s going to work. We probably need to = have a > discussion about the intent here, so please initiate that by > explaining to me what you=E2=80=99re looking for. Suppose a new enum-type property is registered that is not IETF controll= ed, then a new enum subregistry will be created and the designated exper= ts need to be given for that subregistry, hence its inclusion in the tem= plate. Does that make sense? Cheers, Neil. --1c2ca05ae6464dc6900809f598a91023 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Barry,

There's one = very small error in the changes:

Thanks, I'll fix that.

And these comments that I had have not been addressed:

I commented on all of these in m= y reply to the calsify list a few days ago. I presume you are not actual= ly on that list; apologies, I didn't realise that. I've copied them agai= n below.

=E2=80=94= Section 4.4.1 =E2=80=94

 &= nbsp; The priority is specified as an integer in the range 0 to 9. = A value
   of 0 specifies an undefined priority= .  A value of 1 is the highest
   priority.=   A value of 2 is the second highest priority.  Subsequent
=
   numbers specify a decreasing ordinal priority.&n= bsp; A value of 9 is the
   lowest priority.
=

What happens when priority 0 is mix= ed with other priority values?

VAVAILABILITY (RFC7953) treats it the same as lowest priorit= y (9), but I could imagine in other contexts you might treat it the same= as highest priority. The current definition is to match with iCalendar = as it did not seem worth deviating here.

=E2=80=94 Section 4.5.2 =E2=80=94
=

   o  trigger: "Offs= etTrigger|AbsoluteTrigger|UnknownTrigger"
  &nbs= p;   (mandatory)

This = is a manner of specifying this sort of thing that has not been
=
used before.  You=E2=80=99ve always been using a defined type.=   Here (and in
other items below) you appear to be us= ing specific strings with no
explanation about what the =E2= =80=9C|=E2=80=9D means.  There=E2=80=99s an inconsistency here
<= /div>
that I=E2=80=99d like to see fixed or clearly explained.

I'm not sure exactly wha= t you find inconsistent here. These are types, not strings. The d= efinitions of the OffsetTrigger, AbsoluteTrigger and UnknownTrigger type= s are immediately below. As per the Type Signatures conventions specifie= d in Section 1.3, the =E2=80=9C|=E2=80=9D means alt= ernation: the value can be any one of these types..
<= br>
=E2=80=94 Section 8.2.3 =E2= =80=94

   This prefera= bly takes the form of an RFC, but for simple definitions
&= nbsp;  a description in the registry may be sufficient.

I=E2=80=99ve had a conversation with IANA a= bout this.  The operative bit here
is whether "a desc= ription in the registry" could serve as the
"specification= ".  I don't think we'd accept that.  It's supposed to
be, according to BCP 26, a "permanent and readily available public=
specification, in sufficient detail so that interoperabil= ity between
independent implementations is possible." = ; While what you put in the
registry can be considered per= manent, and it's certainly readily
available and public, i= t's a bit of a stretch. And it's hard to
imagine that a se= ntence or two in a registry could be "sufficient
detail".&= nbsp; I'd say that some document, however brief, that's external
to IANA is required.

The intention here was to reduce friction for people that want = to add simple properties, to encourage registration rather than use of v= endor-specific values which tend to lead to less interoperability. I do = think there are many simple properties where the entire description coul= d trivially fit in the registry and a document is overkill. Consider the= title property for example, the entire definition is:

<=
h4 style=3D"display:inline;white-space:pre;font-family:monospace;font-si=
ze:1em;font-weight:bold;">4.2.1.  title

   Type: "String" (optional, default: empty String).

   A short summary of the object.

Pretending for a moment this wasn't in the initial spec, this wo= uld be registered like so:

Pr= operty Name: title
Property Type: String
Property Context: JSEvent, JSTask, JSGroup, Link
Reference or Description: A short summary of the object.
Intended Use: Common
Change Controll= er: IETF

Requiring a whole d= ocument for something like this just seems overkill to me, but I defer t= o IANA and your judgement on this; what would you suggest we do?

=E2=80=94 Sec= tion 8.4.1 =E2=80=94

  = ; o  Experts: The initial list of experts for Expert Review of upda= tes
      to the subregistry.
=

Hm, are you actually proposing that= registrations provide their own
lists of experts, rather = than having them appointed by the IESG?  I
don=E2=80=99= t think that=E2=80=99s going to work.  We probably need to have a
discussion about the intent here, so please initiate that b= y
explaining to me what you=E2=80=99re looking for.

Suppose a new enum-type p= roperty is registered that is not IETF controlled, then a new enum subre= gistry will be created and the designated experts need to be given for t= hat subregistry, hence its inclusion in the template. Does that make sen= se?

Cheers,
Neil.<= br>
--1c2ca05ae6464dc6900809f598a91023-- From nobody Sun Feb 23 15:21:48 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 7C93E3A11CC; Sun, 23 Feb 2020 15:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqlH76YZPjuk; Sun, 23 Feb 2020 15:21:46 -0800 (PST) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) (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 9A6103A11CB; Sun, 23 Feb 2020 15:21:46 -0800 (PST) Received: by mail-il1-f177.google.com with SMTP id p78so6202853ilb.10; Sun, 23 Feb 2020 15:21:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RdU4d6EVZiULOTu1VI2kDlZhopmHMlz2plm9zVOcntM=; b=XAVCW8hSfwzM7G/sIm32siNB6FKnmtoAPsKuzh/CGkmu2XoFlRhfSutxj0vWl/IWTM X/06lwXkRzMg5qncPXGa1EIofDNEVxoz7UjWDG6BBEH2D1CMtnLeId2RywGx7rTOUyAM D3avw8O/EkR5B6Rz9P04Gg2nv/MTt1xcXPrf7+us+pKijr4s2oDH0YuXGFtywNV/UoVz 0kTZsu4Ez0PJoK1DVpK7y1oukjFSJ4Rptyd+3TN+ibKBppDMek0NJ4tf0AKGRQC2RTH1 AghDajv9LY2qyO4JgmqCPtXnM823aYuuwHiNx4ucsnodSYmM7KblWdKkC7UvHhtxolSb myWA== X-Gm-Message-State: APjAAAWIwWgJ9MjHwt99225iq9J32h3uBIxzf16x6nDsGBo71wKk0TAx SsY0QhIExw/mXs6+6BnK3bWbrbtIc2g6afmZVovxqQ== X-Google-Smtp-Source: APXvYqwCs6zoyvVetg6RF0XrYglbNBKPSjE7xBRjYDvHwkdDmmDiwtspkOfhba54PPPIaBYf3+Yc7Oz1XGJvYjAa79M= X-Received: by 2002:a92:9885:: with SMTP id a5mr55831356ill.107.1582500105664; Sun, 23 Feb 2020 15:21:45 -0800 (PST) MIME-Version: 1.0 References: <0accc1d2-3f8e-4b52-b454-f944f836eeea@beta.fastmail.com> In-Reply-To: <0accc1d2-3f8e-4b52-b454-f944f836eeea@beta.fastmail.com> From: Barry Leiba Date: Sun, 23 Feb 2020 15:21:34 -0800 Message-ID: To: Neil Jenkins Cc: draft-ietf-calext-jscalendar.all@ietf.org, calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-jscalendar-23 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, 23 Feb 2020 23:21:47 -0000 > I commented on all of these in my reply to the calsify list a few days ago. I presume you are not actually > on that list; apologies, I didn't realise that. I've copied them again below. Thanks, I'll take a look. Yes, I look at the archive when I need to see things, but it's always best to send to me explicitly when you're sending to me. Looking at your responses now. Barry From nobody Sun Feb 23 16:29: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 6ADA93A12AA; Sun, 23 Feb 2020 16:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nRDNN7DFRp1; Sun, 23 Feb 2020 16:29:01 -0800 (PST) Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) (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 103453A12A9; Sun, 23 Feb 2020 16:29:01 -0800 (PST) Received: by mail-il1-f176.google.com with SMTP id l4so6317942ilj.1; Sun, 23 Feb 2020 16:29:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=795UBe5Jt+rkZh/K6j4j8KGyb+51cYkY1ZCKHkMUSWc=; b=UIw6awKZQ+iZh582xVx0znAuDLLiKG1+HlW69qe+QFdZmM4Rzo0d6fH54deo9WiRg8 AF8IWVwgZv2mEMc+qAFQaFSGF4ZLZZKtYkR9zhea1ytgOvwFMad1oZF4VWtCjv/uxaMA uNuOnLJk8s++p631MLAhnWiCJCFK5eaK5pfHvKo2j3XSlkL7Zi3WjaKNbbHb9GYuDcJa QpUyHg2HZ5w1cA292JpOJH6kaKIkEpLlAMG/5M1GIt/BX/D8MY0v2ThMO6hrNdyxmpyt dFN4iLsnpszMMysPIdd4LMgdaKqOrD1dCQIb1MXoO/s7A3jfSVvs6aj/ujXDqBff3JBl lQIA== X-Gm-Message-State: APjAAAUiYPhwEa71xb56uDz9fmkcIkz19Bp0E9eoV2HloPNuWkDI83mU 3+qQ3CPlcbVykJW8DZ8d99aTL9BvctLlWEhQ50w32Cyf X-Google-Smtp-Source: APXvYqy4tqWlhi6N6TPzMEqWxaGqHg1lLXNbAnheWKnOysRTU0a3SVKk0ZSBwzJJPXcDbW1cI5FPe6Qt+VVFIIsXvdA= X-Received: by 2002:a92:d3cc:: with SMTP id c12mr55170958ilh.266.1582504139844; Sun, 23 Feb 2020 16:28:59 -0800 (PST) MIME-Version: 1.0 References: <0accc1d2-3f8e-4b52-b454-f944f836eeea@beta.fastmail.com> In-Reply-To: <0accc1d2-3f8e-4b52-b454-f944f836eeea@beta.fastmail.com> From: Barry Leiba Date: Sun, 23 Feb 2020 16:28:48 -0800 Message-ID: To: Neil Jenkins Cc: draft-ietf-calext-jscalendar.all@ietf.org, calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-jscalendar-23 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, 24 Feb 2020 00:29:02 -0000 > =E2=80=94 Section 4.4.1 =E2=80=94 > > The priority is specified as an integer in the range 0 to 9. A value > of 0 specifies an undefined priority. A value of 1 is the highest > priority. A value of 2 is the second highest priority. Subsequent > numbers specify a decreasing ordinal priority. A value of 9 is the > lowest priority. > > What happens when priority 0 is mixed with other priority values? > > > VAVAILABILITY (RFC7953) treats it the same as lowest priority (9), but I = could imagine in other contexts > you might treat it the same as highest priority. The current definition i= s to match with iCalendar as it did not > seem worth deviating here. OK, that makes sense. Maybe it's worth a minor wording change. Does something like this work for you (if not, I'm also OK with leaving it as is)?: NEW A value of 0 specifies an undefined priority, for which the treatment will vary by situation. END > =E2=80=94 Section 4.5.2 =E2=80=94 > > o trigger: "OffsetTrigger|AbsoluteTrigger|UnknownTrigger" > (mandatory) > > This is a manner of specifying this sort of thing that has not been > used before. You=E2=80=99ve always been using a defined type. Here (and= in > other items below) you appear to be using specific strings with no > explanation about what the =E2=80=9C|=E2=80=9D means. There=E2=80=99s an= inconsistency here > that I=E2=80=99d like to see fixed or clearly explained. > > I'm not sure exactly what you find inconsistent here. These are types, no= t strings. The definitions > of the OffsetTrigger, AbsoluteTrigger and UnknownTrigger types are immedi= ately below. As per the > Type Signatures conventions specified in Section 1.3, the =E2=80=9C|=E2= =80=9D means alternation: the value can be > any one of these types. Yes, I did figure out what it means, and in retrospect I'm not sure what I want you to do with it. Let's drop this one and leave the text as it is. > =E2=80=94 Section 8.2.3 =E2=80=94 > > This preferably takes the form of an RFC, but for simple definitions > a description in the registry may be sufficient. > > I=E2=80=99ve had a conversation with IANA about this. The operative bit = here > is whether "a description in the registry" could serve as the > "specification". I don't think we'd accept that. It's supposed to > be, according to BCP 26, a "permanent and readily available public > specification, in sufficient detail so that interoperability between > independent implementations is possible." While what you put in the > registry can be considered permanent, and it's certainly readily > available and public, it's a bit of a stretch. And it's hard to > imagine that a sentence or two in a registry could be "sufficient > detail". I'd say that some document, however brief, that's external > to IANA is required. > > The intention here was to reduce friction for people that want to add sim= ple properties, to encourage > registration rather than use of vendor-specific values which tend to lead= to less interoperability. I do think > there are many simple properties where the entire description could trivi= ally fit in the registry and a > document is overkill. Consider the title property for example, the entire= definition is: > > 4.2.1. title > > Type: "String" (optional, default: empty String). > > A short summary of the object. > > Pretending for a moment this wasn't in the initial spec, this would be re= gistered like so: > > Property Name: title > Property Type: String > Property Context: JSEvent, JSTask, JSGroup, Link > Reference or Description: A short summary of the object. > Intended Use: Common > Change Controller: IETF > > Requiring a whole document for something like this just seems overkill to= me, but I defer to IANA and > your judgement on this; what would you suggest we do? For something that simple, sure. Do you really anticipate extensions that are sufficiently simple, of that sort of nature, that a one-sentence explanation could be sufficient for interoperable implementations? If you really think that's likely, we could allow it, subject to the designated expert's judgment. Alternative to "a whole document" is a web page or wiki page that documents it. The point is that we don't generally want to store implementation documentation in IANA registries. Your point that a single sentence might be enough is reasonable. Maybe this will work?: NEW That documentation will usually be in an RFC, but simple definitions are likely to use a web/wiki page, and if a sentence or two is deemed sufficient it could be described in the registry itself. END > =E2=80=94 Section 8.4.1 =E2=80=94 > > o Experts: The initial list of experts for Expert Review of updates > to the subregistry. > > Hm, are you actually proposing that registrations provide their own > lists of experts, rather than having them appointed by the IESG? I > don=E2=80=99t think that=E2=80=99s going to work. We probably need to ha= ve a > discussion about the intent here, so please initiate that by > explaining to me what you=E2=80=99re looking for. > > > Suppose a new enum-type property is registered that is not IETF controlle= d, > then a new enum subregistry will be created and the designated experts ne= ed > to be given for that subregistry, hence its inclusion in the template. Do= es that > make sense? Well, Expert Review (or Specification Required) uses experts designated by (appointed by) the IESG. Here, it sounds like you're talking about creating registries that use some other sort of peer review, using experts not appointed by the IESG -- appointed by, it seems, whoever creates the registry. I'm quite sure that IANA will be unhappy with that, as they aren't set up to consult arbitrary experts and to track their responses, without having the IESG to act as managers and do problem resolution. What happens when the specified experts disappear -- their email addresses no longer work, or the experts are unresponsive? Who deals with that? We have a whole process for how expert review works within the IETF, but we don't have any process for dealing with outside experts. So, the *concept* makes sense, but, as the saying goes, the devil is in the details. Barry From nobody Sun Feb 23 18:43:56 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 7B6D83A0821; Sun, 23 Feb 2020 18:43:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <158251223541.1160.460356772196212225@ietfa.amsl.com> Date: Sun, 23 Feb 2020 18:43:55 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-25.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 02:43:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : JSCalendar: A JSON representation of calendar data Authors : Neil Jenkins Robert Stepanek Filename : draft-ietf-calext-jscalendar-25.txt Pages : 77 Date : 2020-02-23 Abstract: This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format, and to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also JSON-based, JSCalendar is not a direct mapping from iCalendar, but defines the data model independently and expands semantics where appropriate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-25 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-25 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Feb 23 18:46:42 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 8E02A3A082A; Sun, 23 Feb 2020 18:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.583 X-Spam-Level: X-Spam-Status: No, score=-0.583 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, URIBL_RHS_DOB=1.514] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=HihCvqip; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lOaQ788v 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 eOe_scZY_nYH; Sun, 23 Feb 2020 18:46:38 -0800 (PST) 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 9A7E53A0827; Sun, 23 Feb 2020 18:46:38 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EB72B20CBC; Sun, 23 Feb 2020 21:46:37 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 23 Feb 2020 21:46:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=c2iO Wt055kW7lFxgPq6W4Pu04XU7WSPlY4spEIAWBKo=; b=HihCvqipZ0nrQDuAL11C OwHqIHsSoPa9VIMyF/qllOBuo84ovDf+T9JOU7nxi3o2yZq01KzzW7Yl50ndo4Y9 mItwYlsRlM067DbyCxPiznv033BNSxFVM1NzMhHAi3WTU+ZyNVPriFSu5jGP6VJL aJ2uIZjWhhTHv5jmsV7jTBRlqfNO1oKUF56zdd9uCYXL0n1DfXkqZhcLNGha71iy CsiIwzsbYFFn2dQVJ9BmY12wC606lecSs5l0GPbRqHSv41VSO99STWPyQtK/sEVu u79Ze8f7EoFrhoE2OOEHYC7qq09rJKiPWxHGr1i9FqaQ0Xcl2Eq5E/XKjVndtzNG qA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=c2iOWt 055kW7lFxgPq6W4Pu04XU7WSPlY4spEIAWBKo=; b=lOaQ788vNohhIjX+6q2X9P mAVMUoe6KpmtQPNC3ow7Gxy/ECxcOG5ZHgKU3t3VTZSnoM6tsaPDm7MfKPWoInm8 Y50O9VYLrqR1qFTdmh/CyjzUty1b9hFadlw7G2h5pOX1wNn6MGXFbxC/eYclFVa/ Ko5FCO7fAVuSQVEYvwMjh+BHwMaEGE8Qm7AYeZKIhsB7ZNwgQ4sdruQnIqrJ90Rw b0TRcLeBBQdB16I9+mAZbaMUR50dyyTZfFjzHcjgB2x4UiEqalaRzhBRT7Q8PJpv C1TszHuoU5iKCVecaTCkqdBS3kKGpV/cCqkf1ihgGlBoabdAFhyFl1oqQvLsQQZw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrkeelgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A0FC9180096; Sun, 23 Feb 2020 21:46:37 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-947-gbed3ff6-fmstable-20200220v2 Mime-Version: 1.0 Message-Id: <1fa00973-195a-489f-a4f9-d919ab80b7f5@beta.fastmail.com> In-Reply-To: References: <0accc1d2-3f8e-4b52-b454-f944f836eeea@beta.fastmail.com> Date: Mon, 24 Feb 2020 13:46:17 +1100 From: "Neil Jenkins" To: "Barry Leiba" Cc: draft-ietf-calext-jscalendar.all@ietf.org, calsify@ietf.org Content-Type: multipart/alternative; boundary=b9706964f03f4269a3437efe0980621b Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-jscalendar-23 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, 24 Feb 2020 02:46:41 -0000 --b9706964f03f4269a3437efe0980621b Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Barry, > OK, that makes sense. Maybe it's worth a minor wording change. Does > something like this work for you >=20 > NEW > A value of 0 specifies an undefined priority, for which the treatment > will vary by situation. > END Yes, I'm happy with that; I've added it in. > Do you really anticipate extensions that are sufficiently simple, of t= hat sort of nature, that a one-sentence explanation could be sufficient = for interoperable implementations? I do, yes. Many properties are that simple. > Maybe this will work?: >=20 > NEW > That documentation will usually be in an RFC, but simple > definitions are likely to use a web/wiki page, and if a sentence > or two is deemed sufficient it could be described in the registry > itself. > END That looks good to me, I've adopted that too. > > =E2=80=94 Section 8.4.1 =E2=80=94 > > > > o Experts: The initial list of experts for Expert Review of updates > > to the subregistry. > > > > Hm, are you actually proposing that registrations provide their own > > lists of experts, rather than having them appointed by the IESG? I > > don=E2=80=99t think that=E2=80=99s going to work. We probably need t= o have a > > discussion about the intent here, so please initiate that by > > explaining to me what you=E2=80=99re looking for. > > > > > > Suppose a new enum-type property is registered that is not IETF cont= rolled, > > then a new enum subregistry will be created and the designated exper= ts need > > to be given for that subregistry, hence its inclusion in the templat= e. Does that > > make sense? >=20 > Well, Expert Review (or Specification Required) uses experts > designated by (appointed by) the IESG. Here, it sounds like you're > talking about creating registries that use some other sort of peer > review, using experts not appointed by the IESG -- appointed by, it > seems, whoever creates the registry. I'm quite sure that IANA will be > unhappy with that, as they aren't set up to consult arbitrary experts > and to track their responses, without having the IESG to act as > managers and do problem resolution. What happens when the specified > experts disappear -- their email addresses no longer work, or the > experts are unresponsive? Who deals with that? We have a whole > process for how expert review works within the IETF, but we don't have= > any process for dealing with outside experts. >=20 > So, the *concept* makes sense, but, as the saying goes, the devil is > in the details. OK, understood. I've now made it so the registry is just IETF designated= experts (like the others); see the diff in v25 . I hope this resolves the issue. Cheers, Neil. --b9706964f03f4269a3437efe0980621b Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Barry,<= br>

OK, tha= t makes sense.  Maybe it's worth a minor wording change.  Does=
something like this work for you

=
NEW
A value of 0 specifies an undefined priority, for= which the treatment
will vary by situation.
END

Yes, I'm happy with that;= I've added it in.

Do you really anticipate extensions that are sufficiently simp= le, of that sort of nature, that a one-sentence explanation could be suf= ficient for interoperable implementations?
I do, yes. Many properties are that simple.
<= br>
Maybe this will work?:=

NEW
   That docume= ntation will usually be in an RFC, but simple
  = definitions are likely to use a web/wiki page, and if a sentence
   or two is deemed sufficient it could be described i= n the registry
   itself.
END
<= /div>

That looks good to me, I've adopte= d that too.

=
> =E2=80=94 Section 8.4.1 =E2=80=94
>
=
>    o  Experts: The initial list of experts= for Expert Review of updates
>    =    to the subregistry.
>
> H= m, are you actually proposing that registrations provide their own
> lists of experts, rather than having them appointed by the= IESG?  I
> don=E2=80=99t think that=E2=80=99s goi= ng to work.  We probably need to have a
> discussi= on about the intent here, so please initiate that by
> = explaining to me what you=E2=80=99re looking for.
>
=
>
> Suppose a new enum-type property is r= egistered that is not IETF controlled,
> then a new enu= m subregistry will be created and the designated experts need
<= div>> to be given for that subregistry, hence its inclusion in the te= mplate. Does that
> make sense?

Well, Expert Review (or Specification Required) uses experts
designated by (appointed by) the IESG.  Here, it sounds li= ke you're
talking about creating registries that use some = other sort of peer
review, using experts not appointed by = the IESG -- appointed by, it
seems, whoever creates the re= gistry.  I'm quite sure that IANA will be
unhappy wit= h that, as they aren't set up to consult arbitrary experts
and to track their responses, without having the IESG to act as
managers and do problem resolution.  What happens when the s= pecified
experts disappear -- their email addresses no lon= ger work, or the
experts are unresponsive?  Who deals= with that?  We have a whole
process for how expert r= eview works within the IETF, but we don't have
any process= for dealing with outside experts.

So, the = *concept* makes sense, but, as the saying goes, the devil is
in the details.

OK, underst= ood. I've now made it so the registry is just IETF designated experts (l= ike the others); see the diff in v25. I hope this resolv= es the issue.

Cheers,
Neil.
--b9706964f03f4269a3437efe0980621b-- From nobody Sun Feb 23 21:29: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 547053A07FE; Sun, 23 Feb 2020 21:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.116 X-Spam-Level: X-Spam-Status: No, score=0.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1db0apfHmpkU; Sun, 23 Feb 2020 21:29:13 -0800 (PST) Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) (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 1A06B3A0845; Sun, 23 Feb 2020 21:29:12 -0800 (PST) Received: by mail-io1-f46.google.com with SMTP id c16so8963630ioh.6; Sun, 23 Feb 2020 21:29:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UvnNn/CyCSPhWiIUUzJFVyx9gRmOpCv3F6GFY1Xfqes=; b=RYJh3V+zrmS5NmVzaFIJM0eE17j8DTinsArR5cyv50TFm97bywZjsB26iSdmgQiR+W DXaVsE4u6fBqk/rKIxWrLluB3Xn3UCFWpHC9i2sUVI091L5eIR214TDbv4gwN9yhjUUq DIn5+jHbLajYM5z0WKYq+zmegIe955jTt24aRKWKxpyt6aD6Wg45UF/JGmXVOHpwYwng vRm7qO3E3CkBBCjQzyCYeISGhegt3OChnCJsmpo/jGgZ1y29MhzWrsYzyHyiIje1HqCN tk5PlWSL+gEkJy/t5G1zyr8APiYWGMap4gKT7LbjtMpp12KLFWvY/tVaYyUhfq/YV6NS JaLA== X-Gm-Message-State: APjAAAUXVi2IZn5Ldn2vBWn0j5LBCobG0861mn1XEEEXz7MGmg7DVxT/ x9vi86QtABUVldJCvcGzdQJtiCPo7bO3326WVVbj6Q== X-Google-Smtp-Source: APXvYqykcMBelKh114yuolE0/Fm88Te0OCsj+armjliLngQ6Os5Gb6vdqOYFTSyGnwxnNNaMcBy3KK8mDl7wP4sSUkg= X-Received: by 2002:a02:a388:: with SMTP id y8mr49216004jak.70.1582522152032; Sun, 23 Feb 2020 21:29:12 -0800 (PST) MIME-Version: 1.0 References: <0accc1d2-3f8e-4b52-b454-f944f836eeea@beta.fastmail.com> <1fa00973-195a-489f-a4f9-d919ab80b7f5@beta.fastmail.com> In-Reply-To: <1fa00973-195a-489f-a4f9-d919ab80b7f5@beta.fastmail.com> From: Barry Leiba Date: Sun, 23 Feb 2020 21:29:01 -0800 Message-ID: To: Neil Jenkins Cc: calsify@ietf.org, draft-ietf-calext-jscalendar.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000b89eb3059f4ba610" Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-jscalendar-23 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, 24 Feb 2020 05:29:18 -0000 --000000000000b89eb3059f4ba610 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All good... onward and forward. b On Sun, Feb 23, 2020 at 6:46 PM Neil Jenkins wrote= : > Hi Barry, > > OK, that makes sense. Maybe it's worth a minor wording change. Does > something like this work for you > > NEW > A value of 0 specifies an undefined priority, for which the treatment > will vary by situation. > END > > > Yes, I'm happy with that; I've added it in. > > Do you really anticipate extensions that are sufficiently simple, of that > sort of nature, that a one-sentence explanation could be sufficient for > interoperable implementations? > > > I do, yes. Many properties are that simple. > > Maybe this will work?: > > NEW > That documentation will usually be in an RFC, but simple > definitions are likely to use a web/wiki page, and if a sentence > or two is deemed sufficient it could be described in the registry > itself. > END > > > That looks good to me, I've adopted that too. > > > =E2=80=94 Section 8.4.1 =E2=80=94 > > > > o Experts: The initial list of experts for Expert Review of updates > > to the subregistry. > > > > Hm, are you actually proposing that registrations provide their own > > lists of experts, rather than having them appointed by the IESG? I > > don=E2=80=99t think that=E2=80=99s going to work. We probably need to = have a > > discussion about the intent here, so please initiate that by > > explaining to me what you=E2=80=99re looking for. > > > > > > Suppose a new enum-type property is registered that is not IETF > controlled, > > then a new enum subregistry will be created and the designated experts > need > > to be given for that subregistry, hence its inclusion in the template. > Does that > > make sense? > > Well, Expert Review (or Specification Required) uses experts > designated by (appointed by) the IESG. Here, it sounds like you're > talking about creating registries that use some other sort of peer > review, using experts not appointed by the IESG -- appointed by, it > seems, whoever creates the registry. I'm quite sure that IANA will be > unhappy with that, as they aren't set up to consult arbitrary experts > and to track their responses, without having the IESG to act as > managers and do problem resolution. What happens when the specified > experts disappear -- their email addresses no longer work, or the > experts are unresponsive? Who deals with that? We have a whole > process for how expert review works within the IETF, but we don't have > any process for dealing with outside experts. > > So, the *concept* makes sense, but, as the saying goes, the devil is > in the details. > > > OK, understood. I've now made it so the registry is just IETF designated > experts (like the others); see the diff > in = v25 > . I hope > this resolves the issue. > > Cheers, > Neil. > --000000000000b89eb3059f4ba610 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All good... onward=C2=A0and forward.

b

On Sun, Feb 23, 2020 at 6:4= 6 PM Neil Jenkins <neilj@fastm= ailteam.com> wrote:
<= div>
Hi Barry,

OK, that makes sense.=C2=A0 Maybe it's w= orth a minor wording change.=C2=A0 Does
something like this w= ork for you

NEW
A value of 0 spe= cifies an undefined priority, for which the treatment
will va= ry by situation.
END

Yes, I'm happy with that; I've added it in.

Do you re= ally anticipate extensions that are sufficiently simple, of that sort of na= ture, that a one-sentence explanation could be sufficient for interoperable= implementations?

I do, yes. Many= properties are that simple.

Maybe this will work?:

NEW
=C2=A0=C2=A0 That documentation will us= ually be in an RFC, but simple
=C2=A0=C2=A0 definitions are l= ikely to use a web/wiki page, and if a sentence
=C2=A0=C2=A0 = or two is deemed sufficient it could be described in the registry
=
=C2=A0=C2=A0 itself.
END

=
That looks good to me, I've adopted that too.

> =E2=80=94 Section 8.4.1 =E2=80=94
>
>=C2=A0=C2=A0=C2=A0 o=C2=A0 Experts: The initial list of experts f= or Expert Review of updates
>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 to the subregistry.
>
> Hm, are= you actually proposing that registrations provide their own
= > lists of experts, rather than having them appointed by the IESG?=C2=A0= I
> don=E2=80=99t think that=E2=80=99s going to work.=C2= =A0 We probably need to have a
> discussion about the inte= nt here, so please initiate that by
> explaining to me wha= t you=E2=80=99re looking for.
>
>
> Suppose a new enum-type property is registered that is not IETF= controlled,
> then a new enum subregistry will be created= and the designated experts need
> to be given for that su= bregistry, hence its inclusion in the template. Does that
>= ; make sense?

Well, Expert Review (or Specific= ation Required) uses experts
designated by (appointed by) the= IESG.=C2=A0 Here, it sounds like you're
talking about cr= eating registries that use some other sort of peer
review, us= ing experts not appointed by the IESG -- appointed by, it
see= ms, whoever creates the registry.=C2=A0 I'm quite sure that IANA will b= e
unhappy with that, as they aren't set up to consult arb= itrary experts
and to track their responses, without having t= he IESG to act as
managers and do problem resolution.=C2=A0 W= hat happens when the specified
experts disappear -- their ema= il addresses no longer work, or the
experts are unresponsive?= =C2=A0 Who deals with that?=C2=A0 We have a whole
process for= how expert review works within the IETF, but we don't have
any process for dealing with outside experts.

So, the *concept* makes sense, but, as the saying goes, the devil is
=
in the details.

=
OK, understood. I've now made it so the registry is just IETF desi= gnated experts (like the others); see the diff i= n v25. I hope this resolves the issue.
Cheers,
Neil.
<= /div> --000000000000b89eb3059f4ba610-- From nobody Mon Feb 24 07:23:27 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 874D33A0D1F; Mon, 24 Feb 2020 07:23:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-calext-jscalendar@ietf.org, calsify@ietf.org, calext-chairs@ietf.org, Daniel Migault , daniel.migaultf@ericsson.com, barryleiba@gmail.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158255780248.5348.1738418778445910742.idtracker@ietfa.amsl.com> Date: Mon, 24 Feb 2020 07:23:22 -0800 Archived-At: Subject: [calsify] Last Call: (JSCalendar: A JSON representation of calendar data) to Proposed Standard 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, 24 Feb 2020 15:23:23 -0000 The IESG has received a request from the Calendaring Extensions WG (calext) to consider the following document: - 'JSCalendar: A JSON representation of calendar data' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-03-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format, and to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also JSON-based, JSCalendar is not a direct mapping from iCalendar, but defines the data model independently and expands semantics where appropriate. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Feb 25 18:04: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 AC7B93A08E8; Tue, 25 Feb 2020 18:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.117 X-Spam-Level: X-Spam-Status: No, score=0.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_RHS_DOB=1.514] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy4xL3bOTooN; Tue, 25 Feb 2020 18:04:37 -0800 (PST) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) (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 B27963A08E6; Tue, 25 Feb 2020 18:04:37 -0800 (PST) Received: by mail-io1-f47.google.com with SMTP id m25so1548799ioo.8; Tue, 25 Feb 2020 18:04:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7xlhyVJoylZj37WewVCZNCECDfFT8nHD0U/p5zWaGYY=; b=o77aPDEVCW3dTNsSBOYTYhbV2jiPhcvkzsSttBq9d/7yq0tkSqGadgs6pI11dEzwN3 F7kDo19sSXz9of1pIk8JMa1Siz0L1C2C+2SBxfMszDw1TiYbv2p0l4Q1X23SfqBQQq3w fH4tt9Myb0Eg4/vQPLIWuM/VzinaMYFOoRl/3FI1Gp/2qVDH3ZoTlYi2mVeXrzNku0pw KooKavJgWg45n1ZBpYjanCsFBydXAPPSh3LmoMp71WgHS1u5qvpJw5TxNWgXTdKjRVNM if8edSdOeXRr7Bzzzh/l3UsU3uuiabif2fFUJtcF59YV3Zo1D9mgjWG5yKSm6Ro0vvHh qG+g== X-Gm-Message-State: APjAAAUT+KGeJre+Ew0brJ/PHz7Sz5sozv/9hBa+kcvcLn8mE7/PpCNp 8B/RsjLvRjbuaplLCqg6jaqaPbxZuOids4+09Gry9A== X-Google-Smtp-Source: APXvYqwpe4qgIbjKjOPk92OJNllFU+6TI+KPQCSEtAZ4UV/tBL99dBhPfJVRolj/P+/zxSlF+MvaPtO/n8xkbN0FHWQ= X-Received: by 2002:a5e:8417:: with SMTP id h23mr1679613ioj.17.1582682675487; Tue, 25 Feb 2020 18:04:35 -0800 (PST) MIME-Version: 1.0 References: <0accc1d2-3f8e-4b52-b454-f944f836eeea@beta.fastmail.com> <1fa00973-195a-489f-a4f9-d919ab80b7f5@beta.fastmail.com> In-Reply-To: From: Barry Leiba Date: Tue, 25 Feb 2020 18:04:24 -0800 Message-ID: To: Neil Jenkins Cc: calsify@ietf.org, draft-ietf-calext-jscalendar.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000aa2cb6059f7106f9" Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-jscalendar-23 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, 26 Feb 2020 02:04:40 -0000 --000000000000aa2cb6059f7106f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I chatted with Michelle Cotton (IANA), and she suggested that it would work better for them if we called the policy Expert Review instead of Specification Required, but still said that we expect a document, etc, as we now say, and the Expert will judge the suitability of that. No need to make any change now, but please queue it up for when you next make a change. It=E2=80=99s just a minimal thing at this point. Barry On Sun, Feb 23, 2020 at 9:29 PM Barry Leiba wrote= : > All good... onward and forward. > > b > > On Sun, Feb 23, 2020 at 6:46 PM Neil Jenkins > wrote: > >> Hi Barry, >> >> OK, that makes sense. Maybe it's worth a minor wording change. Does >> something like this work for you >> >> NEW >> A value of 0 specifies an undefined priority, for which the treatment >> will vary by situation. >> END >> >> >> Yes, I'm happy with that; I've added it in. >> >> Do you really anticipate extensions that are sufficiently simple, of tha= t >> sort of nature, that a one-sentence explanation could be sufficient for >> interoperable implementations? >> >> >> I do, yes. Many properties are that simple. >> >> Maybe this will work?: >> >> NEW >> That documentation will usually be in an RFC, but simple >> definitions are likely to use a web/wiki page, and if a sentence >> or two is deemed sufficient it could be described in the registry >> itself. >> END >> >> >> That looks good to me, I've adopted that too. >> >> > =E2=80=94 Section 8.4.1 =E2=80=94 >> > >> > o Experts: The initial list of experts for Expert Review of update= s >> > to the subregistry. >> > >> > Hm, are you actually proposing that registrations provide their own >> > lists of experts, rather than having them appointed by the IESG? I >> > don=E2=80=99t think that=E2=80=99s going to work. We probably need to= have a >> > discussion about the intent here, so please initiate that by >> > explaining to me what you=E2=80=99re looking for. >> > >> > >> > Suppose a new enum-type property is registered that is not IETF >> controlled, >> > then a new enum subregistry will be created and the designated experts >> need >> > to be given for that subregistry, hence its inclusion in the template. >> Does that >> > make sense? >> >> Well, Expert Review (or Specification Required) uses experts >> designated by (appointed by) the IESG. Here, it sounds like you're >> talking about creating registries that use some other sort of peer >> review, using experts not appointed by the IESG -- appointed by, it >> seems, whoever creates the registry. I'm quite sure that IANA will be >> unhappy with that, as they aren't set up to consult arbitrary experts >> and to track their responses, without having the IESG to act as >> managers and do problem resolution. What happens when the specified >> experts disappear -- their email addresses no longer work, or the >> experts are unresponsive? Who deals with that? We have a whole >> process for how expert review works within the IETF, but we don't have >> any process for dealing with outside experts. >> >> So, the *concept* makes sense, but, as the saying goes, the devil is >> in the details. >> >> >> OK, understood. I've now made it so the registry is just IETF designated >> experts (like the others); see the diff >> in >> v25 . I >> hope this resolves the issue. >> >> Cheers, >> Neil. >> > --000000000000aa2cb6059f7106f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I chatted with Michelle Cotton (IANA), and she sugge= sted that it would work better for them if we called the policy Expert Revi= ew instead of Specification Required, but still said that we expect a docum= ent, etc, as we now say, and the Expert will judge the suitability of that.=

No need to make a= ny change now, but please queue it up for when you next make a change.=C2= =A0 It=E2=80=99s just a minimal thing at this=C2=A0point.

Barry

On Sun, Feb 23, 2020 at 9:29 PM= Barry Leiba <barryleiba@comp= uter.org> wrote:
All good... onward=C2=A0and forward.

b

<= div dir=3D"ltr" class=3D"gmail_attr">On Sun, Feb 23, 2020 at 6:46 PM Neil J= enkins <neil= j@fastmailteam.com> wrote:
<= u>
Hi Barry,

OK, that makes sen= se.=C2=A0 Maybe it's worth a minor wording change.=C2=A0 Does
=
something like this work for you

NEW
<= /div>
A value of 0 specifies an undefined priority, for which the treat= ment
will vary by situation.
END

Yes, I'm happy with that; I've added it= in.

Do you really anticipate extensions tha= t are sufficiently simple, of that sort of nature, that a one-sentence expl= anation could be sufficient for interoperable implementations?

I do, yes. Many properties are that simple.

Maybe this will work?:

NEW
=C2=A0=C2=A0 That documentation will usually be in= an RFC, but simple
=C2=A0=C2=A0 definitions are likely to us= e a web/wiki page, and if a sentence
=C2=A0=C2=A0 or two is d= eemed sufficient it could be described in the registry
=C2=A0= =C2=A0 itself.
END

= That looks good to me, I've adopted that too.
=
> =E2=80=94 Section 8.4.1 =E2=80=94
><= br>
>=C2=A0=C2=A0=C2=A0 o=C2=A0 Experts: The initial list of e= xperts for Expert Review of updates
>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 to the subregistry.
>
> H= m, are you actually proposing that registrations provide their own
> lists of experts, rather than having them appointed by the IESG?= =C2=A0 I
> don=E2=80=99t think that=E2=80=99s going to wor= k.=C2=A0 We probably need to have a
> discussion about the= intent here, so please initiate that by
> explaining to m= e what you=E2=80=99re looking for.
>
>
> Suppose a new enum-type property is registered that is not= IETF controlled,
> then a new enum subregistry will be cr= eated and the designated experts need
> to be given for th= at subregistry, hence its inclusion in the template. Does that
> make sense?

Well, Expert Review (or Spe= cification Required) uses experts
designated by (appointed by= ) the IESG.=C2=A0 Here, it sounds like you're
talking abo= ut creating registries that use some other sort of peer
revie= w, using experts not appointed by the IESG -- appointed by, it
seems, whoever creates the registry.=C2=A0 I'm quite sure that IANA w= ill be
unhappy with that, as they aren't set up to consul= t arbitrary experts
and to track their responses, without hav= ing the IESG to act as
managers and do problem resolution.=C2= =A0 What happens when the specified
experts disappear -- thei= r email addresses no longer work, or the
experts are unrespon= sive?=C2=A0 Who deals with that?=C2=A0 We have a whole
proces= s for how expert review works within the IETF, but we don't have
any process for dealing with outside experts.

So, the *concept* makes sense, but, as the saying goes, the devil i= s
in the details.

=
OK, understood. I've now made it so the registry is just IETF= designated experts (like the others); see the diff<= /a> in v25. I hope this resolves the issue.

Cheers,
Neil.
--000000000000aa2cb6059f7106f9-- From nobody Fri Feb 28 11: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 8BA403A1A58 for ; Fri, 28 Feb 2020 11:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=twitch.tv 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 PzUF0EERNE9o for ; Fri, 28 Feb 2020 11:44:10 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 1576E3A1A56 for ; Fri, 28 Feb 2020 11:44:09 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id v4so4334406wrs.8 for ; Fri, 28 Feb 2020 11:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitch.tv; s=google; h=mime-version:from:date:message-id:subject:to; bh=70LsTfiKNSehkxImF1dfx0dJdCQKS31iyIjIy20CnP8=; b=YjM6bHc5pr1F9zuD5Kww7zmPrAvMXcyhzXMOPeBlPPTvqjPvM3MaT6MZjTU2LGT5QB Qw0q9nR8CLHQc0MMWzOpCYha2heZU+ZgAHcQHA/mIHATfConSrzaS4x7zzsPfMl051Vn VQoDk4wpB9XupfoVBA8X4tHUKQoJFOcxrxs1Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=70LsTfiKNSehkxImF1dfx0dJdCQKS31iyIjIy20CnP8=; b=lgOwX1/qDHsHwHy941WPAwwLejAi3OrnptgRzGnB0S8K1K5kraa7lMXC5y2wdWWu0X nuJp0Uc5HhLsjC43HRUBCYG5vXHew+8YQEYJIAWtOaqh7tqw+GezLLX0Wj6EmvEw3XAA bytBUduAFPfgYFEglS5jkwy+YhYuvvhgqkb29/g4CdkNmCZuE6Ayhp4I5NYWABvZmgv2 vZF7azHb4WbDINlbxTYFkL2lpozJtpjfQAfy6ZZrARr28KD0QxQCWSWjoZo0t8Ap9adj vkSIlZ1XhxlUHR+jCoA4GeNp4XbyT/POMupoYTMZtVwaEUfhZv0ejC108DAR6uYT+Xve 8YKw== X-Gm-Message-State: APjAAAVmqisT631MJJyD1KyumX6sAgkrXnL7hzlDXVSOjCzF41lCmLSb g9pOU5vmYQbRNhNiYaOrjeC1tjbwS+VP4BAOxuxM9vXWEg== X-Google-Smtp-Source: APXvYqyL8uIUTQormMhTtHrcDYDISFKlIhqyMBWUYA44WEO5xIndvGJ5FlxojqX7s2B/Ma3Do/gLYzpvB5S9CT3Umqo= X-Received: by 2002:a05:6000:110b:: with SMTP id z11mr6368115wrw.252.1582919047778; Fri, 28 Feb 2020 11:44:07 -0800 (PST) MIME-Version: 1.0 From: Ryan Gunter Date: Fri, 28 Feb 2020 12:43:31 -0700 Message-ID: To: calsify@ietf.org Content-Type: multipart/alternative; boundary="0000000000008d389a059fa80f8d" Archived-At: Subject: [calsify] Informational RFC Question - Maintenance Notifications 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, 28 Feb 2020 19:44:12 -0000 --0000000000008d389a059fa80f8d Content-Type: text/plain; charset="UTF-8" Hello, I hope the group is doing well! A few months ago I submitted a draft to add x-maint properties to icalendar attachments to indicate upcoming network maintenances. https://datatracker.ietf.org/doc/html/draft-gunter-calext-maintenance-notifications During an IETF meeting (and through some emails as well), it was suggested to define a schema to use the STRUCTURED-DATA property presented in the current eventput-extensions draft. Then, an Informational RFC could be written about this particular use case. Is this still the best approach? If so, I am going to start working on getting something defined at schema.org and creating the informational document. Ryan Gunter | *Twitch* | Network Engineering | +1.415.568.7607 --0000000000008d389a059fa80f8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I hope the group is d= oing well!

A few months ago I submitted a draf= t to add x-maint properties to icalendar attachments to indicate upcoming n= etwork maintenances.


During an IETF meeting (and through some emai= ls as well), it was suggested to define a schema to use the STRUCTURED-DATA= property presented in the current eventput-extensions draft.=C2=A0 Then, a= n Informational RFC could be written about this particular use case.=C2=A0 = Is this still the best approach?=C2=A0 If so, I am going to start working o= n getting something defined at schema.org= and creating the informational document.


=

R= yan Gunter=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0Twitch<= font style=3D"font-size:12.7273px">=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0 Networ= k Engineering=C2=A0 =C2=A0= | =C2=A0=C2=A0= +1.415.568.7607
=
--0000000000008d389a059fa80f8d-- From nobody Fri Feb 28 12:23:53 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAF23A1D67 for ; Fri, 28 Feb 2020 12:23:51 -0800 (PST) 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 ogSnvBAjol7s for ; Fri, 28 Feb 2020 12:23:50 -0800 (PST) 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 E18023A1D61 for ; Fri, 28 Feb 2020 12:23:49 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id c17so4886149ioc.4 for ; Fri, 28 Feb 2020 12:23:49 -0800 (PST) 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=QOlYctYzzWnLa7huI60zESvpNWoA7TpWH8xAXGbee3o=; b=aau4nUHcIOoS8q7y5iAfI6xo3mIhReAqNiXhnAvU3Rj32J5+cBcqa8nTMgVJnBU6Mz remLE45jbb1yfhb8xl0HsvtxBdUoN/vu1KLF9Gbdf3EQ728gSbAjrcs8lhmX69aHhG8p iKYUjFeHCnopSl/fQvr9yKtZxtMlYHnmFeMYmtk1/bJf7S65d5OLQERwslhQFvgJ3YGR 3UHTHwL6/HwB9YIVeKBLQfMyTW3U0swo+UAAUrapzIF/L19dA3whUiASKgi0R7xxgGSB jo7NOLAY+UJTey3EGj7EtUhPWL9eeeRJwrBFFvbgd7+jVkLPom01HLgGN1nUaiwJ5Yv2 dUyw== 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=QOlYctYzzWnLa7huI60zESvpNWoA7TpWH8xAXGbee3o=; b=eF+ZxEVDweWskU1oElqo20rUD1IuBlbjGTMsQNqqDOenON8XdLw9ov/AZ2Mfj5NPys Ba88zcQDZd3uAMr3+XA+nlg1YQDovG2uKX7ghNSsr6yFrpRt/kQX5lPJWsNjtAPsOrJR OQ4m1hrvWAtYcAWt7EQQ9Mn8FNBuDgeILRQI5Nq/S/tXjCUxOfYvi80Nzxl0PlwHnPL1 rCPQamL2Oi6LWhkFoNMue1ZYk/GdsRH0/zK7TKZ6PTXGGZ9jMHwXYdwYDyexW9Jof0mb RVPTyOM9LhtGfNrO0HcD1dLDNViLan4O0ShvZP8gdgPdoGnNVe6QJ087t8I0Ykphgv8f brEQ== X-Gm-Message-State: APjAAAXLELrfBxhsUg1wWB/jZFXikkbPCMYhB6wv31njdbG04YEH5HBV xdmpP63s/QhgdewC8PH+LvvJpUIC X-Google-Smtp-Source: APXvYqy2c/IR3adR9vi5UPRlvzjjgJB+cYsHlFwmmFUNScRpFdDTaig+X9fQw0fxxrG1As1jqjN3xQ== X-Received: by 2002:a05:6602:95:: with SMTP id h21mr4922410iob.271.1582921429078; Fri, 28 Feb 2020 12:23:49 -0800 (PST) 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 y62sm3408228ilk.32.2020.02.28.12.23.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 28 Feb 2020 12:23:48 -0800 (PST) To: calsify@ietf.org References: From: Michael Douglass Message-ID: <3e70f4a7-2247-b6c4-fbd7-9e1bc4e1f91d@gmail.com> Date: Fri, 28 Feb 2020 15:23:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------79125954DFFD0E6F6D1C2117" Content-Language: en-US Archived-At: Subject: Re: [calsify] Informational RFC Question - Maintenance Notifications 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, 28 Feb 2020 20:23:52 -0000 This is a multi-part message in MIME format. --------------79125954DFFD0E6F6D1C2117 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I believe that to be the best approach. On 2/28/20 14:43, Ryan Gunter wrote: > Hello, > > I hope the group is doing well! > > A few months ago I submitted a draft to add x-maint properties to > icalendar attachments to indicate upcoming network maintenances. > > https://datatracker.ietf.org/doc/html/draft-gunter-calext-maintenance-notifications > > During an IETF meeting (and through some emails as well), it was > suggested to define a schema to use the STRUCTURED-DATA property > presented in the current eventput-extensions draft. Then, an > Informational RFC could be written about this particular use case.  Is > this still the best approach?  If so, I am going to start working on > getting something defined at schema.org and > creating the informational document. > > > > Ryan Gunter | *Twitch* |   Network Engineering| > +1.415.568.7607 > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------79125954DFFD0E6F6D1C2117 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I believe that to be the best approach.

On 2/28/20 14:43, Ryan Gunter wrote:
Hello,

I hope the group is doing well!

A few months ago I submitted a draft to add x-maint properties to icalendar attachments to indicate upcoming network maintenances.


During an IETF meeting (and through some emails as well), it was suggested to define a schema to use the STRUCTURED-DATA property presented in the current eventput-extensions draft.  Then, an Informational RFC could be written about this particular use case.  Is this still the best approach?  If so, I am going to start working on getting something defined at schema.org and creating the informational document.



Ryan Gunter  |   Twitch   |   Network Engineering   |   +1.415.568.7607

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------79125954DFFD0E6F6D1C2117-- From nobody Fri Feb 28 12:51:01 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 A73D23A1DC1 for ; Fri, 28 Feb 2020 12:50:59 -0800 (PST) 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_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=AD/70d7o; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=c4l3rGN9 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 YwsctQ7fJ44G for ; Fri, 28 Feb 2020 12:50:58 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C66B3A1DC3 for ; Fri, 28 Feb 2020 12:50:58 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 2B72321E56 for ; Fri, 28 Feb 2020 15:50:57 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 28 Feb 2020 15:50:57 -0500 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; s=fm2; bh=TCgFqlnAdJQPixt6JO8+JjklhiU fdtBUuH/SVtbwSB4=; b=AD/70d7odgj5SvG7hdzvI1ef6ms1tpBgvFVGjO1uoLj bnpLk3D0sw5BP8Zb7P0txs81mUQbl93D5OjzHyStaNQczKHv/Mjs1RVDLPgxs4t6 KnS9BfQ65fCerWvVbvwlc5chXhaTgJCPE078vXNbOFreHkXSFtZKL8OdSrI21myb 02aEcA5L1qGwkQCiUTRlg2RVoZyoOy1E4tryKz1yT6Ruefre2Rx87hfsM8v7AQtf v1Fz+pWkszv+naOSMjRVcvHD3L/pOZ4hen7v03R/EPO4rNFxxxGKqbmUVyZpKd1H RYSTuhp9KyOLoJ0d19hhsfZkh1w/LuQXIdtb2POL0xg== 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=TCgFql nAdJQPixt6JO8+JjklhiUfdtBUuH/SVtbwSB4=; b=c4l3rGN9jMLBA7Vk9QbsiT o4hw/84WCRijCStGjjaG7ZAhXWwhbyMDiClotrnH5mIb1g/k9hBeMtyLDkCmJo3c 5tsAd2nuOe5ffZD1kwtYFb0Ktchs5l1MEmQcrkhwb4lpNv3AePR19/oELZOpPAyk OCcDF01Fv7uKgm2Ntt/lVIgBoQkQXghCIodw60SIWoPPIaraJJ+HS/1HPFRE1hPI EENBkW2mRwNXRL/82yRwlm0PZ+ZqvISdtbkkC0fr+kfdyQOuGugdVVsGqxqFPUo1 Zr4d32DgrggK9tG4KfEhQIaYqnHF7qPXPjKP7VifkCdX6QQC1rXeDU2JnKK/qPdA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrleekgddugeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhfhokffffgggjggtsegrtd erredtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgr shhtmhgrihhlrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgpdhstghhvghmrg drohhrghdpthifihhttghhrdhtvhenucfkphepjeegrdejjedrkeehrddvhedtnecuvehl uhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfh grshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 9FDBE3061203 for ; Fri, 28 Feb 2020 15:50:56 -0500 (EST) To: calsify@ietf.org References: <3e70f4a7-2247-b6c4-fbd7-9e1bc4e1f91d@gmail.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <6cc0d0c0-9389-9c1e-c263-87f7376fe864@fastmail.com> Date: Fri, 28 Feb 2020 15:50:56 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <3e70f4a7-2247-b6c4-fbd7-9e1bc4e1f91d@gmail.com> Content-Type: multipart/alternative; boundary="------------35243DA8E2A99235472D8311" Content-Language: en-US Archived-At: Subject: Re: [calsify] Informational RFC Question - Maintenance Notifications 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, 28 Feb 2020 20:51:00 -0000 This is a multi-part message in MIME format. --------------35243DA8E2A99235472D8311 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Agreed. On 2/28/20 3:23 PM, Michael Douglass wrote: > > I believe that to be the best approach. > > On 2/28/20 14:43, Ryan Gunter wrote: >> Hello, >> >> I hope the group is doing well! >> >> A few months ago I submitted a draft to add x-maint properties to >> icalendar attachments to indicate upcoming network maintenances. >> >> https://datatracker.ietf.org/doc/html/draft-gunter-calext-maintenance-notifications >> >> During an IETF meeting (and through some emails as well), it was >> suggested to define a schema to use the STRUCTURED-DATA property >> presented in the current eventput-extensions draft.  Then, an >> Informational RFC could be written about this particular use case.  >> Is this still the best approach?  If so, I am going to start working >> on getting something defined at schema.org and >> creating the informational document. >> >> >> >> Ryan Gunter | *Twitch* |   Network >> Engineering| +1.415.568.7607 >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Ken Murchison Cyrus Development Team Fastmail US LLC --------------35243DA8E2A99235472D8311 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Agreed.


On 2/28/20 3:23 PM, Michael Douglass wrote:

I believe that to be the best approach.

On 2/28/20 14:43, Ryan Gunter wrote:
Hello,

I hope the group is doing well!

A few months ago I submitted a draft to add x-maint properties to icalendar attachments to indicate upcoming network maintenances.


During an IETF meeting (and through some emails as well), it was suggested to define a schema to use the STRUCTURED-DATA property presented in the current eventput-extensions draft.  Then, an Informational RFC could be written about this particular use case.  Is this still the best approach?  If so, I am going to start working on getting something defined at schema.org and creating the informational document.



Ryan Gunter  |   Twitch   |   Network Engineering   |   +1.415.568.7607

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


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

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC
--------------35243DA8E2A99235472D8311--