From nobody Thu Dec 3 03:25: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 983793A046A for ; Thu, 3 Dec 2020 03:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=isEe77T6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UQ9q4cuH 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 eLnYHr4k8OJN for ; Thu, 3 Dec 2020 03:25:40 -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 4CC463A045E for ; Thu, 3 Dec 2020 03:25:40 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 57844D72; Thu, 3 Dec 2020 06:25:39 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Thu, 03 Dec 2020 06:25:39 -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=fm1; bh=26+E 5qyqdExcR2uhu5mFGbsf+sHdbaYlEcrdl5mW78c=; b=isEe77T6mmZxidGjxXZy hGHkAU8pAIcqAKdRODu11PxpYNBfAnmuylJyfWlx4avF09e/tBjQBM/EfwGd4ep0 /zVXgp/aDcPNm5/jUOIl3ACIax/1Xd5TbZvFZUeE7Kbeo7A627od3VfzrlbDmdXC TiAVJL700dUIOD9DNbTxc52NhakoPKV9luT4h+1BU9j1/NFQ3hf1YvTJeug991y3 XTRuVh5Fm+wCtoaVaCFQbVrC+O6TJPlVbah4E/uQUv5n4OJV4HAt5Hit45vAH5GI OApNIDVZt3P7LoBJ7xIWvg1SQpIMqKIZB1eupg4hIJnP7CAZNpDHft7P/qrUEM8j 6g== 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=fm1; bh=26+E5q yqdExcR2uhu5mFGbsf+sHdbaYlEcrdl5mW78c=; b=UQ9q4cuHMP2k/AxqE5kpn4 Z8lL6sJbWif7Y6OhQVthLQXx83NoJGQd9RKjx9MYMXEQQNbaoXtPBYLNMhEmBsoM Rs+B/iA+drLupBNu8nzE2+LCvSrrkdPsUwDdx55snLkz9k9LiGvR7N/9HQbqJIeC PEIoURFkdZ8zU3zcHKqxU3HajTi/zzhZCPOUpI1Jm+21FOc8etmDfjbCp6trjY/h AqUne3K0nbSUmNvEEeYSpVVbuuh06M0T6Ne8ymisJZy6XlMswcIkT2yhaspSv5Rk oBiYBqe4cmuTv5LkfbPTRQUXNiCh368NgCoIcxdYsTvLj8fKt8OWvMJPkrMQ/awQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeiiedgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepjeduieeggedvueduveduueduhefhgfefkefgffeugeev tefhfeevheduiefhhfehnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrd horhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep sghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 50009180093; Thu, 3 Dec 2020 06:25:38 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <1e3bd9bc-1326-4384-a624-6a629d5c9393@dogfood.fastmail.com> In-Reply-To: References: Date: Thu, 03 Dec 2020 22:25:18 +1100 From: "Bron Gondwana" To: "Shane Carr" , calsify@ietf.org Cc: "Temporal Champions" , "Richard Gibson" , "Ujjwal Sharma" Content-Type: multipart/alternative; boundary=b5eee404c1984b829550b12dda6d671e Archived-At: Subject: Re: [calsify] ECMAScript Extensions to RFC 3339 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, 03 Dec 2020 11:25:42 -0000 --b5eee404c1984b829550b12dda6d671e Content-Type: text/plain Hi all, I raised this work briefly at the last IETF in both the DISPATCH and CALEXT working groups, just to make everyone aware that it's going on, but I also made myself a note to follow up on it - so here's my follow up :) How's the work going? Are you still planning to bring it to the IETF? Do you need any help with anything in that process? Cheers, Bron. (loosely wearing my CALEXT chair hat, but also generally interested) On Wed, Sep 2, 2020, at 12:55, Shane Carr wrote: > Dear CalExt experts, > > My name is Shane and I am helping push the ECMAScript Temporal proposal, bringing new date/time types to JavaScript. It's our version of Joda Time. > > I would like your feedback on the following extensions that we are proposing to the ISO-8601 / RFC 3339 strings outputted by Temporal. > > https://github.com/tc39/proposal-temporal/blob/main/docs/iso-string-ext.md > > Of particular interest is our proposed representation of dates in non-Gregorian calendar systems. > > I would appreciate it if you could send feedback! > > Thanks, > Shane > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --b5eee404c1984b829550b12dda6d671e Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi all,

I raised this work briefly at the l= ast IETF in both the DISPATCH and CALEXT working groups, just to make ev= eryone aware that it's going on, but I also made myself a note to follow= up on it - so here's my follow up :)

How's the work goin= g?   Are you still planning to bring it to the IETF?  Do = you need any help with anything in that process?

Cheers,<= br>

Bron.

(loosely wearing my CALEXT chair hat= , but also generally interested)

On Wed, Sep 2, 2020, at 12:55, Shane Carr wrote:
<= /div>
Dear CalExt experts,

My name is Shane and= I am helping push the ECMAScript Temporal proposal, bringing new date/t= ime types to JavaScript.  It's our version of Joda Time.
<= div>
I would like your feedback on the following extension= s that we are proposing to the ISO-8601 / RFC 3339 strings outputted by = Temporal.


Of particular interest is our proposed representation = of dates in non-Gregorian calendar systems.

I would appreciate it if you could send feedback!

Thanks,
Shane

_= ______________________________________________
calsify mai= ling list


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


--b5eee404c1984b829550b12dda6d671e-- From nobody Thu Dec 3 03:34:46 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 5C5033A0657 for ; Thu, 3 Dec 2020 03:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ribose.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 te1zrmkZ2L_L for ; Thu, 3 Dec 2020 03:34:43 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-eopbgr1300058.outbound.protection.outlook.com [40.107.130.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98223A064B for ; Thu, 3 Dec 2020 03:34:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cs2m6YimyrCkyp0gCYZrN9NdLyxRCCYVKvHfQYiBm5vCcPC1YoCEoQUzDS6sTV1HRH47MOluvDjMZgIMTcrx7fRAdI/7wwxlkWSMpv5Bo+rUaTTQolhAtIs7qKNbM+xouPjmRcHBgBKFOsAf1p9wlZb2XKBcJuaM7l38oX7yAg4ZEYkN/YlfjQvuZj/EYrLZhMW4mr9Z2kFIqGfV04vwvtn6Uh6hGatQCyg4Nv1jTzcCcF4JrA72qWzH9h3ukJQCwAkbzEoOVh55pzsaepo9D77ITfKSbfpw+TXuMJTf/Kqywpa08alPCvi/3FVDQ1d62gsszvLUlIUIGhT4SQLgDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1rh2v17RfNdMQ5IvKlNZ8ALw98h316ZO0WooMnsIrgc=; b=mt1v3fn1zUfCqOHeAlYZeVVUoYVWNxCRENt4fHGO43sGjRwC7MYbijFS06PK+P3YWREQpxob8GLv3sB6hk9IjcA4x2rXafLF4MtCWPOxVg1IGWXjneiPH+HDPnQzDAicMTk+G832PxGmJBvxGbQIJuXXUj+OJ+8/XCjfzR0vbTYiOlu6dbmLD3z8VEf6mxfkRR9p8W91VEu+g/Rfo+oLzrqlQALsO3OHx4zIdjr+iaLx6onrgAz3bX/CvhUWInHnUJWnApaahsjLrOMYLbkpzrJHP332t+fS5GaWOJOwUtBwkVWLk87wKpIe8eTAsIuctbamd2ilkO9BtH5LlmVvqw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ribose.com; dmarc=pass action=none header.from=ribose.com; dkim=pass header.d=ribose.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ribose.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1rh2v17RfNdMQ5IvKlNZ8ALw98h316ZO0WooMnsIrgc=; b=c/zMrixc6iSvmErPh0UeZfdcGpH4XFYPItFfiiAnqLWxJYcjLZ4o98sGmo1QdcqoKbJ5LlazyR/b1XIpC6QOk2pRNmv4xg78TFgnKDasrhUp81q1b0g6OI+frc/45dC1HRsiZWwrV96qT4chWFQm39FXyP4q1u2OOlvuFONik0g= Received: from HK0PR01MB2900.apcprd01.prod.exchangelabs.com (2603:1096:203:98::14) by HK2PR01MB3331.apcprd01.prod.exchangelabs.com (2603:1096:202:20::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.25; Thu, 3 Dec 2020 11:34:33 +0000 Received: from HK0PR01MB2900.apcprd01.prod.exchangelabs.com ([fe80::d5ed:114b:15c:3c2d]) by HK0PR01MB2900.apcprd01.prod.exchangelabs.com ([fe80::d5ed:114b:15c:3c2d%4]) with mapi id 15.20.3632.017; Thu, 3 Dec 2020 11:34:32 +0000 From: Ronald Tse To: Bron Gondwana CC: Shane Carr , "calsify@ietf.org" , Temporal Champions , Richard Gibson Thread-Topic: [calsify] ECMAScript Extensions to RFC 3339 Thread-Index: AQHWgNUlhypD0a2rH0ecIbxQ68RSYqnlzEoAgAACk4A= Date: Thu, 3 Dec 2020 11:34:32 +0000 Message-ID: <4B877C35-9687-4155-93F2-2EE8549D4AEF@ribose.com> References: <1e3bd9bc-1326-4384-a624-6a629d5c9393@dogfood.fastmail.com> In-Reply-To: <1e3bd9bc-1326-4384-a624-6a629d5c9393@dogfood.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.4) authentication-results: fastmailteam.com; dkim=none (message not signed) header.d=none;fastmailteam.com; dmarc=none action=none header.from=ribose.com; x-originating-ip: [58.153.245.161] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7cdac70e-f100-42a5-a57d-08d8977f679c x-ms-traffictypediagnostic: HK2PR01MB3331: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EmKRUdWbkWLyJHo2yhUfBqV2Y+DF6QSvCNhlFv1FaKpEODR3ydPNq0IunHI164m3Aw7blFz3kxisIBZPNiCLb1NzGbL01gjc1l/cLQv4zKKyKWej08Yo4H400+jDRiInmjJ+rQGIRjAdVRWgm4RZ7Doun4C/oiM6tOq3cUwsPOH03ExRicEhhnCRD9soNe5kEbuTsVqpHD5wvSrNz2kukRhULlRc5Ro8lLcsd7TGGtjk2xWqG8aE15ymwCY69LOms8zpxHcQo4Mrm/ESw+84ozPhI5LnoFw3f1H08uOLNVHfEnO9L5h/gUNRKO7gD5AbZBzufh99XaPzUUCssY6DqwKOG42cVtUOsgSyLqZlwCJZyyYlX0uqJXByu5Y3u4apOXx8Kte8xA+5Sco5g5p3Sg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HK0PR01MB2900.apcprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(366004)(376002)(136003)(396003)(39830400003)(346002)(33656002)(66476007)(64756008)(76116006)(316002)(91956017)(6486002)(5660300002)(66556008)(4326008)(54906003)(66946007)(66446008)(6512007)(26005)(2616005)(478600001)(966005)(36756003)(166002)(53546011)(71200400001)(8936002)(6506007)(86362001)(83380400001)(8676002)(6916009)(2906002)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?RyHHVxQGmzAgns6tZxHHhK3g1z/qRi5aTWBNqU4RsHl0WsKlRVhuEAxVBTCC?= =?us-ascii?Q?ezDTgXN/hmOA9bA+a0c+X8gbak2mdxR7axSJd5XR3WGZZOEx0iSep85Iofe9?= =?us-ascii?Q?qLburYNDh7X2T5Se4LsRx8IbgBuaSPNeDAVFKg3ABVrGRaL5AAdcfL9gIQfK?= =?us-ascii?Q?D6/jyVId3g3RYp+Tu4BVM2390DpyM7DlTaGa3u5LE796ClQHz12uq0H1M/cU?= =?us-ascii?Q?E1qUh+V3pa81POUybpRU2FmuNGF6YnIQL7ztelR2m9yXjiomU7fTmuWrpMNG?= =?us-ascii?Q?pZzqlUGoEU9dKOuce3oHL5xqa+Q136gf3iN0VMSYKR8vg6kXcaQSAZ4piVHi?= =?us-ascii?Q?toQx4XC+bQfU+rWmseOOr3Co6VonPHWMUO/GRn4685+PVAbSJGqgDwd2dXbi?= =?us-ascii?Q?W7w3Azr6h/yisDPryOZ/WZnnzeHq1kdP3u6eVcRlKzuNOinVuidN1yaHVesn?= =?us-ascii?Q?xxloZNrgb61SEYyHKOrvt74yvnhBFW/V7OB6HsMYu0I2uS/kimvnJ86X/d+e?= =?us-ascii?Q?Ro9PGe88te1VGOMRdF8arZvZG59YfjG+/xXGE7MTgMaoxbmG5Rx8oF96XKkq?= =?us-ascii?Q?Y08xnS+alBomYgRzTXzLFTuPBopXA3t1juFsYMHu+nw7pg6ARuFdSzHRhQrd?= =?us-ascii?Q?Yhg8r/0UgCJ5oMbZnM38iVb3Y8pEZK97WL1zPQR1SkfoC7QniIkqSz2N06KW?= =?us-ascii?Q?Z3xm4wfj5R8ebyPpzMDu76Fidk7muOHcr+mtmQy0edGop/Nf7fxGBW3+H/Q4?= =?us-ascii?Q?XLBkUToEtecGMmbgQMLEwFYq2KRfwUlvaBvosDWZ8Ir+WILR/kDJ8orJ43xO?= =?us-ascii?Q?f7B3TY0y/f4q5ufJVnbXUaWpiPAE1wiYxfzgL+3h4i8DRg82YNjZPUHEdAgD?= =?us-ascii?Q?LRP+po7wQssyFOblraD3ZL2kOUS2ITy4a/4f6bab7poHB2XehIeOfwojXNed?= =?us-ascii?Q?NtDqLsHwsfFmDfqNEkkAdSDlCWXDdqXbI4tSV4I693BJS2pr62uZ+A6dNqTQ?= =?us-ascii?Q?WR+7?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_4B877C359687415593F22EE8549D4AEFribosecom_" MIME-Version: 1.0 X-OriginatorOrg: ribose.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HK0PR01MB2900.apcprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7cdac70e-f100-42a5-a57d-08d8977f679c X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2020 11:34:32.6505 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: krejeP+C+q/BOsdJHpE3nLI4+d/9isVNnzxQB+xfpo65USEP9+Wx0NEgSM5ZxZxw X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2PR01MB3331 Archived-At: Subject: Re: [calsify] ECMAScript Extensions to RFC 3339 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, 03 Dec 2020 11:34:45 -0000 --_000_4B877C359687415593F22EE8549D4AEFribosecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bron, Ujjwal has already taken the initiative to start a new draft for RFC 3339. The draft is at https://github.com/ryzokuken/draft-ryzokuken-datetime-exten= ded/ Kind regards, Ron _____________________________________ Ronald Tse Ribose Inc. +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ On Dec 3, 2020, at 7:25 PM, Bron Gondwana > wrote: Hi all, I raised this work briefly at the last IETF in both the DISPATCH and CALEXT= working groups, just to make everyone aware that it's going on, but I also= made myself a note to follow up on it - so here's my follow up :) How's the work going? Are you still planning to bring it to the IETF? Do= you need any help with anything in that process? Cheers, Bron. (loosely wearing my CALEXT chair hat, but also generally interested) On Wed, Sep 2, 2020, at 12:55, Shane Carr wrote: Dear CalExt experts, My name is Shane and I am helping push the ECMAScript Temporal proposal, br= inging new date/time types to JavaScript. It's our version of Joda Time. I would like your feedback on the following extensions that we are proposin= g to the ISO-8601 / RFC 3339 strings outputted by Temporal. https://github.com/tc39/proposal-temporal/blob/main/docs/iso-string-ext.md Of particular interest is our proposed representation of dates in non-Grego= rian calendar systems. I would appreciate it if you could send feedback! Thanks, Shane _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify --_000_4B877C359687415593F22EE8549D4AEFribosecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8CF50EB4C9F5164EAE2C01F119F35C22@apcprd01.prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable Hi Bron,

Ujjwal has already taken the initiative to start a new draf= t for RFC 3339.

The draft is at https://github.com/ryzokuk= en/draft-ryzokuken-datetime-extended/

Kind regards,
Ron

_____________________________________

Ronald Tse
Ribose Inc.

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+
This message may contain confidential and/or privileged
information.  If you are not the addressee or authorized to
receive this for the addressee, you must not use, copy,
disclose or take any action based on this message or any
information herein.  If you have received this message in
error, please advise the sender immediately by reply e-mail
and delete this message.  Thank you for your cooperation.
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+

On Dec 3, 2020, at 7:25 PM, Bron Gondwana <brong@fastmailteam.com> wrot= e:

Hi all,

I raised this work briefly at the last IETF in both the DISPATCH and CALEXT= working groups, just to make everyone aware that it's going on, but I also= made myself a note to follow up on it - so here's my follow up :)

How's the work going?   Are you still planning to bring it to the= IETF?  Do you need any help with anything in that process?

Cheers,

Bron.

(loosely wearing my CALEXT chair hat, but also generally interested)

On Wed, Sep 2, 2020, at 12:55, Shane Carr wrote:
Dear CalExt experts,

My name is Shane and I am helping push the ECMAScript Tempo= ral proposal, bringing new date/time types to JavaScript.  It's our ve= rsion of Joda Time.

I would like your feedback on the following extensions that= we are proposing to the ISO-8601 / RFC 3339 strings outputted by Temporal.=

https://github.com/tc39/proposal-tem= poral/blob/main/docs/iso-string-ext.md

Of particular interest is our proposed representation of da= tes in non-Gregorian calendar systems.

I would appreciate it if you could send feedback!

Thanks,
Shane

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


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


_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify<= /a>

--_000_4B877C359687415593F22EE8549D4AEFribosecom_-- From nobody Thu Dec 3 03:46:34 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F7A3A067A for ; Thu, 3 Dec 2020 03:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=QzhvJRNU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d6YTMYyd 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 99-JKQVFhwg0 for ; Thu, 3 Dec 2020 03:46:30 -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 C8A203A064B for ; Thu, 3 Dec 2020 03:46:30 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 10B1E5C0074; Thu, 3 Dec 2020 06:46:30 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Thu, 03 Dec 2020 06:46:30 -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=fm1; bh=xKdn eVOiC69tz3/mLuG1Up/C8nKZ9/W8+DzSPGyBFiA=; b=QzhvJRNUOtbeMFnETrsn 2ZNVUpj9NlZuAqkgdygPhsxMED7blcpCpitFDXp6MVxOW3jPnhwgpLcjWWSaWkT8 LrrSe+D95MJ5r3EEbjfdfoFDpYPGKhSfLJ5/aCSWsoY111fugMuwfx3vyARY0NRU G58vAIm/xoN+RaFGZvL0EuABHQl2AasOIjXKSc6jDOYHmUeFM/Kon/uTEfqdkeIm Qg8wJuCFVIHGScoEqjL1/iBhXfSORaC3Gb8fQ9lfPlMR2/0hFVHjbLWoQ2c/T3E1 vVRyHcwBWjRyVUIen4qKmev/cDQLlIvwW2P9mCfvhO3JBdW2wc2dHANXoG8DTHKx vQ== 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=fm1; bh=xKdneV OiC69tz3/mLuG1Up/C8nKZ9/W8+DzSPGyBFiA=; b=d6YTMYydeF0gZTGHjPaexe G1FiJv+9XKOrN9MnH4t76mIef+HHzu/qVheSd26ITI6zOgUX69/KiY6ZrJiq6s+a rO4yKXu1O82GVZAb4f46Whth9V5GmiahqVqQZRDnu5ZzdAtsHFuyi4IMMPSBrpYL UIefjyYJnS56BsyyLn1i2mNSvILQrBSBarAet+A5FVtsUGmb9i1fXHWJFdyaPYp4 eaP6pQP8uxevfNKse/5BSdMvpykUj3TABBaTuw8sEJyrexpF+bVVbJPSynrQUAFT sLy26B+D4Tiiogx66ezJC5q903ok1odIfKEWI13kBs3HcN3hz0GlRsDf9nebl/Qw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeiiedgfeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnhepjeduieeggedvueduveduueduhefhgfefkefgffeugeev tefhfeevheduiefhhfehnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrd horhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhep sghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7B450180093; Thu, 3 Dec 2020 06:46:29 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: In-Reply-To: <4B877C35-9687-4155-93F2-2EE8549D4AEF@ribose.com> References: <1e3bd9bc-1326-4384-a624-6a629d5c9393@dogfood.fastmail.com> <4B877C35-9687-4155-93F2-2EE8549D4AEF@ribose.com> Date: Thu, 03 Dec 2020 22:46:08 +1100 From: "Bron Gondwana" To: "Ronald Tse" Cc: "Shane Carr" , "calsify@ietf.org" , "Temporal Champions" , "Richard Gibson" Content-Type: multipart/alternative; boundary=c4a3430fd09e42cf9f88e8eb73a454a6 Archived-At: Subject: Re: [calsify] ECMAScript Extensions to RFC 3339 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, 03 Dec 2020 11:46:33 -0000 --c4a3430fd09e42cf9f88e8eb73a454a6 Content-Type: text/plain Ahh excellent. Thanks Ronald. RFCs don't work quite the same was as ISO numbers (you don't get to use the old number again, it would be a new RFC number which replaces the old one, so 3339 will only be mentioned in the metadata) - and if it's going to be published at the IETF we'll need to find the right venue for the work to happen. Hence my question about the publishing plans. Cheers, Bron. On Thu, Dec 3, 2020, at 22:34, Ronald Tse wrote: > Hi Bron, > > Ujjwal has already taken the initiative to start a new draft for RFC 3339. > > The draft is at https://github.com/ryzokuken/draft-ryzokuken-datetime-extended/ > > Kind regards, > Ron > > _____________________________________ > > Ronald Tse > Ribose Inc. > > +=========================================================+ > This message may contain confidential and/or privileged > information. If you are not the addressee or authorized to > receive this for the addressee, you must not use, copy, > disclose or take any action based on this message or any > information herein. If you have received this message in > error, please advise the sender immediately by reply e-mail > and delete this message. Thank you for your cooperation. > +=========================================================+ > >> On Dec 3, 2020, at 7:25 PM, Bron Gondwana wrote: >> >> Hi all, >> >> I raised this work briefly at the last IETF in both the DISPATCH and CALEXT working groups, just to make everyone aware that it's going on, but I also made myself a note to follow up on it - so here's my follow up :) >> >> How's the work going? Are you still planning to bring it to the IETF? Do you need any help with anything in that process? >> >> Cheers, >> >> Bron. >> >> (loosely wearing my CALEXT chair hat, but also generally interested) >> >> On Wed, Sep 2, 2020, at 12:55, Shane Carr wrote: >>> Dear CalExt experts, >>> >>> My name is Shane and I am helping push the ECMAScript Temporal proposal, bringing new date/time types to JavaScript. It's our version of Joda Time. >>> >>> I would like your feedback on the following extensions that we are proposing to the ISO-8601 / RFC 3339 strings outputted by Temporal. >>> >>> https://github.com/tc39/proposal-temporal/blob/main/docs/iso-string-ext.md >>> >>> Of particular interest is our proposed representation of dates in non-Gregorian calendar systems. >>> >>> I would appreciate it if you could send feedback! >>> >>> Thanks, >>> Shane >>> >>> _______________________________________________ >>> calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify >>> >> >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --c4a3430fd09e42cf9f88e8eb73a454a6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Ahh excellent.  Thanks Ronald.

RFCs do= n't work quite the same was as ISO numbers (you don't get to use the old= number again, it would be a new RFC number which replaces the old one, = so 3339 will only be mentioned in the metadata) - and if it's going to b= e published at the IETF we'll need to find the right venue for the work = to happen.  Hence my question about the publishing plans.
=

Cheers,
Kind regards,
Ron

_____________________________________

=
Ronald Tse
Ribose Inc.

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
This message may co= ntain confidential and/or privileged
information.  I= f you are not the addressee or authorized to
receive this= for the addressee, you must not use, copy,
disclose or t= ake any action based on this message or any
information h= erein.  If you have received this message in
error, = please advise the sender immediately by reply e-mail
and = delete this message.  Thank you for your cooperation.
+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

On Dec 3, 20= 20, at 7:25 PM, Bron Gondwana <brong@fastmailteam.com> wrote:
Hi all,

I raised thi= s work briefly at the last IETF in both the DISPATCH and CALEXT working = groups, just to make everyone aware that it's going on, but I also made = myself a note to follow up on it - so here's my follow up :)

How's the wo= rk going?   Are you still planning to bring it to the IETF?&nb= sp; Do you need any help with anything in that process?

Cheers,
=

Bron.
<= /div>

(loos= ely wearing my CALEXT chair hat, but also generally interested)

On We= d, Sep 2, 2020, at 12:55, Shane Carr wrote:
=
Dear CalExt experts,

My name is Shane= and I am helping push the ECMAScript Temporal proposal, bringing new da= te/time types to JavaScript.  It's our version of Joda Time.

I would like your fee= dback on the following extensions that we are proposing to the ISO-8601 = / RFC 3339 strings outputted by Temporal.
https://github.c= om/tc39/proposal-temporal/blob/main/docs/iso-string-ext.md
=

Of particular interest i= s our proposed representation of dates in non-Gregorian calendar systems= .

I would appre= ciate it if you could send feedback!

Thanks,
Shane

_________________= ______________________________
calsify maili= ng list
calsify@ietf.org
https://ww= w.ietf.org/mailman/listinfo/calsify

=

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


_______________________= ________________________
calsify mailing list

<= div class=3D"signature">--
  Bron= Gondwana, CEO, Fastmail Pty Ltd
 = ; brong@fastmailteam.com


--c4a3430fd09e42cf9f88e8eb73a454a6-- From nobody Thu Dec 3 04:12: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 48CE13A083B for ; Thu, 3 Dec 2020 04:12:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=igalia.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 SyM_ZuH2SrHN for ; Thu, 3 Dec 2020 04:12:27 -0800 (PST) Received: from fanzine.igalia.com (fanzine.igalia.com [178.60.130.6]) (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 031133A0836 for ; Thu, 3 Dec 2020 04:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=xR/Awim0ZhFavyNuCUx/S12FBnEUS1f5SX/tJaXhJ64=; b=UCeoW7oxdjqmAYizFnj3UQ5d+6R+uCJqrhtRT0/Q8nU6h2rHqJo8RdOR90BO7j/l526j11I6WQLFAMFAx3LOGL7Q8ItYvbY+Dx3KzeyWSPXU90E5njuxp4qQoCgIPxQe9Xejwis3FBGTgcYbGsBo4pRsOdOqAne/ze+zJqdVFOT2ecvfKvx7n5Ov+p8rG5Kq+kETHZ/NsvUTyywG5lNgZMbx6YOHp2EqgG3Es6j8n7dhEq8ylEoPfb6veLx3oAUm+VvuZ+OKdGm5scvuZPYQVLfaBzH/gk5yAKEtlAFr8lj0zNCyAWyD5BV0zOjudnJDkV5zIxfb2DN8stAB9a3WGQ==; Received: from [183.83.214.112] (helo=[192.168.0.190]) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1kknT9-0001Fe-NK for ; Thu, 03 Dec 2020 13:12:19 +0100 To: calsify@ietf.org References: <1e3bd9bc-1326-4384-a624-6a629d5c9393@dogfood.fastmail.com> <4B877C35-9687-4155-93F2-2EE8549D4AEF@ribose.com> From: Ujjwal Sharma Message-ID: <0541684e-483a-c393-dbff-5eb4f0f28f97@igalia.com> Date: Thu, 3 Dec 2020 17:42:04 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] ECMAScript Extensions to RFC 3339 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, 03 Dec 2020 12:12:30 -0000 Hi Bron! Thanks Ron! As Ron mentioned, I've started hacking on a draft in that GitHub repository, and plan to make significant progress on it in the coming weeks. I've made it an I-D that obsoletes 3339, but the README was copied over from the 3339 template and needs to be changed. I'll clean up the GitHub repo, continue making updates and hopefully publish a version on datatracker soon. That said, I'm still not too familiar with the process so please feel free to let me know if I'm missing a step. Thanks, Ujjwal On 12/3/20 5:16 PM, Bron Gondwana wrote: > Ahh excellent.  Thanks Ronald. > > RFCs don't work quite the same was as ISO numbers (you don't get to use > the old number again, it would be a new RFC number which replaces the > old one, so 3339 will only be mentioned in the metadata) - and if it's > going to be published at the IETF we'll need to find the right venue for > the work to happen.  Hence my question about the publishing plans. > > Cheers, > > Bron. > > On Thu, Dec 3, 2020, at 22:34, Ronald Tse wrote: >> Hi Bron, >> >> Ujjwal has already taken the initiative to start a new draft for RFC 3339. >> >> The draft is >> at https://github.com/ryzokuken/draft-ryzokuken-datetime-extended/ >> >> >> Kind regards, >> Ron >> >> _____________________________________ >> >> Ronald Tse >> Ribose Inc. >> >> +=========================================================+ >> This message may contain confidential and/or privileged >> information.  If you are not the addressee or authorized to >> receive this for the addressee, you must not use, copy, >> disclose or take any action based on this message or any >> information herein.  If you have received this message in >> error, please advise the sender immediately by reply e-mail >> and delete this message.  Thank you for your cooperation. >> +=========================================================+ >> >>> On Dec 3, 2020, at 7:25 PM, Bron Gondwana >> > wrote: >>> >>> Hi all, >>> >>> I raised this work briefly at the last IETF in both the DISPATCH and >>> CALEXT working groups, just to make everyone aware that it's going >>> on, but I also made myself a note to follow up on it - so here's my >>> follow up :) >>> >>> How's the work going?   Are you still planning to bring it to the >>> IETF?  Do you need any help with anything in that process? >>> >>> Cheers, >>> >>> Bron. >>> >>> (loosely wearing my CALEXT chair hat, but also generally interested) >>> >>> On Wed, Sep 2, 2020, at 12:55, Shane Carr wrote: >>>> Dear CalExt experts, >>>> >>>> My name is Shane and I am helping push the ECMAScript Temporal >>>> proposal, bringing new date/time types to JavaScript.  It's our >>>> version of Joda Time. >>>> >>>> I would like your feedback on the following extensions that we are >>>> proposing to the ISO-8601 / RFC 3339 strings outputted by Temporal. >>>> >>>> https://github.com/tc39/proposal-temporal/blob/main/docs/iso-string-ext.md >>>> >>>> >>>> Of particular interest is our proposed representation of dates in >>>> non-Gregorian calendar systems. >>>> >>>> I would appreciate it if you could send feedback! >>>> >>>> Thanks, >>>> Shane >>>> >>>> _______________________________________________ >>>> calsify mailing list >>>> calsify@ietf.org >>>> https://www.ietf.org/mailman/listinfo/calsify >>>> >>>> >>> >>> -- >>>   Bron Gondwana, CEO, Fastmail Pty Ltd >>>   brong@fastmailteam.com >>> >>> >>> _______________________________________________ >>> calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify >>> > > -- >   Bron Gondwana, CEO, Fastmail Pty Ltd >   brong@fastmailteam.com > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Ujjwal "Ryzokuken" Sharma (he/him) Compilers Hacker, Node.js Core Collaborator and Speaker From nobody Thu Dec 3 13:15:58 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5253A3A0CC0; Thu, 3 Dec 2020 13:15:56 -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.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, 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 4n_frrlG518a; Thu, 3 Dec 2020 13:15:54 -0800 (PST) Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.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 4EA053A0CBB; Thu, 3 Dec 2020 13:15:51 -0800 (PST) Received: by mail-vs1-f53.google.com with SMTP id 128so2067330vsw.10; Thu, 03 Dec 2020 13:15:51 -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=qqv+4FmGnrn9TBSIEBTmDafOXNn/Etpi2ZKLMCB4Sbg=; b=NjGOVBx8YbbyAaKWWhx13q8R0rAcCLv4kSR3dl9mRc+cEVB6OJjP50IM4uDRwj89FI sh/Nlv5aUv3s6hI7NTU2FpliKmNy1Uh9/oxjnPSUdF12y/7Om/cyqj6sggmiKfEDMJQ3 Plg+x1BwHmJmCoVVU8VFMLJzyZYd+BpYROkrSgxHFzhWYc4TY6f9HUKIEiHjDX3MMP2l OZlIvscGiu2zKrfQ/1wll1DIkl+ufOsK46IrckMKS55UAdfYMeOt69oMjk+Jlbt3alPW ai+T78z6HezpJhs6RS6OhQW5tqvDbnoHrAxKTmhMJCc06/Fc0AHl3ObXspLL02w50wU/ SeoA== X-Gm-Message-State: AOAM532L8PfTOv2lmCTIpdjPk1US/qp1KaWp4CPwTd3i2VysDqufuucU LAaNQeoZmpCs4Q/XV8Z2usju9YRd/0OiNk3t+TJPw4uoqkcD6w== X-Google-Smtp-Source: ABdhPJxEAGvnh4zi8pdEkLOyIdwUHZktcBzganKKkzEaTUMwTyAd8mAL678g0jMgqIrlON8G/QdLKzevl2fkCU3+ELs= X-Received: by 2002:a67:f7c4:: with SMTP id a4mr1381955vsp.14.1607030149818; Thu, 03 Dec 2020 13:15:49 -0800 (PST) MIME-Version: 1.0 From: Barry Leiba Date: Thu, 3 Dec 2020 16:15:38 -0500 Message-ID: To: draft-ietf-calext-valarm-extensions.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-valarm-extensions-03 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, 03 Dec 2020 21:15:56 -0000 Most of my comments are minor, but there are a couple of things to discuss (particularly how to handle the ABNF). I'm going to put this in "revised I-D needed", but let's talk about the things that need discussion before submitting a revision for the others. =E2=80=94 Section 2 =E2=80=94 There=E2=80=99s no need for the =E2=80=9C[1]=E2=80=9D citation, and it only= messes up idnits. Please remove it and the =E2=80=9CURLs=E2=80=9D section at the end. =E2=80=94 Section 3 =E2=80=94 My biggest issue here is with the ABNF, so let=E2=80=99s please have a discussion about it. First, some minor things: 1. This is probably a good time to pay attention to BCP 178 (RFC 6648) by removing the x-prop construction (and x-name elsewhere in the draft). 2. Why is there a need to define new constructs (=E2=80=9Calarmcext=E2=80= =9D, =E2=80=9Caudiopropext=E2=80=9D, and so on), rather than just re-defining th= e base ones (=E2=80=9Calarmc=E2=80=9D, =E2=80=9Caudioprop=E2=80=9D, =E2=80=A6)? It see= ms to me that this just confuses things, and the point here is to make changes that are compatible, but more readily extensible. Now, the big one: 3. I have never liked the way iCalendar did its ABNF, to the point where I think it=E2=80=99s wrong and harmful, causing confusion and not permitting automated processing of the ABNF. It relies on normative comments where that=E2=80=99s not necessary, and ABNF was never intended to= be usef that way. Comments are meant to be explanatory, and normative comments are meant to be used only as a last resort, when you can=E2=80=99t express what you need in the formal language. I would much rather limit the comments to a statment that elements can appear in any order, and then use the ABNF to convey whether the elements are required and how many times they can appear. Taking =E2=80=9Calarmprop=E2=80=9D as an example, here=E2=80=99s a re-write= of it in the way ABNF should be representing it: OLD alarmprop =3D *( ; the following are REQUIRED, ; but MUST NOT occur more than once action / trigger / ; one set of action properties MUST be ; present and MUST match the action specified ; in the ACTION property actionprops / ; the following is OPTIONAL, ; and MAY occur more than once x-prop / iana-prop ) NEW alarmprop =3D ; the elements herein may appear in any order, ; and the order is not significant. action trigger actionprops ; MUST match the action specified ; in the ACTION property [*iana-prop] END For =E2=80=9Caudiopropext=E2=80=9D: OLD audiopropext =3D *( ; 'duration' and 'repeat' are both OPTIONAL, ; and MUST NOT occur more than once each, ; but if one occurs, so MUST the other duration / repeat / ; the following is OPTIONAL, ; but MUST NOT occur more than once attach ) NEW audiopropext =3D ; the elements herein may appear in any order, ; and the order is not significant. [duration repeat] [attach] ) END Is there really a good reason not to move in this direction? The mechanism of saying that everything can appear zero or more times, and then limiting that with comments seems very poor. =E2=80=94 Section 6.1 =E2=80=94 Certain kinds of alarm may not provide feedback as to when the calendar user sees them, for example email based alerts. Nit: This sentence isn=E2=80=99t properly ordered (and has a couple of othe= r nit-level errors). NEW Certain kinds of alarms, such as email-based alerts, might not provide feedback as to when the calendar user sees them. END =E2=80=94 Section 7 =E2=80=94 Clients SHOULD add a "RELATED-TO" property to the new "VALARM" component with a value set to the "UID" property value of the "VALARM" component being snoozed. If the "VALARM" component being snoozed does not already have a "UID" property, the client SHOULD add one. The "RELATED-TO" property added to the new "VALARM" component SHOULD include a "RELTYPE" property parameter with a value set to "SNOOZE". Why the SHOULDs? This is new function; why are these not MUSTs? When the "snooze" alarm is triggered and dismissed the client SHOULD remove the corresponding "VALARM" component, or set the "ACKNOWLEDGED" property (see Section 6.1). Alternatively, if the "snooze" alarm is itself "snoozed", the client SHOULD remove the original "snooze" alarm and create a new one, with the appropriate trigger time and relationship set. Same here about the SHOULDs. Also, it=E2=80=99s not clear to me how this relates to the original alarm. It would be good to say, explicitly, that the original VALARM is not removed. But also, is the =E2=80=9CACKNOWLEDGED=E2=80=9D time on the original alarm changed to show t= he time that the snooze was dismissed? If not, why not? And is there a reason to choose between the apparently equal alternatives presented in the first sentence? Or is the choice entirely up to the implementation? =E2=80=94 Section 7.1 =E2=80=94 This specification adds the "SNOOZE" relationship type for use with the "RELTYPE" property defined in Section 3.2.15 of [RFC5545]. This is used to relate a "snoozed" "VALARM" component to the original alarm that the "snooze" was generated for. Maybe I=E2=80=99m being too picky here, but I don=E2=80=99t think the RELTY= PE of SNOOZE is used to relate the alarms: the UID property is used for that. Maybe =E2=80=9CThis is used when relating=E2=80=9D is better wording= ? =E2=80=94 Section 8.1 =E2=80=94 When the property value is set to "ARRIVE", the alarm is triggered when the calendar user agent arrives in the vicinity of any of the specified locations. When set to "DEPART", the alarm is triggered when the calendar user agent departs from the vicinity of any specified locations. I think we need to more clearly specify =E2=80=9Cvicinity=E2=80=9D here, ev= en if it=E2=80=99s just to say that the definition is up to the implementation. As it is, I don=E2=80=99t know whether I need to depart from my kitchen, from my house, from my street, from my town, or whatever. When the property value is set to "CONNECT", the alarm is triggered when the calendar user agent connects to a Bluetooth(R) [BTcore]-enabled automobile. When set to "DISCONNECT", the alarm is triggered when the calendar user agent disconnects from a Bluetooth(R)-enabled automobile. Nit: It=E2=80=99s odd to have the citation in the middle of the compound modifier. I suggest rewriting to avoid the problem: NEW When the property value is set to "CONNECT", the alarm is triggered when the calendar user agent connects to an automobile that is enabled for Bluetooth(R) [BTcore]. When set to "DISCONNECT", the alarm is triggered when the calendar user agent disconnects from a Bluetooth(R)-enabled automobile. END Example: The following is an example of this property: PROXIMITY:ARRIVE I think this example is useless, as it=E2=80=99s incomplete without the geo location. And you have Section 8.2 immediately after, so why not just remove this? =E2=80=94 Section 11 =E2=80=94 Throughout this section, please specify the names and/or URIs of the registries, to make it easier for both IANA and other readers to find them. For example, in Section 11.1: NEW This document defines the following new iCalendar properties to be added to the Properties registry defined in Section 8.2.3 of [RFC5545] and located here: END --=20 Barry From nobody Thu Dec 3 18:09:15 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24333A1208 for ; Thu, 3 Dec 2020 18:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=oRyn2Ij9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WDwUR2N7 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 tc1S616vYW4f for ; Thu, 3 Dec 2020 18:09:11 -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 312883A1207 for ; Thu, 3 Dec 2020 18:09:11 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 5553EDF9 for ; Thu, 3 Dec 2020 21:09:10 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Thu, 03 Dec 2020 21:09:10 -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=fm1; bh=tY9tMk/ s2Sjf6WOmPJv8E5tpg37wd/zRPwFepfLlIeM=; b=oRyn2Ij9EHPO/ygsygB157R ClVNSKoOHLtVnVHoG+W2V8o8LpRlffK7u5+mhUu12gbLhuha0gHVJrr0ZosMKKtS IwOoFuapyKJgAj/QHvGLMY4yk5NYGhCCyNVOh0i2KN2cEW6jlNN7fRrFE+aHUXnF HY42aPdTV9U5Toh7HUcHlmP8nJNrqAKng6SAksVHGJxdjjl9ssr2EMa0fd/0+i1p f/i6vSl51uO9Q5jq1xauQjv39Sr80kTblt2JOOYv/SHyT/Ioemh6gNHDwRm2ac24 sGDuyPGdepUUCfcksywrDb4yFD65Tdof2WiyXVcgznzWd9KhHVyXqMiYasXesCw= = 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=fm1; bh=tY9tMk /s2Sjf6WOmPJv8E5tpg37wd/zRPwFepfLlIeM=; b=WDwUR2N7WAao4XJdv+8cse ovki6F4r9s55EO7EOIFonhVxWbJ/kmqq+s36zsg5NtNYcIrJLWWKL1bbS9Jcw7E5 v3zCqRR+K9C6e8ycRYYf0ABjOWTBQQ5KdEyFlC19Brb4fxZFshju7f+SVGnAL6aW ZnOivBaA/M9WY94PbKn4/Cirrv7bdD1lOdMN+yeJ3yZoyBeBJf2Iy3gvsO1HIBLt VY9y1EBk7uuPYfgF4rCNwe5ZPZFmNGdWeWxdBjFiIQERpClFYusQPjWHkq6ao+c8 7FXX9u79tA7tQuM2hhOd4s1oVEtz34rAb0a8NwUXpJ98fiwa3BfB3c5puDPzPBZA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeijedggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeejudeigeegvd euudevudeuudehhffgfeekgfffueegveethfefveehudeihffhheenucffohhmrghinhep ghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdr tghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 94C40180093; Thu, 3 Dec 2020 21:09:08 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: In-Reply-To: <0541684e-483a-c393-dbff-5eb4f0f28f97@igalia.com> References: <1e3bd9bc-1326-4384-a624-6a629d5c9393@dogfood.fastmail.com> <4B877C35-9687-4155-93F2-2EE8549D4AEF@ribose.com> <0541684e-483a-c393-dbff-5eb4f0f28f97@igalia.com> Date: Fri, 04 Dec 2020 13:08:47 +1100 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=e3ad5ef5a63a406089e1f91afad9884c Archived-At: Subject: Re: [calsify] ECMAScript Extensions to RFC 3339 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, 04 Dec 2020 02:09:14 -0000 --e3ad5ef5a63a406089e1f91afad9884c Content-Type: text/plain Excellent, I'm glad to hear that it's coming along. That's totally fine, and it doesn't even matter if the first draft uploaded to the datatracker is riddled with metadata errors because people will be happy to help you fix those! The main thing is having a draft that I can do a call for adoption from and we can get it onto the calext agenda for March (or even ask people to look at it between meetings). Cheers, Bron. On Thu, Dec 3, 2020, at 23:12, Ujjwal Sharma wrote: > Hi Bron! Thanks Ron! > > As Ron mentioned, I've started hacking on a draft in that GitHub > repository, and plan to make significant progress on it in the coming > weeks. I've made it an I-D that obsoletes 3339, but the README was > copied over from the 3339 template and needs to be changed. > > I'll clean up the GitHub repo, continue making updates and hopefully > publish a version on datatracker soon. That said, I'm still not too > familiar with the process so please feel free to let me know if I'm > missing a step. > > Thanks, > Ujjwal > > On 12/3/20 5:16 PM, Bron Gondwana wrote: > > Ahh excellent. Thanks Ronald. > > > > RFCs don't work quite the same was as ISO numbers (you don't get to use > > the old number again, it would be a new RFC number which replaces the > > old one, so 3339 will only be mentioned in the metadata) - and if it's > > going to be published at the IETF we'll need to find the right venue for > > the work to happen. Hence my question about the publishing plans. > > > > Cheers, > > > > Bron. > > > > On Thu, Dec 3, 2020, at 22:34, Ronald Tse wrote: > >> Hi Bron, > >> > >> Ujjwal has already taken the initiative to start a new draft for RFC 3339. > >> > >> The draft is > >> at https://github.com/ryzokuken/draft-ryzokuken-datetime-extended/ > >> > >> > >> Kind regards, > >> Ron > >> > >> _____________________________________ > >> > >> Ronald Tse > >> Ribose Inc. > >> > >> +=========================================================+ > >> This message may contain confidential and/or privileged > >> information. If you are not the addressee or authorized to > >> receive this for the addressee, you must not use, copy, > >> disclose or take any action based on this message or any > >> information herein. If you have received this message in > >> error, please advise the sender immediately by reply e-mail > >> and delete this message. Thank you for your cooperation. > >> +=========================================================+ > >> > >>> On Dec 3, 2020, at 7:25 PM, Bron Gondwana >>> > wrote: > >>> > >>> Hi all, > >>> > >>> I raised this work briefly at the last IETF in both the DISPATCH and > >>> CALEXT working groups, just to make everyone aware that it's going > >>> on, but I also made myself a note to follow up on it - so here's my > >>> follow up :) > >>> > >>> How's the work going? Are you still planning to bring it to the > >>> IETF? Do you need any help with anything in that process? > >>> > >>> Cheers, > >>> > >>> Bron. > >>> > >>> (loosely wearing my CALEXT chair hat, but also generally interested) > >>> > >>> On Wed, Sep 2, 2020, at 12:55, Shane Carr wrote: > >>>> Dear CalExt experts, > >>>> > >>>> My name is Shane and I am helping push the ECMAScript Temporal > >>>> proposal, bringing new date/time types to JavaScript. It's our > >>>> version of Joda Time. > >>>> > >>>> I would like your feedback on the following extensions that we are > >>>> proposing to the ISO-8601 / RFC 3339 strings outputted by Temporal. > >>>> > >>>> https://github.com/tc39/proposal-temporal/blob/main/docs/iso-string-ext.md > >>>> > >>>> > >>>> Of particular interest is our proposed representation of dates in > >>>> non-Gregorian calendar systems. > >>>> > >>>> I would appreciate it if you could send feedback! > >>>> > >>>> Thanks, > >>>> Shane > >>>> > >>>> _______________________________________________ > >>>> calsify mailing list > >>>> calsify@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/calsify > >>>> > >>>> > >>> > >>> -- > >>> Bron Gondwana, CEO, Fastmail Pty Ltd > >>> brong@fastmailteam.com > >>> > >>> > >>> _______________________________________________ > >>> calsify mailing list > >>> calsify@ietf.org > >>> https://www.ietf.org/mailman/listinfo/calsify > >>> > > > > -- > > Bron Gondwana, CEO, Fastmail Pty Ltd > > brong@fastmailteam.com > > > > > > > > _______________________________________________ > > calsify mailing list > > calsify@ietf.org > > https://www.ietf.org/mailman/listinfo/calsify > > > > -- > Ujjwal "Ryzokuken" Sharma (he/him) > > Compilers Hacker, Node.js Core Collaborator and Speaker > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --e3ad5ef5a63a406089e1f91afad9884c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Excellent, I'm glad to hear that it's coming along.  = That's totally fine, and it doesn't even matter if the first draft uploa= ded to the datatracker is riddled with metadata errors because people wi= ll be happy to help you fix those!  The main thing is having a draf= t that I can do a call for adoption from and we can get it onto the cale= xt agenda for March (or even ask people to look at it between meetings).=

Cheers,

B= ron.

On Thu, D= ec 3, 2020, at 23:12, Ujjwal Sharma wrote:
Hi Bron! Th= anks Ron!

As Ron mentioned, I've started hacking on a dra= ft in that GitHub
repository,= and plan to make significant progress on it in the coming
weeks. I've made it an I-D that obsoletes = 3339, but the README was
copi= ed over from the 3339 template and needs to be changed.

I= 'll clean up the GitHub repo, continue making updates and hopefully
<= /div>
publish a version on datatracker = soon. That said, I'm still not too
familiar with the process so please feel free to let me know if I'= m
missing a step.

Thanks,
Ujjwal
<= div style=3D"font-family:Arial;">
On 12/3/20 5:16 PM, Bron Gondwana wrote:
> Ahh excellent.  Thanks Ronald.
> 
> RFCs don't work quite the same was as ISO numbers (you d= on't get to use
> the old = number again, it would be a new RFC number which replaces the
<= div style=3D"font-family:Arial;">> old one, so 3339 will only be ment= ioned in the metadata) - and if it's
> going to be published at the IETF we'll need to find the ri= ght venue for
> the work t= o happen.  Hence my question about the publishing plans.
<= div style=3D"font-family:Arial;">> 
> Cheers,
&= gt; 
> Bron.
> 
> On Thu, Dec 3, 2020, at 22:34, Ronald Tse wrote:
>> Hi Bron,
>>
>> Ujjwal has already taken the initiative to start a n= ew draft for RFC 3339.
>&g= t;
>> The draft is
<= /div>
>>
>&= gt; Kind regards,
>> Ro= n
>>
>> _____________________________________<= br>
>>
>> Ronald Tse
>> Ribose Inc.
>>
>> +=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+
>&g= t; This message may contain confidential and/or privileged
>> information.  If you are not= the addressee or authorized to
>> receive this for the addressee, you must not use, copy,
<= /div>
>> disclose or take any act= ion based on this message or any
>> information herein.  If you have received this message= in
>> error, please ad= vise the sender immediately by reply e-mail
>> and delete this message.  Thank you for you= r cooperation.
>> +=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+
>&g= t;
>>> On Dec 3, 202= 0, at 7:25 PM, Bron Gondwana <brong@fastmailteam.com
>>> <mailto:brong= @fastmailteam.com>> wrote:
>>>
>>= > Hi all,
>>>
=
>>> I raised this work = briefly at the last IETF in both the DISPATCH and
>>> CALEXT working groups, just to make ev= eryone aware that it's going
= >>> on, but I also made myself a note to follow up on it - so h= ere's my
>>> follow = up :)
>>>
<= div style=3D"font-family:Arial;">>>> How's the work going? = ;  Are you still planning to bring it to the
>>> IETF?  Do you need any help with = anything in that process?
>= ;>>
>>> Cheers= ,
>>>
>>> Bron.
>>>
>>> (loosely wearing my CALEXT chair hat, but also generally= interested)
>>>
=
>>> On Wed, Sep 2, 2020= , at 12:55, Shane Carr wrote:
>>>> Dear CalExt experts,
>>>>
&g= t;>>> My name is Shane and I am helping push the ECMAScript Tem= poral
>>>> propos= al, bringing new date/time types to JavaScript.  It's our
=
>>>> version of Joda Time.=
>>>>
>>>> I would like your feedb= ack on the following extensions that we are
>>>> proposing to the ISO-8601 / RFC 3339 str= ings outputted by Temporal.
&= gt;>>>
>>>>
>>>> Of particular interest is our proposed represen= tation of dates in
>>&g= t;> non-Gregorian calendar systems.
>>>>
&g= t;>>> I would appreciate it if you could send feedback!
>>>>
>>>> Thanks,
>>>> Shane
>>>>
>>>> _______________________________________________
>>>> calsify mailing l= ist
>>>>
>>>
>>> -= -
>>>   Bron Go= ndwana, CEO, Fastmail Pty Ltd
>>>
>>&g= t;
>>> _____________= __________________________________
>>> calsify mailing list
>>> <https://www.ietf.org/mailman/listinfo/calsify>
> 
> --
&= gt;   Bron Gondwana, CEO, Fastmail Pty Ltd
> 
> 
=
> 
> ______________________________________________= _
> calsify mailing list
> 

-- 
Ujjwal "Ryzokuken" Sharma (he/him)

Compilers Hacker, Node.js Core Collaborator and Speaker

_______________________________________________
calsify mailing list


--
  Br= on Gondwana, CEO, Fastmail Pty Ltd
&nb= sp; brong@fastmailteam.com

<= /div>

--e3ad5ef5a63a406089e1f91afad9884c-- From nobody Mon Dec 14 15:54: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 E97743A127C for ; Mon, 14 Dec 2020 15:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 xOexG_NUdtW0 for ; Mon, 14 Dec 2020 15:54:17 -0800 (PST) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 D821B3A127B for ; Mon, 14 Dec 2020 15:54:16 -0800 (PST) Received: by mail-vs1-xe2c.google.com with SMTP id r24so9983196vsg.10 for ; Mon, 14 Dec 2020 15:54:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WJupDB19Z4dCOu5RXWmsGVq2GBax0hxXQEqNIA057eM=; b=qRqbVQle47mcG2BJunGFMb0rIwyrY9HLKZpgg6mGXvY7NtEj+yOcwumJFM5G2m9PEZ ANirQlR5WvEv82v9lWetCtmgl/yJNjcDura2cPzsUd3uB4WM1MRZaOgwQ6KYg2DUH9cg GtRs9b/YL2rYtjF/tAmvEYMy26fAQMBP0pbjjFN47TuA1xh84qfqvC6DgJeaaC6AVJAu LXrPtbKdxBMCfNNlAVBhMToTkUyyN/pqjJVo4o7dl5BLvQ8AJcrQmggol7a6jxr4hjfc SGlncU9PbHS3cC6ycDPeNf+hn3c12ChXQZWJkFdpAdhmhtWCYF6o87nIPNbMCZwqOhJ7 jL8w== 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=WJupDB19Z4dCOu5RXWmsGVq2GBax0hxXQEqNIA057eM=; b=IEw+dbebZpIkpRjC5cUkTyyqo0o2bc0ZR+JrrZCTXZoc5gAw78ugKXRU52TyBU8++z Tm4dCpG4YkTymNFmnrXApTSrRxm3rxclsV+7vAes/l3gT9FahOsGwrhVK1t3VedtlOCg yxTcGno93B5j0e/on9+K0mEBumIcXxABfSuQG7Cip5qOaC465+Xm52G6rHk54iyd5VaN /vApw2i/RHrHv6+FDk0/snKQpdA+2KSxjAamF0Dq4FnA2jI0xj1YZNSPxSCCa7FJjcfO TRs6xrCKLfMmiZfppukL9Vm0YVLeOkUrpJqQKeQOf8tMUSRORRk7M6MJ5KzkQsDoAnRR kAsg== X-Gm-Message-State: AOAM53367nM6sos+Pj/RDeU2E2+lPc6+/v/x9xjgnEE2nOV4tVuM44SP S1gAzRbVa1q7aCMpLjGEDlrkwjSiOq9o04GEthwBfcF+MvBPfQ== X-Google-Smtp-Source: ABdhPJz7S9d3Bu+/nKmA7MvUKKsEkvGgtj5EnlTsX5AHRPMJ9pml2OJyNLFoYjlEqOFBvsNZ9fdIRJHyvie6jUIpPRw= X-Received: by 2002:a67:d20e:: with SMTP id y14mr14422290vsi.11.1607990055759; Mon, 14 Dec 2020 15:54:15 -0800 (PST) MIME-Version: 1.0 References: <20190728114511.A93CFB80D0D@rfc-editor.org> <1EBEA8BC-3A1D-4798-8CAD-0A76DCF850B3@cisco.com> <877ba1d2-310f-403a-a6b5-fb7831858b72@www.fastmail.com> In-Reply-To: <877ba1d2-310f-403a-a6b5-fb7831858b72@www.fastmail.com> From: =?UTF-8?Q?Eug=C3=A8ne_Adell?= Date: Tue, 15 Dec 2020 00:46:11 +0100 Message-ID: To: Stan Kalisch Cc: Eliot Lear , RFC Errata System , ben@nostrum.com, adam@nostrum.com, aamelnikov@fastmail.fm, calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [calsify] [Editorial Errata Reported] RFC5545 (5794) 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, 14 Dec 2020 23:54:20 -0000 Hi guys, was it possible to decide anything on this Errata ? I think that even a rejected one is still better, if commented appropriately for the future readers, as they don't (I think) investigate in the mailing lists. best regards Eugene Le lun. 29 juil. 2019 =C3=A0 04:08, Stan Kalisch a =C3=A9crit : > > Hi, > > On Sun, Jul 28, 2019, at 8:30 AM, Eliot Lear wrote: > > The erratum is correct. Good catch. Under the IESG criteria, as this is= editorial and will not cause any interoperability or other implementation = concerns, it is normally marked =E2=80=9Chold for update=E2=80=9D. However= , because of the particular nature of this erratum, anyone who clicks on th= e web searchable index gets sent to the wrong place. That=E2=80=99s annoyi= ng. Suggestions? > > > Per https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/: > > "Only errors that could cause implementation or deployment problems or si= gnificant confusion should be Verified." > > So, the way I read it, it comes down to whether the confusion this could = cause is judged to be "significant". My personal opinion is that, given th= at the table of contents should go up to page 167, and given that there wil= l be more than a few marginally exhausted implementers likely reading this = at some point, it's "significant enough." > > > Stan > > Eliot > > > > > On 28 Jul 2019, at 13:45, RFC Errata System = wrote: > > > > The following errata report has been submitted for RFC5545, > > "Internet Calendaring and Scheduling Core Object Specification (iCalend= ar)". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid5794 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Eugene Adell > > > > Section: ToC > > > > Original Text > > ------------- > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 > > 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 6 > > 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 > > 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 7 > > 3. iCalendar Object Specification . . . . . . . . . . . . . . . 8 > > 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 8 > > 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 > > 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 11 > > 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 11 > > 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 12 > > 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 12 > > 3.2.1. Alternate Text Representation . . . . . . . . . . . . 13 > > 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 > > 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 15 > > 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 16 > > 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 16 > > 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 17 > > 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 17 > > 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 18 > > 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 19 > > 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 20 > > 3.2.11. Group or List Membership . . . . . . . . . . . . . . 20 > > 3.2.12. Participation Status . . . . . . . . . . . . . . . . 21 > > 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 22 > > 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 23 > > 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 24 > > 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 25 > > 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 25 > > 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 26 > > 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 26 > > 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 28 > > 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 29 > > 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 29 > > 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 30 > > 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 30 > > 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 31 > > 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 31 > > 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 34 > > 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 35 > > 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 35 > > 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 36 > > 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 37 > > 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45 > > 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 46 > > 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 48 > > 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49 > > 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 49 > > 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 50 > > 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 50 > > 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52 > > 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 56 > > 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 58 > > 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 60 > > 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 63 > > 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 72 > > 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 77 > > 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 77 > > 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 78 > > 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 79 > > 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 80 > > 3.8. Component Properties . . . . . . . . . . . . . . . . . . 81 > > 3.8.1. Descriptive Component Properties . . . . . . . . . . 81 > > 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 81 > > 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 82 > > 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 83 > > 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 84 > > 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 85 > > 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 87 > > 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 88 > > 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 89 > > 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 90 > > 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 92 > > 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 93 > > 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 94 > > 3.8.2. Date and Time Component Properties . . . . . . . . . 95 > > 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 95 > > 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 96 > > 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 97 > > 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 99 > > 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 100 > > 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 101 > > 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 102 > > 3.8.3. Time Zone Component Properties . . . . . . . . . . . 103 > > 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 103 > > 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 105 > > 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 106 > > 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 106 > > 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 107 > > 3.8.4. Relationship Component Properties . . . . . . . . . . 108 > > 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 108 > > 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 111 > > > > 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 113 > > 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 114 > > 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 117 > > 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 118 > > 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 119 > > 3.8.5. Recurrence Component Properties . . . . . . . . . . . 120 > > 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 120 > > 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 122 > > 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 124 > > 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 134 > > 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 134 > > 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 135 > > 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 135 > > 3.8.7. Change Management Component Properties . . . . . . . 138 > > 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 138 > > 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 139 > > 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 140 > > 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 141 > > 3.8.8. Miscellaneous Component Properties . . . . . . . . . 142 > > 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 142 > > 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 142 > > 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 144 > > 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 146 > > 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 150 > > 6. Internationalization Considerations . . . . . . . . . . . . . 151 > > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 151 > > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 151 > > 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 151 > > 8.2. New iCalendar Elements Registration . . . . . . . . . . . 155 > > 8.2.1. iCalendar Elements Registration Procedure . . . . . . 155 > > 8.2.2. Registration Template for Components . . . . . . . . 155 > > 8.2.3. Registration Template for Properties . . . . . . . . 156 > > 8.2.4. Registration Template for Parameters . . . . . . . . 156 > > 8.2.5. Registration Template for Value Data Types . . . . . 157 > > 8.2.6. Registration Template for Values . . . . . . . . . . 157 > > 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 158 > > 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 158 > > 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 158 > > 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 161 > > 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 162 > > 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 162 > > 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 163 > > 8.3.7. Participation Statuses Registry . . . . . . . . . . . 163 > > 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 164 > > 8.3.9. Participation Roles Registry . . . . . . . . . . . . 164 > > 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 165 > > 8.3.11. Classifications Registry . . . . . . . . . . . . . . 165 > > 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 165 > > 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 165 > > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 > > 10.1. Normative References . . . . . . . . . . . . . . . . . . 166 > > 10.2. Informative References . . . . . . . . . . . . . . . . . 167 > > Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 169 > > A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 169 > > A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 169 > > A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 169 > > > > > > Corrected Text > > -------------- > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 > > 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 6 > > 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 > > 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 8 > > 3. iCalendar Object Specification . . . . . . . . . . . . . . . 8 > > 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 9 > > 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 > > 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 12 > > 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 12 > > 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 13 > > 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 13 > > 3.2.1. Alternate Text Representation . . . . . . . . . . . . 14 > > 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 > > 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 16 > > 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 17 > > 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 17 > > 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 18 > > 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 18 > > 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 19 > > 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 20 > > 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 21 > > 3.2.11. Group or List Membership . . . . . . . . . . . . . . 21 > > 3.2.12. Participation Status . . . . . . . . . . . . . . . . 22 > > 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 23 > > 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 24 > > 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 25 > > 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 25 > > 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 26 > > 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 27 > > 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 27 > > 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 29 > > 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 30 > > 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 30 > > 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 31 > > 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 31 > > 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 32 > > 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 32 > > 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 35 > > 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 36 > > 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 37 > > 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 37 > > 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 38 > > 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45 > > 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 47 > > 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 49 > > 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49 > > 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 50 > > 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 51 > > 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 51 > > 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52 > > 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 55 > > 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 57 > > 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 59 > > 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 62 > > 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 71 > > 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 76 > > 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 76 > > 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 77 > > 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 78 > > 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 79 > > 3.8. Component Properties . . . . . . . . . . . . . . . . . . 80 > > 3.8.1. Descriptive Component Properties . . . . . . . . . . 80 > > 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 80 > > 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 81 > > 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 82 > > 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 83 > > 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 84 > > 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 85 > > 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 87 > > 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 88 > > 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 89 > > 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 91 > > 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 92 > > 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 93 > > 3.8.2. Date and Time Component Properties . . . . . . . . . 94 > > 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 94 > > 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 95 > > 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 96 > > 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 97 > > 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 99 > > 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 100 > > 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 101 > > 3.8.3. Time Zone Component Properties . . . . . . . . . . . 102 > > 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 102 > > 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 103 > > 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 104 > > 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 105 > > 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 106 > > 3.8.4. Relationship Component Properties . . . . . . . . . . 106 > > 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 107 > > 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 109 > > 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 111 > > 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 112 > > 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 115 > > 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 116 > > 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 117 > > 3.8.5. Recurrence Component Properties . . . . . . . . . . . 118 > > 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 118 > > 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 120 > > 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 122 > > 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 132 > > 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 132 > > 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 133 > > 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 133 > > 3.8.7. Change Management Component Properties . . . . . . . 136 > > 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 136 > > 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 137 > > 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 138 > > 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 138 > > 3.8.8. Miscellaneous Component Properties . . . . . . . . . 139 > > 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 140 > > 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 140 > > 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 141 > > 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 144 > > 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 147 > > 6. Internationalization Considerations . . . . . . . . . . . . . 148 > > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 148 > > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 149 > > 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 149 > > 8.2. New iCalendar Elements Registration . . . . . . . . . . . 152 > > 8.2.1. iCalendar Elements Registration Procedure . . . . . . 152 > > 8.2.2. Registration Template for Components . . . . . . . . 152 > > 8.2.3. Registration Template for Properties . . . . . . . . 153 > > 8.2.4. Registration Template for Parameters . . . . . . . . 153 > > 8.2.5. Registration Template for Value Data Types . . . . . 154 > > 8.2.6. Registration Template for Values . . . . . . . . . . 154 > > 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 155 > > 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 155 > > 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 156 > > 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 158 > > 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 159 > > 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 160 > > 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 160 > > 8.3.7. Participation Statuses Registry . . . . . . . . . . . 161 > > 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 161 > > 8.3.9. Participation Roles Registry . . . . . . . . . . . . 162 > > 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 162 > > 8.3.11. Classifications Registry . . . . . . . . . . . . . . 162 > > 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 163 > > 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 163 > > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 164 > > 10.1. Normative References . . . . . . . . . . . . . . . . . . 164 > > 10.2. Informative References . . . . . . . . . . . . . . . . . 165 > > Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 167 > > A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 167 > > A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 167 > > A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 167 > > > > > > Notes > > ----- > > Most of the Table Of Contents give wrong page numbers > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5545 (draft-ietf-calsify-rfc2445bis-10) > > -------------------------------------- > > Title : Internet Calendaring and Scheduling Core Object S= pecification (iCalendar) > > Publication Date : September 2009 > > Author(s) : B. Desruisseaux, Ed. > > Category : PROPOSED STANDARD > > Source : Calendaring and Scheduling Standards Simplificati= on > > Area : Applications > > Stream : IETF > > Verifying Party : IESG > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > > Attachments: > > signature.asc > > From nobody Mon Dec 14 17:09: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 601DC3A132A; Mon, 14 Dec 2020 17:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, MAY_BE_FORGED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 PAFL2NjOdkwT; Mon, 14 Dec 2020 17:09:19 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 388B03A132E; Mon, 14 Dec 2020 17:09:19 -0800 (PST) Received: from macbook-pro.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 0BF18vIX080850 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 14 Dec 2020 19:08:58 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1607994540; bh=vOVgKZYQKVDsliGOheXyp4oEWUXVa7FT7unslk9Bw7U=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=IAkHuo0IQoSTpXINzzpN4viihJc46+33tY/0Is+OF8jGJOk1dubJ9gyy6y9FvVDJS TyvlXH9mBVY7tUbfBv5x7JTe4DsqqXM4pDA+Jn/u906KSOwURQwZrrfH5i5fx79prj wNfGYooudGK6U8xLKAaY1Rkug+1OjbxPARpSCkGs= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be macbook-pro.lan Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Ben Campbell In-Reply-To: Date: Mon, 14 Dec 2020 19:08:51 -0600 Cc: Stan Kalisch , Eliot Lear , RFC Errata System , Adam Roach , aamelnikov@fastmail.fm, calsify@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190728114511.A93CFB80D0D@rfc-editor.org> <1EBEA8BC-3A1D-4798-8CAD-0A76DCF850B3@cisco.com> <877ba1d2-310f-403a-a6b5-fb7831858b72@www.fastmail.com> To: =?utf-8?Q?Eug=C3=A8ne_Adell?= , ART Area X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [calsify] [Editorial Errata Reported] RFC5545 (5794) 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, 15 Dec 2020 01:09:27 -0000 This went to a bunch of ex-ART-ADs. Forwarding to the current ones=E2=80=A6= Ben. > On Dec 14, 2020, at 5:46 PM, Eug=C3=A8ne Adell = wrote: >=20 > Hi guys, >=20 > was it possible to decide anything on this Errata ? I think that even > a rejected one is still better, if commented appropriately for the > future readers, as they don't (I think) investigate in the mailing > lists. >=20 > best regards > Eugene >=20 > Le lun. 29 juil. 2019 =C3=A0 04:08, Stan Kalisch > a =C3=A9crit : >>=20 >> Hi, >>=20 >> On Sun, Jul 28, 2019, at 8:30 AM, Eliot Lear wrote: >>=20 >> The erratum is correct. Good catch. Under the IESG criteria, as = this is editorial and will not cause any interoperability or other = implementation concerns, it is normally marked =E2=80=9Chold for = update=E2=80=9D. However, because of the particular nature of this = erratum, anyone who clicks on the web searchable index gets sent to the = wrong place. That=E2=80=99s annoying. Suggestions? >>=20 >>=20 >> Per = https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/: >>=20 >> "Only errors that could cause implementation or deployment problems = or significant confusion should be Verified." >>=20 >> So, the way I read it, it comes down to whether the confusion this = could cause is judged to be "significant". My personal opinion is that, = given that the table of contents should go up to page 167, and given = that there will be more than a few marginally exhausted implementers = likely reading this at some point, it's "significant enough." >>=20 >>=20 >> Stan >>=20 >> Eliot >>=20 >>=20 >>=20 >>> On 28 Jul 2019, at 13:45, RFC Errata System = wrote: >>>=20 >>> The following errata report has been submitted for RFC5545, >>> "Internet Calendaring and Scheduling Core Object Specification = (iCalendar)". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> https://www.rfc-editor.org/errata/eid5794 >>>=20 >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Eugene Adell >>>=20 >>> Section: ToC >>>=20 >>> Original Text >>> ------------- >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 5 >>> 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . = 6 >>> 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . = 6 >>> 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . = 7 >>> 3. iCalendar Object Specification . . . . . . . . . . . . . . . = 8 >>> 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . = 8 >>> 3.1.1. List and Field Separators . . . . . . . . . . . . . . = 11 >>> 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . = 11 >>> 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . = 11 >>> 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . = 12 >>> 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . = 12 >>> 3.2.1. Alternate Text Representation . . . . . . . . . . . . = 13 >>> 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . = 15 >>> 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . = 15 >>> 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . = 16 >>> 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . = 16 >>> 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . = 17 >>> 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . = 17 >>> 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . = 18 >>> 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . = 19 >>> 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . = 20 >>> 3.2.11. Group or List Membership . . . . . . . . . . . . . . = 20 >>> 3.2.12. Participation Status . . . . . . . . . . . . . . . . = 21 >>> 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . = 22 >>> 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . = 23 >>> 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . = 24 >>> 3.2.16. Participation Role . . . . . . . . . . . . . . . . . = 25 >>> 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . = 25 >>> 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . = 26 >>> 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . = 26 >>> 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . = 28 >>> 3.3. Property Value Data Types . . . . . . . . . . . . . . . . = 29 >>> 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . = 29 >>> 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . = 30 >>> 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . = 30 >>> 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . = 31 >>> 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . = 31 >>> 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . = 34 >>> 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . = 35 >>> 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . = 35 >>> 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . = 36 >>> 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . = 37 >>> 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . = 45 >>> 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . = 46 >>> 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . = 48 >>> 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . = 49 >>> 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . = 49 >>> 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . = 50 >>> 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . = 50 >>> 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . = 52 >>> 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . = 56 >>> 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . = 58 >>> 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . = 60 >>> 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . = 63 >>> 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . = 72 >>> 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . = 77 >>> 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . = 77 >>> 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . = 78 >>> 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . = 79 >>> 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . = 80 >>> 3.8. Component Properties . . . . . . . . . . . . . . . . . . = 81 >>> 3.8.1. Descriptive Component Properties . . . . . . . . . . = 81 >>> 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . = 81 >>> 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . = 82 >>> 3.8.1.3. Classification . . . . . . . . . . . . . . . . . = 83 >>> 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . = 84 >>> 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . = 85 >>> 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . = 87 >>> 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . = 88 >>> 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . = 89 >>> 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . = 90 >>> 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . = 92 >>> 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . = 93 >>> 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . = 94 >>> 3.8.2. Date and Time Component Properties . . . . . . . . . = 95 >>> 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . = 95 >>> 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . = 96 >>> 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . = 97 >>> 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . = 99 >>> 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . = 100 >>> 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . = 101 >>> 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . = 102 >>> 3.8.3. Time Zone Component Properties . . . . . . . . . . . = 103 >>> 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . = 103 >>> 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . = 105 >>> 3.8.3.3. Time Zone Offset =46rom . . . . . . . . . . . . . . = 106 >>> 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . = 106 >>> 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . = 107 >>> 3.8.4. Relationship Component Properties . . . . . . . . . . = 108 >>> 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . = 108 >>> 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . = 111 >>>=20 >>> 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . = 113 >>> 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . = 114 >>> 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . = 117 >>> 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . = 118 >>> 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . = 119 >>> 3.8.5. Recurrence Component Properties . . . . . . . . . . . = 120 >>> 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . = 120 >>> 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . = 122 >>> 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . = 124 >>> 3.8.6. Alarm Component Properties . . . . . . . . . . . . . = 134 >>> 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . = 134 >>> 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . = 135 >>> 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . = 135 >>> 3.8.7. Change Management Component Properties . . . . . . . = 138 >>> 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . = 138 >>> 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . = 139 >>> 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . = 140 >>> 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . = 141 >>> 3.8.8. Miscellaneous Component Properties . . . . . . . . . = 142 >>> 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . = 142 >>> 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . = 142 >>> 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . = 144 >>> 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . = 146 >>> 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . = 150 >>> 6. Internationalization Considerations . . . . . . . . . . . . . = 151 >>> 7. Security Considerations . . . . . . . . . . . . . . . . . . . = 151 >>> 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 151 >>> 8.1. iCalendar Media Type Registration . . . . . . . . . . . . = 151 >>> 8.2. New iCalendar Elements Registration . . . . . . . . . . . = 155 >>> 8.2.1. iCalendar Elements Registration Procedure . . . . . . = 155 >>> 8.2.2. Registration Template for Components . . . . . . . . = 155 >>> 8.2.3. Registration Template for Properties . . . . . . . . = 156 >>> 8.2.4. Registration Template for Parameters . . . . . . . . = 156 >>> 8.2.5. Registration Template for Value Data Types . . . . . = 157 >>> 8.2.6. Registration Template for Values . . . . . . . . . . = 157 >>> 8.3. Initial iCalendar Elements Registries . . . . . . . . . . = 158 >>> 8.3.1. Components Registry . . . . . . . . . . . . . . . . . = 158 >>> 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . = 158 >>> 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . = 161 >>> 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . = 162 >>> 8.3.5. Calendar User Types Registry . . . . . . . . . . . . = 162 >>> 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . = 163 >>> 8.3.7. Participation Statuses Registry . . . . . . . . . . . = 163 >>> 8.3.8. Relationship Types Registry . . . . . . . . . . . . . = 164 >>> 8.3.9. Participation Roles Registry . . . . . . . . . . . . = 164 >>> 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . = 165 >>> 8.3.11. Classifications Registry . . . . . . . . . . . . . . = 165 >>> 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . = 165 >>> 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . = 165 >>> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . = 166 >>> 10.1. Normative References . . . . . . . . . . . . . . . . . . = 166 >>> 10.2. Informative References . . . . . . . . . . . . . . . . . = 167 >>> Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . = 169 >>> A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . = 169 >>> A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . = 169 >>> A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . = 169 >>>=20 >>>=20 >>> Corrected Text >>> -------------- >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 5 >>> 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . = 6 >>> 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . = 6 >>> 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . = 8 >>> 3. iCalendar Object Specification . . . . . . . . . . . . . . . = 8 >>> 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . = 9 >>> 3.1.1. List and Field Separators . . . . . . . . . . . . . . = 11 >>> 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . = 12 >>> 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . = 12 >>> 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . = 13 >>> 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . = 13 >>> 3.2.1. Alternate Text Representation . . . . . . . . . . . . = 14 >>> 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . = 15 >>> 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . = 16 >>> 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . = 17 >>> 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . = 17 >>> 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . = 18 >>> 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . = 18 >>> 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . = 19 >>> 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . = 20 >>> 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . = 21 >>> 3.2.11. Group or List Membership . . . . . . . . . . . . . . = 21 >>> 3.2.12. Participation Status . . . . . . . . . . . . . . . . = 22 >>> 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . = 23 >>> 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . = 24 >>> 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . = 25 >>> 3.2.16. Participation Role . . . . . . . . . . . . . . . . . = 25 >>> 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . = 26 >>> 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . = 27 >>> 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . = 27 >>> 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . = 29 >>> 3.3. Property Value Data Types . . . . . . . . . . . . . . . . = 30 >>> 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . = 30 >>> 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . = 31 >>> 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . = 31 >>> 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . = 32 >>> 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . = 32 >>> 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . = 35 >>> 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . = 36 >>> 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . = 37 >>> 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . = 37 >>> 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . = 38 >>> 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . = 45 >>> 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . = 47 >>> 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . = 49 >>> 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . = 49 >>> 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . = 50 >>> 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . = 51 >>> 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . = 51 >>> 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . = 52 >>> 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . = 55 >>> 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . = 57 >>> 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . = 59 >>> 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . = 62 >>> 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . = 71 >>> 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . = 76 >>> 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . = 76 >>> 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . = 77 >>> 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . = 78 >>> 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . = 79 >>> 3.8. Component Properties . . . . . . . . . . . . . . . . . . = 80 >>> 3.8.1. Descriptive Component Properties . . . . . . . . . . = 80 >>> 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . = 80 >>> 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . = 81 >>> 3.8.1.3. Classification . . . . . . . . . . . . . . . . . = 82 >>> 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . = 83 >>> 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . = 84 >>> 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . = 85 >>> 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . = 87 >>> 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . = 88 >>> 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . = 89 >>> 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . = 91 >>> 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . = 92 >>> 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . = 93 >>> 3.8.2. Date and Time Component Properties . . . . . . . . . = 94 >>> 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . = 94 >>> 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . = 95 >>> 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . = 96 >>> 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . = 97 >>> 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . = 99 >>> 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . = 100 >>> 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . = 101 >>> 3.8.3. Time Zone Component Properties . . . . . . . . . . . = 102 >>> 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . = 102 >>> 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . = 103 >>> 3.8.3.3. Time Zone Offset =46rom . . . . . . . . . . . . . . = 104 >>> 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . = 105 >>> 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . = 106 >>> 3.8.4. Relationship Component Properties . . . . . . . . . . = 106 >>> 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . = 107 >>> 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . = 109 >>> 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . = 111 >>> 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . = 112 >>> 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . = 115 >>> 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . = 116 >>> 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . = 117 >>> 3.8.5. Recurrence Component Properties . . . . . . . . . . . = 118 >>> 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . = 118 >>> 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . = 120 >>> 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . = 122 >>> 3.8.6. Alarm Component Properties . . . . . . . . . . . . . = 132 >>> 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . = 132 >>> 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . = 133 >>> 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . = 133 >>> 3.8.7. Change Management Component Properties . . . . . . . = 136 >>> 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . = 136 >>> 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . = 137 >>> 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . = 138 >>> 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . = 138 >>> 3.8.8. Miscellaneous Component Properties . . . . . . . . . = 139 >>> 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . = 140 >>> 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . = 140 >>> 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . = 141 >>> 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . = 144 >>> 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . = 147 >>> 6. Internationalization Considerations . . . . . . . . . . . . . = 148 >>> 7. Security Considerations . . . . . . . . . . . . . . . . . . . = 148 >>> 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 149 >>> 8.1. iCalendar Media Type Registration . . . . . . . . . . . . = 149 >>> 8.2. New iCalendar Elements Registration . . . . . . . . . . . = 152 >>> 8.2.1. iCalendar Elements Registration Procedure . . . . . . = 152 >>> 8.2.2. Registration Template for Components . . . . . . . . = 152 >>> 8.2.3. Registration Template for Properties . . . . . . . . = 153 >>> 8.2.4. Registration Template for Parameters . . . . . . . . = 153 >>> 8.2.5. Registration Template for Value Data Types . . . . . = 154 >>> 8.2.6. Registration Template for Values . . . . . . . . . . = 154 >>> 8.3. Initial iCalendar Elements Registries . . . . . . . . . . = 155 >>> 8.3.1. Components Registry . . . . . . . . . . . . . . . . . = 155 >>> 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . = 156 >>> 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . = 158 >>> 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . = 159 >>> 8.3.5. Calendar User Types Registry . . . . . . . . . . . . = 160 >>> 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . = 160 >>> 8.3.7. Participation Statuses Registry . . . . . . . . . . . = 161 >>> 8.3.8. Relationship Types Registry . . . . . . . . . . . . . = 161 >>> 8.3.9. Participation Roles Registry . . . . . . . . . . . . = 162 >>> 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . = 162 >>> 8.3.11. Classifications Registry . . . . . . . . . . . . . . = 162 >>> 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . = 163 >>> 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . = 163 >>> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . = 164 >>> 10.1. Normative References . . . . . . . . . . . . . . . . . . = 164 >>> 10.2. Informative References . . . . . . . . . . . . . . . . . = 165 >>> Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . = 167 >>> A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . = 167 >>> A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . = 167 >>> A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . = 167 >>>=20 >>>=20 >>> Notes >>> ----- >>> Most of the Table Of Contents give wrong page numbers >>>=20 >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>>=20 >>> -------------------------------------- >>> RFC5545 (draft-ietf-calsify-rfc2445bis-10) >>> -------------------------------------- >>> Title : Internet Calendaring and Scheduling Core = Object Specification (iCalendar) >>> Publication Date : September 2009 >>> Author(s) : B. Desruisseaux, Ed. >>> Category : PROPOSED STANDARD >>> Source : Calendaring and Scheduling Standards = Simplification >>> Area : Applications >>> Stream : IETF >>> Verifying Party : IESG >>=20 >>=20 >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >>=20 >>=20 >> Attachments: >>=20 >> signature.asc >>=20 >>=20 From nobody Mon Dec 14 19:27: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 747353A00D9; Mon, 14 Dec 2020 19:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[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] 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 0n59-DF5oJ-O; Mon, 14 Dec 2020 19:27:35 -0800 (PST) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.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 29D093A00D8; Mon, 14 Dec 2020 19:27:35 -0800 (PST) Received: by mail-lf1-f53.google.com with SMTP id m12so35691032lfo.7; Mon, 14 Dec 2020 19:27: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; bh=tJ5UDI1g7O7oqUvNX8lPw08w9uUsN3MSjOwzSMjNBcQ=; b=UCOkYhZu2L9RlMO+q6rMcWcdJ9asnY0CCQxjoEDAvGFdc/hMkvxGbAG4fDKChwHqk1 gtGG77AFYkVgJmtT2jrxdiajscab6bXkn7rc4F4URhtjtytNwdsv+c9K5QV1yQ6FzwVS 9zTvhA8r0vUTrHMdMwXb5hRpFoppgYIokJIqiSc7sCx9807ELeZAWbJssbKiiKz6wZJd ittTwJ92u8dOY7yqh3kcCqwLkx1ye4FvEqNfH/LY4yufw083NPyNxMlgwxkfp3mV6NlD 8I/VkG0wZgPkEqvZ2yKOUM2l+0BXnzHlEYG6TNTfeQdJf8KY6c3fWFMCEUY9hmEn3YGt niHQ== X-Gm-Message-State: AOAM531oTXWvSLafQw1AcX6lmjT9S57wn693YyEhbQZqUmzKXxzYFM6y l5QhfpoA7DNud+XasueHXCiMg9Z+IW17KFe/8KY8yGb1DvI= X-Google-Smtp-Source: ABdhPJwtz1gwYxM5rb9mzESNjFkCFDjLOfwrvLlhBIds3QvcQOYGSuf4vJg5gfPbK5wGYdZh4aJ2CfteovQ9AJFy2k0= X-Received: by 2002:a2e:9756:: with SMTP id f22mr11677316ljj.65.1608002852907; Mon, 14 Dec 2020 19:27:32 -0800 (PST) MIME-Version: 1.0 References: <20190728114511.A93CFB80D0D@rfc-editor.org> <1EBEA8BC-3A1D-4798-8CAD-0A76DCF850B3@cisco.com> <877ba1d2-310f-403a-a6b5-fb7831858b72@www.fastmail.com> In-Reply-To: From: Barry Leiba Date: Mon, 14 Dec 2020 22:27:21 -0500 Message-ID: To: Ben Campbell Cc: ART Area , Adam Roach , Eliot Lear , =?UTF-8?Q?Eug=C3=A8ne_Adell?= , RFC Errata System , Stan Kalisch , aamelnikov@fastmail.fm, calsify@ietf.org Content-Type: multipart/alternative; boundary="000000000000d8717505b678563a" Archived-At: Subject: Re: [calsify] [Editorial Errata Reported] RFC5545 (5794) 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, 15 Dec 2020 03:27:40 -0000 --000000000000d8717505b678563a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99ll have a look at this tomorrow and will handle it. Thanks for t= he poke, and the redirect. Barry On Mon, Dec 14, 2020 at 8:09 PM Ben Campbell wrote: > This went to a bunch of ex-ART-ADs. Forwarding to the current ones=E2=80= =A6 > > Ben. > > > On Dec 14, 2020, at 5:46 PM, Eug=C3=A8ne Adell > wrote: > > > > Hi guys, > > > > was it possible to decide anything on this Errata ? I think that even > > a rejected one is still better, if commented appropriately for the > > future readers, as they don't (I think) investigate in the mailing > > lists. > > > > best regards > > Eugene > > > > Le lun. 29 juil. 2019 =C3=A0 04:08, Stan Kalisch > > a =C3=A9crit : > >> > >> Hi, > >> > >> On Sun, Jul 28, 2019, at 8:30 AM, Eliot Lear wrote: > >> > >> The erratum is correct. Good catch. Under the IESG criteria, as this > is editorial and will not cause any interoperability or other > implementation concerns, it is normally marked =E2=80=9Chold for update= =E2=80=9D. However, > because of the particular nature of this erratum, anyone who clicks on th= e > web searchable index gets sent to the wrong place. That=E2=80=99s annoyi= ng. > Suggestions? > >> > >> > >> Per https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/: > >> > >> "Only errors that could cause implementation or deployment problems or > significant confusion should be Verified." > >> > >> So, the way I read it, it comes down to whether the confusion this > could cause is judged to be "significant". My personal opinion is that, > given that the table of contents should go up to page 167, and given that > there will be more than a few marginally exhausted implementers likely > reading this at some point, it's "significant enough." > >> > >> > >> Stan > >> > >> Eliot > >> > >> > >> > >>> On 28 Jul 2019, at 13:45, RFC Errata System > wrote: > >>> > >>> The following errata report has been submitted for RFC5545, > >>> "Internet Calendaring and Scheduling Core Object Specification > (iCalendar)". > >>> > >>> -------------------------------------- > >>> You may review the report below and at: > >>> https://www.rfc-editor.org/errata/eid5794 > >>> > >>> -------------------------------------- > >>> Type: Editorial > >>> Reported by: Eugene Adell > >>> > >>> Section: ToC > >>> > >>> Original Text > >>> ------------- > >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 5 > >>> 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . = 6 > >>> 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . = 6 > >>> 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . = 7 > >>> 3. iCalendar Object Specification . . . . . . . . . . . . . . . = 8 > >>> 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . = 8 > >>> 3.1.1. List and Field Separators . . . . . . . . . . . . . . 1= 1 > >>> 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 1= 1 > >>> 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 1= 1 > >>> 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 1= 2 > >>> 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 1= 2 > >>> 3.2.1. Alternate Text Representation . . . . . . . . . . . . 1= 3 > >>> 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 1= 5 > >>> 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 1= 5 > >>> 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 1= 6 > >>> 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 1= 6 > >>> 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 1= 7 > >>> 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 1= 7 > >>> 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 1= 8 > >>> 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 1= 9 > >>> 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 2= 0 > >>> 3.2.11. Group or List Membership . . . . . . . . . . . . . . 2= 0 > >>> 3.2.12. Participation Status . . . . . . . . . . . . . . . . 2= 1 > >>> 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 2= 2 > >>> 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 2= 3 > >>> 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 2= 4 > >>> 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 2= 5 > >>> 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 2= 5 > >>> 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 2= 6 > >>> 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 2= 6 > >>> 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 2= 8 > >>> 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 2= 9 > >>> 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 2= 9 > >>> 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 3= 0 > >>> 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 3= 0 > >>> 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 3= 1 > >>> 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 3= 1 > >>> 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 3= 4 > >>> 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 3= 5 > >>> 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 3= 5 > >>> 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 3= 6 > >>> 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 3= 7 > >>> 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 4= 5 > >>> 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 4= 6 > >>> 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 4= 8 > >>> 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 4= 9 > >>> 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 4= 9 > >>> 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 5= 0 > >>> 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 5= 0 > >>> 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 5= 2 > >>> 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 5= 6 > >>> 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 5= 8 > >>> 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 6= 0 > >>> 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 6= 3 > >>> 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 7= 2 > >>> 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 7= 7 > >>> 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 7= 7 > >>> 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 7= 8 > >>> 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 7= 9 > >>> 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 8= 0 > >>> 3.8. Component Properties . . . . . . . . . . . . . . . . . . 8= 1 > >>> 3.8.1. Descriptive Component Properties . . . . . . . . . . 8= 1 > >>> 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 8= 1 > >>> 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 8= 2 > >>> 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 8= 3 > >>> 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 8= 4 > >>> 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 8= 5 > >>> 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 8= 7 > >>> 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 8= 8 > >>> 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 8= 9 > >>> 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 9= 0 > >>> 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 9= 2 > >>> 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 9= 3 > >>> 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 9= 4 > >>> 3.8.2. Date and Time Component Properties . . . . . . . . . 9= 5 > >>> 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 9= 5 > >>> 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 9= 6 > >>> 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 9= 7 > >>> 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 9= 9 > >>> 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 10= 0 > >>> 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 10= 1 > >>> 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 10= 2 > >>> 3.8.3. Time Zone Component Properties . . . . . . . . . . . 10= 3 > >>> 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 10= 3 > >>> 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 10= 5 > >>> 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 10= 6 > >>> 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 10= 6 > >>> 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 10= 7 > >>> 3.8.4. Relationship Component Properties . . . . . . . . . . 10= 8 > >>> 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 10= 8 > >>> 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 11= 1 > >>> > >>> 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 11= 3 > >>> 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 11= 4 > >>> 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 11= 7 > >>> 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 11= 8 > >>> 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 11= 9 > >>> 3.8.5. Recurrence Component Properties . . . . . . . . . . . 12= 0 > >>> 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 12= 0 > >>> 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 12= 2 > >>> 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 12= 4 > >>> 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 13= 4 > >>> 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 13= 4 > >>> 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 13= 5 > >>> 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 13= 5 > >>> 3.8.7. Change Management Component Properties . . . . . . . 13= 8 > >>> 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 13= 8 > >>> 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 13= 9 > >>> 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 14= 0 > >>> 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 14= 1 > >>> 3.8.8. Miscellaneous Component Properties . . . . . . . . . 14= 2 > >>> 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 14= 2 > >>> 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 14= 2 > >>> 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 14= 4 > >>> 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 14= 6 > >>> 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 15= 0 > >>> 6. Internationalization Considerations . . . . . . . . . . . . . 15= 1 > >>> 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15= 1 > >>> 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15= 1 > >>> 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 15= 1 > >>> 8.2. New iCalendar Elements Registration . . . . . . . . . . . 15= 5 > >>> 8.2.1. iCalendar Elements Registration Procedure . . . . . . 15= 5 > >>> 8.2.2. Registration Template for Components . . . . . . . . 15= 5 > >>> 8.2.3. Registration Template for Properties . . . . . . . . 15= 6 > >>> 8.2.4. Registration Template for Parameters . . . . . . . . 15= 6 > >>> 8.2.5. Registration Template for Value Data Types . . . . . 15= 7 > >>> 8.2.6. Registration Template for Values . . . . . . . . . . 15= 7 > >>> 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 15= 8 > >>> 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 15= 8 > >>> 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 15= 8 > >>> 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 16= 1 > >>> 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 16= 2 > >>> 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 16= 2 > >>> 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 16= 3 > >>> 8.3.7. Participation Statuses Registry . . . . . . . . . . . 16= 3 > >>> 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 16= 4 > >>> 8.3.9. Participation Roles Registry . . . . . . . . . . . . 16= 4 > >>> 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 16= 5 > >>> 8.3.11. Classifications Registry . . . . . . . . . . . . . . 16= 5 > >>> 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 16= 5 > >>> 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16= 5 > >>> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16= 6 > >>> 10.1. Normative References . . . . . . . . . . . . . . . . . . 16= 6 > >>> 10.2. Informative References . . . . . . . . . . . . . . . . . 16= 7 > >>> Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 16= 9 > >>> A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 16= 9 > >>> A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 16= 9 > >>> A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 16= 9 > >>> > >>> > >>> Corrected Text > >>> -------------- > >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 5 > >>> 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . = 6 > >>> 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . = 6 > >>> 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . = 8 > >>> 3. iCalendar Object Specification . . . . . . . . . . . . . . . = 8 > >>> 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . = 9 > >>> 3.1.1. List and Field Separators . . . . . . . . . . . . . . 1= 1 > >>> 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 1= 2 > >>> 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 1= 2 > >>> 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 1= 3 > >>> 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 1= 3 > >>> 3.2.1. Alternate Text Representation . . . . . . . . . . . . 1= 4 > >>> 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 1= 5 > >>> 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 1= 6 > >>> 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 1= 7 > >>> 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 1= 7 > >>> 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 1= 8 > >>> 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 1= 8 > >>> 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 1= 9 > >>> 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 2= 0 > >>> 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 2= 1 > >>> 3.2.11. Group or List Membership . . . . . . . . . . . . . . 2= 1 > >>> 3.2.12. Participation Status . . . . . . . . . . . . . . . . 2= 2 > >>> 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 2= 3 > >>> 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 2= 4 > >>> 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 2= 5 > >>> 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 2= 5 > >>> 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 2= 6 > >>> 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 2= 7 > >>> 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 2= 7 > >>> 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 2= 9 > >>> 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 3= 0 > >>> 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 3= 0 > >>> 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 3= 1 > >>> 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 3= 1 > >>> 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 3= 2 > >>> 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 3= 2 > >>> 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 3= 5 > >>> 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 3= 6 > >>> 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 3= 7 > >>> 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 3= 7 > >>> 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 3= 8 > >>> 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 4= 5 > >>> 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 4= 7 > >>> 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 4= 9 > >>> 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 4= 9 > >>> 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 5= 0 > >>> 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 5= 1 > >>> 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 5= 1 > >>> 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 5= 2 > >>> 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 5= 5 > >>> 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 5= 7 > >>> 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 5= 9 > >>> 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 6= 2 > >>> 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 7= 1 > >>> 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 7= 6 > >>> 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 7= 6 > >>> 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 7= 7 > >>> 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 7= 8 > >>> 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 7= 9 > >>> 3.8. Component Properties . . . . . . . . . . . . . . . . . . 8= 0 > >>> 3.8.1. Descriptive Component Properties . . . . . . . . . . 8= 0 > >>> 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 8= 0 > >>> 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 8= 1 > >>> 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 8= 2 > >>> 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 8= 3 > >>> 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 8= 4 > >>> 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 8= 5 > >>> 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 8= 7 > >>> 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 8= 8 > >>> 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 8= 9 > >>> 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 9= 1 > >>> 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 9= 2 > >>> 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 9= 3 > >>> 3.8.2. Date and Time Component Properties . . . . . . . . . 9= 4 > >>> 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 9= 4 > >>> 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 9= 5 > >>> 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 9= 6 > >>> 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 9= 7 > >>> 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 9= 9 > >>> 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 10= 0 > >>> 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 10= 1 > >>> 3.8.3. Time Zone Component Properties . . . . . . . . . . . 10= 2 > >>> 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 10= 2 > >>> 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 10= 3 > >>> 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 10= 4 > >>> 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 10= 5 > >>> 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 10= 6 > >>> 3.8.4. Relationship Component Properties . . . . . . . . . . 10= 6 > >>> 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 10= 7 > >>> 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 10= 9 > >>> 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 11= 1 > >>> 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 11= 2 > >>> 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 11= 5 > >>> 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 11= 6 > >>> 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 11= 7 > >>> 3.8.5. Recurrence Component Properties . . . . . . . . . . . 11= 8 > >>> 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 11= 8 > >>> 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 12= 0 > >>> 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 12= 2 > >>> 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 13= 2 > >>> 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 13= 2 > >>> 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 13= 3 > >>> 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 13= 3 > >>> 3.8.7. Change Management Component Properties . . . . . . . 13= 6 > >>> 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 13= 6 > >>> 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 13= 7 > >>> 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 13= 8 > >>> 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 13= 8 > >>> 3.8.8. Miscellaneous Component Properties . . . . . . . . . 13= 9 > >>> 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 14= 0 > >>> 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 14= 0 > >>> 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 14= 1 > >>> 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 14= 4 > >>> 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 14= 7 > >>> 6. Internationalization Considerations . . . . . . . . . . . . . 14= 8 > >>> 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14= 8 > >>> 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14= 9 > >>> 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 14= 9 > >>> 8.2. New iCalendar Elements Registration . . . . . . . . . . . 15= 2 > >>> 8.2.1. iCalendar Elements Registration Procedure . . . . . . 15= 2 > >>> 8.2.2. Registration Template for Components . . . . . . . . 15= 2 > >>> 8.2.3. Registration Template for Properties . . . . . . . . 15= 3 > >>> 8.2.4. Registration Template for Parameters . . . . . . . . 15= 3 > >>> 8.2.5. Registration Template for Value Data Types . . . . . 15= 4 > >>> 8.2.6. Registration Template for Values . . . . . . . . . . 15= 4 > >>> 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 15= 5 > >>> 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 15= 5 > >>> 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 15= 6 > >>> 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 15= 8 > >>> 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 15= 9 > >>> 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 16= 0 > >>> 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 16= 0 > >>> 8.3.7. Participation Statuses Registry . . . . . . . . . . . 16= 1 > >>> 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 16= 1 > >>> 8.3.9. Participation Roles Registry . . . . . . . . . . . . 16= 2 > >>> 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 16= 2 > >>> 8.3.11. Classifications Registry . . . . . . . . . . . . . . 16= 2 > >>> 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 16= 3 > >>> 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16= 3 > >>> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16= 4 > >>> 10.1. Normative References . . . . . . . . . . . . . . . . . . 16= 4 > >>> 10.2. Informative References . . . . . . . . . . . . . . . . . 16= 5 > >>> Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 16= 7 > >>> A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 16= 7 > >>> A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 16= 7 > >>> A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 16= 7 > >>> > >>> > >>> Notes > >>> ----- > >>> Most of the Table Of Contents give wrong page numbers > >>> > >>> Instructions: > >>> ------------- > >>> This erratum is currently posted as "Reported". If necessary, please > >>> use "Reply All" to discuss whether it should be verified or > >>> rejected. When a decision is reached, the verifying party > >>> can log in to change the status and edit the report, if necessary. > >>> > >>> -------------------------------------- > >>> RFC5545 (draft-ietf-calsify-rfc2445bis-10) > >>> -------------------------------------- > >>> Title : Internet Calendaring and Scheduling Core Object > Specification (iCalendar) > >>> Publication Date : September 2009 > >>> Author(s) : B. Desruisseaux, Ed. > >>> Category : PROPOSED STANDARD > >>> Source : Calendaring and Scheduling Standards > Simplification > >>> Area : Applications > >>> Stream : IETF > >>> Verifying Party : IESG > >> > >> > >> _______________________________________________ > >> calsify mailing list > >> calsify@ietf.org > >> https://www.ietf.org/mailman/listinfo/calsify > >> > >> > >> Attachments: > >> > >> signature.asc > >> > >> > > --000000000000d8717505b678563a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80=99ll have a look at this tomorrow and will handle= it.=C2=A0 Thanks for the poke, and the redirect.
Barry

On Mon, Dec 14, 2020 at 8:09 PM Ben Cam= pbell <ben@nostrum.com> wrote:=
This went to a bunch of ex-ART-ADs= . Forwarding to the current ones=E2=80=A6

Ben.

> On Dec 14, 2020, at 5:46 PM, Eug=C3=A8ne Adell <eugene.adell@gmail.com> wro= te:
>
> Hi guys,
>
> was it possible to decide anything on this Errata ? I think that even<= br> > a rejected one is still better, if commented appropriately for the
> future readers, as they don't (I think) investigate in the mailing=
> lists.
>
> best regards
> Eugene
>
> Le lun. 29 juil. 2019 =C3=A0 04:08, Stan Kalisch
> <s= tan@glyphein.mailforce.net> a =C3=A9crit :
>>
>> Hi,
>>
>> On Sun, Jul 28, 2019, at 8:30 AM, Eliot Lear wrote:
>>
>> The erratum is correct.=C2=A0 Good catch.=C2=A0 Under the IESG cri= teria, as this is editorial and will not cause any interoperability or othe= r implementation concerns, it is normally marked =E2=80=9Chold for update= =E2=80=9D.=C2=A0 However, because of the particular nature of this erratum,= anyone who clicks on the web searchable index gets sent to the wrong place= .=C2=A0 That=E2=80=99s annoying.=C2=A0 Suggestions?
>>
>>
>> Per https://www.ietf.org/b= log/iesg-processing-rfc-errata-ietf-stream/:
>>
>> "Only errors that could cause implementation or deployment pr= oblems or significant confusion should be Verified."
>>
>> So, the way I read it, it comes down to whether the confusion this= could cause is judged to be "significant".=C2=A0 My personal opi= nion is that, given that the table of contents should go up to page 167, an= d given that there will be more than a few marginally exhausted implementer= s likely reading this at some point, it's "significant enough.&quo= t;
>>
>>
>> Stan
>>
>> Eliot
>>
>>
>>
>>> On 28 Jul 2019, at 13:45, RFC Errata System <rfc-editor@rfc-editor.org<= /a>> wrote:
>>>
>>> The following errata report has been submitted for RFC5545, >>> "Internet Calendaring and Scheduling Core Object Specific= ation (iCalendar)".
>>>
>>> --------------------------------------
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid5794<= br> >>>
>>> --------------------------------------
>>> Type: Editorial
>>> Reported by: Eugene Adell <eugene.adell@gmail.com>
>>>
>>> Section: ToC
>>>
>>> Original Text
>>> -------------
>>>=C2=A0 1.=C2=A0 Introduction=C2=A0 . . . . . . . . . . . . . . = . . . . . . . . . .=C2=A0 =C2=A05
>>>=C2=A0 2.=C2=A0 Basic Grammar and Conventions . . . . . . . . .= . . . . . . .=C2=A0 =C2=A06
>>>=C2=A0 =C2=A0 2.1.=C2=A0 Formatting Conventions=C2=A0 . . . . .= . . . . . . . . . . . .=C2=A0 =C2=A06
>>>=C2=A0 =C2=A0 2.2.=C2=A0 Related Memos . . . . . . . . . . . . = . . . . . . . . . .=C2=A0 =C2=A07
>>>=C2=A0 3.=C2=A0 iCalendar Object Specification=C2=A0 . . . . . = . . . . . . . . . .=C2=A0 =C2=A08
>>>=C2=A0 =C2=A0 3.1.=C2=A0 Content Lines . . . . . . . . . . . . = . . . . . . . . . .=C2=A0 =C2=A08
>>>=C2=A0 =C2=A0 =C2=A0 3.1.1.=C2=A0 List and Field Separators . .= . . . . . . . . . . . .=C2=A0 11
>>>=C2=A0 =C2=A0 =C2=A0 3.1.2.=C2=A0 Multiple Values . . . . . . .= . . . . . . . . . . . .=C2=A0 11
>>>=C2=A0 =C2=A0 =C2=A0 3.1.3.=C2=A0 Binary Content=C2=A0 . . . . = . . . . . . . . . . . . . . .=C2=A0 11
>>>=C2=A0 =C2=A0 =C2=A0 3.1.4.=C2=A0 Character Set . . . . . . . .= . . . . . . . . . . . .=C2=A0 12
>>>=C2=A0 =C2=A0 3.2.=C2=A0 Property Parameters . . . . . . . . . = . . . . . . . . . .=C2=A0 12
>>>=C2=A0 =C2=A0 =C2=A0 3.2.1.=C2=A0 Alternate Text Representation= . . . . . . . . . . . .=C2=A0 13
>>>=C2=A0 =C2=A0 =C2=A0 3.2.2.=C2=A0 Common Name . . . . . . . . .= . . . . . . . . . . . .=C2=A0 15
>>>=C2=A0 =C2=A0 =C2=A0 3.2.3.=C2=A0 Calendar User Type=C2=A0 . . = . . . . . . . . . . . . . . .=C2=A0 15
>>>=C2=A0 =C2=A0 =C2=A0 3.2.4.=C2=A0 Delegators=C2=A0 . . . . . . = . . . . . . . . . . . . . . .=C2=A0 16
>>>=C2=A0 =C2=A0 =C2=A0 3.2.5.=C2=A0 Delegatees=C2=A0 . . . . . . = . . . . . . . . . . . . . . .=C2=A0 16
>>>=C2=A0 =C2=A0 =C2=A0 3.2.6.=C2=A0 Directory Entry Reference . .= . . . . . . . . . . . .=C2=A0 17
>>>=C2=A0 =C2=A0 =C2=A0 3.2.7.=C2=A0 Inline Encoding . . . . . . .= . . . . . . . . . . . .=C2=A0 17
>>>=C2=A0 =C2=A0 =C2=A0 3.2.8.=C2=A0 Format Type . . . . . . . . .= . . . . . . . . . . . .=C2=A0 18
>>>=C2=A0 =C2=A0 =C2=A0 3.2.9.=C2=A0 Free/Busy Time Type . . . . .= . . . . . . . . . . . .=C2=A0 19
>>>=C2=A0 =C2=A0 =C2=A0 3.2.10. Language=C2=A0 . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 20
>>>=C2=A0 =C2=A0 =C2=A0 3.2.11. Group or List Membership=C2=A0 . .= . . . . . . . . . . . .=C2=A0 20
>>>=C2=A0 =C2=A0 =C2=A0 3.2.12. Participation Status=C2=A0 . . . .= . . . . . . . . . . . .=C2=A0 21
>>>=C2=A0 =C2=A0 =C2=A0 3.2.13. Recurrence Identifier Range . . . = . . . . . . . . . .=C2=A0 22
>>>=C2=A0 =C2=A0 =C2=A0 3.2.14. Alarm Trigger Relationship=C2=A0 .= . . . . . . . . . . . .=C2=A0 23
>>>=C2=A0 =C2=A0 =C2=A0 3.2.15. Relationship Type . . . . . . . . = . . . . . . . . . .=C2=A0 24
>>>=C2=A0 =C2=A0 =C2=A0 3.2.16. Participation Role=C2=A0 . . . . .= . . . . . . . . . . . .=C2=A0 25
>>>=C2=A0 =C2=A0 =C2=A0 3.2.17. RSVP Expectation=C2=A0 . . . . . .= . . . . . . . . . . . .=C2=A0 25
>>>=C2=A0 =C2=A0 =C2=A0 3.2.18. Sent By . . . . . . . . . . . . . = . . . . . . . . . .=C2=A0 26
>>>=C2=A0 =C2=A0 =C2=A0 3.2.19. Time Zone Identifier=C2=A0 . . . .= . . . . . . . . . . . .=C2=A0 26
>>>=C2=A0 =C2=A0 =C2=A0 3.2.20. Value Data Types=C2=A0 . . . . . .= . . . . . . . . . . . .=C2=A0 28
>>>=C2=A0 =C2=A0 3.3.=C2=A0 Property Value Data Types . . . . . . = . . . . . . . . . .=C2=A0 29
>>>=C2=A0 =C2=A0 =C2=A0 3.3.1.=C2=A0 Binary=C2=A0 . . . . . . . . = . . . . . . . . . . . . . . .=C2=A0 29
>>>=C2=A0 =C2=A0 =C2=A0 3.3.2.=C2=A0 Boolean . . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 30
>>>=C2=A0 =C2=A0 =C2=A0 3.3.3.=C2=A0 Calendar User Address . . . .= . . . . . . . . . . . .=C2=A0 30
>>>=C2=A0 =C2=A0 =C2=A0 3.3.4.=C2=A0 Date=C2=A0 . . . . . . . . . = . . . . . . . . . . . . . . .=C2=A0 31
>>>=C2=A0 =C2=A0 =C2=A0 3.3.5.=C2=A0 Date-Time . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 31
>>>=C2=A0 =C2=A0 =C2=A0 3.3.6.=C2=A0 Duration=C2=A0 . . . . . . . = . . . . . . . . . . . . . . .=C2=A0 34
>>>=C2=A0 =C2=A0 =C2=A0 3.3.7.=C2=A0 Float . . . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 35
>>>=C2=A0 =C2=A0 =C2=A0 3.3.8.=C2=A0 Integer . . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 35
>>>=C2=A0 =C2=A0 =C2=A0 3.3.9.=C2=A0 Period of Time=C2=A0 . . . . = . . . . . . . . . . . . . . .=C2=A0 36
>>>=C2=A0 =C2=A0 =C2=A0 3.3.10. Recurrence Rule . . . . . . . . . = . . . . . . . . . .=C2=A0 37
>>>=C2=A0 =C2=A0 =C2=A0 3.3.11. Text=C2=A0 . . . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 45
>>>=C2=A0 =C2=A0 =C2=A0 3.3.12. Time=C2=A0 . . . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 46
>>>=C2=A0 =C2=A0 =C2=A0 3.3.13. URI . . . . . . . . . . . . . . . = . . . . . . . . . .=C2=A0 48
>>>=C2=A0 =C2=A0 =C2=A0 3.3.14. UTC Offset=C2=A0 . . . . . . . . .= . . . . . . . . . . . .=C2=A0 49
>>>=C2=A0 =C2=A0 3.4.=C2=A0 iCalendar Object=C2=A0 . . . . . . . .= . . . . . . . . . . . .=C2=A0 49
>>>=C2=A0 =C2=A0 3.5.=C2=A0 Property=C2=A0 . . . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 50
>>>=C2=A0 =C2=A0 3.6.=C2=A0 Calendar Components . . . . . . . . . = . . . . . . . . . .=C2=A0 50
>>>=C2=A0 =C2=A0 =C2=A0 3.6.1.=C2=A0 Event Component . . . . . . .= . . . . . . . . . . . .=C2=A0 52
>>>=C2=A0 =C2=A0 =C2=A0 3.6.2.=C2=A0 To-Do Component . . . . . . .= . . . . . . . . . . . .=C2=A0 56
>>>=C2=A0 =C2=A0 =C2=A0 3.6.3.=C2=A0 Journal Component . . . . . .= . . . . . . . . . . . .=C2=A0 58
>>>=C2=A0 =C2=A0 =C2=A0 3.6.4.=C2=A0 Free/Busy Component . . . . .= . . . . . . . . . . . .=C2=A0 60
>>>=C2=A0 =C2=A0 =C2=A0 3.6.5.=C2=A0 Time Zone Component . . . . .= . . . . . . . . . . . .=C2=A0 63
>>>=C2=A0 =C2=A0 =C2=A0 3.6.6.=C2=A0 Alarm Component . . . . . . .= . . . . . . . . . . . .=C2=A0 72
>>>=C2=A0 =C2=A0 3.7.=C2=A0 Calendar Properties . . . . . . . . . = . . . . . . . . . .=C2=A0 77
>>>=C2=A0 =C2=A0 =C2=A0 3.7.1.=C2=A0 Calendar Scale=C2=A0 . . . . = . . . . . . . . . . . . . . .=C2=A0 77
>>>=C2=A0 =C2=A0 =C2=A0 3.7.2.=C2=A0 Method=C2=A0 . . . . . . . . = . . . . . . . . . . . . . . .=C2=A0 78
>>>=C2=A0 =C2=A0 =C2=A0 3.7.3.=C2=A0 Product Identifier=C2=A0 . . = . . . . . . . . . . . . . . .=C2=A0 79
>>>=C2=A0 =C2=A0 =C2=A0 3.7.4.=C2=A0 Version . . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 80
>>>=C2=A0 =C2=A0 3.8.=C2=A0 Component Properties=C2=A0 . . . . . .= . . . . . . . . . . . .=C2=A0 81
>>>=C2=A0 =C2=A0 =C2=A0 3.8.1.=C2=A0 Descriptive Component Propert= ies=C2=A0 . . . . . . . . . .=C2=A0 81
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.1.=C2=A0 Attachment=C2=A0 . .= . . . . . . . . . . . . . . . . .=C2=A0 81
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.2.=C2=A0 Categories=C2=A0 . .= . . . . . . . . . . . . . . . . .=C2=A0 82
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.3.=C2=A0 Classification=C2=A0= . . . . . . . . . . . . . . . . .=C2=A0 83
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.4.=C2=A0 Comment . . . . . . = . . . . . . . . . . . . . . .=C2=A0 84
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.5.=C2=A0 Description . . . . = . . . . . . . . . . . . . . .=C2=A0 85
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.6.=C2=A0 Geographic Position = . . . . . . . . . . . . . . .=C2=A0 87
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.7.=C2=A0 Location=C2=A0 . . .= . . . . . . . . . . . . . . . . .=C2=A0 88
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.8.=C2=A0 Percent Complete=C2= =A0 . . . . . . . . . . . . . . . .=C2=A0 89
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.9.=C2=A0 Priority=C2=A0 . . .= . . . . . . . . . . . . . . . . .=C2=A0 90
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.10. Resources . . . . . . . .= . . . . . . . . . . . .=C2=A0 92
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.11. Status=C2=A0 . . . . . . = . . . . . . . . . . . . . . .=C2=A0 93
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.12. Summary . . . . . . . . .= . . . . . . . . . . . .=C2=A0 94
>>>=C2=A0 =C2=A0 =C2=A0 3.8.2.=C2=A0 Date and Time Component Prope= rties=C2=A0 . . . . . . . . .=C2=A0 95
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.2.1.=C2=A0 Date-Time Completed = . . . . . . . . . . . . . . .=C2=A0 95
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.2.2.=C2=A0 Date-Time End . . . = . . . . . . . . . . . . . . .=C2=A0 96
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.2.3.=C2=A0 Date-Time Due . . . = . . . . . . . . . . . . . . .=C2=A0 97
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.2.4.=C2=A0 Date-Time Start . . = . . . . . . . . . . . . . . .=C2=A0 99
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.2.5.=C2=A0 Duration=C2=A0 . . .= . . . . . . . . . . . . . . . . . 100
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.2.6.=C2=A0 Free/Busy Time=C2=A0= . . . . . . . . . . . . . . . . . 101
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.2.7.=C2=A0 Time Transparency . = . . . . . . . . . . . . . . . 102
>>>=C2=A0 =C2=A0 =C2=A0 3.8.3.=C2=A0 Time Zone Component Propertie= s=C2=A0 . . . . . . . . . . . 103
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.3.1.=C2=A0 Time Zone Identifier= =C2=A0 . . . . . . . . . . . . . . 103
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.3.2.=C2=A0 Time Zone Name=C2=A0= . . . . . . . . . . . . . . . . . 105
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.3.3.=C2=A0 Time Zone Offset Fro= m . . . . . . . . . . . . . . 106
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.3.4.=C2=A0 Time Zone Offset To = . . . . . . . . . . . . . . . 106
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.3.5.=C2=A0 Time Zone URL . . . = . . . . . . . . . . . . . . . 107
>>>=C2=A0 =C2=A0 =C2=A0 3.8.4.=C2=A0 Relationship Component Proper= ties . . . . . . . . . . 108
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.4.1.=C2=A0 Attendee=C2=A0 . . .= . . . . . . . . . . . . . . . . . 108
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.4.2.=C2=A0 Contact . . . . . . = . . . . . . . . . . . . . . . 111
>>>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.4.3.=C2=A0 Organizer . . . . . = . . . . . . . . . . . . . . . 113
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.4.4.=C2=A0 Recurrence ID . . . = . . . . . . . . . . . . . . . 114
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.4.5.=C2=A0 Related To=C2=A0 . .= . . . . . . . . . . . . . . . . . 117
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.4.6.=C2=A0 Uniform Resource Loc= ator=C2=A0 . . . . . . . . . . . . 118
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.4.7.=C2=A0 Unique Identifier . = . . . . . . . . . . . . . . . 119
>>>=C2=A0 =C2=A0 =C2=A0 3.8.5.=C2=A0 Recurrence Component Properti= es . . . . . . . . . . . 120
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.5.1.=C2=A0 Exception Date-Times= =C2=A0 . . . . . . . . . . . . . . 120
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.5.2.=C2=A0 Recurrence Date-Time= s . . . . . . . . . . . . . . 122
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.5.3.=C2=A0 Recurrence Rule . . = . . . . . . . . . . . . . . . 124
>>>=C2=A0 =C2=A0 =C2=A0 3.8.6.=C2=A0 Alarm Component Properties=C2= =A0 . . . . . . . . . . . . . 134
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.6.1.=C2=A0 Action=C2=A0 . . . .= . . . . . . . . . . . . . . . . . 134
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.6.2.=C2=A0 Repeat Count=C2=A0 .= . . . . . . . . . . . . . . . . . 135
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.6.3.=C2=A0 Trigger . . . . . . = . . . . . . . . . . . . . . . 135
>>>=C2=A0 =C2=A0 =C2=A0 3.8.7.=C2=A0 Change Management Component P= roperties=C2=A0 . . . . . . . 138
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.7.1.=C2=A0 Date-Time Created . = . . . . . . . . . . . . . . . 138
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.7.2.=C2=A0 Date-Time Stamp . . = . . . . . . . . . . . . . . . 139
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.7.3.=C2=A0 Last Modified . . . = . . . . . . . . . . . . . . . 140
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.7.4.=C2=A0 Sequence Number . . = . . . . . . . . . . . . . . . 141
>>>=C2=A0 =C2=A0 =C2=A0 3.8.8.=C2=A0 Miscellaneous Component Prope= rties=C2=A0 . . . . . . . . . 142
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.8.1.=C2=A0 IANA Properties . . = . . . . . . . . . . . . . . . 142
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.8.2.=C2=A0 Non-Standard Propert= ies . . . . . . . . . . . . . 142
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.8.3.=C2=A0 Request Status=C2=A0= . . . . . . . . . . . . . . . . . 144
>>>=C2=A0 4.=C2=A0 iCalendar Object Examples . . . . . . . . . . .= . . . . . . . 146
>>>=C2=A0 5.=C2=A0 Recommended Practices . . . . . . . . . . . . .= . . . . . . . 150
>>>=C2=A0 6.=C2=A0 Internationalization Considerations . . . . . .= . . . . . . . 151
>>>=C2=A0 7.=C2=A0 Security Considerations . . . . . . . . . . . .= . . . . . . . 151
>>>=C2=A0 8.=C2=A0 IANA Considerations . . . . . . . . . . . . . .= . . . . . . . 151
>>>=C2=A0 =C2=A0 8.1.=C2=A0 iCalendar Media Type Registration . . = . . . . . . . . . . 151
>>>=C2=A0 =C2=A0 8.2.=C2=A0 New iCalendar Elements Registration . = . . . . . . . . . . 155
>>>=C2=A0 =C2=A0 =C2=A0 8.2.1.=C2=A0 iCalendar Elements Registrati= on Procedure . . . . . . 155
>>>=C2=A0 =C2=A0 =C2=A0 8.2.2.=C2=A0 Registration Template for Com= ponents=C2=A0 . . . . . . . . 155
>>>=C2=A0 =C2=A0 =C2=A0 8.2.3.=C2=A0 Registration Template for Pro= perties=C2=A0 . . . . . . . . 156
>>>=C2=A0 =C2=A0 =C2=A0 8.2.4.=C2=A0 Registration Template for Par= ameters=C2=A0 . . . . . . . . 156
>>>=C2=A0 =C2=A0 =C2=A0 8.2.5.=C2=A0 Registration Template for Val= ue Data Types=C2=A0 . . . . . 157
>>>=C2=A0 =C2=A0 =C2=A0 8.2.6.=C2=A0 Registration Template for Val= ues=C2=A0 . . . . . . . . . . 157
>>>=C2=A0 =C2=A0 8.3.=C2=A0 Initial iCalendar Elements Registries = . . . . . . . . . . 158
>>>=C2=A0 =C2=A0 =C2=A0 8.3.1.=C2=A0 Components Registry . . . . .= . . . . . . . . . . . . 158
>>>=C2=A0 =C2=A0 =C2=A0 8.3.2.=C2=A0 Properties Registry . . . . .= . . . . . . . . . . . . 158
>>>=C2=A0 =C2=A0 =C2=A0 8.3.3.=C2=A0 Parameters Registry . . . . .= . . . . . . . . . . . . 161
>>>=C2=A0 =C2=A0 =C2=A0 8.3.4.=C2=A0 Value Data Types Registry . .= . . . . . . . . . . . . 162
>>>=C2=A0 =C2=A0 =C2=A0 8.3.5.=C2=A0 Calendar User Types Registry= =C2=A0 . . . . . . . . . . . . 162
>>>=C2=A0 =C2=A0 =C2=A0 8.3.6.=C2=A0 Free/Busy Time Types Registry= . . . . . . . . . . . . 163
>>>=C2=A0 =C2=A0 =C2=A0 8.3.7.=C2=A0 Participation Statuses Regist= ry . . . . . . . . . . . 163
>>>=C2=A0 =C2=A0 =C2=A0 8.3.8.=C2=A0 Relationship Types Registry .= . . . . . . . . . . . . 164
>>>=C2=A0 =C2=A0 =C2=A0 8.3.9.=C2=A0 Participation Roles Registry= =C2=A0 . . . . . . . . . . . . 164
>>>=C2=A0 =C2=A0 =C2=A0 8.3.10. Actions Registry=C2=A0 . . . . . .= . . . . . . . . . . . . 165
>>>=C2=A0 =C2=A0 =C2=A0 8.3.11. Classifications Registry=C2=A0 . .= . . . . . . . . . . . . 165
>>>=C2=A0 =C2=A0 =C2=A0 8.3.12. Methods Registry=C2=A0 . . . . . .= . . . . . . . . . . . . 165
>>>=C2=A0 9.=C2=A0 Acknowledgments . . . . . . . . . . . . . . . .= . . . . . . . 165
>>>=C2=A0 10. References=C2=A0 . . . . . . . . . . . . . . . . . .= . . . . . . . 166
>>>=C2=A0 =C2=A0 10.1. Normative References=C2=A0 . . . . . . . . = . . . . . . . . . . 166
>>>=C2=A0 =C2=A0 10.2. Informative References=C2=A0 . . . . . . . = . . . . . . . . . . 167
>>>=C2=A0 Appendix A.=C2=A0 Differences from RFC 2445=C2=A0 . . . = . . . . . . . . . . 169
>>>=C2=A0 =C2=A0 A.1.=C2=A0 New Restrictions=C2=A0 . . . . . . . .= . . . . . . . . . . . . 169
>>>=C2=A0 =C2=A0 A.2.=C2=A0 Restrictions Removed=C2=A0 . . . . . .= . . . . . . . . . . . . 169
>>>=C2=A0 =C2=A0 A.3.=C2=A0 Deprecated Features . . . . . . . . . = . . . . . . . . . . 169
>>>
>>>
>>> Corrected Text
>>> --------------
>>>=C2=A0 1.=C2=A0 Introduction=C2=A0 . . . . . . . . . . . . . . = . . . . . . . . . .=C2=A0 =C2=A05
>>>=C2=A0 2.=C2=A0 Basic Grammar and Conventions . . . . . . . . .= . . . . . . .=C2=A0 =C2=A06
>>>=C2=A0 =C2=A0 2.1.=C2=A0 Formatting Conventions=C2=A0 . . . . .= . . . . . . . . . . . .=C2=A0 =C2=A06
>>>=C2=A0 =C2=A0 2.2.=C2=A0 Related Memos . . . . . . . . . . . . = . . . . . . . . . .=C2=A0 =C2=A08
>>>=C2=A0 3.=C2=A0 iCalendar Object Specification=C2=A0 . . . . . = . . . . . . . . . .=C2=A0 =C2=A08
>>>=C2=A0 =C2=A0 3.1.=C2=A0 Content Lines . . . . . . . . . . . . = . . . . . . . . . .=C2=A0 =C2=A09
>>>=C2=A0 =C2=A0 =C2=A0 3.1.1.=C2=A0 List and Field Separators . .= . . . . . . . . . . . .=C2=A0 11
>>>=C2=A0 =C2=A0 =C2=A0 3.1.2.=C2=A0 Multiple Values . . . . . . .= . . . . . . . . . . . .=C2=A0 12
>>>=C2=A0 =C2=A0 =C2=A0 3.1.3.=C2=A0 Binary Content=C2=A0 . . . . = . . . . . . . . . . . . . . .=C2=A0 12
>>>=C2=A0 =C2=A0 =C2=A0 3.1.4.=C2=A0 Character Set . . . . . . . .= . . . . . . . . . . . .=C2=A0 13
>>>=C2=A0 =C2=A0 3.2.=C2=A0 Property Parameters . . . . . . . . . = . . . . . . . . . .=C2=A0 13
>>>=C2=A0 =C2=A0 =C2=A0 3.2.1.=C2=A0 Alternate Text Representation= . . . . . . . . . . . .=C2=A0 14
>>>=C2=A0 =C2=A0 =C2=A0 3.2.2.=C2=A0 Common Name . . . . . . . . .= . . . . . . . . . . . .=C2=A0 15
>>>=C2=A0 =C2=A0 =C2=A0 3.2.3.=C2=A0 Calendar User Type=C2=A0 . . = . . . . . . . . . . . . . . .=C2=A0 16
>>>=C2=A0 =C2=A0 =C2=A0 3.2.4.=C2=A0 Delegators=C2=A0 . . . . . . = . . . . . . . . . . . . . . .=C2=A0 17
>>>=C2=A0 =C2=A0 =C2=A0 3.2.5.=C2=A0 Delegatees=C2=A0 . . . . . . = . . . . . . . . . . . . . . .=C2=A0 17
>>>=C2=A0 =C2=A0 =C2=A0 3.2.6.=C2=A0 Directory Entry Reference . .= . . . . . . . . . . . .=C2=A0 18
>>>=C2=A0 =C2=A0 =C2=A0 3.2.7.=C2=A0 Inline Encoding . . . . . . .= . . . . . . . . . . . .=C2=A0 18
>>>=C2=A0 =C2=A0 =C2=A0 3.2.8.=C2=A0 Format Type . . . . . . . . .= . . . . . . . . . . . .=C2=A0 19
>>>=C2=A0 =C2=A0 =C2=A0 3.2.9.=C2=A0 Free/Busy Time Type . . . . .= . . . . . . . . . . . .=C2=A0 20
>>>=C2=A0 =C2=A0 =C2=A0 3.2.10. Language=C2=A0 . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 21
>>>=C2=A0 =C2=A0 =C2=A0 3.2.11. Group or List Membership=C2=A0 . .= . . . . . . . . . . . .=C2=A0 21
>>>=C2=A0 =C2=A0 =C2=A0 3.2.12. Participation Status=C2=A0 . . . .= . . . . . . . . . . . .=C2=A0 22
>>>=C2=A0 =C2=A0 =C2=A0 3.2.13. Recurrence Identifier Range . . . = . . . . . . . . . .=C2=A0 23
>>>=C2=A0 =C2=A0 =C2=A0 3.2.14. Alarm Trigger Relationship=C2=A0 .= . . . . . . . . . . . .=C2=A0 24
>>>=C2=A0 =C2=A0 =C2=A0 3.2.15. Relationship Type . . . . . . . . = . . . . . . . . . .=C2=A0 25
>>>=C2=A0 =C2=A0 =C2=A0 3.2.16. Participation Role=C2=A0 . . . . .= . . . . . . . . . . . .=C2=A0 25
>>>=C2=A0 =C2=A0 =C2=A0 3.2.17. RSVP Expectation=C2=A0 . . . . . .= . . . . . . . . . . . .=C2=A0 26
>>>=C2=A0 =C2=A0 =C2=A0 3.2.18. Sent By . . . . . . . . . . . . . = . . . . . . . . . .=C2=A0 27
>>>=C2=A0 =C2=A0 =C2=A0 3.2.19. Time Zone Identifier=C2=A0 . . . .= . . . . . . . . . . . .=C2=A0 27
>>>=C2=A0 =C2=A0 =C2=A0 3.2.20. Value Data Types=C2=A0 . . . . . .= . . . . . . . . . . . .=C2=A0 29
>>>=C2=A0 =C2=A0 3.3.=C2=A0 Property Value Data Types . . . . . . = . . . . . . . . . .=C2=A0 30
>>>=C2=A0 =C2=A0 =C2=A0 3.3.1.=C2=A0 Binary=C2=A0 . . . . . . . . = . . . . . . . . . . . . . . .=C2=A0 30
>>>=C2=A0 =C2=A0 =C2=A0 3.3.2.=C2=A0 Boolean . . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 31
>>>=C2=A0 =C2=A0 =C2=A0 3.3.3.=C2=A0 Calendar User Address . . . .= . . . . . . . . . . . .=C2=A0 31
>>>=C2=A0 =C2=A0 =C2=A0 3.3.4.=C2=A0 Date=C2=A0 . . . . . . . . . = . . . . . . . . . . . . . . .=C2=A0 32
>>>=C2=A0 =C2=A0 =C2=A0 3.3.5.=C2=A0 Date-Time . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 32
>>>=C2=A0 =C2=A0 =C2=A0 3.3.6.=C2=A0 Duration=C2=A0 . . . . . . . = . . . . . . . . . . . . . . .=C2=A0 35
>>>=C2=A0 =C2=A0 =C2=A0 3.3.7.=C2=A0 Float . . . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 36
>>>=C2=A0 =C2=A0 =C2=A0 3.3.8.=C2=A0 Integer . . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 37
>>>=C2=A0 =C2=A0 =C2=A0 3.3.9.=C2=A0 Period of Time=C2=A0 . . . . = . . . . . . . . . . . . . . .=C2=A0 37
>>>=C2=A0 =C2=A0 =C2=A0 3.3.10. Recurrence Rule . . . . . . . . . = . . . . . . . . . .=C2=A0 38
>>>=C2=A0 =C2=A0 =C2=A0 3.3.11. Text=C2=A0 . . . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 45
>>>=C2=A0 =C2=A0 =C2=A0 3.3.12. Time=C2=A0 . . . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 47
>>>=C2=A0 =C2=A0 =C2=A0 3.3.13. URI . . . . . . . . . . . . . . . = . . . . . . . . . .=C2=A0 49
>>>=C2=A0 =C2=A0 =C2=A0 3.3.14. UTC Offset=C2=A0 . . . . . . . . .= . . . . . . . . . . . .=C2=A0 49
>>>=C2=A0 =C2=A0 3.4.=C2=A0 iCalendar Object=C2=A0 . . . . . . . .= . . . . . . . . . . . .=C2=A0 50
>>>=C2=A0 =C2=A0 3.5.=C2=A0 Property=C2=A0 . . . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 51
>>>=C2=A0 =C2=A0 3.6.=C2=A0 Calendar Components . . . . . . . . . = . . . . . . . . . .=C2=A0 51
>>>=C2=A0 =C2=A0 =C2=A0 3.6.1.=C2=A0 Event Component . . . . . . .= . . . . . . . . . . . .=C2=A0 52
>>>=C2=A0 =C2=A0 =C2=A0 3.6.2.=C2=A0 To-Do Component . . . . . . .= . . . . . . . . . . . .=C2=A0 55
>>>=C2=A0 =C2=A0 =C2=A0 3.6.3.=C2=A0 Journal Component . . . . . .= . . . . . . . . . . . .=C2=A0 57
>>>=C2=A0 =C2=A0 =C2=A0 3.6.4.=C2=A0 Free/Busy Component . . . . .= . . . . . . . . . . . .=C2=A0 59
>>>=C2=A0 =C2=A0 =C2=A0 3.6.5.=C2=A0 Time Zone Component . . . . .= . . . . . . . . . . . .=C2=A0 62
>>>=C2=A0 =C2=A0 =C2=A0 3.6.6.=C2=A0 Alarm Component . . . . . . .= . . . . . . . . . . . .=C2=A0 71
>>>=C2=A0 =C2=A0 3.7.=C2=A0 Calendar Properties . . . . . . . . . = . . . . . . . . . .=C2=A0 76
>>>=C2=A0 =C2=A0 =C2=A0 3.7.1.=C2=A0 Calendar Scale=C2=A0 . . . . = . . . . . . . . . . . . . . .=C2=A0 76
>>>=C2=A0 =C2=A0 =C2=A0 3.7.2.=C2=A0 Method=C2=A0 . . . . . . . . = . . . . . . . . . . . . . . .=C2=A0 77
>>>=C2=A0 =C2=A0 =C2=A0 3.7.3.=C2=A0 Product Identifier=C2=A0 . . = . . . . . . . . . . . . . . .=C2=A0 78
>>>=C2=A0 =C2=A0 =C2=A0 3.7.4.=C2=A0 Version . . . . . . . . . . .= . . . . . . . . . . . .=C2=A0 79
>>>=C2=A0 =C2=A0 3.8.=C2=A0 Component Properties=C2=A0 . . . . . .= . . . . . . . . . . . .=C2=A0 80
>>>=C2=A0 =C2=A0 =C2=A0 3.8.1.=C2=A0 Descriptive Component Propert= ies=C2=A0 . . . . . . . . . .=C2=A0 80
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.1.=C2=A0 Attachment=C2=A0 . .= . . . . . . . . . . . . . . . . .=C2=A0 80
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.2.=C2=A0 Categories=C2=A0 . .= . . . . . . . . . . . . . . . . .=C2=A0 81
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.3.=C2=A0 Classification=C2=A0= . . . . . . . . . . . . . . . . .=C2=A0 82
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.4.=C2=A0 Comment . . . . . . = . . . . . . . . . . . . . . .=C2=A0 83
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.5.=C2=A0 Description . . . . = . . . . . . . . . . . . . . .=C2=A0 84
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.6.=C2=A0 Geographic Position = . . . . . . . . . . . . . . .=C2=A0 85
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.7.=C2=A0 Location=C2=A0 . . .= . . . . . . . . . . . . . . . . .=C2=A0 87
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.8.=C2=A0 Percent Complete=C2= =A0 . . . . . . . . . . . . . . . .=C2=A0 88
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.9.=C2=A0 Priority=C2=A0 . . .= . . . . . . . . . . . . . . . . .=C2=A0 89
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.10. Resources . . . . . . . .= . . . . . . . . . . . .=C2=A0 91
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.11. Status=C2=A0 . . . . . . = . . . . . . . . . . . . . . .=C2=A0 92
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.1.12. Summary . . . . . . . . .= . . . . . . . . . . . .=C2=A0 93
>>>=C2=A0 =C2=A0 =C2=A0 3.8.2.=C2=A0 Date and Time Component Prope= rties=C2=A0 . . . . . . . . .=C2=A0 94
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.2.1.=C2=A0 Date-Time Completed = . . . . . . . . . . . . . . .=C2=A0 94
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.2.2.=C2=A0 Date-Time End . . . = . . . . . . . . . . . . . . .=C2=A0 95
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.2.3.=C2=A0 Date-Time Due . . . = . . . . . . . . . . . . . . .=C2=A0 96
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.2.4.=C2=A0 Date-Time Start . . = . . . . . . . . . . . . . . .=C2=A0 97
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.2.5.=C2=A0 Duration=C2=A0 . . .= . . . . . . . . . . . . . . . . .=C2=A0 99
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.2.6.=C2=A0 Free/Busy Time=C2=A0= . . . . . . . . . . . . . . . . . 100
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.2.7.=C2=A0 Time Transparency . = . . . . . . . . . . . . . . . 101
>>>=C2=A0 =C2=A0 =C2=A0 3.8.3.=C2=A0 Time Zone Component Propertie= s=C2=A0 . . . . . . . . . . . 102
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.3.1.=C2=A0 Time Zone Identifier= =C2=A0 . . . . . . . . . . . . . . 102
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.3.2.=C2=A0 Time Zone Name=C2=A0= . . . . . . . . . . . . . . . . . 103
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.3.3.=C2=A0 Time Zone Offset Fro= m . . . . . . . . . . . . . . 104
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.3.4.=C2=A0 Time Zone Offset To = . . . . . . . . . . . . . . . 105
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.3.5.=C2=A0 Time Zone URL . . . = . . . . . . . . . . . . . . . 106
>>>=C2=A0 =C2=A0 =C2=A0 3.8.4.=C2=A0 Relationship Component Proper= ties . . . . . . . . . . 106
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.4.1.=C2=A0 Attendee=C2=A0 . . .= . . . . . . . . . . . . . . . . . 107
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.4.2.=C2=A0 Contact . . . . . . = . . . . . . . . . . . . . . . 109
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.4.3.=C2=A0 Organizer . . . . . = . . . . . . . . . . . . . . . 111
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.4.4.=C2=A0 Recurrence ID . . . = . . . . . . . . . . . . . . . 112
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.4.5.=C2=A0 Related To=C2=A0 . .= . . . . . . . . . . . . . . . . . 115
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.4.6.=C2=A0 Uniform Resource Loc= ator=C2=A0 . . . . . . . . . . . . 116
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.4.7.=C2=A0 Unique Identifier . = . . . . . . . . . . . . . . . 117
>>>=C2=A0 =C2=A0 =C2=A0 3.8.5.=C2=A0 Recurrence Component Properti= es . . . . . . . . . . . 118
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.5.1.=C2=A0 Exception Date-Times= =C2=A0 . . . . . . . . . . . . . . 118
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.5.2.=C2=A0 Recurrence Date-Time= s . . . . . . . . . . . . . . 120
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.5.3.=C2=A0 Recurrence Rule . . = . . . . . . . . . . . . . . . 122
>>>=C2=A0 =C2=A0 =C2=A0 3.8.6.=C2=A0 Alarm Component Properties=C2= =A0 . . . . . . . . . . . . . 132
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.6.1.=C2=A0 Action=C2=A0 . . . .= . . . . . . . . . . . . . . . . . 132
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.6.2.=C2=A0 Repeat Count=C2=A0 .= . . . . . . . . . . . . . . . . . 133
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.6.3.=C2=A0 Trigger . . . . . . = . . . . . . . . . . . . . . . 133
>>>=C2=A0 =C2=A0 =C2=A0 3.8.7.=C2=A0 Change Management Component P= roperties=C2=A0 . . . . . . . 136
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.7.1.=C2=A0 Date-Time Created . = . . . . . . . . . . . . . . . 136
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.7.2.=C2=A0 Date-Time Stamp . . = . . . . . . . . . . . . . . . 137
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.7.3.=C2=A0 Last Modified . . . = . . . . . . . . . . . . . . . 138
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.7.4.=C2=A0 Sequence Number . . = . . . . . . . . . . . . . . . 138
>>>=C2=A0 =C2=A0 =C2=A0 3.8.8.=C2=A0 Miscellaneous Component Prope= rties=C2=A0 . . . . . . . . . 139
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.8.1.=C2=A0 IANA Properties . . = . . . . . . . . . . . . . . . 140
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.8.2.=C2=A0 Non-Standard Propert= ies . . . . . . . . . . . . . 140
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.8.8.3.=C2=A0 Request Status=C2=A0= . . . . . . . . . . . . . . . . . 141
>>>=C2=A0 4.=C2=A0 iCalendar Object Examples . . . . . . . . . . .= . . . . . . . 144
>>>=C2=A0 5.=C2=A0 Recommended Practices . . . . . . . . . . . . .= . . . . . . . 147
>>>=C2=A0 6.=C2=A0 Internationalization Considerations . . . . . .= . . . . . . . 148
>>>=C2=A0 7.=C2=A0 Security Considerations . . . . . . . . . . . .= . . . . . . . 148
>>>=C2=A0 8.=C2=A0 IANA Considerations . . . . . . . . . . . . . .= . . . . . . . 149
>>>=C2=A0 =C2=A0 8.1.=C2=A0 iCalendar Media Type Registration . . = . . . . . . . . . . 149
>>>=C2=A0 =C2=A0 8.2.=C2=A0 New iCalendar Elements Registration . = . . . . . . . . . . 152
>>>=C2=A0 =C2=A0 =C2=A0 8.2.1.=C2=A0 iCalendar Elements Registrati= on Procedure . . . . . . 152
>>>=C2=A0 =C2=A0 =C2=A0 8.2.2.=C2=A0 Registration Template for Com= ponents=C2=A0 . . . . . . . . 152
>>>=C2=A0 =C2=A0 =C2=A0 8.2.3.=C2=A0 Registration Template for Pro= perties=C2=A0 . . . . . . . . 153
>>>=C2=A0 =C2=A0 =C2=A0 8.2.4.=C2=A0 Registration Template for Par= ameters=C2=A0 . . . . . . . . 153
>>>=C2=A0 =C2=A0 =C2=A0 8.2.5.=C2=A0 Registration Template for Val= ue Data Types=C2=A0 . . . . . 154
>>>=C2=A0 =C2=A0 =C2=A0 8.2.6.=C2=A0 Registration Template for Val= ues=C2=A0 . . . . . . . . . . 154
>>>=C2=A0 =C2=A0 8.3.=C2=A0 Initial iCalendar Elements Registries = . . . . . . . . . . 155
>>>=C2=A0 =C2=A0 =C2=A0 8.3.1.=C2=A0 Components Registry . . . . .= . . . . . . . . . . . . 155
>>>=C2=A0 =C2=A0 =C2=A0 8.3.2.=C2=A0 Properties Registry . . . . .= . . . . . . . . . . . . 156
>>>=C2=A0 =C2=A0 =C2=A0 8.3.3.=C2=A0 Parameters Registry . . . . .= . . . . . . . . . . . . 158
>>>=C2=A0 =C2=A0 =C2=A0 8.3.4.=C2=A0 Value Data Types Registry . .= . . . . . . . . . . . . 159
>>>=C2=A0 =C2=A0 =C2=A0 8.3.5.=C2=A0 Calendar User Types Registry= =C2=A0 . . . . . . . . . . . . 160
>>>=C2=A0 =C2=A0 =C2=A0 8.3.6.=C2=A0 Free/Busy Time Types Registry= . . . . . . . . . . . . 160
>>>=C2=A0 =C2=A0 =C2=A0 8.3.7.=C2=A0 Participation Statuses Regist= ry . . . . . . . . . . . 161
>>>=C2=A0 =C2=A0 =C2=A0 8.3.8.=C2=A0 Relationship Types Registry .= . . . . . . . . . . . . 161
>>>=C2=A0 =C2=A0 =C2=A0 8.3.9.=C2=A0 Participation Roles Registry= =C2=A0 . . . . . . . . . . . . 162
>>>=C2=A0 =C2=A0 =C2=A0 8.3.10. Actions Registry=C2=A0 . . . . . .= . . . . . . . . . . . . 162
>>>=C2=A0 =C2=A0 =C2=A0 8.3.11. Classifications Registry=C2=A0 . .= . . . . . . . . . . . . 162
>>>=C2=A0 =C2=A0 =C2=A0 8.3.12. Methods Registry=C2=A0 . . . . . .= . . . . . . . . . . . . 163
>>>=C2=A0 9.=C2=A0 Acknowledgments . . . . . . . . . . . . . . . .= . . . . . . . 163
>>>=C2=A0 10. References=C2=A0 . . . . . . . . . . . . . . . . . .= . . . . . . . 164
>>>=C2=A0 =C2=A0 10.1. Normative References=C2=A0 . . . . . . . . = . . . . . . . . . . 164
>>>=C2=A0 =C2=A0 10.2. Informative References=C2=A0 . . . . . . . = . . . . . . . . . . 165
>>>=C2=A0 Appendix A.=C2=A0 Differences from RFC 2445=C2=A0 . . . = . . . . . . . . . . 167
>>>=C2=A0 =C2=A0 A.1.=C2=A0 New Restrictions=C2=A0 . . . . . . . .= . . . . . . . . . . . . 167
>>>=C2=A0 =C2=A0 A.2.=C2=A0 Restrictions Removed=C2=A0 . . . . . .= . . . . . . . . . . . . 167
>>>=C2=A0 =C2=A0 A.3.=C2=A0 Deprecated Features . . . . . . . . . = . . . . . . . . . . 167
>>>
>>>
>>> Notes
>>> -----
>>> Most of the Table Of Contents give wrong page numbers
>>>
>>> Instructions:
>>> -------------
>>> This erratum is currently posted as "Reported". If n= ecessary, please
>>> use "Reply All" to discuss whether it should be veri= fied or
>>> rejected. When a decision is reached, the verifying party
>>> can log in to change the status and edit the report, if necess= ary.
>>>
>>> --------------------------------------
>>> RFC5545 (draft-ietf-calsify-rfc2445bis-10)
>>> --------------------------------------
>>> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: = Internet Calendaring and Scheduling Core Object Specification (iCalendar) >>> Publication Date=C2=A0 =C2=A0 : September 2009
>>> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: B. Desruis= seaux, Ed.
>>> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED S= TANDARD
>>> Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Calen= daring and Scheduling Standards Simplification
>>> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : = Applications
>>> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF<= br> >>> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>>
>>
>> _______________________________________________
>> calsify mailing list
>> calsify@ietf= .org
>> https://www.ietf.org/mailman/listinfo/calsify<= /a>
>>
>>
>> Attachments:
>>
>> signature.asc
>>
>>

--000000000000d8717505b678563a-- From nobody Tue Dec 15 07:08: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 588313A1175; Tue, 15 Dec 2020 07:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQcIHSO5Nb_W; Tue, 15 Dec 2020 07:08:51 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85513A1021; Tue, 15 Dec 2020 07:08:51 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AD073F40709; Tue, 15 Dec 2020 07:08:46 -0800 (PST) To: eugene.adell@gmail.com, bernard.desruisseaux@oracle.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: barryleiba@computer.org, iesg@ietf.org, calsify@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20201215150846.AD073F40709@rfc-editor.org> Date: Tue, 15 Dec 2020 07:08:46 -0800 (PST) Archived-At: Subject: [calsify] [Errata Verified] RFC5545 (5794) 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, 15 Dec 2020 15:08:54 -0000 The following errata report has been verified for RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5794 -------------------------------------- Status: Verified Type: Editorial Reported by: Eugene Adell Date Reported: 2019-07-28 Verified by: Barry Leiba (IESG) Section: ToC Original Text ------------- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 6 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 7 3. iCalendar Object Specification . . . . . . . . . . . . . . . 8 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 11 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 11 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 12 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 12 3.2.1. Alternate Text Representation . . . . . . . . . . . . 13 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 15 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 16 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 16 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 17 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 17 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 18 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 19 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 20 3.2.11. Group or List Membership . . . . . . . . . . . . . . 20 3.2.12. Participation Status . . . . . . . . . . . . . . . . 21 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 22 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 23 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 24 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 25 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 25 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 26 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 28 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 29 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 30 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 31 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 34 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 36 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 37 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 46 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 49 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 50 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 50 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 56 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 58 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 60 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 63 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 72 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 77 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 77 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 78 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 79 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 80 3.8. Component Properties . . . . . . . . . . . . . . . . . . 81 3.8.1. Descriptive Component Properties . . . . . . . . . . 81 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 81 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 82 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 83 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 84 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 85 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 87 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 88 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 89 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 90 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 92 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 93 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 94 3.8.2. Date and Time Component Properties . . . . . . . . . 95 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 95 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 96 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 97 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 99 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 100 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 101 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 102 3.8.3. Time Zone Component Properties . . . . . . . . . . . 103 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 103 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 105 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 106 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 106 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 107 3.8.4. Relationship Component Properties . . . . . . . . . . 108 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 108 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 111 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 113 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 114 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 117 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 118 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 119 3.8.5. Recurrence Component Properties . . . . . . . . . . . 120 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 120 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 122 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 124 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 134 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 134 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 135 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 135 3.8.7. Change Management Component Properties . . . . . . . 138 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 138 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 139 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 140 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 141 3.8.8. Miscellaneous Component Properties . . . . . . . . . 142 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 142 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 142 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 144 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 146 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 150 6. Internationalization Considerations . . . . . . . . . . . . . 151 7. Security Considerations . . . . . . . . . . . . . . . . . . . 151 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 151 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 151 8.2. New iCalendar Elements Registration . . . . . . . . . . . 155 8.2.1. iCalendar Elements Registration Procedure . . . . . . 155 8.2.2. Registration Template for Components . . . . . . . . 155 8.2.3. Registration Template for Properties . . . . . . . . 156 8.2.4. Registration Template for Parameters . . . . . . . . 156 8.2.5. Registration Template for Value Data Types . . . . . 157 8.2.6. Registration Template for Values . . . . . . . . . . 157 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 158 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 158 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 158 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 161 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 162 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 162 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 163 8.3.7. Participation Statuses Registry . . . . . . . . . . . 163 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 164 8.3.9. Participation Roles Registry . . . . . . . . . . . . 164 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 165 8.3.11. Classifications Registry . . . . . . . . . . . . . . 165 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 165 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 165 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 10.1. Normative References . . . . . . . . . . . . . . . . . . 166 10.2. Informative References . . . . . . . . . . . . . . . . . 167 Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 169 A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 169 A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 169 A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 169 Corrected Text -------------- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 6 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 8 3. iCalendar Object Specification . . . . . . . . . . . . . . . 8 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 12 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 12 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 13 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 13 3.2.1. Alternate Text Representation . . . . . . . . . . . . 14 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 16 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 17 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 17 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 18 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 18 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 19 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 20 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 21 3.2.11. Group or List Membership . . . . . . . . . . . . . . 21 3.2.12. Participation Status . . . . . . . . . . . . . . . . 22 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 23 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 24 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 25 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 25 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 26 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 27 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 29 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 30 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 31 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 32 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 35 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 37 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 37 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 38 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 47 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 50 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 51 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 51 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 55 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 57 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 59 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 62 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 71 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 76 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 76 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 77 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 78 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 79 3.8. Component Properties . . . . . . . . . . . . . . . . . . 80 3.8.1. Descriptive Component Properties . . . . . . . . . . 80 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 80 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 81 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 82 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 83 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 84 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 85 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 87 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 88 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 89 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 91 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 92 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 93 3.8.2. Date and Time Component Properties . . . . . . . . . 94 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 94 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 95 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 96 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 97 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 99 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 100 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 101 3.8.3. Time Zone Component Properties . . . . . . . . . . . 102 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 102 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 103 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 104 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 105 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 106 3.8.4. Relationship Component Properties . . . . . . . . . . 106 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 107 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 109 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 111 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 112 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 115 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 116 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 117 3.8.5. Recurrence Component Properties . . . . . . . . . . . 118 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 118 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 120 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 122 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 132 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 132 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 133 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 133 3.8.7. Change Management Component Properties . . . . . . . 136 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 136 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 137 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 138 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 138 3.8.8. Miscellaneous Component Properties . . . . . . . . . 139 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 140 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 140 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 141 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 144 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 147 6. Internationalization Considerations . . . . . . . . . . . . . 148 7. Security Considerations . . . . . . . . . . . . . . . . . . . 148 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 149 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 149 8.2. New iCalendar Elements Registration . . . . . . . . . . . 152 8.2.1. iCalendar Elements Registration Procedure . . . . . . 152 8.2.2. Registration Template for Components . . . . . . . . 152 8.2.3. Registration Template for Properties . . . . . . . . 153 8.2.4. Registration Template for Parameters . . . . . . . . 153 8.2.5. Registration Template for Value Data Types . . . . . 154 8.2.6. Registration Template for Values . . . . . . . . . . 154 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 155 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 155 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 156 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 158 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 159 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 160 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 160 8.3.7. Participation Statuses Registry . . . . . . . . . . . 161 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 161 8.3.9. Participation Roles Registry . . . . . . . . . . . . 162 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 162 8.3.11. Classifications Registry . . . . . . . . . . . . . . 162 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 163 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 163 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 164 10.1. Normative References . . . . . . . . . . . . . . . . . . 164 10.2. Informative References . . . . . . . . . . . . . . . . . 165 Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 167 A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 167 A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 167 A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 167 Notes ----- Most of the Table Of Contents gives wrong page numbers. ===== Verifier notes ===== Indeed: the character table in Section 2.1, which appears at the top of page 8 in the RFC, appears to have been added during final editing, and has thrown off the page numbering for all sections beginning with 2.2. -------------------------------------- RFC5545 (draft-ietf-calsify-rfc2445bis-10) -------------------------------------- Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Publication Date : September 2009 Author(s) : B. Desruisseaux, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG From nobody Tue Dec 15 07:11: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 B57A13A11C3; Tue, 15 Dec 2020 07:11:41 -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 4Tu9LCS_Zunr; Tue, 15 Dec 2020 07:11:38 -0800 (PST) Received: from mail-lf1-f50.google.com (mail-lf1-f50.google.com [209.85.167.50]) (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 618943A1021; Tue, 15 Dec 2020 07:11:38 -0800 (PST) Received: by mail-lf1-f50.google.com with SMTP id 23so40216222lfg.10; Tue, 15 Dec 2020 07:11:38 -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=5o/dP7qinrOBfo5CzfeRJRNHuZfQXf2D6Zh0Ki5zkDA=; b=VfWl/XPUTfHg4Gl+LqLqgWSVPgMO9Xils/vB3zqas32GbrnwtpiQJA46wntK8VuQFk 7hdFssPs57cnSm9Ho5kIr8n2JYMRftd3QigWoWkL9sfBu44iokjTvC/W0rol6tV3X3UJ iTJg2seJ1DAjBUQHn7076ZmwRJ580QxO4zBomIClkhE5C2WJwj7qwr0zqccYBd4hRqmS YK8hs8vLvRWv2yVRn7uRlpr04JOpzVzexzgX9vGu1WjNRb1Hdml3FOemE4xZSVt1RkS5 Prr+sgZG+grolaBbTY5ofK/IN/EL3nLb37Kpq1sGFgvSx91TJJb9bkNpiG5dibaqVnVv KHVw== X-Gm-Message-State: AOAM5303X4mWfl5ABy5zZEI+7YvnOyzovk8eRhyJvILwELK2wkoV8nGE FXtdXrRW60q4sUNs6eeOuzirRNmnyvGjSTsBVNI= X-Google-Smtp-Source: ABdhPJzh2wMqS26s5neqVJ+4uZL8PE3PzWm8SQl04uCS9k8zRIIN3aAHmym3byySqkddCUFmdIMap3C9I21LYvcR0g8= X-Received: by 2002:a2e:9756:: with SMTP id f22mr12721726ljj.65.1608045095914; Tue, 15 Dec 2020 07:11:35 -0800 (PST) MIME-Version: 1.0 References: <20190728114511.A93CFB80D0D@rfc-editor.org> <1EBEA8BC-3A1D-4798-8CAD-0A76DCF850B3@cisco.com> <877ba1d2-310f-403a-a6b5-fb7831858b72@www.fastmail.com> In-Reply-To: From: Barry Leiba Date: Tue, 15 Dec 2020 10:11:24 -0500 Message-ID: To: Ben Campbell Cc: =?UTF-8?Q?Eug=C3=A8ne_Adell?= , ART Area , Stan Kalisch , Eliot Lear , RFC Errata System , Adam Roach , Alexey Melnikov , calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [calsify] [Editorial Errata Reported] RFC5545 (5794) 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, 15 Dec 2020 15:11:42 -0000 I have marked this as "Verified", and added the following to the comments: ------------------------------- =3D=3D=3D=3D=3D Verifier notes =3D=3D=3D=3D=3D Indeed: the character table in Section 2.1, which appears at the top of page 8 in the RFC, appears to have been added during final editing, and has thrown off the page numbering for all sections beginning with 2.2. ------------------------------- Eliot is correct that we would normally mark such things as "Held for Document Update" because it's not substantive and won't cause any real implementation issues, but this seemed odd enough that I thought it worth handling as an exception, and making it "Verified". Thanks, Eug=C3=A8ne, for noticing and reporting it... and then for followin= g up. Barry On Mon, Dec 14, 2020 at 8:09 PM Ben Campbell wrote: > > This went to a bunch of ex-ART-ADs. Forwarding to the current ones=E2=80= =A6 > > Ben. > > > On Dec 14, 2020, at 5:46 PM, Eug=C3=A8ne Adell = wrote: > > > > Hi guys, > > > > was it possible to decide anything on this Errata ? I think that even > > a rejected one is still better, if commented appropriately for the > > future readers, as they don't (I think) investigate in the mailing > > lists. > > > > best regards > > Eugene > > > > Le lun. 29 juil. 2019 =C3=A0 04:08, Stan Kalisch > > a =C3=A9crit : > >> > >> Hi, > >> > >> On Sun, Jul 28, 2019, at 8:30 AM, Eliot Lear wrote: > >> > >> The erratum is correct. Good catch. Under the IESG criteria, as this= is editorial and will not cause any interoperability or other implementati= on concerns, it is normally marked =E2=80=9Chold for update=E2=80=9D. Howe= ver, because of the particular nature of this erratum, anyone who clicks on= the web searchable index gets sent to the wrong place. That=E2=80=99s ann= oying. Suggestions? > >> > >> > >> Per https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/: > >> > >> "Only errors that could cause implementation or deployment problems or= significant confusion should be Verified." > >> > >> So, the way I read it, it comes down to whether the confusion this cou= ld cause is judged to be "significant". My personal opinion is that, given= that the table of contents should go up to page 167, and given that there = will be more than a few marginally exhausted implementers likely reading th= is at some point, it's "significant enough." > >> > >> > >> Stan > >> > >> Eliot > >> > >> > >> > >>> On 28 Jul 2019, at 13:45, RFC Errata System wrote: > >>> > >>> The following errata report has been submitted for RFC5545, > >>> "Internet Calendaring and Scheduling Core Object Specification (iCale= ndar)". > >>> > >>> -------------------------------------- > >>> You may review the report below and at: > >>> https://www.rfc-editor.org/errata/eid5794 > >>> > >>> -------------------------------------- > >>> Type: Editorial > >>> Reported by: Eugene Adell > >>> > >>> Section: ToC > >>> > >>> Original Text > >>> ------------- > >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 5 > >>> 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . = 6 > >>> 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . = 6 > >>> 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . = 7 > >>> 3. iCalendar Object Specification . . . . . . . . . . . . . . . = 8 > >>> 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . = 8 > >>> 3.1.1. List and Field Separators . . . . . . . . . . . . . . 1= 1 > >>> 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 1= 1 > >>> 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 1= 1 > >>> 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 1= 2 > >>> 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 1= 2 > >>> 3.2.1. Alternate Text Representation . . . . . . . . . . . . 1= 3 > >>> 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 1= 5 > >>> 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 1= 5 > >>> 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 1= 6 > >>> 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 1= 6 > >>> 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 1= 7 > >>> 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 1= 7 > >>> 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 1= 8 > >>> 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 1= 9 > >>> 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 2= 0 > >>> 3.2.11. Group or List Membership . . . . . . . . . . . . . . 2= 0 > >>> 3.2.12. Participation Status . . . . . . . . . . . . . . . . 2= 1 > >>> 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 2= 2 > >>> 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 2= 3 > >>> 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 2= 4 > >>> 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 2= 5 > >>> 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 2= 5 > >>> 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 2= 6 > >>> 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 2= 6 > >>> 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 2= 8 > >>> 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 2= 9 > >>> 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 2= 9 > >>> 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 3= 0 > >>> 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 3= 0 > >>> 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 3= 1 > >>> 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 3= 1 > >>> 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 3= 4 > >>> 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 3= 5 > >>> 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 3= 5 > >>> 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 3= 6 > >>> 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 3= 7 > >>> 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 4= 5 > >>> 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 4= 6 > >>> 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 4= 8 > >>> 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 4= 9 > >>> 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 4= 9 > >>> 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 5= 0 > >>> 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 5= 0 > >>> 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 5= 2 > >>> 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 5= 6 > >>> 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 5= 8 > >>> 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 6= 0 > >>> 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 6= 3 > >>> 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 7= 2 > >>> 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 7= 7 > >>> 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 7= 7 > >>> 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 7= 8 > >>> 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 7= 9 > >>> 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 8= 0 > >>> 3.8. Component Properties . . . . . . . . . . . . . . . . . . 8= 1 > >>> 3.8.1. Descriptive Component Properties . . . . . . . . . . 8= 1 > >>> 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 8= 1 > >>> 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 8= 2 > >>> 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 8= 3 > >>> 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 8= 4 > >>> 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 8= 5 > >>> 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 8= 7 > >>> 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 8= 8 > >>> 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 8= 9 > >>> 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 9= 0 > >>> 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 9= 2 > >>> 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 9= 3 > >>> 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 9= 4 > >>> 3.8.2. Date and Time Component Properties . . . . . . . . . 9= 5 > >>> 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 9= 5 > >>> 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 9= 6 > >>> 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 9= 7 > >>> 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 9= 9 > >>> 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 10= 0 > >>> 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 10= 1 > >>> 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 10= 2 > >>> 3.8.3. Time Zone Component Properties . . . . . . . . . . . 10= 3 > >>> 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 10= 3 > >>> 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 10= 5 > >>> 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 10= 6 > >>> 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 10= 6 > >>> 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 10= 7 > >>> 3.8.4. Relationship Component Properties . . . . . . . . . . 10= 8 > >>> 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 10= 8 > >>> 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 11= 1 > >>> > >>> 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 11= 3 > >>> 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 11= 4 > >>> 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 11= 7 > >>> 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 11= 8 > >>> 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 11= 9 > >>> 3.8.5. Recurrence Component Properties . . . . . . . . . . . 12= 0 > >>> 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 12= 0 > >>> 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 12= 2 > >>> 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 12= 4 > >>> 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 13= 4 > >>> 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 13= 4 > >>> 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 13= 5 > >>> 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 13= 5 > >>> 3.8.7. Change Management Component Properties . . . . . . . 13= 8 > >>> 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 13= 8 > >>> 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 13= 9 > >>> 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 14= 0 > >>> 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 14= 1 > >>> 3.8.8. Miscellaneous Component Properties . . . . . . . . . 14= 2 > >>> 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 14= 2 > >>> 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 14= 2 > >>> 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 14= 4 > >>> 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 14= 6 > >>> 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 15= 0 > >>> 6. Internationalization Considerations . . . . . . . . . . . . . 15= 1 > >>> 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15= 1 > >>> 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15= 1 > >>> 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 15= 1 > >>> 8.2. New iCalendar Elements Registration . . . . . . . . . . . 15= 5 > >>> 8.2.1. iCalendar Elements Registration Procedure . . . . . . 15= 5 > >>> 8.2.2. Registration Template for Components . . . . . . . . 15= 5 > >>> 8.2.3. Registration Template for Properties . . . . . . . . 15= 6 > >>> 8.2.4. Registration Template for Parameters . . . . . . . . 15= 6 > >>> 8.2.5. Registration Template for Value Data Types . . . . . 15= 7 > >>> 8.2.6. Registration Template for Values . . . . . . . . . . 15= 7 > >>> 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 15= 8 > >>> 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 15= 8 > >>> 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 15= 8 > >>> 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 16= 1 > >>> 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 16= 2 > >>> 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 16= 2 > >>> 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 16= 3 > >>> 8.3.7. Participation Statuses Registry . . . . . . . . . . . 16= 3 > >>> 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 16= 4 > >>> 8.3.9. Participation Roles Registry . . . . . . . . . . . . 16= 4 > >>> 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 16= 5 > >>> 8.3.11. Classifications Registry . . . . . . . . . . . . . . 16= 5 > >>> 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 16= 5 > >>> 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16= 5 > >>> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16= 6 > >>> 10.1. Normative References . . . . . . . . . . . . . . . . . . 16= 6 > >>> 10.2. Informative References . . . . . . . . . . . . . . . . . 16= 7 > >>> Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 16= 9 > >>> A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 16= 9 > >>> A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 16= 9 > >>> A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 16= 9 > >>> > >>> > >>> Corrected Text > >>> -------------- > >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 5 > >>> 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . = 6 > >>> 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . = 6 > >>> 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . = 8 > >>> 3. iCalendar Object Specification . . . . . . . . . . . . . . . = 8 > >>> 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . = 9 > >>> 3.1.1. List and Field Separators . . . . . . . . . . . . . . 1= 1 > >>> 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 1= 2 > >>> 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 1= 2 > >>> 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 1= 3 > >>> 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 1= 3 > >>> 3.2.1. Alternate Text Representation . . . . . . . . . . . . 1= 4 > >>> 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 1= 5 > >>> 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 1= 6 > >>> 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 1= 7 > >>> 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 1= 7 > >>> 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 1= 8 > >>> 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 1= 8 > >>> 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 1= 9 > >>> 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 2= 0 > >>> 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 2= 1 > >>> 3.2.11. Group or List Membership . . . . . . . . . . . . . . 2= 1 > >>> 3.2.12. Participation Status . . . . . . . . . . . . . . . . 2= 2 > >>> 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 2= 3 > >>> 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 2= 4 > >>> 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 2= 5 > >>> 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 2= 5 > >>> 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 2= 6 > >>> 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 2= 7 > >>> 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 2= 7 > >>> 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 2= 9 > >>> 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 3= 0 > >>> 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 3= 0 > >>> 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 3= 1 > >>> 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 3= 1 > >>> 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 3= 2 > >>> 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 3= 2 > >>> 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 3= 5 > >>> 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 3= 6 > >>> 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 3= 7 > >>> 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 3= 7 > >>> 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 3= 8 > >>> 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 4= 5 > >>> 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 4= 7 > >>> 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 4= 9 > >>> 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 4= 9 > >>> 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 5= 0 > >>> 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 5= 1 > >>> 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 5= 1 > >>> 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 5= 2 > >>> 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 5= 5 > >>> 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 5= 7 > >>> 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 5= 9 > >>> 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 6= 2 > >>> 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 7= 1 > >>> 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 7= 6 > >>> 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 7= 6 > >>> 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 7= 7 > >>> 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 7= 8 > >>> 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 7= 9 > >>> 3.8. Component Properties . . . . . . . . . . . . . . . . . . 8= 0 > >>> 3.8.1. Descriptive Component Properties . . . . . . . . . . 8= 0 > >>> 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 8= 0 > >>> 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 8= 1 > >>> 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 8= 2 > >>> 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 8= 3 > >>> 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 8= 4 > >>> 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 8= 5 > >>> 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 8= 7 > >>> 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 8= 8 > >>> 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 8= 9 > >>> 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 9= 1 > >>> 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 9= 2 > >>> 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 9= 3 > >>> 3.8.2. Date and Time Component Properties . . . . . . . . . 9= 4 > >>> 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 9= 4 > >>> 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 9= 5 > >>> 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 9= 6 > >>> 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 9= 7 > >>> 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 9= 9 > >>> 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 10= 0 > >>> 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 10= 1 > >>> 3.8.3. Time Zone Component Properties . . . . . . . . . . . 10= 2 > >>> 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 10= 2 > >>> 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 10= 3 > >>> 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 10= 4 > >>> 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 10= 5 > >>> 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 10= 6 > >>> 3.8.4. Relationship Component Properties . . . . . . . . . . 10= 6 > >>> 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 10= 7 > >>> 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 10= 9 > >>> 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 11= 1 > >>> 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 11= 2 > >>> 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 11= 5 > >>> 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 11= 6 > >>> 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 11= 7 > >>> 3.8.5. Recurrence Component Properties . . . . . . . . . . . 11= 8 > >>> 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 11= 8 > >>> 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 12= 0 > >>> 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 12= 2 > >>> 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 13= 2 > >>> 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 13= 2 > >>> 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 13= 3 > >>> 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 13= 3 > >>> 3.8.7. Change Management Component Properties . . . . . . . 13= 6 > >>> 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 13= 6 > >>> 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 13= 7 > >>> 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 13= 8 > >>> 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 13= 8 > >>> 3.8.8. Miscellaneous Component Properties . . . . . . . . . 13= 9 > >>> 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 14= 0 > >>> 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 14= 0 > >>> 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 14= 1 > >>> 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 14= 4 > >>> 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 14= 7 > >>> 6. Internationalization Considerations . . . . . . . . . . . . . 14= 8 > >>> 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14= 8 > >>> 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14= 9 > >>> 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 14= 9 > >>> 8.2. New iCalendar Elements Registration . . . . . . . . . . . 15= 2 > >>> 8.2.1. iCalendar Elements Registration Procedure . . . . . . 15= 2 > >>> 8.2.2. Registration Template for Components . . . . . . . . 15= 2 > >>> 8.2.3. Registration Template for Properties . . . . . . . . 15= 3 > >>> 8.2.4. Registration Template for Parameters . . . . . . . . 15= 3 > >>> 8.2.5. Registration Template for Value Data Types . . . . . 15= 4 > >>> 8.2.6. Registration Template for Values . . . . . . . . . . 15= 4 > >>> 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 15= 5 > >>> 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 15= 5 > >>> 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 15= 6 > >>> 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 15= 8 > >>> 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 15= 9 > >>> 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 16= 0 > >>> 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 16= 0 > >>> 8.3.7. Participation Statuses Registry . . . . . . . . . . . 16= 1 > >>> 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 16= 1 > >>> 8.3.9. Participation Roles Registry . . . . . . . . . . . . 16= 2 > >>> 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 16= 2 > >>> 8.3.11. Classifications Registry . . . . . . . . . . . . . . 16= 2 > >>> 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 16= 3 > >>> 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16= 3 > >>> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16= 4 > >>> 10.1. Normative References . . . . . . . . . . . . . . . . . . 16= 4 > >>> 10.2. Informative References . . . . . . . . . . . . . . . . . 16= 5 > >>> Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 16= 7 > >>> A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 16= 7 > >>> A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 16= 7 > >>> A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 16= 7 > >>> > >>> > >>> Notes > >>> ----- > >>> Most of the Table Of Contents give wrong page numbers > >>> > >>> Instructions: > >>> ------------- > >>> This erratum is currently posted as "Reported". If necessary, please > >>> use "Reply All" to discuss whether it should be verified or > >>> rejected. When a decision is reached, the verifying party > >>> can log in to change the status and edit the report, if necessary. > >>> > >>> -------------------------------------- > >>> RFC5545 (draft-ietf-calsify-rfc2445bis-10) > >>> -------------------------------------- > >>> Title : Internet Calendaring and Scheduling Core Object= Specification (iCalendar) > >>> Publication Date : September 2009 > >>> Author(s) : B. Desruisseaux, Ed. > >>> Category : PROPOSED STANDARD > >>> Source : Calendaring and Scheduling Standards Simplifica= tion > >>> Area : Applications > >>> Stream : IETF > >>> Verifying Party : IESG > >> > >> > >> _______________________________________________ > >> calsify mailing list > >> calsify@ietf.org > >> https://www.ietf.org/mailman/listinfo/calsify > >> > >> > >> Attachments: > >> > >> signature.asc > >> > >> > From nobody Tue Dec 15 07:48:27 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EBC3A11DB; Tue, 15 Dec 2020 07:48:25 -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, 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 RKtKJHMxCtle; Tue, 15 Dec 2020 07:48:22 -0800 (PST) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D59C3A11B7; Tue, 15 Dec 2020 07:48:22 -0800 (PST) Received: by mail-vk1-xa33.google.com with SMTP id b190so4885749vka.0; Tue, 15 Dec 2020 07:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=661thoEg/25+GPo/WK0obhc5iRVLk7CjNUsv96yKZLg=; b=gWm/cDFN6rNLa5xVfFg6A3fivJdEkbIJmaWBtgVUlnMR+yLSj4M6CmgPUJaEC+9+ki UlIM9kMUFSK5rZLgwp/ehmFApakewerElbsjf1ertf64N8CPVs3t1F5cR4QBI0tDKuus dfuFncm3MQ1lx41/6Jgumz7WunVDfBL2x8KCfy8Y+gEFZnkARPCWPcZvsjxPg2qKy431 ogUC7La/nVAPK4xb8K+7GgO/T+UUJEpS0kxNsF2JSOCevjNRWMdls7S4TwMAd6l/ure7 Dg2mIuLTs7TgMh5Zal1jSgf6IopR34MY2FMaNHOQgYPX3AvmC3nJqfDloJ/emjaoW700 0qJg== 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=661thoEg/25+GPo/WK0obhc5iRVLk7CjNUsv96yKZLg=; b=Pkhntny2i7czr/iZB4dhbu9VxOdyY682fsgLQUSZXNxh1hNClX5Ze13Kd+j3me9/jg Sqivrlzp/qrQ7G0yui+bNjN2mODCADt6qcg+TTwEX5Wo3AoWVcPYp+ZiKnFEXsXLY0YV 5YwnF3LumZXrJhUbwnmeljxmq4LB9yXF2C/exf+KiBVxZB2UXxag/UHy0gdgEoO75JzM 1ilugOLaKIKuc2lUybtNquQRoS9LejNbm6MPVj9kjZjHy6mAVNwcV/Nqdmn8AJUPFX3Q BrF1jz37cRmZaE+Mb7L2e4WsTdoUFjeS1EgaIs0bYY3kC9hEJwHMbQaGhgQE7r97LznQ KpoA== X-Gm-Message-State: AOAM532qgLe8ZMv57V53O8xSYU5x6oU62oWcQPfK+YmWqpiH5rkc9xvb BTyt5S7UDpDbPadQHIMmBfZEGIoxNFKEbtcBub4= X-Google-Smtp-Source: ABdhPJy3IXPkYv3W2zTJ/eVlGfVxm4D56smE815B/MUthArRszzbhw/3PgkyU7IFHemt+X6/LZF+Y1U8/MY6mEz8pxI= X-Received: by 2002:a1f:95c6:: with SMTP id x189mr10536134vkd.9.1608047301159; Tue, 15 Dec 2020 07:48:21 -0800 (PST) MIME-Version: 1.0 References: <20190728114511.A93CFB80D0D@rfc-editor.org> <1EBEA8BC-3A1D-4798-8CAD-0A76DCF850B3@cisco.com> <877ba1d2-310f-403a-a6b5-fb7831858b72@www.fastmail.com> In-Reply-To: From: =?UTF-8?Q?Eug=C3=A8ne_Adell?= Date: Tue, 15 Dec 2020 16:40:14 +0100 Message-ID: To: Barry Leiba Cc: Ben Campbell , ART Area , Stan Kalisch , Eliot Lear , RFC Errata System , Adam Roach , Alexey Melnikov , calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [calsify] [Editorial Errata Reported] RFC5545 (5794) 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, 15 Dec 2020 15:48:25 -0000 Thanks one more time Barry for verifying one of my Erratas. best regards Eugene Le mar. 15 d=C3=A9c. 2020 =C3=A0 16:11, Barry Leiba a =C3=A9crit : > > I have marked this as "Verified", and added the following to the comments= : > > ------------------------------- > =3D=3D=3D=3D=3D Verifier notes =3D=3D=3D=3D=3D > Indeed: the character table in Section 2.1, which appears at the top > of page 8 in the RFC, appears to have been added during final editing, > and has thrown off the page numbering for all sections beginning with > 2.2. > ------------------------------- > > Eliot is correct that we would normally mark such things as "Held for > Document Update" because it's not substantive and won't cause any real > implementation issues, but this seemed odd enough that I thought it > worth handling as an exception, and making it "Verified". > > Thanks, Eug=C3=A8ne, for noticing and reporting it... and then for follow= ing up. > > Barry > > On Mon, Dec 14, 2020 at 8:09 PM Ben Campbell wrote: > > > > This went to a bunch of ex-ART-ADs. Forwarding to the current ones=E2= =80=A6 > > > > Ben. > > > > > On Dec 14, 2020, at 5:46 PM, Eug=C3=A8ne Adell wrote: > > > > > > Hi guys, > > > > > > was it possible to decide anything on this Errata ? I think that even > > > a rejected one is still better, if commented appropriately for the > > > future readers, as they don't (I think) investigate in the mailing > > > lists. > > > > > > best regards > > > Eugene > > > > > > Le lun. 29 juil. 2019 =C3=A0 04:08, Stan Kalisch > > > a =C3=A9crit : > > >> > > >> Hi, > > >> > > >> On Sun, Jul 28, 2019, at 8:30 AM, Eliot Lear wrote: > > >> > > >> The erratum is correct. Good catch. Under the IESG criteria, as th= is is editorial and will not cause any interoperability or other implementa= tion concerns, it is normally marked =E2=80=9Chold for update=E2=80=9D. Ho= wever, because of the particular nature of this erratum, anyone who clicks = on the web searchable index gets sent to the wrong place. That=E2=80=99s a= nnoying. Suggestions? > > >> > > >> > > >> Per https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream= /: > > >> > > >> "Only errors that could cause implementation or deployment problems = or significant confusion should be Verified." > > >> > > >> So, the way I read it, it comes down to whether the confusion this c= ould cause is judged to be "significant". My personal opinion is that, giv= en that the table of contents should go up to page 167, and given that ther= e will be more than a few marginally exhausted implementers likely reading = this at some point, it's "significant enough." > > >> > > >> > > >> Stan > > >> > > >> Eliot > > >> > > >> > > >> > > >>> On 28 Jul 2019, at 13:45, RFC Errata System wrote: > > >>> > > >>> The following errata report has been submitted for RFC5545, > > >>> "Internet Calendaring and Scheduling Core Object Specification (iCa= lendar)". > > >>> > > >>> -------------------------------------- > > >>> You may review the report below and at: > > >>> https://www.rfc-editor.org/errata/eid5794 > > >>> > > >>> -------------------------------------- > > >>> Type: Editorial > > >>> Reported by: Eugene Adell > > >>> > > >>> Section: ToC > > >>> > > >>> Original Text > > >>> ------------- > > >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 5 > > >>> 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . = 6 > > >>> 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . = 6 > > >>> 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . = 7 > > >>> 3. iCalendar Object Specification . . . . . . . . . . . . . . . = 8 > > >>> 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . = 8 > > >>> 3.1.1. List and Field Separators . . . . . . . . . . . . . . = 11 > > >>> 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . = 11 > > >>> 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . = 11 > > >>> 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . = 12 > > >>> 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . = 12 > > >>> 3.2.1. Alternate Text Representation . . . . . . . . . . . . = 13 > > >>> 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . = 15 > > >>> 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . = 15 > > >>> 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . = 16 > > >>> 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . = 16 > > >>> 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . = 17 > > >>> 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . = 17 > > >>> 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . = 18 > > >>> 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . = 19 > > >>> 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . = 20 > > >>> 3.2.11. Group or List Membership . . . . . . . . . . . . . . = 20 > > >>> 3.2.12. Participation Status . . . . . . . . . . . . . . . . = 21 > > >>> 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . = 22 > > >>> 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . = 23 > > >>> 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . = 24 > > >>> 3.2.16. Participation Role . . . . . . . . . . . . . . . . . = 25 > > >>> 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . = 25 > > >>> 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . = 26 > > >>> 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . = 26 > > >>> 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . = 28 > > >>> 3.3. Property Value Data Types . . . . . . . . . . . . . . . . = 29 > > >>> 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . = 29 > > >>> 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . = 30 > > >>> 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . = 30 > > >>> 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . = 31 > > >>> 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . = 31 > > >>> 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . = 34 > > >>> 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . = 35 > > >>> 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . = 35 > > >>> 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . = 36 > > >>> 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . = 37 > > >>> 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . = 45 > > >>> 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . = 46 > > >>> 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . = 48 > > >>> 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . = 49 > > >>> 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . = 49 > > >>> 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . = 50 > > >>> 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . = 50 > > >>> 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . = 52 > > >>> 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . = 56 > > >>> 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . = 58 > > >>> 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . = 60 > > >>> 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . = 63 > > >>> 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . = 72 > > >>> 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . = 77 > > >>> 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . = 77 > > >>> 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . = 78 > > >>> 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . = 79 > > >>> 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . = 80 > > >>> 3.8. Component Properties . . . . . . . . . . . . . . . . . . = 81 > > >>> 3.8.1. Descriptive Component Properties . . . . . . . . . . = 81 > > >>> 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . = 81 > > >>> 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . = 82 > > >>> 3.8.1.3. Classification . . . . . . . . . . . . . . . . . = 83 > > >>> 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . = 84 > > >>> 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . = 85 > > >>> 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . = 87 > > >>> 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . = 88 > > >>> 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . = 89 > > >>> 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . = 90 > > >>> 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . = 92 > > >>> 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . = 93 > > >>> 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . = 94 > > >>> 3.8.2. Date and Time Component Properties . . . . . . . . . = 95 > > >>> 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . = 95 > > >>> 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . = 96 > > >>> 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . = 97 > > >>> 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . = 99 > > >>> 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . = 100 > > >>> 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . = 101 > > >>> 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . = 102 > > >>> 3.8.3. Time Zone Component Properties . . . . . . . . . . . = 103 > > >>> 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . = 103 > > >>> 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . = 105 > > >>> 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . = 106 > > >>> 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . = 106 > > >>> 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . = 107 > > >>> 3.8.4. Relationship Component Properties . . . . . . . . . . = 108 > > >>> 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . = 108 > > >>> 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . = 111 > > >>> > > >>> 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . = 113 > > >>> 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . = 114 > > >>> 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . = 117 > > >>> 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . = 118 > > >>> 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . = 119 > > >>> 3.8.5. Recurrence Component Properties . . . . . . . . . . . = 120 > > >>> 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . = 120 > > >>> 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . = 122 > > >>> 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . = 124 > > >>> 3.8.6. Alarm Component Properties . . . . . . . . . . . . . = 134 > > >>> 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . = 134 > > >>> 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . = 135 > > >>> 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . = 135 > > >>> 3.8.7. Change Management Component Properties . . . . . . . = 138 > > >>> 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . = 138 > > >>> 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . = 139 > > >>> 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . = 140 > > >>> 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . = 141 > > >>> 3.8.8. Miscellaneous Component Properties . . . . . . . . . = 142 > > >>> 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . = 142 > > >>> 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . = 142 > > >>> 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . = 144 > > >>> 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . = 146 > > >>> 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . = 150 > > >>> 6. Internationalization Considerations . . . . . . . . . . . . . = 151 > > >>> 7. Security Considerations . . . . . . . . . . . . . . . . . . . = 151 > > >>> 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 151 > > >>> 8.1. iCalendar Media Type Registration . . . . . . . . . . . . = 151 > > >>> 8.2. New iCalendar Elements Registration . . . . . . . . . . . = 155 > > >>> 8.2.1. iCalendar Elements Registration Procedure . . . . . . = 155 > > >>> 8.2.2. Registration Template for Components . . . . . . . . = 155 > > >>> 8.2.3. Registration Template for Properties . . . . . . . . = 156 > > >>> 8.2.4. Registration Template for Parameters . . . . . . . . = 156 > > >>> 8.2.5. Registration Template for Value Data Types . . . . . = 157 > > >>> 8.2.6. Registration Template for Values . . . . . . . . . . = 157 > > >>> 8.3. Initial iCalendar Elements Registries . . . . . . . . . . = 158 > > >>> 8.3.1. Components Registry . . . . . . . . . . . . . . . . . = 158 > > >>> 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . = 158 > > >>> 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . = 161 > > >>> 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . = 162 > > >>> 8.3.5. Calendar User Types Registry . . . . . . . . . . . . = 162 > > >>> 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . = 163 > > >>> 8.3.7. Participation Statuses Registry . . . . . . . . . . . = 163 > > >>> 8.3.8. Relationship Types Registry . . . . . . . . . . . . . = 164 > > >>> 8.3.9. Participation Roles Registry . . . . . . . . . . . . = 164 > > >>> 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . = 165 > > >>> 8.3.11. Classifications Registry . . . . . . . . . . . . . . = 165 > > >>> 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . = 165 > > >>> 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . = 165 > > >>> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . = 166 > > >>> 10.1. Normative References . . . . . . . . . . . . . . . . . . = 166 > > >>> 10.2. Informative References . . . . . . . . . . . . . . . . . = 167 > > >>> Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . = 169 > > >>> A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . = 169 > > >>> A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . = 169 > > >>> A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . = 169 > > >>> > > >>> > > >>> Corrected Text > > >>> -------------- > > >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 5 > > >>> 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . = 6 > > >>> 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . = 6 > > >>> 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . = 8 > > >>> 3. iCalendar Object Specification . . . . . . . . . . . . . . . = 8 > > >>> 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . = 9 > > >>> 3.1.1. List and Field Separators . . . . . . . . . . . . . . = 11 > > >>> 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . = 12 > > >>> 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . = 12 > > >>> 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . = 13 > > >>> 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . = 13 > > >>> 3.2.1. Alternate Text Representation . . . . . . . . . . . . = 14 > > >>> 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . = 15 > > >>> 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . = 16 > > >>> 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . = 17 > > >>> 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . = 17 > > >>> 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . = 18 > > >>> 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . = 18 > > >>> 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . = 19 > > >>> 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . = 20 > > >>> 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . = 21 > > >>> 3.2.11. Group or List Membership . . . . . . . . . . . . . . = 21 > > >>> 3.2.12. Participation Status . . . . . . . . . . . . . . . . = 22 > > >>> 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . = 23 > > >>> 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . = 24 > > >>> 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . = 25 > > >>> 3.2.16. Participation Role . . . . . . . . . . . . . . . . . = 25 > > >>> 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . = 26 > > >>> 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . = 27 > > >>> 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . = 27 > > >>> 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . = 29 > > >>> 3.3. Property Value Data Types . . . . . . . . . . . . . . . . = 30 > > >>> 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . = 30 > > >>> 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . = 31 > > >>> 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . = 31 > > >>> 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . = 32 > > >>> 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . = 32 > > >>> 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . = 35 > > >>> 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . = 36 > > >>> 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . = 37 > > >>> 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . = 37 > > >>> 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . = 38 > > >>> 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . = 45 > > >>> 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . = 47 > > >>> 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . = 49 > > >>> 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . = 49 > > >>> 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . = 50 > > >>> 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . = 51 > > >>> 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . = 51 > > >>> 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . = 52 > > >>> 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . = 55 > > >>> 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . = 57 > > >>> 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . = 59 > > >>> 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . = 62 > > >>> 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . = 71 > > >>> 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . = 76 > > >>> 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . = 76 > > >>> 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . = 77 > > >>> 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . = 78 > > >>> 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . = 79 > > >>> 3.8. Component Properties . . . . . . . . . . . . . . . . . . = 80 > > >>> 3.8.1. Descriptive Component Properties . . . . . . . . . . = 80 > > >>> 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . = 80 > > >>> 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . = 81 > > >>> 3.8.1.3. Classification . . . . . . . . . . . . . . . . . = 82 > > >>> 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . = 83 > > >>> 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . = 84 > > >>> 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . = 85 > > >>> 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . = 87 > > >>> 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . = 88 > > >>> 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . = 89 > > >>> 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . = 91 > > >>> 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . = 92 > > >>> 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . = 93 > > >>> 3.8.2. Date and Time Component Properties . . . . . . . . . = 94 > > >>> 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . = 94 > > >>> 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . = 95 > > >>> 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . = 96 > > >>> 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . = 97 > > >>> 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . = 99 > > >>> 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . = 100 > > >>> 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . = 101 > > >>> 3.8.3. Time Zone Component Properties . . . . . . . . . . . = 102 > > >>> 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . = 102 > > >>> 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . = 103 > > >>> 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . = 104 > > >>> 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . = 105 > > >>> 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . = 106 > > >>> 3.8.4. Relationship Component Properties . . . . . . . . . . = 106 > > >>> 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . = 107 > > >>> 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . = 109 > > >>> 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . = 111 > > >>> 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . = 112 > > >>> 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . = 115 > > >>> 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . = 116 > > >>> 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . = 117 > > >>> 3.8.5. Recurrence Component Properties . . . . . . . . . . . = 118 > > >>> 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . = 118 > > >>> 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . = 120 > > >>> 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . = 122 > > >>> 3.8.6. Alarm Component Properties . . . . . . . . . . . . . = 132 > > >>> 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . = 132 > > >>> 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . = 133 > > >>> 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . = 133 > > >>> 3.8.7. Change Management Component Properties . . . . . . . = 136 > > >>> 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . = 136 > > >>> 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . = 137 > > >>> 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . = 138 > > >>> 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . = 138 > > >>> 3.8.8. Miscellaneous Component Properties . . . . . . . . . = 139 > > >>> 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . = 140 > > >>> 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . = 140 > > >>> 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . = 141 > > >>> 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . = 144 > > >>> 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . = 147 > > >>> 6. Internationalization Considerations . . . . . . . . . . . . . = 148 > > >>> 7. Security Considerations . . . . . . . . . . . . . . . . . . . = 148 > > >>> 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 149 > > >>> 8.1. iCalendar Media Type Registration . . . . . . . . . . . . = 149 > > >>> 8.2. New iCalendar Elements Registration . . . . . . . . . . . = 152 > > >>> 8.2.1. iCalendar Elements Registration Procedure . . . . . . = 152 > > >>> 8.2.2. Registration Template for Components . . . . . . . . = 152 > > >>> 8.2.3. Registration Template for Properties . . . . . . . . = 153 > > >>> 8.2.4. Registration Template for Parameters . . . . . . . . = 153 > > >>> 8.2.5. Registration Template for Value Data Types . . . . . = 154 > > >>> 8.2.6. Registration Template for Values . . . . . . . . . . = 154 > > >>> 8.3. Initial iCalendar Elements Registries . . . . . . . . . . = 155 > > >>> 8.3.1. Components Registry . . . . . . . . . . . . . . . . . = 155 > > >>> 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . = 156 > > >>> 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . = 158 > > >>> 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . = 159 > > >>> 8.3.5. Calendar User Types Registry . . . . . . . . . . . . = 160 > > >>> 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . = 160 > > >>> 8.3.7. Participation Statuses Registry . . . . . . . . . . . = 161 > > >>> 8.3.8. Relationship Types Registry . . . . . . . . . . . . . = 161 > > >>> 8.3.9. Participation Roles Registry . . . . . . . . . . . . = 162 > > >>> 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . = 162 > > >>> 8.3.11. Classifications Registry . . . . . . . . . . . . . . = 162 > > >>> 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . = 163 > > >>> 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . = 163 > > >>> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . = 164 > > >>> 10.1. Normative References . . . . . . . . . . . . . . . . . . = 164 > > >>> 10.2. Informative References . . . . . . . . . . . . . . . . . = 165 > > >>> Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . = 167 > > >>> A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . = 167 > > >>> A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . = 167 > > >>> A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . = 167 > > >>> > > >>> > > >>> Notes > > >>> ----- > > >>> Most of the Table Of Contents give wrong page numbers > > >>> > > >>> Instructions: > > >>> ------------- > > >>> This erratum is currently posted as "Reported". If necessary, pleas= e > > >>> use "Reply All" to discuss whether it should be verified or > > >>> rejected. When a decision is reached, the verifying party > > >>> can log in to change the status and edit the report, if necessary. > > >>> > > >>> -------------------------------------- > > >>> RFC5545 (draft-ietf-calsify-rfc2445bis-10) > > >>> -------------------------------------- > > >>> Title : Internet Calendaring and Scheduling Core Obje= ct Specification (iCalendar) > > >>> Publication Date : September 2009 > > >>> Author(s) : B. Desruisseaux, Ed. > > >>> Category : PROPOSED STANDARD > > >>> Source : Calendaring and Scheduling Standards Simplifi= cation > > >>> Area : Applications > > >>> Stream : IETF > > >>> Verifying Party : IESG > > >> > > >> > > >> _______________________________________________ > > >> calsify mailing list > > >> calsify@ietf.org > > >> https://www.ietf.org/mailman/listinfo/calsify > > >> > > >> > > >> Attachments: > > >> > > >> signature.asc > > >> > > >> > > From nobody Tue Dec 15 09:26:21 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EFA3A1274; Tue, 15 Dec 2020 09:26:19 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgCY0O_CSA-1; Tue, 15 Dec 2020 09:26:17 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 BA2083A1271; Tue, 15 Dec 2020 09:26:17 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id y15so15165588qtv.5; Tue, 15 Dec 2020 09:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=LkbKrEDrBjvcPdAClb+lKSxtG3XLDsj7w2nJzM1I/vk=; b=Mi8CU32HoEnuNR9PgpLZ5+HAQMs6vNX6Q1JsR47dtzcaMto5snOXOch/IpN+Dt4JGg VNVl4FoWM9OwpbL+Eq5eF/Blc0vsiXsDiu27g1np+1m3NFRuL6acKYNniEeO+B9y+kg6 L+0SpCveg/DekC8TzE09dl2cFbyCzEsfTKrxIWgENIQ7YfVJXaRU7wiaxV6g7qbDhGyr 3MhU21EKoIZtzkGjSp/jnAAilcOtYVQOuDDLanRs3tYM63/oKQBYXXPe8oPN3s9t6XQ7 ceyH+gHhCo83Be+i9599gaK3VgXx08PJ+FeM82JBHaIESYCkMQkaBLop4RCk6EPjcjAd F7+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=LkbKrEDrBjvcPdAClb+lKSxtG3XLDsj7w2nJzM1I/vk=; b=CxaZl6buuKaXmT7woqyh8stXF3K0u8BagW7/gHuTSVrX2ycxeRQzFoR5BnREhWGSpO 0+tjVmtVM+FuZMpbzY1782kLnaW7Qb6q0g83MbeMJjIb/uK0aOhe1wEi3dYHgBLVLJ/d IiaOht4UJf9HtjcRLqNGSwfrlEhAg19h6Ta4Io3FjefEBrdLs+0gfvUy4N9wIQJJ4ER9 8Y17yUeliRpaOqUbde47GUNkvzan8T0P2C7cA1+romVxvzs4GEbF9yxz4o2fGEPO7CQv V96MLQUwPS/F+b0lAExKSjCnJydWm7CcfzGOBwx41co3DQs5UIXSalhYIDCjXEX3BTy0 SrPw== X-Gm-Message-State: AOAM5313roD8zE3Ya0YxNNJMSe5G4tJcWsIhGUOV2+vcAoRsNp2mWEzX dQiVewlu67uIWXkD2k3w75ub+IqRzpFr9w== X-Google-Smtp-Source: ABdhPJyG3Gh95luJkwgUlcwLhf/+/EvBbD9WfJajStzo3Tp41WfHyDVz7u57JDPZOn7gwFsst6GVKg== X-Received: by 2002:ac8:b07:: with SMTP id e7mr38973406qti.311.1608053176503; Tue, 15 Dec 2020 09:26:16 -0800 (PST) Received: from MacBook-Pro-2019.local (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id r5sm17007579qti.28.2020.12.15.09.26.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Dec 2020 09:26:15 -0800 (PST) To: Barry Leiba , draft-ietf-calext-ical-relations.all@ietf.org Cc: calsify@ietf.org References: From: Michael Douglass Message-ID: <7d01160e-de34-17d2-ebc9-5f8904db9f62@gmail.com> Date: Tue, 15 Dec 2020 12:26:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DAAC5B8AA681D73ED20FAFBF" Content-Language: en-US Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-ical-relations-05 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2020 17:26:20 -0000 This is a multi-part message in MIME format. --------------DAAC5B8AA681D73ED20FAFBF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I'm hoping to get through all your message today but I thought I'd deal with at least one point separately: On 11/19/20 14:08, Barry Leiba wrote: > This is probably a good time to pay attention to BCP 178 (RFC 6648) by > removing the x-name construction from the ABNF (also in Section 5.1). > > I agree with your point - however 6648 says > 5. Does not override existing specifications that legislate the use > of "X-" for particular application protocols (e.g., the "x-name" > token in [RFC5545 ]); this is a matter for the designers of those > protocols. So 5545 in section 3.1 defines x-name and goes on to say: > Applications MUST ignore x-param and iana-param values they don't > recognize. There are about 50 references to "x-". In section 3.6 I found > Applications MUST ignore > x-comp and iana-comp values they don't recognize. Applications that > support importing iCalendar objects SHOULD support all of the > component types defined in this document, and SHOULD NOT silently > drop any components as that can lead to user data loss. > On a side note in section 3.6.6 I found this: > Note: Implementations should carefully consider whether they > accept alarm components from untrusted sources, e.g., when > importing calendar objects from external sources. One > reasonable policy is to always ignore alarm components that the > calendar user has not set herself, or at least ask for > confirmation in such a case. > > and 3.8.6.1 > Applications MUST ignore alarms with x-name > and iana-token values they don't recognize. > 3.8.8.1 and 3.8.8.2 deals with iana and x-properties I think what I'm working round to saying is that it's probably time to consider a replacement for 5545. In my opinion 5545+ should state up front what MUST be processed and what CAN or SHOULD be ignored (though that may differ with the protocol used) In the shorter term we probably at least ought to have an update which explicitly deprecates x- for 5545 --------------DAAC5B8AA681D73ED20FAFBF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I'm hoping to get through all your message today but I thought I'd deal with at least one point separately:

On 11/19/20 14:08, Barry Leiba wrote:

This is probably a good time to pay attention to BCP 178 (RFC 6648) by
removing the x-name construction from the ABNF (also in Section 5.1).

I agree with your point - however 6648 says

   5.  Does not override existing specifications that legislate the use
       of "X-" for particular application protocols (e.g., the "x-name"
       token in [RFC5545]); this is a matter for the designers of those
       protocols.
So 5545 in section 3.1 defines x-name

and goes on to say:

   Applications MUST ignore x-param and iana-param values they don't
   recognize.
There are about 50 references to "x-".

In section 3.6 I found

Applications MUST ignore
   x-comp and iana-comp values they don't recognize.  Applications that
   support importing iCalendar objects SHOULD support all of the
   component types defined in this document, and SHOULD NOT silently
   drop any components as that can lead to user data loss.
On a side note in section 3.6.6 I found this:

         Note: Implementations should carefully consider whether they
         accept alarm components from untrusted sources, e.g., when
         importing calendar objects from external sources.  One
         reasonable policy is to always ignore alarm components that the
         calendar user has not set herself, or at least ask for
         confirmation in such a case.

and 3.8.6.1

 Applications MUST ignore alarms with x-name
      and iana-token values they don't recognize.
3.8.8.1 and 3.8.8.2 deals with iana and x-properties

I think what I'm working round to saying is that it's probably time to consider a replacement for 5545. In my opinion 5545+ should state up front what MUST be processed and what CAN or SHOULD be ignored (though that may differ with the protocol used)

In the shorter term we probably at least ought to have an update which explicitly deprecates x- for 5545




--------------DAAC5B8AA681D73ED20FAFBF-- From nobody Tue Dec 15 10:04: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 890413A129F; Tue, 15 Dec 2020 10:04:11 -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_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 hJwEN5-ASjTc; Tue, 15 Dec 2020 10:04:10 -0800 (PST) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (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 A5B103A129E; Tue, 15 Dec 2020 10:04:09 -0800 (PST) Received: by mail-lf1-f44.google.com with SMTP id o13so18530223lfr.3; Tue, 15 Dec 2020 10:04:09 -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=1qt4tvFvXqqkg5dCgMZ367oFU5uhdKqsj7yoAyO3WIo=; b=apvjef0xVnUezCDXvCqPzWxSYdRc4f/KTtAOuO6gPlAIJ7twcI15cnlu5PfR7SH7a6 BdJ/nVmxohSYa28436kXGZd/6KCAKriBi+3WU8mMdj5qdBswnSwwVC30JU5yTVzPvLh3 nDUj9UOri8uUeNYDSKdRr2CDX9gybAgg8KdoN0hPrjWCscptw8IocNyxGn0cZTPGRlEq MXNjrQV1PMHDxXHeeVAdkMICco8OREWwYqSyFqbc8YIo4v1iwJmT5rSnbf2Z6LeGVwi6 JDQ3GPlpsA2bDF71xN0vbpz4JcCxTRo72m9VkOEOT69jkStQ4QCGjXVvrtQlJHX6G4cY 2eAg== X-Gm-Message-State: AOAM533EkiDfvqnv3YR59J8M+V8WnfR4LyJdRyNEgr5/YTlcB9zGZmrv VMTa7HoZB9e+ftk3pbt5IhInYVuB74qBBCt7tSw= X-Google-Smtp-Source: ABdhPJzsKJilyaonqTUi+vMpe9IlPwvFDlja2tQlPyYQwYnjuV1zuDmVUPyjQQLj1sTzO/EEMmlwy/pqkBAYObR6r0M= X-Received: by 2002:a2e:b047:: with SMTP id d7mr8317688ljl.467.1608055447595; Tue, 15 Dec 2020 10:04:07 -0800 (PST) MIME-Version: 1.0 References: <7d01160e-de34-17d2-ebc9-5f8904db9f62@gmail.com> In-Reply-To: <7d01160e-de34-17d2-ebc9-5f8904db9f62@gmail.com> From: Barry Leiba Date: Tue, 15 Dec 2020 13:03:56 -0500 Message-ID: To: Michael Douglass Cc: draft-ietf-calext-ical-relations.all@ietf.org, calsify@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-ical-relations-05 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2020 18:04:12 -0000 I agree that it's not up to this document to deprecate x- for iCalendar in general, I agree that we should probably consider a 5545bis, and that we might at least consider a separate doc to deprecate x-. Still, I see no reason that we shouldn't *now* eliminate "x-" from new extensions/additions that we publish. That said, I'm not going to hold out on this point, and if the working group thinks it's best to leave "x-" in for now, I will still move the document forward. But I'd like to hear *why* the working group think that (and not just "because it's still in a lot of other places as well"). Barry On Tue, Dec 15, 2020 at 12:26 PM Michael Douglass wrote: > > I'm hoping to get through all your message today but I thought I'd deal with at least one point separately: > > On 11/19/20 14:08, Barry Leiba wrote: > > This is probably a good time to pay attention to BCP 178 (RFC 6648) by > removing the x-name construction from the ABNF (also in Section 5.1). > > > I agree with your point - however 6648 says > > 5. Does not override existing specifications that legislate the use > of "X-" for particular application protocols (e.g., the "x-name" > token in [RFC5545]); this is a matter for the designers of those > protocols. > > So 5545 in section 3.1 defines x-name > > and goes on to say: > > Applications MUST ignore x-param and iana-param values they don't > recognize. > > There are about 50 references to "x-". > > In section 3.6 I found > > Applications MUST ignore > x-comp and iana-comp values they don't recognize. Applications that > support importing iCalendar objects SHOULD support all of the > component types defined in this document, and SHOULD NOT silently > drop any components as that can lead to user data loss. > > On a side note in section 3.6.6 I found this: > > Note: Implementations should carefully consider whether they > accept alarm components from untrusted sources, e.g., when > importing calendar objects from external sources. One > reasonable policy is to always ignore alarm components that the > calendar user has not set herself, or at least ask for > confirmation in such a case. > > > and 3.8.6.1 > > Applications MUST ignore alarms with x-name > and iana-token values they don't recognize. > > 3.8.8.1 and 3.8.8.2 deals with iana and x-properties > > I think what I'm working round to saying is that it's probably time to consider a replacement for 5545. In my opinion 5545+ should state up front what MUST be processed and what CAN or SHOULD be ignored (though that may differ with the protocol used) > > In the shorter term we probably at least ought to have an update which explicitly deprecates x- for 5545 > > > > From nobody Tue Dec 15 11:03:00 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 15E803A16CF; Tue, 15 Dec 2020 11:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MKObiG_CAGj; Tue, 15 Dec 2020 11:02:56 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAAB33A16CE; Tue, 15 Dec 2020 11:02:56 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id y15so15433962qtv.5; Tue, 15 Dec 2020 11:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=ydtcuwFcpeE93CFIleG9ixnF3oTzCh+TdRbTJ9kVh6Y=; b=a7Q53f28DtsUJod+wvmKXoB8m888rv+gR4a4bw9ZfIjz3Sl/5WJekuixBhbBYbvt21 Y/ICSirQBoRkJ2x5prRmP4tc/pNNMfb648mlLQuR7xg3ivqLeGh26gPS733Om0RtO7MS wEeVsiv+o6CqLcOaZB2izC49zpKyPuz/43EIHYgxJ8+x7INeu5UGTcGxn00gL1fmPtmM 5acbm0bXicjlU6ic5blZonne1UHteeYtO0wU3J2Lcz6mV9h9IYPZPLciIbZM03P0z/Y3 90mR3gbh275yZiS5jKp+Zzw1zgwFfsuEW1dpkh327YV6qKH04GRdr7ZEIJTXPOsamob+ UOdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ydtcuwFcpeE93CFIleG9ixnF3oTzCh+TdRbTJ9kVh6Y=; b=AfcATh8PBVsQRSRdgbEvCWtY1pesO9xwayqllt/9aH7/bV4ED6o0DyApyFweGrXg9E Mcr7FLev2woO09ESJj0AeN175V/zzVh3D3s7m3Ro1zlXa9yHz+SmlnInhlO1TcPLTZ1b VwDfhiksjp6lyuHHONnajnEgVUEyTfDaFNzjwMSO5pAw2/O11oBm7WJ+/LsHGJDPYkwV O2JB4/vHyyaQairDyVg6uuxiAl0a3YOcO8lrfd1bzVhgQJYR7y0nlcd+FN5aLdBtzE9S /1QmgRIM/abGMj+rs0euVC+eFjs9K+ccBDAXAgBXJ0ITT2YLBoQNl7+f6NBsK0AZQyYb LNIQ== X-Gm-Message-State: AOAM53228KGK/BAUuAvCDkzhlJNre2uGBkejathw7vv+bH8IFsF6LV2D niVP2mLhQ5b5h0r1L3O3FHxsV8VcEkKszA== X-Google-Smtp-Source: ABdhPJwX5sdbUGBrD3lDroZYJcr134bWb75yJE6U7c8ELdWbZRRmjf64CpXkD0RmuyKRsW4zm/7M2A== X-Received: by 2002:ac8:730d:: with SMTP id x13mr38079769qto.162.1608058975053; Tue, 15 Dec 2020 11:02:55 -0800 (PST) Received: from MacBook-Pro-2019.local (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id m8sm17798027qkn.41.2020.12.15.11.02.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Dec 2020 11:02:53 -0800 (PST) To: Barry Leiba Cc: draft-ietf-calext-ical-relations.all@ietf.org, calsify@ietf.org References: <7d01160e-de34-17d2-ebc9-5f8904db9f62@gmail.com> From: Michael Douglass Message-ID: <96df1f46-9c2f-b5e5-3530-432181488bfa@gmail.com> Date: Tue, 15 Dec 2020 14:02:53 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-ical-relations-05 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2020 19:02:58 -0000 On 12/15/20 13:03, Barry Leiba wrote: > I agree that it's not up to this document to deprecate x- for > iCalendar in general, I agree that we should probably consider a > 5545bis, and that we might at least consider a separate doc to > deprecate x-. Still, I see no reason that we shouldn't *now* > eliminate "x-" from new extensions/additions that we publish. I think it's reasonable to remove them from this spec > > That said, I'm not going to hold out on this point, and if the working > group thinks it's best to leave "x-" in for now, I will still move the > document forward. But I'd like to hear *why* the working group think > that (and not just "because it's still in a lot of other places as > well"). I think we've already moved in practice away from  x-. It's just we haven't explicitly said so anywhere. Probably an agenda item for the next meeting? > > Barry > > On Tue, Dec 15, 2020 at 12:26 PM Michael Douglass > wrote: >> I'm hoping to get through all your message today but I thought I'd deal with at least one point separately: >> >> On 11/19/20 14:08, Barry Leiba wrote: >> >> This is probably a good time to pay attention to BCP 178 (RFC 6648) by >> removing the x-name construction from the ABNF (also in Section 5.1). >> >> >> I agree with your point - however 6648 says >> >> 5. Does not override existing specifications that legislate the use >> of "X-" for particular application protocols (e.g., the "x-name" >> token in [RFC5545]); this is a matter for the designers of those >> protocols. >> >> So 5545 in section 3.1 defines x-name >> >> and goes on to say: >> >> Applications MUST ignore x-param and iana-param values they don't >> recognize. >> >> There are about 50 references to "x-". >> >> In section 3.6 I found >> >> Applications MUST ignore >> x-comp and iana-comp values they don't recognize. Applications that >> support importing iCalendar objects SHOULD support all of the >> component types defined in this document, and SHOULD NOT silently >> drop any components as that can lead to user data loss. >> >> On a side note in section 3.6.6 I found this: >> >> Note: Implementations should carefully consider whether they >> accept alarm components from untrusted sources, e.g., when >> importing calendar objects from external sources. One >> reasonable policy is to always ignore alarm components that the >> calendar user has not set herself, or at least ask for >> confirmation in such a case. >> >> >> and 3.8.6.1 >> >> Applications MUST ignore alarms with x-name >> and iana-token values they don't recognize. >> >> 3.8.8.1 and 3.8.8.2 deals with iana and x-properties >> >> I think what I'm working round to saying is that it's probably time to consider a replacement for 5545. In my opinion 5545+ should state up front what MUST be processed and what CAN or SHOULD be ignored (though that may differ with the protocol used) >> >> In the shorter term we probably at least ought to have an update which explicitly deprecates x- for 5545 >> >> >> >> From nobody Tue Dec 15 11:14:38 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAC2B3A107B; Tue, 15 Dec 2020 11:14:36 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UrDiKEzavZp; Tue, 15 Dec 2020 11:14:35 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8863A11D4; Tue, 15 Dec 2020 11:14:34 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id b64so16252821qkc.12; Tue, 15 Dec 2020 11:14:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=KJ5VkEBC9y2qXR7bhH8nnO4P+jqJt4ncXCqXtbr3eqM=; b=f59V3+xonJflf1QWhqzwvyNvLs0Kc92zosvdrHkAWmVuw1yabevWHirnK0NwhuG8O7 W1iYHVlUYV+4+mMaUNYNjc2DDHn0VFT+9bwXiymlN/x/nv+jRLNkEZnOMB+hZ9UontBV ek72P/w+DEl3cmI9FFDYSdajVbjDdOzw93ZfE9DKbNENUd2mhUCmv4RTKd3NhjxVnFMJ evcxW0HLZZ/yAyHY3h60K3kQoDJrdLyVCF8xGUx6a6TtvEbdgIHZ9/qWCdVhfXZdLDst o/et4keTG0/OATabj/Fv94Ne0FgoNHIDGQUaGtt6xA1YFw006+b23QbkepCYA6KCABJw 7Vqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=KJ5VkEBC9y2qXR7bhH8nnO4P+jqJt4ncXCqXtbr3eqM=; b=Lq7DDX6G4yshybB50HWiGhUn749+NxqoUVwBWeOYLo2R5NkYmlTQrEibV9iTJDlYbq 3/1cSHGprMCQEdn4/K+yFGoRqDAx39UKLHIS5uvaWqNTK0ZTQscVWxPYOSblaciAs0Pj ICXL1LggAKFFJVmizm27VOFMaf00+KyOYh7jbLG8DXybwNkt6cO2DNwmpXBnOEFUAgtI cAz6t0UlgS6k5jsOp6cRbWkpP4y8DGLaH8K40bgysok2xeM03AGX3/XywOsj8qZQpGx7 2VgfDp+XIjGhlskPnNK+B8i1OKqk94qDsvXTiXaK6fsaTumHtdXkj9tLshLI4OBVUE1V ZVdw== X-Gm-Message-State: AOAM530/+L5EsoH6Ev69TGQxKSjgyqPQaec4YVW7tgBJtcX0VwFzkx4k UJU9FJ/aexeIQ8orj/aHBtvBfAK/nyAo/Q== X-Google-Smtp-Source: ABdhPJy4ty1ay1bfl+QPgqdtoigtTNXsLCexSjY7AuICViNCJkiR48AIyQOS+JQFTec04ZT1ThJ8KA== X-Received: by 2002:a37:aec2:: with SMTP id x185mr40535952qke.64.1608059673571; Tue, 15 Dec 2020 11:14:33 -0800 (PST) Received: from MacBook-Pro-2019.local (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id d9sm16679143qtm.66.2020.12.15.11.14.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Dec 2020 11:14:32 -0800 (PST) To: Barry Leiba Cc: draft-ietf-calext-ical-relations.all@ietf.org, calsify@ietf.org References: <7d01160e-de34-17d2-ebc9-5f8904db9f62@gmail.com> From: Michael Douglass Message-ID: <0c4d0766-d521-f20f-402d-2af84add4d3a@gmail.com> Date: Tue, 15 Dec 2020 14:14:33 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-ical-relations-05 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2020 19:14:37 -0000 I should perhaps point out that many of these issues are really due to the practice of requiring full replacement of an entity rather than having an update mechanism. SOAP for example, explicitly requires that an unrecognized (by the schema) element be dropped so it's a requirement to have an update mechanism that doesn't require a full copy of the data. The specification only defines what's valid. I've been advocating for some time (while recognising the work involved) that we should have a data model specification that is independent of the representation. Other specs defining representations would then effectively be mappings onto the model. OASIS - I believe - does this with their pim - a platform independent model. The psm is the platform specific model which defines that mapping. They do in fact have a pim for a large subset of the calendaring model. https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-calendar#technical On 12/15/20 13:03, Barry Leiba wrote: > I agree that it's not up to this document to deprecate x- for > iCalendar in general, I agree that we should probably consider a > 5545bis, and that we might at least consider a separate doc to > deprecate x-. Still, I see no reason that we shouldn't *now* > eliminate "x-" from new extensions/additions that we publish. > > That said, I'm not going to hold out on this point, and if the working > group thinks it's best to leave "x-" in for now, I will still move the > document forward. But I'd like to hear *why* the working group think > that (and not just "because it's still in a lot of other places as > well"). > > Barry > > On Tue, Dec 15, 2020 at 12:26 PM Michael Douglass > wrote: >> I'm hoping to get through all your message today but I thought I'd deal with at least one point separately: >> >> On 11/19/20 14:08, Barry Leiba wrote: >> >> This is probably a good time to pay attention to BCP 178 (RFC 6648) by >> removing the x-name construction from the ABNF (also in Section 5.1). >> >> >> I agree with your point - however 6648 says >> >> 5. Does not override existing specifications that legislate the use >> of "X-" for particular application protocols (e.g., the "x-name" >> token in [RFC5545]); this is a matter for the designers of those >> protocols. >> >> So 5545 in section 3.1 defines x-name >> >> and goes on to say: >> >> Applications MUST ignore x-param and iana-param values they don't >> recognize. >> >> There are about 50 references to "x-". >> >> In section 3.6 I found >> >> Applications MUST ignore >> x-comp and iana-comp values they don't recognize. Applications that >> support importing iCalendar objects SHOULD support all of the >> component types defined in this document, and SHOULD NOT silently >> drop any components as that can lead to user data loss. >> >> On a side note in section 3.6.6 I found this: >> >> Note: Implementations should carefully consider whether they >> accept alarm components from untrusted sources, e.g., when >> importing calendar objects from external sources. One >> reasonable policy is to always ignore alarm components that the >> calendar user has not set herself, or at least ask for >> confirmation in such a case. >> >> >> and 3.8.6.1 >> >> Applications MUST ignore alarms with x-name >> and iana-token values they don't recognize. >> >> 3.8.8.1 and 3.8.8.2 deals with iana and x-properties >> >> I think what I'm working round to saying is that it's probably time to consider a replacement for 5545. In my opinion 5545+ should state up front what MUST be processed and what CAN or SHOULD be ignored (though that may differ with the protocol used) >> >> In the shorter term we probably at least ought to have an update which explicitly deprecates x- for 5545 >> >> >> >> From nobody Tue Dec 15 12:54:02 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 1AF6E3A18EB; Tue, 15 Dec 2020 12:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePw5LCJZXsLG; Tue, 15 Dec 2020 12:53:53 -0800 (PST) Received: from mail-qv1-xf36.google.com (mail-qv1-xf36.google.com [IPv6:2607:f8b0:4864:20::f36]) (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 E92D43A176B; Tue, 15 Dec 2020 12:53:33 -0800 (PST) Received: by mail-qv1-xf36.google.com with SMTP id l14so10289528qvh.2; Tue, 15 Dec 2020 12:53:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=8u2e8JX+t98dk1xnbMJPBvFBrsJ3E7wkv6dudk1OAn4=; b=L4gyuQ0BzcPaYn9skz1IfKcA4jF1JXqed2Z0CNrcd3cuOJuDL6tgZCbAUZqc9ijSLR Zg3tcF5HcZOPE4EgwUeYHlpToBbipIdqNqQd/jSzOdkbMsoQ/QF7YfBW2+Q6MoiW8qAG LzqarlhoaG+6ZYeGaFJnbPc6DpGJZB7Eu8CoFM8pGxLVz4M7ZIyucHABLvI8LihuoAvn d/j/Xa+oCd1VUSOujCZy24hr7jX5qAEt9gOwWz5BsQZ+q60JoZZ6obhzbl01oYzvupHH rWBoTLlbLrJ7lC/QvFmP59/ZfrK4gdtKPzG1QyAKYx+2CgBWby6xdHvS5pbiGEzyqsyr nuUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=8u2e8JX+t98dk1xnbMJPBvFBrsJ3E7wkv6dudk1OAn4=; b=j1qzyMbyvODI47EaCmEIOVIlF+rusP51LYOFXvFu/5MttqOr8hXNR+tvQ8J6l5Iy57 Q/O9x6QWgV6KvUSGlHtawjgEPYdp7KzomJhZA5BcWC3knDhnUq8eQpzsjCSEH63YjvKE 21ZsZGAATXEAXaxLBKqWz+uENuEgxt0cM180mPvwmzM9pdp4lBiNaw4suftOUZDnaAoL SimNyxec0JfWGpZSE6gbygv13tBKXcJTt2TR97YHtfW9DgwcUMsPvJkQMUfFJqTpJZYj 7qD7Ody08hs/JqyXNu6Hjaj1lVUVXZS/fL3ukFmj/u+x01hb6my+TQYxr5LEwUMOKhkk 8uJA== X-Gm-Message-State: AOAM531owTUu5wowRQBj9yDUcsnHQf8oLKl1guSAEhoN36jyVZQ3+OuH WamT/rbfAUxkTpMkIh6rce5qSOciSildZg== X-Google-Smtp-Source: ABdhPJz0DUcc5rkhqfKiILhsrYb0muYdwVHzIUxzCa1TmsKlXUCCtRtUBt/vswoe4+hc47p//9ZOsw== X-Received: by 2002:a05:6214:14ee:: with SMTP id k14mr1798998qvw.36.1608065612642; Tue, 15 Dec 2020 12:53:32 -0800 (PST) Received: from MacBook-Pro-2019.local (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id d16sm14964984qkb.42.2020.12.15.12.53.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Dec 2020 12:53:31 -0800 (PST) To: Barry Leiba , draft-ietf-calext-ical-relations.all@ietf.org Cc: calsify@ietf.org References: From: Michael Douglass Message-ID: Date: Tue, 15 Dec 2020 15:53:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9AA75616291252BFDDD4723A" Content-Language: en-US Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-ical-relations-05 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2020 20:54:01 -0000 This is a multi-part message in MIME format. --------------9AA75616291252BFDDD4723A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Just dealing with the abnf issues. Can I try out a suggestion for section 8.1 - The RELATED-TO abnf On 11/19/20 14:08, Barry Leiba wrote: > — Section 8.1 — > > definition here extends the definition in Section 3.8.4.5. of > [RFC5545] > > Also here: remove the dot at the end of the section number. > > For the ABNF in this section I have the same comments as for the ABNF > in Section 7.1. In addition, this defines “relparam”, but “relparam” > is already defined in Section 5.1. That needs to be fixed. > OLD related = "RELATED-TO" relparam ( ":" text ) / ( ";" "VALUE" "=" "UID" ":" uid ) ( ";" "VALUE" "=" "URI" ":" uri ) CRLF relparam = *( ; ; The following are OPTIONAL, ; but MUST NOT occur more than once. ; (";" reltypeparam) / (";" gapparam) / ; ; The following is OPTIONAL, ; and MAY occur more than once. ; (";" other-param) ; ) NEW related = "RELATED-TO" relparam ( ":" text ) / ( ";" "VALUE" "=" "UID" ":" uid ) / ( ";" "VALUE" "=" "URI" ":" uri ) CRLF relparam = ; the elements herein may appear in any order, ; and the order is not significant. [";" reltypeparam] [";" gapparam] *(";" other-param) END I'm not sure that this construct is still the best way to relate a VALUE parameter to a specific value type. It still seems to constrain the order. Does this work better? START related = "RELATED-TO" relparam ":" ( uid / ; for VALUE=UID uri / ; for VALUE=URI text ) ; for VALUE=TEXT or default CRLF relparam = ; the elements herein may appear in any order, ; and the order is not significant. [";" ("VALUE" "=" "UID" / "VALUE" "=" "URI" / "VALUE" "=" "TEXT")] [";" reltypeparam] [";" gapparam] *(";" other-param) END This seems to do the job - if it works I can redo the abnf for the other properties (and for eventpub) --------------9AA75616291252BFDDD4723A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Just dealing with the abnf issues. Can I try out a suggestion for section 8.1 - The RELATED-TO abnf

On 11/19/20 14:08, Barry Leiba wrote:
— Section 8.1 —

      definition here extends the definition in Section 3.8.4.5. of
      [RFC5545]

Also here: remove the dot at the end of the section number.

For the ABNF in this section I have the same comments as for the ABNF
in Section 7.1.  In addition, this defines “relparam”, but “relparam”
is already defined in Section 5.1.  That needs to be fixed.

OLD

related    = "RELATED-TO" relparam ( ":" text ) /
             (
               ";" "VALUE" "=" "UID"
               ":" uid
             ) 
             (
               ";" "VALUE" "=" "URI"
               ":" uri
             )
             CRLF

relparam   = *(
            ;
            ; The following are OPTIONAL,
            ; but MUST NOT occur more than once.
            ;
            (";" reltypeparam) /
            (";" gapparam) /
            ;
            ; The following is OPTIONAL,
            ; and MAY occur more than once.
            ;
            (";" other-param)
            ;
            )

NEW

related    = "RELATED-TO" relparam ( ":" text ) /
             (
               ";" "VALUE" "=" "UID"
               ":" uid
             ) /
             (
               ";" "VALUE" "=" "URI"
               ":" uri
             )
             CRLF

relparam   = ; the elements herein may appear in any order,
             ; and the order is not significant.
             [";" reltypeparam]
             [";" gapparam]
             *(";" other-param)

END

I'm not sure that this construct is still the best way to relate a VALUE parameter to a specific value type. It still seems to constrain the order.

Does this work better?

START

related    = "RELATED-TO" relparam ":"
             ( uid /  ; for VALUE=UID
               uri /  ; for VALUE=URI
               text ) ; for VALUE=TEXT or default 
             CRLF

relparam   = ; the elements herein may appear in any order,
             ; and the order is not significant.
             [";" ("VALUE" "=" "UID" /
                   "VALUE" "=" "URI" /
                   "VALUE" "=" "TEXT")]
             [";" reltypeparam]
             [";" gapparam]
             *(";" other-param)
END

This seems to do the job - if it works I can redo the abnf for the other properties (and for eventpub)

--------------9AA75616291252BFDDD4723A-- From nobody Sat Dec 19 10:50:21 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E973A0E76 for ; Sat, 19 Dec 2020 10:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=mnCwXW/6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Qru9gT5l 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 Vo3_V-GMkmUo for ; Sat, 19 Dec 2020 10:50:18 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4614B3A0E7A for ; Sat, 19 Dec 2020 10:50:18 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 4FD524D2 for ; Sat, 19 Dec 2020 13:50:17 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sat, 19 Dec 2020 13:50:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= to:from:subject:message-id:date:mime-version:content-type; s= fm1; bh=/35ZJPcimpoMvP3fFt90ffGqCDxt/vFcjNGy+B5NrZE=; b=mnCwXW/6 Tq4DAND2e8V8ApZ0WrCHfjgKcAfjvLiTUTPiiWUyC/5bLzPJy2S8CrgAqttXl/Y6 ueA7DpS6d+H81QIx2YLelw6EGg72l6p7t+OI1OpuBR5FIJWibT0HUm6TwQqzlDsr YLUkk8CYp9w9Wu4R3V4m/bncz6niFve9+GcywZ/LxP9b+KJuQtr6mHxy+lKRHivD 8pQIfwIKaC+ZUDBrAu8SutvvipsiI7Mrjh4XQ2lCp3YP8Byw45P+yw8MMb+WMjsN RrdxjHHmYSq5yNHQW11+4MefLxywMZCSqbXQnU/kzPlRIWYAiXAUcfWKc5SyZQzx fh6weT1+VahPyQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=/35ZJPcimpoMvP3fFt90ffGqCDxt/ vFcjNGy+B5NrZE=; b=Qru9gT5ljNTvD8/KAaLVTCwlWC7q2tnRv2WquX0nSCgx4 8DZhCcyQPhXwuA/xCPEUD39PvUmrYkbY1SUuXMNQq9aNcPutoLHOs04sm6tdnROn tsnwCu2sptpOMZUBuUeCGDDrZ2vXlTj0n1iskICUukhKakjdnpudjxokMlQB61Vt gTazdmugTUWSRH1MgbmXybGXirXi6cFT63uh7E8ZNOC91afoFNn1nCq8F8+Dl/mg xSion7g5ITQEi8ALgOkadjlAr/bB6zTJxSXOXQ4eI1EqgaPCO120bBa6vn/nvNtF D85LI8rJxYGKO+2mxx0Pgn8e/ehype3WE7nuAIFnw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudelkedguddvudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepvffhuffkffgfgggtsegrtderre dtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgrshht mhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeejgeelhedtgeevgfdtvedtleevvd evffffhfejleelfeefffejffeflefhueekhfenucfkphepjeegrdejjedrkeehrddvhedt necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhurh gthhesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 7A7A924005A for ; Sat, 19 Dec 2020 13:50:16 -0500 (EST) To: Calsify From: Ken Murchison Message-ID: <57f81335-b7a9-6a9f-df5f-bab580689a33@fastmail.com> Date: Sat, 19 Dec 2020 13:50:13 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------7F998C830D4372089120212B" Content-Language: en-US Archived-At: Subject: [calsify] draft-ietf-calext-jscalendar-icalendar-02 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2020 18:50:20 -0000 This is a multi-part message in MIME format. --------------7F998C830D4372089120212B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit All, I just had cause to consult jscalendar-icalendar Section 2.1 and I have a couple of issues: 1. Why is this value specified to be the entire date-time plus fractional seconds?  Wouldn't the fractional seconds be sufficient? 2. The definition of the parameter is incorrect: 1. It doesn't include the game of the parameter in the definition 2. The value isn't DATE-TIME or DURATION, its value is an extension of date-time.  If keeping a full time representation it should be something like "date-time "." 1*DIGIT -- Kenneth Murchison Senior Software Developer Fastmail US LLC --------------7F998C830D4372089120212B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

All,

I just had cause to consult jscalendar-icalendar Section 2.1 and I have a couple of issues:

  1. Why is this value specified to be the entire date-time plus fractional seconds?  Wouldn't the fractional seconds be sufficient?
  2. The definition of the parameter is incorrect:
    1. It doesn't include the game of the parameter in the definition
    2. The value isn't DATE-TIME or DURATION, its value is an extension of date-time.  If keeping a full time representation it should be something like "date-time "." 1*DIGIT

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
--------------7F998C830D4372089120212B-- From nobody Sun Dec 20 21:09:33 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6603A0C67 for ; Sun, 20 Dec 2020 21:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTysbqvMN6A7 for ; Sun, 20 Dec 2020 21:09:30 -0800 (PST) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 4C3033A0C64 for ; Sun, 20 Dec 2020 21:09:30 -0800 (PST) Received: by mail-qv1-xf35.google.com with SMTP id d11so3946438qvo.11 for ; Sun, 20 Dec 2020 21:09:30 -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=NDJ1+HZNYpfWNpVuhZHTPdz+FOWKq+HaOG2LwG2I1bM=; b=reR/Uod4EU9nVFSbm0dEf0MD+T000g/aHx2VPkeA52HJ6B/xYt13suTd3EaQgrBokd iyf3MNefRJLysEWxk2g1Bk1WaO9t2zG12q0wR6478z4NlCr98Zc87ewh3Nx8YO9AeKsG 1t7tBZDH7Bc9XJBvOYNAL+8foNIwzOdjaY1eXJ24mgmAXZGylE7Bxx06FuFl8RvQ+iNf ph5tNYP3xrJXs2VeJ/27wXZHbcnRtBei/4bvLQvJLSgB5NtoT4slwFFUibiW3mTITvzI bIF0Hi8oXiDcfpLKQSdJtuBPRA0bfKJJkis37D4jvGKUN+Xom9+H3S/y9nCPTXyX+SkV k42A== 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=NDJ1+HZNYpfWNpVuhZHTPdz+FOWKq+HaOG2LwG2I1bM=; b=BTvPYjzIiKXeui2RSGW/HlyByHKgB1wXoTpDXyf7XpZsmzBWW0U5UPtO05EpTTFVhB fyhhQt98JTvTkIKJ0wWSOph6xabiTDRvxlOM75UK8HLZC1tr/G4sIPRK9mdymwLK6G+S ce0XYDDg+S4zxDyXKayvgxGdAE2XBsqrdnSSveJbkwadSifDZtIZ0zfwKlkYpYdJ99UU tZkvNu7tYf6gxQO1GLkcomErYy0/dDN+K7ETLekQQL7mE1WQYH/SnwbcH2Z0B8JYVv/U 9Sn2z5nlAfAeq2hzDKqKfSoK75Vu2wQJXYU5c8fZOk1b6g3ccqk5BnMxxphKmHxBTj/N RQhg== X-Gm-Message-State: AOAM530qHbypK6PkvPVI6lAvAe8tfNYowvySrFjK6zFoULuZrE1ri4B1 G4uMQb3Y8EIIcJMVLjUm1mG8Nsua9MeX2g== X-Google-Smtp-Source: ABdhPJww4xfDoGvgGp6G7TgQhyG4nXIIH6g4FTKb1RQFkexlVOeZYsiEAuJm3aM1vpkUzUrAxlSgeg== X-Received: by 2002:a0c:9ccb:: with SMTP id j11mr3314359qvf.44.1608527369006; Sun, 20 Dec 2020 21:09:29 -0800 (PST) Received: from [192.168.1.151] (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id r22sm10646123qkk.67.2020.12.20.21.09.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 20 Dec 2020 21:09:27 -0800 (PST) To: Ken Murchison , Calsify References: <57f81335-b7a9-6a9f-df5f-bab580689a33@fastmail.com> From: Michael Douglass Message-ID: Date: Mon, 21 Dec 2020 00:09:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <57f81335-b7a9-6a9f-df5f-bab580689a33@fastmail.com> Content-Type: multipart/alternative; boundary="------------2EE05A8186AE1F3A57E18BCE" Content-Language: en-US Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar-icalendar-02 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, 21 Dec 2020 05:09:32 -0000 This is a multi-part message in MIME format. --------------2EE05A8186AE1F3A57E18BCE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/19/20 13:50, Ken Murchison wrote: > > All, > > I just had cause to consult jscalendar-icalendar Section 2.1 > and I have a couple of issues: > > 1. Why is this value specified to be the entire date-time plus > fractional seconds?  Wouldn't the fractional seconds be sufficient? > 2. The definition of the parameter is incorrect: > 1. It doesn't include the game of the parameter in the definition > 2. The value isn't DATE-TIME or DURATION, its value is an > extension of date-time.  If keeping a full time representation > it should be something like "date-time "." 1*DIGIT > 1.This was my suggestion - way back in April As I recall my main problem with the previous approach - which was just the fractional part - was that it led to ambiguities and having to define how the full value was rounded to produce the truncated iCalendar value. Having the full value means you just choose to use either the (possibly adjusted) property value or the (possibly more accurate) FRACTIONAL parameter value. No processing or worrying about edge cases. 2. I think FRACTIONAL can be used for DURATION as well as as for DTSTART and the abnf is wrong anyway. We have fractional-param = DATE-TIME or DURATION shouldn't it be something like fractional-param = "FRACTIONAL" = (date-time | dur-value) ["." 1*DIGIT] ; Value is extended date-time when used with the DTSTART property ; Value is extended dur-value when used with the DURATION property and we need abnf for etending DTSTART and DURATION > > -- > Kenneth Murchison > Senior Software Developer > Fastmail US LLC > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------2EE05A8186AE1F3A57E18BCE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/19/20 13:50, Ken Murchison wrote:

All,

I just had cause to consult jscalendar-icalendar Section 2.1 and I have a couple of issues:

  1. Why is this value specified to be the entire date-time plus fractional seconds?  Wouldn't the fractional seconds be sufficient?
  2. The definition of the parameter is incorrect:
    1. It doesn't include the game of the parameter in the definition
    2. The value isn't DATE-TIME or DURATION, its value is an extension of date-time.  If keeping a full time representation it should be something like "date-time "." 1*DIGIT
1.This was my suggestion - way back in April

As I recall my main problem with the previous approach - which was just the fractional part - was that it led to ambiguities and having to define how the full value was rounded to produce the truncated iCalendar value. Having the full value means you just choose to use either the (possibly adjusted) property value or the (possibly more accurate) FRACTIONAL parameter value. No processing or worrying about edge cases.

2. I think FRACTIONAL can be used for DURATION as well as as for DTSTART and the abnf is wrong anyway. We have

fractional-param = DATE-TIME or DURATION

shouldn't it be something like

fractional-param = "FRACTIONAL" = (date-time | dur-value) ["." 1*DIGIT]
; Value is extended date-time when used with the DTSTART property
; Value is extended dur-value when used with the DURATION property

and we need abnf for etending DTSTART and DURATION



-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------2EE05A8186AE1F3A57E18BCE-- From nobody Sun Dec 20 23:12:04 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584A83A0EAC for ; Sun, 20 Dec 2020 23:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=KwY1411H; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=C/AoY7qs 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 yyW-f3UiFs_D for ; Sun, 20 Dec 2020 23:12:00 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C623A0EAA for ; Sun, 20 Dec 2020 23:12:00 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 4018361F for ; Mon, 21 Dec 2020 02:12:00 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 21 Dec 2020 02:12:00 -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=fm1; bh=sbse01b 5IkJMQ92FHC9pGi73A563Ch/8e30xM1hzR4I=; b=KwY1411H0Q4zAPIGGE0KAL0 m+Aj6al1BnxoVi6oSeK7T0IjCIaFOv6icDNWMP52AoRo8peV8KiCOb13KV9m3uER aJNrzA4pl3Jw0eoHQIgukSdF951bwHriE7MmjThuQCOE6ttN8BSPEOrq4VVtfLKm +Z0/RQ5MbANsTxclQNl7zq0t9skYg11fCvPwDxYct8cFo7M07EwrtyHYfVdOuCy/ F6B/ByOgIOqf1Smmi3UXoDGGOXHsncdFmsIZVFl07X9b8ZxHyK88PW7ZfoYlv+Z4 rvpsbu/BKkiH1KbIN4xzN5saIgyEV3JsPMlBvySNSvUEBLq0L3sCCAUlZmcnbfA= = 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=fm1; bh=sbse01 b5IkJMQ92FHC9pGi73A563Ch/8e30xM1hzR4I=; b=C/AoY7qs4Yd8Q3zZP9AzEO ReP3IJwPIU5PGeRlx/bNydw1qFnitEXuZG2ZBW7L5cwpN/RfbEJnIYPNd41E10pM Pch61+X5hm+f5i4g0qHdKcD6y+Oo1IrVo69ooyPJqYa1ihe2EeJEkuojnjQACPt+ 8zMF5StV3nSw01BqTwjQq1JygQkl8bZcUTrcBMHKPj061tmDKEnOFRAA5tagzSYS zVfu3fjOSvf/iJgtqbdP2eobxGmXV3rvUeAvnxUH3oJO3bc9Gop5KV3kaC7necDg udOQwIVTuOp/El68Osd8rOlgEm0nl1LiHaGFuOi5KYl5QWxjrmm16XXBdRD3WULA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddtuddguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshht ohesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeehgeeuvd dtkefhtefgueefgfdvueetgeeffeelhedvudegjeejhfetuefgveevieenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmh grihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DC52E1800C1; Mon, 21 Dec 2020 02:11:58 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: <5ab63fe9-62af-4295-87a2-939d3b7df185@www.fastmail.com> In-Reply-To: References: <57f81335-b7a9-6a9f-df5f-bab580689a33@fastmail.com> Date: Mon, 21 Dec 2020 08:11:37 +0100 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=a2b431187a4643d6af656ea7efe09ec6 Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar-icalendar-02 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, 21 Dec 2020 07:12:02 -0000 --a2b431187a4643d6af656ea7efe09ec6 Content-Type: text/plain On Mon, Dec 21, 2020, at 6:09 AM, Michael Douglass wrote: > On 12/19/20 13:50, Ken Murchison wrote: >> 1. Why is this value specified to be the entire date-time plus fractional seconds? Wouldn't the fractional seconds be sufficient? > 1.This was my suggestion - way back in April We even agreed to this change, and while I implemented it in April, I did not update the RFC. My apologies, I just came to realize last week. I will update it in the next days. Cheers, Robert --a2b431187a4643d6af656ea7efe09ec6 Content-Type: text/html
On Mon, Dec 21, 2020, at 6:09 AM, Michael Douglass wrote:
On 12/19/20 13:50, Ken Murchison wrote:
  1. Why is this value specified to be the entire date-time plus fractional seconds?  Wouldn't the fractional seconds be sufficient?
1.This was my suggestion - way back in April

We even agreed to this change, and while I implemented it in April, I did not update the RFC. My apologies, I just came to realize last week. I will update it in the next days.

Cheers,
Robert
--a2b431187a4643d6af656ea7efe09ec6-- From nobody Mon Dec 21 04:17:10 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2843A0F22 for ; Mon, 21 Dec 2020 04:17:08 -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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=XMd30ACG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PoIwNFV3 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 ZphBjZJpoSpK for ; Mon, 21 Dec 2020 04:17:07 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3EE3A0F0F for ; Mon, 21 Dec 2020 04:17:06 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2E7BB5C017E; Mon, 21 Dec 2020 07:17:06 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 21 Dec 2020 07:17:06 -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=fm1; bh=JmQnLiXGCtbC/03yI5yjcsS973c 2M8mVKV4rzHBMF/w=; b=XMd30ACGd3CjCS78QJZDkLYkixhQCEOH6o3RJiXlZeQ Q2Z0hxPTefuKcTYt7vuuTlh/tU8mMYzs6n1yIExiSXei82NKWk9D7e2J6Vf5kRKN w2Lx3q7tPc9bwHRKkCnwKR6jV5g56XJNB8uqKSppUHi+GyYL/znrCE7CTc/eLlF1 KjGumaA9PQGtOrEiSL0FJYpQRogCosEFEkilshlnK6QZiZ6QEJMZI/egfIiweCW6 ypqeeib93AmkEq15csbFmGTTNTKWHcivZ4zfgifA+VzX9tJFXkVoZpleCbiDVccm fdXOICuXYNZQ5vpoplh9QI8kJuAA9xvoBzLFLpgJJrg== 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=fm1; bh=JmQnLi XGCtbC/03yI5yjcsS973c2M8mVKV4rzHBMF/w=; b=PoIwNFV3St4cL9KqUEcmkU uZrdEsHqXKXyLyxjPkdM3Rs6fXq0i4I5v4FoI0XmkiGglGgGNuCLUBwvBNCQLoPJ n3mI3TZywdjOnoDgefP1ZYiBm60l/uiSxBiX2G7gdx3Dou484fKgHLzNrmRH2aPD E5VtVFe88R3B0uXAmugtafPBugDSFQl63Z4XuZnuYr3HlQrc+PxFWmFcuDH82/kl 3lIWDvqAIoZO6krp6WXc6IrANspiV+9lnnqseIOc1gN/FjiFCWsi1r18st2qai42 UrV4NW/yeMe+6y0CWSl3C6HK/uFxxuvH3UR7WcgMFLO+ouQ9tVN3tMFaND/791oA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddtvddggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtsegrtderredtfeejnecuhfhrohhmpefmvghnucfo uhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlrdgtohhmqeenucggtffrrg htthgvrhhnpeekheevhfduleeufeduhfellefffeeigeeguddvveekiefhvdeujeeffeej tdegfeenucfkphepjeegrdejjedrkeehrddvhedtnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id CF4CE24005C; Mon, 21 Dec 2020 07:17:05 -0500 (EST) To: Michael Douglass , Calsify References: <57f81335-b7a9-6a9f-df5f-bab580689a33@fastmail.com> From: Ken Murchison Message-ID: <9595a7c0-2fb8-4e68-cd45-ce97bc13532f@fastmail.com> Date: Mon, 21 Dec 2020 07:17:04 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B28A566E3D1C7FC7F506B1A6" Content-Language: en-US Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar-icalendar-02 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, 21 Dec 2020 12:17:09 -0000 This is a multi-part message in MIME format. --------------B28A566E3D1C7FC7F506B1A6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Mike, On 12/21/20 12:09 AM, Michael Douglass wrote: > > On 12/19/20 13:50, Ken Murchison wrote: >> >> All, >> >> I just had cause to consult jscalendar-icalendar Section 2.1 >> and I have a couple of >> issues: >> >> 1. Why is this value specified to be the entire date-time plus >> fractional seconds?  Wouldn't the fractional seconds be sufficient? >> 2. The definition of the parameter is incorrect: >> 1. It doesn't include the game of the parameter in the definition >> 2. The value isn't DATE-TIME or DURATION, its value is an >> extension of date-time.  If keeping a full time >> representation it should be something like "date-time "." 1*DIGIT >> > 1.This was my suggestion - way back in April > > As I recall my main problem with the previous approach - which was > just the fractional part - was that it led to ambiguities and having > to define how the full value was rounded to produce the truncated > iCalendar value. Having the full value means you just choose to use > either the (possibly adjusted) property value or the (possibly more > accurate) FRACTIONAL parameter value. No processing or worrying about > edge cases. > Now that you refreshed my memory, I do recall this discussion. If we allow the fractional part to be positive OR negative, doesn't this solve the rounding problem?  If the full value is rounded with value R, the fractional part can be set to -R. > 2. I think FRACTIONAL can be used for DURATION as well as as for > DTSTART and the abnf is wrong anyway. We have > > fractional-param = DATE-TIME or DURATION > > shouldn't it be something like > > fractional-param = "FRACTIONAL" = (date-time | dur-value) ["." 1*DIGIT] > ; Value is extended date-time when used with the DTSTART property > ; Value is extended dur-value when used with the DURATION property If we're going to keep FRACTIONAL as being the full value, we will have to be more creative with the ABNF because date-time has [time-utc] as its last component, and for durations, we probably only want/need the fractional part when the duration includes dur-second.  So perhaps: fractional-param = "FRACTIONAL" "=" (date-time-frac / dur-frac) date-time-frac = date "T" time-frac time-frac = time-hour time-minute time-second frac-sec [time-utc] frac-sec = "." 1*DIGIT dur-frac = (["+"] / "-") "P" dur-day dur-time-frac dur-time-frac = 1*DIGIT "H" 1*DIGIT "M" dur-second frac-sec Having gone through this exercise, I think it would be a lot simpler to just do: fractional-param = "FRACTIONAL" "=" (["+"] / "-") "." 1*DIGIT -- Kenneth Murchison Senior Software Developer Fastmail US LLC --------------B28A566E3D1C7FC7F506B1A6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Mike,


On 12/21/20 12:09 AM, Michael Douglass wrote:

On 12/19/20 13:50, Ken Murchison wrote:

All,

I just had cause to consult jscalendar-icalendar Section 2.1 and I have a couple of issues:

  1. Why is this value specified to be the entire date-time plus fractional seconds?  Wouldn't the fractional seconds be sufficient?
  2. The definition of the parameter is incorrect:
    1. It doesn't include the game of the parameter in the definition
    2. The value isn't DATE-TIME or DURATION, its value is an extension of date-time.  If keeping a full time representation it should be something like "date-time "." 1*DIGIT
1.This was my suggestion - way back in April

As I recall my main problem with the previous approach - which was just the fractional part - was that it led to ambiguities and having to define how the full value was rounded to produce the truncated iCalendar value. Having the full value means you just choose to use either the (possibly adjusted) property value or the (possibly more accurate) FRACTIONAL parameter value. No processing or worrying about edge cases.


Now that you refreshed my memory, I do recall this discussion.  If we allow the fractional part to be positive OR negative, doesn't this solve the rounding problem?  If the full value is rounded with value R, the fractional part can be set to -R.

2. I think FRACTIONAL can be used for DURATION as well as as for DTSTART and the abnf is wrong anyway. We have

fractional-param = DATE-TIME or DURATION

shouldn't it be something like

fractional-param = "FRACTIONAL" = (date-time | dur-value) ["." 1*DIGIT]
; Value is extended date-time when used with the DTSTART property
; Value is extended dur-value when used with the DURATION property


If we're going to keep FRACTIONAL as being the full value, we will have to be more creative with the ABNF because date-time has [time-utc] as its last component, and for durations, we probably only want/need the fractional part when the duration includes dur-second.  So perhaps:

fractional-param = "FRACTIONAL" "=" (date-time-frac / dur-frac)

date-time-frac = date "T" time-frac

time-frac = time-hour time-minute time-second frac-sec [time-utc]

frac-sec = "." 1*DIGIT

dur-frac = (["+"] / "-") "P" dur-day dur-time-frac

dur-time-frac = 1*DIGIT "H" 1*DIGIT "M" dur-second frac-sec


Having gone through this exercise, I think it would be a lot simpler to just do:

fractional-param = "FRACTIONAL" "=" (["+"] / "-") "." 1*DIGIT

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
--------------B28A566E3D1C7FC7F506B1A6-- From nobody Mon Dec 21 04:31:49 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 4644C3A0F13 for ; Mon, 21 Dec 2020 04:31:47 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=PMKgbrpR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nroR+5Bm 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 DBkOm4OCw7UN for ; Mon, 21 Dec 2020 04:31:45 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B6FA3A0E58 for ; Mon, 21 Dec 2020 04:31:45 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 969F65C0101 for ; Mon, 21 Dec 2020 07:31:44 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 21 Dec 2020 07:31:44 -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=fm1; bh=2yZ047w 8DFj9y2zOHoN4JyT6zIvRxukaXPIJb0XVr84=; b=PMKgbrpRDAjB7hETscrhgeN a3yQ/TwQoXc+4hVwzTk/BLAuiZX3B/gz2MYNT/7LE8uWqpbRH4T0PRJXaDUjck5S YctyJfclMesot+OUBnqYXSdft8NrRfzaVvs0KFDsao5Pq8p0Xf4fQ6M3wFxsPCve 0DVm2CeBAEQ/kd617oi3iO6IsMHUPAxPjO/lO/n9EW5IlEw5C3z7P5hmD5ggPI31 HdOBDRYe+1yQ//f2tGEiOEYbqRgocCVYK6yl9x5ruPJrCZ1sMR88DJSBSn5VnLag xrocWwdVQLN2QvGEIyrj5LQQPyM+Ri2yqn3gODO+G3pZFBQB/0glIGub6PwmwuA= = 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=fm1; bh=2yZ047 w8DFj9y2zOHoN4JyT6zIvRxukaXPIJb0XVr84=; b=nroR+5BmtsIuKk8d5syLai sFumqI3e7zdN1eXOZzPFrSvUhrDsDJI5KvSyhrQln7IFIqsFZZZS++ifkWKfPRWP Igg8zCN3AZSJvabd0/X3CsW20BpSDdn8C4L8qveu8IadPh5TnMmUpmFmwIQSia00 /9QkKwDIRGh2CI+6VgTbiHDYKtdE1ayt1JQJFGeTXFiH8FNcgiOBsGCrMIdBdYnX Zq035r9ZeH/BXv3Y9KuWumW7IoS38YF3c5mk30UUP0Oszd3+flMQCR7aEEpoIqu8 W7pkBZA0RDNzieGyG1bo1F+lEbyVTtnO1WYwRkYUh1TlF56YPNN08GinITL41M/g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddtvddggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnheptefhffffke eukeevleelgeelhfegfeejueegteekjeekgfdthfehhedvheehvdfhnecuffhomhgrihhn pehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 499D91800C1; Mon, 21 Dec 2020 07:31:44 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: <6eb94ffd-2d3f-4e42-88bb-ef352495351d@www.fastmail.com> In-Reply-To: <9595a7c0-2fb8-4e68-cd45-ce97bc13532f@fastmail.com> References: <57f81335-b7a9-6a9f-df5f-bab580689a33@fastmail.com> <9595a7c0-2fb8-4e68-cd45-ce97bc13532f@fastmail.com> Date: Mon, 21 Dec 2020 13:31:24 +0100 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=9912e59f48ec4d10bfc3fd08f6ee0859 Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar-icalendar-02 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, 21 Dec 2020 12:31:47 -0000 --9912e59f48ec4d10bfc3fd08f6ee0859 Content-Type: text/plain As noted in my previous email: we already agreed to not set the complete timestamp in the FRACTIONAL parameter value. Instead we will set a SUBSECONDS parameter which will be defined to a FLOAT value with MUST be positive and less than 1.0. Cheers, Robert On Mon, Dec 21, 2020, at 1:17 PM, Ken Murchison wrote: > Hi Mike, > > On 12/21/20 12:09 AM, Michael Douglass wrote: >> >> On 12/19/20 13:50, Ken Murchison wrote: >>> All, >>> I just had cause to consult jscalendar-icalendar Section 2.1 and I have a couple of issues: >>> 1. Why is this value specified to be the entire date-time plus fractional seconds? Wouldn't the fractional seconds be sufficient? >>> 2. The definition of the parameter is incorrect: >>> 1. It doesn't include the game of the parameter in the definition >>> 2. The value isn't DATE-TIME or DURATION, its value is an extension of date-time. If keeping a full time representation it should be something like "date-time "." 1*DIGIT >> 1.This was my suggestion - way back in April >> As I recall my main problem with the previous approach - which was just the fractional part - was that it led to ambiguities and having to define how the full value was rounded to produce the truncated iCalendar value. Having the full value means you just choose to use either the (possibly adjusted) property value or the (possibly more accurate) FRACTIONAL parameter value. No processing or worrying about edge cases. > > Now that you refreshed my memory, I do recall this discussion. If we allow the fractional part to be positive OR negative, doesn't this solve the rounding problem? If the full value is rounded with value R, the fractional part can be set to -R. >> 2. I think FRACTIONAL can be used for DURATION as well as as for DTSTART and the abnf is wrong anyway. We have >> fractional-param = DATE-TIME or DURATION >> shouldn't it be something like >> fractional-param = "FRACTIONAL" = (date-time | dur-value) ["." 1*DIGIT] ; Value is extended date-time when used with the DTSTART property ; Value is extended dur-value when used with the DURATION property > > If we're going to keep FRACTIONAL as being the full value, we will have to be more creative with the ABNF because date-time has [time-utc] as its last component, and for durations, we probably only want/need the fractional part when the duration includes dur-second. So perhaps: > fractional-param = "FRACTIONAL" "=" (date-time-frac / dur-frac) > date-time-frac = date "T" time-frac > time-frac = time-hour time-minute time-second frac-sec [time-utc] > frac-sec = "." 1*DIGIT > > dur-frac = (["+"] / "-") "P" dur-day dur-time-frac > dur-time-frac = 1*DIGIT "H" 1*DIGIT "M" dur-second frac-sec > > Having gone through this exercise, I think it would be a lot simpler to just do: > fractional-param = "FRACTIONAL" "=" (["+"] / "-") "." 1*DIGIT > -- > Kenneth Murchison Senior Software Developer Fastmail US LLC > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --9912e59f48ec4d10bfc3fd08f6ee0859 Content-Type: text/html
As noted in my previous email: we already agreed to not set the complete timestamp in the FRACTIONAL parameter value.

Instead we will set a SUBSECONDS parameter which will be defined to a FLOAT value with MUST be positive and less than 1.0.

Cheers,
Robert

On Mon, Dec 21, 2020, at 1:17 PM, Ken Murchison wrote:

Hi Mike,


On 12/21/20 12:09 AM, Michael Douglass wrote:

On 12/19/20 13:50, Ken Murchison wrote:

All,

I just had cause to consult jscalendar-icalendar Section 2.1 and I have a couple of issues:

  1. Why is this value specified to be the entire date-time plus fractional seconds?  Wouldn't the fractional seconds be sufficient?
  2. The definition of the parameter is incorrect:
    1. It doesn't include the game of the parameter in the definition
    2. The value isn't DATE-TIME or DURATION, its value is an extension of date-time.  If keeping a full time representation it should be something like "date-time "." 1*DIGIT
1.This was my suggestion - way back in April

As I recall my main problem with the previous approach - which was just the fractional part - was that it led to ambiguities and having to define how the full value was rounded to produce the truncated iCalendar value. Having the full value means you just choose to use either the (possibly adjusted) property value or the (possibly more accurate) FRACTIONAL parameter value. No processing or worrying about edge cases.


Now that you refreshed my memory, I do recall this discussion.  If we allow the fractional part to be positive OR negative, doesn't this solve the rounding problem?  If the full value is rounded with value R, the fractional part can be set to -R.

2. I think FRACTIONAL can be used for DURATION as well as as for DTSTART and the abnf is wrong anyway. We have

fractional-param = DATE-TIME or DURATION

shouldn't it be something like

fractional-param = "FRACTIONAL" = (date-time | dur-value) ["." 1*DIGIT]
; Value is extended date-time when used with the DTSTART property
; Value is extended dur-value when used with the DURATION property


If we're going to keep FRACTIONAL as being the full value, we will have to be more creative with the ABNF because date-time has [time-utc] as its last component, and for durations, we probably only want/need the fractional part when the duration includes dur-second.  So perhaps:

fractional-param = "FRACTIONAL" "=" (date-time-frac / dur-frac)

date-time-frac = date "T" time-frac

time-frac = time-hour time-minute time-second frac-sec [time-utc]

frac-sec = "." 1*DIGIT


dur-frac = (["+"] / "-") "P" dur-day dur-time-frac

dur-time-frac = 1*DIGIT "H" 1*DIGIT "M" dur-second frac-sec


Having gone through this exercise, I think it would be a lot simpler to just do:

fractional-param = "FRACTIONAL" "=" (["+"] / "-") "." 1*DIGIT

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
_______________________________________________
calsify mailing list


--9912e59f48ec4d10bfc3fd08f6ee0859-- From nobody Mon Dec 21 04:42:07 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A333A0F46 for ; Mon, 21 Dec 2020 04:42:06 -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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=GgE1YF7V; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KKtDTt4J 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 z7NUT7q1ue-N for ; Mon, 21 Dec 2020 04:42:03 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 166DC3A0F41 for ; Mon, 21 Dec 2020 04:42:03 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 697215C00AA for ; Mon, 21 Dec 2020 07:42:02 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 21 Dec 2020 07:42:02 -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=fm1; bh=gwtBKYtN9/4wWQDDFF941e0RUpB Muuxf37nqoTsCnrc=; b=GgE1YF7VidK5rCScJyyZdGQdZJ4IGHX+hL1Y/ZAYgfB 2TVXrVM1Dt+e9KNE8/mP/JUreU0SVXJze/IU1ld12kJn4yI1aSAkKdI6MNzpZTmX cdHY/heEdSbfJTj+4+XGSQ+OjTl0HNp1+og7cU1Efn4s/49tt58Fwrb3RPojXHps LToJM1GaB41+KncKd+9FXwClJr89849hftTryEmJ9lMb5Jb2TJR+NAQnaFBpN6Em H+JV7tFvNn1OIMbvaKcw3O3P8CVBLFYnq2QbrkYjL/jo0t+zjPcsJIKgtP5i213r wcuqLlwqiaMIjW7MvfQshX/Lf8APGjkJxXXuPFqnkhw== 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=fm1; bh=gwtBKY tN9/4wWQDDFF941e0RUpBMuuxf37nqoTsCnrc=; b=KKtDTt4JOCh8hCsjNfCfy5 UvGg+235g4qyG2aFrJBlCDYNRFC2Ar6JL3qcF9LfI5Aa39sfubulWyBXaD7FOUsN 8bZ+2nuAqRQBvobD9RRHU0KP2dBOU1NI3fZUk9nk9YQBaRn3bYv1LT9lJyMm9v+t RH4ny8iRER5mx6iiXajZ4/WMdM+3Zb8+C1VLK4B7nxcVuNCCey+hvHiP7e2aNJ6v 2J2UTTC/Zhk4EYVC7yD2UjHfeowhXahWt/YXWQJuzBtOreu0iN3BU8xBloZIrV5p FG5cUoXmdFwFMvmV1CXppr7aMOsNIG5FnN7//o175ZO9+Rql5vB+ZdCe7PtedyIg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddtvddggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehfrghs thhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhepffeuhfevgffgvdduuedvteeije euvddvkedugeegvdffvefgudffueeileeggeegnecuffhomhgrihhnpehivghtfhdrohhr ghenucfkphepjeegrdejjedrkeehrddvhedtnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhm X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id EBCDC240064 for ; Mon, 21 Dec 2020 07:42:01 -0500 (EST) To: calsify@ietf.org References: <57f81335-b7a9-6a9f-df5f-bab580689a33@fastmail.com> <9595a7c0-2fb8-4e68-cd45-ce97bc13532f@fastmail.com> <6eb94ffd-2d3f-4e42-88bb-ef352495351d@www.fastmail.com> From: Ken Murchison Message-ID: <385d8dec-09ce-8884-d9cc-0eeb792d692e@fastmail.com> Date: Mon, 21 Dec 2020 07:42:01 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <6eb94ffd-2d3f-4e42-88bb-ef352495351d@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------9C6A0FB579D787F24730C0DB" Content-Language: en-US Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar-icalendar-02 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, 21 Dec 2020 12:42:06 -0000 This is a multi-part message in MIME format. --------------9C6A0FB579D787F24730C0DB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/21/20 7:31 AM, Robert Stepanek wrote: > As noted in my previous email: we already agreed to not set the > complete timestamp in the FRACTIONAL parameter value. > > Instead we will set a SUBSECONDS parameter which will be defined to a > FLOAT value with MUST be positive and less than 1.0. OK, but if it MUST be positive, don't we still have the issue that Mike brought up regarding rounding?  Or we will state that the property value MUST NOT be rounded up. > > On Mon, Dec 21, 2020, at 1:17 PM, Ken Murchison wrote: >> >> Hi Mike, >> >> >> On 12/21/20 12:09 AM, Michael Douglass wrote: >>> >>> On 12/19/20 13:50, Ken Murchison wrote: >>>> >>>> All, >>>> >>>> I just had cause to consult jscalendar-icalendar Section 2.1 >>>> and I >>>> have a couple of issues: >>>> >>>> 1. Why is this value specified to be the entire date-time plus >>>> fractional seconds?  Wouldn't the fractional seconds be sufficient? >>>> 2. The definition of the parameter is incorrect: >>>> 1. It doesn't include the game of the parameter in the definition >>>> 2. The value isn't DATE-TIME or DURATION, its value is an >>>> extension of date-time.  If keeping a full time >>>> representation it should be something like "date-time "." >>>> 1*DIGIT >>>> >>> 1.This was my suggestion - way back in April >>> >>> As I recall my main problem with the previous approach - which was >>> just the fractional part - was that it led to ambiguities and having >>> to define how the full value was rounded to produce the truncated >>> iCalendar value. Having the full value means you just choose to use >>> either the (possibly adjusted) property value or the (possibly more >>> accurate) FRACTIONAL parameter value. No processing or worrying >>> about edge cases. >>> >> >> Now that you refreshed my memory, I do recall this discussion.  If we >> allow the fractional part to be positive OR negative, doesn't this >> solve the rounding problem?  If the full value is rounded with value >> R, the fractional part can be set to -R. >> >>> 2. I think FRACTIONAL can be used for DURATION as well as as for >>> DTSTART and the abnf is wrong anyway. We have >>> >>> fractional-param = DATE-TIME or DURATION >>> >>> shouldn't it be something like >>> >>> fractional-param = "FRACTIONAL" = (date-time | dur-value) ["." 1*DIGIT] >>> ; Value is extended date-time when used with the DTSTART property >>> ; Value is extended dur-value when used with the DURATION property >> >> >> If we're going to keep FRACTIONAL as being the full value, we will >> have to be more creative with the ABNF because date-time has >> [time-utc] as its last component, and for durations, we probably only >> want/need the fractional part when the duration includes dur-second.  >> So perhaps: >> >> fractional-param = "FRACTIONAL" "=" (date-time-frac / dur-frac) >> >> date-time-frac = date "T" time-frac >> >> time-frac = time-hour time-minute time-second frac-sec [time-utc] >> >> frac-sec = "." 1*DIGIT >> >> >> dur-frac = (["+"] / "-") "P" dur-day dur-time-frac >> >> dur-time-frac = 1*DIGIT "H" 1*DIGIT "M" dur-second frac-sec >> >> >> Having gone through this exercise, I think it would be a lot simpler >> to just do: >> >> fractional-param = "FRACTIONAL" "=" (["+"] / "-") "." 1*DIGIT >> >> -- >> Kenneth Murchison >> Senior Software Developer >> Fastmail US LLC >> _______________________________________________ >> 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 -- Kenneth Murchison Senior Software Developer Fastmail US LLC --------------9C6A0FB579D787F24730C0DB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/21/20 7:31 AM, Robert Stepanek wrote:
As noted in my previous email: we already agreed to not set the complete timestamp in the FRACTIONAL parameter value.

Instead we will set a SUBSECONDS parameter which will be defined to a FLOAT value with MUST be positive and less than 1.0.


OK, but if it MUST be positive, don't we still have the issue that Mike brought up regarding rounding?  Or we will state that the property value MUST NOT be rounded up.




On Mon, Dec 21, 2020, at 1:17 PM, Ken Murchison wrote:

Hi Mike,


On 12/21/20 12:09 AM, Michael Douglass wrote:

On 12/19/20 13:50, Ken Murchison wrote:

All,

I just had cause to consult jscalendar-icalendar Section 2.1 and I have a couple of issues:

  1. Why is this value specified to be the entire date-time plus fractional seconds?  Wouldn't the fractional seconds be sufficient?
  2. The definition of the parameter is incorrect:
    1. It doesn't include the game of the parameter in the definition
    2. The value isn't DATE-TIME or DURATION, its value is an extension of date-time.  If keeping a full time representation it should be something like "date-time "." 1*DIGIT
1.This was my suggestion - way back in April

As I recall my main problem with the previous approach - which was just the fractional part - was that it led to ambiguities and having to define how the full value was rounded to produce the truncated iCalendar value. Having the full value means you just choose to use either the (possibly adjusted) property value or the (possibly more accurate) FRACTIONAL parameter value. No processing or worrying about edge cases.


Now that you refreshed my memory, I do recall this discussion.  If we allow the fractional part to be positive OR negative, doesn't this solve the rounding problem?  If the full value is rounded with value R, the fractional part can be set to -R.

2. I think FRACTIONAL can be used for DURATION as well as as for DTSTART and the abnf is wrong anyway. We have

fractional-param = DATE-TIME or DURATION

shouldn't it be something like

fractional-param = "FRACTIONAL" = (date-time | dur-value) ["." 1*DIGIT]
; Value is extended date-time when used with the DTSTART property
; Value is extended dur-value when used with the DURATION property


If we're going to keep FRACTIONAL as being the full value, we will have to be more creative with the ABNF because date-time has [time-utc] as its last component, and for durations, we probably only want/need the fractional part when the duration includes dur-second.  So perhaps:

fractional-param = "FRACTIONAL" "=" (date-time-frac / dur-frac)

date-time-frac = date "T" time-frac

time-frac = time-hour time-minute time-second frac-sec [time-utc]

frac-sec = "." 1*DIGIT


dur-frac = (["+"] / "-") "P" dur-day dur-time-frac

dur-time-frac = 1*DIGIT "H" 1*DIGIT "M" dur-second frac-sec


Having gone through this exercise, I think it would be a lot simpler to just do:

fractional-param = "FRACTIONAL" "=" (["+"] / "-") "." 1*DIGIT

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
_______________________________________________
calsify mailing list



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

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
--------------9C6A0FB579D787F24730C0DB-- From nobody Mon Dec 21 04:54:46 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 30D243A0FAD for ; Mon, 21 Dec 2020 04:54:44 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=ARhnZQI0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J4v0nlpU 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 OyVbbyVpGaVT for ; Mon, 21 Dec 2020 04:54:43 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05EF3A0FB0 for ; Mon, 21 Dec 2020 04:54:42 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3B13E5C0151 for ; Mon, 21 Dec 2020 07:54:42 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 21 Dec 2020 07:54:42 -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=fm1; bh=jVnK5+a TuY1Fdv2uLENnYEg7FlsAqwIYq8WONuOXfTc=; b=ARhnZQI0WNqub3x310MY8eS lRBwmqJVppvUqspGkAGP8TaV/90eIuwKPSqwVtWsRSBoiR/+6ltYSRvrC/qvdTVZ U2bKf8jDyh9HqnYid67vLZV6rl4b0fyxcjbPzXHG6v0M/b8dmES/1IFsa/qApoio rwY/EeC9T5pHRerW2sqEoiD/qP59jmBN80Le3I/dH/NgI+175oi28tLWXasw48f6 19skENmMAFV5xyc/5zpoKym8ChOgl4bILRG0+jnW0yZzRoKJh71H5w4d5i5tAKKG iJEw3QAMNt0c+clEFHSUOLQtZYnfrvqCb6ZUUjeA735osE2R4mZT84vY8+z2MfA= = 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=fm1; bh=jVnK5+ aTuY1Fdv2uLENnYEg7FlsAqwIYq8WONuOXfTc=; b=J4v0nlpUMJ6Gh6rQjk1NEh JCX0ckfMr4UDVcbWkxw6RLA6N5rwwNglsW5+pWV2Lr+XkdZ24V2OhVZ8U+qtKEnw uBdHMt2d/Ln/fEMIq2USGG7djMSxYLQUZr7HSJAYNJgqoaXrlBxweopii7dk3r+2 APilFg7fzF9mOCtZcJM8tJbYUYCWC/kk2G7qrFL/4O7+nL2FCOmK7Kq+Y0I0NJQt 4FwdZhpO2JqUBkN8oy4Cmj1xQ4XujqjATOV+wsIBDkGqRnPvFtTTTaZU1rk30sXw vUQrJCHFM1w9ikDIP1kjMo3Z6gVFmTqvqHPQKGlT3A4mqqvPc29kN0SolcrHYy/g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddtvddggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepheeguedvtd ekhfetgfeufefgvdeuteegfeefleehvddugeejjefhteeugfevveeinecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E76641800C1; Mon, 21 Dec 2020 07:54:41 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: <971461a9-6327-4f2b-a1c9-1c6a7c9a3f97@www.fastmail.com> In-Reply-To: <385d8dec-09ce-8884-d9cc-0eeb792d692e@fastmail.com> References: <57f81335-b7a9-6a9f-df5f-bab580689a33@fastmail.com> <9595a7c0-2fb8-4e68-cd45-ce97bc13532f@fastmail.com> <6eb94ffd-2d3f-4e42-88bb-ef352495351d@www.fastmail.com> <385d8dec-09ce-8884-d9cc-0eeb792d692e@fastmail.com> Date: Mon, 21 Dec 2020 13:54:18 +0100 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=2ccdc0c1fc59473eb0aa7bfbd9c0e759 Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar-icalendar-02 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, 21 Dec 2020 12:54:44 -0000 --2ccdc0c1fc59473eb0aa7bfbd9c0e759 Content-Type: text/plain On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote: > On 12/21/20 7:31 AM, Robert Stepanek wrote: >> As noted in my previous email: we already agreed to not set the complete timestamp in the FRACTIONAL parameter value. >> >> Instead we will set a SUBSECONDS parameter which will be defined to a FLOAT value with MUST be positive and less than 1.0. > OK, but if it MUST be positive, don't we still have the issue that Mike brought up regarding rounding? Or we will state that the property value MUST NOT be rounded up. It MUST NOT be rounded, because any client aware of SUBSECONDS would then calculate with a wrong value. The SUBSECONDS parameter only defines the fractional seconds part. Cheers, Robert --2ccdc0c1fc59473eb0aa7bfbd9c0e759 Content-Type: text/html
On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote:
On 12/21/20 7:31 AM, Robert Stepanek wrote:
As noted in my previous email: we already agreed to not set the complete timestamp in the FRACTIONAL parameter value.

Instead we will set a SUBSECONDS parameter which will be defined to a FLOAT value with MUST be positive and less than 1.0.

OK, but if it MUST be positive, don't we still have the issue that Mike brought up regarding rounding?  Or we will state that the property value MUST NOT be rounded up.


It MUST NOT be rounded, because any client aware of SUBSECONDS would then calculate with a wrong value. The SUBSECONDS parameter only defines the fractional seconds part.

Cheers,
Robert

--2ccdc0c1fc59473eb0aa7bfbd9c0e759-- From nobody Mon Dec 21 05:03: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 7D4443A0FBA for ; Mon, 21 Dec 2020 05:03:42 -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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=XlL7A2PO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kPYjfDbi 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 piDWNEUARsBE for ; Mon, 21 Dec 2020 05:03:41 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35CFB3A0FB6 for ; Mon, 21 Dec 2020 05:03:41 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9A57E5C0186 for ; Mon, 21 Dec 2020 08:03:40 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 21 Dec 2020 08:03:40 -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=fm1; bh=2hgjPEsbnPou+6FITptMtgA7YAo qXwGDv4ZHAS8Cf/g=; b=XlL7A2PORSlKnbDLB+qVA9KqEjw7n/3lI6H4J0Q5elM GRzDNFTGwtynNCdXrKWHs5fBigBMJ37kJzu7PYcpiSe/4u1MZAtujJhU+06yuocs hEC8u70DCnNaOf3ucr+fzaDH27KCHAS0/ESkfjYsZHkT9uX6fDFqX7J1rv9UR5Hx iXDZvnuWeNNS25fE6HRAXomYA4dqiBVWP5Kux5EuGLAOn1KfMWtuvvlHB+TaT943 zdPDCGsiByU8oWO/mwG8DoMMG9Rt90+WRPZVHDi+TgCV1rtx0ypYieDg9uBivVad 2OTfzbp00/bAq7WymLwwhNQD0E3oeQWwpw2TtaK+qgg== 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=fm1; bh=2hgjPE sbnPou+6FITptMtgA7YAoqXwGDv4ZHAS8Cf/g=; b=kPYjfDbikVR/J2hZbitDfg 1sGFxrxGYZMiWmCk+DKYtzrUlNOgfz8w7jq/fP8ZJsawz+1+k0GUq7HJR5BuMgeN 0VxRYF0cWGQQJkv3ccKdt5gvuZpa5ISpxssnZ84xvogFd4cKA0QSln7RVh4MQoN+ +UNNicy25ntWQXeF5hs1TiIEWJxMBDHubVqxksiki18b5ateGrA5NKd5gfzbzaYA f/w0Zaz1hwClX8XYS66iqDNRuaKcW+gtWLFNHV5JO9OsySQRUU2OiiXb+Xz0QwEb Rk5AQuWStwlwXya1oY8JGM6Hy7nQadgi6RvsaAhLHsJusm84ISp82YOdIMqfQ4dw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddtvddgheduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehfrghs thhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhepkeehvefhudelueefudfhleelff efieeggeduvdevkeeihfdvueejfeefjedtgeefnecukfhppeejgedrjeejrdekhedrvdeh tdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuh hrtghhsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 389DB240062 for ; Mon, 21 Dec 2020 08:03:40 -0500 (EST) To: calsify@ietf.org References: <57f81335-b7a9-6a9f-df5f-bab580689a33@fastmail.com> <9595a7c0-2fb8-4e68-cd45-ce97bc13532f@fastmail.com> <6eb94ffd-2d3f-4e42-88bb-ef352495351d@www.fastmail.com> <385d8dec-09ce-8884-d9cc-0eeb792d692e@fastmail.com> <971461a9-6327-4f2b-a1c9-1c6a7c9a3f97@www.fastmail.com> From: Ken Murchison Message-ID: Date: Mon, 21 Dec 2020 08:03:39 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <971461a9-6327-4f2b-a1c9-1c6a7c9a3f97@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------6027B243464F1B527C5A1F36" Content-Language: en-US Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar-icalendar-02 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, 21 Dec 2020 13:03:43 -0000 This is a multi-part message in MIME format. --------------6027B243464F1B527C5A1F36 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/21/20 7:54 AM, Robert Stepanek wrote: > On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote: >> On 12/21/20 7:31 AM, Robert Stepanek wrote: >>> As noted in my previous email: we already agreed to not set the >>> complete timestamp in the FRACTIONAL parameter value. >>> >>> Instead we will set a SUBSECONDS parameter which will be defined to >>> a FLOAT value with MUST be positive and less than 1.0. >> >> OK, but if it MUST be positive, don't we still have the issue that >> Mike brought up regarding rounding?  Or we will state that the >> property value MUST NOT be rounded up. >> > > It MUST NOT be rounded, because any client aware of SUBSECONDS would > then calculate with a wrong value. The SUBSECONDS parameter only > defines the fractional seconds part. OK.  WFM -- Kenneth Murchison Senior Software Developer Fastmail US LLC --------------6027B243464F1B527C5A1F36 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 12/21/20 7:54 AM, Robert Stepanek wrote:
On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote:
On 12/21/20 7:31 AM, Robert Stepanek wrote:
As noted in my previous email: we already agreed to not set the complete timestamp in the FRACTIONAL parameter value.

Instead we will set a SUBSECONDS parameter which will be defined to a FLOAT value with MUST be positive and less than 1.0.

OK, but if it MUST be positive, don't we still have the issue that Mike brought up regarding rounding?  Or we will state that the property value MUST NOT be rounded up.


It MUST NOT be rounded, because any client aware of SUBSECONDS would then calculate with a wrong value. The SUBSECONDS parameter only defines the fractional seconds part.


OK.  WFM

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
--------------6027B243464F1B527C5A1F36-- From nobody Mon Dec 21 07:32:20 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0203A11C3 for ; Mon, 21 Dec 2020 07:32:19 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=k5P9WnnF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lPuayHJN 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 v2w3u2lcknz5 for ; Mon, 21 Dec 2020 07:32:17 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C303A11C2 for ; Mon, 21 Dec 2020 07:32:17 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6557E5C01F0 for ; Mon, 21 Dec 2020 10:32:16 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 21 Dec 2020 10:32:16 -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=fm1; bh=Nlze+Zr 0aPKBIurDKNfcBPV7Jj0O/sYJAS1FULvp0do=; b=k5P9WnnF7w6o+2sciAMiXvX YwG+3FJ0s+4DQL6FF0f7Q3kbpbbrE5Y0j8+Q1359jfsu+lk5a7jXOn9glx+IR9Dl dlWDdaIetgGoa4NDi5hZslCMLRbisExOHN0NPUR5wGrf4mmD/ST4RnL8ShceYExE omkmvDp8ZWO8qyJBvbWwFbP6or43rUeLGsx+Q5RtgOtT4Z7MmqDK3/6X50ier6/a Jqi19xxIscVZYLt9v8iHZ2GWgkdr2GbP9gxdmiCcdo/5aL3VNskG2/bAfwKPa737 Nl3KML26BBRTO6E5pAOGw5yP3wPkYFD00YXGwWQNRhwp8jA8FrlNtn2Lmx5gX4w= = 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=fm1; bh=Nlze+Z r0aPKBIurDKNfcBPV7Jj0O/sYJAS1FULvp0do=; b=lPuayHJNHeNq329HM7pyAt 8kHtdNZJSmxHFL+RVJSpA5M2//dtZvjcNjQsCqPPUpeJaWKDj3VeuXCtmvye7AMV v1PQhTafy94X+ZiY8Um9hci9bfgfBW6/cpnAaq6f3BuUIw/GlyVxtMVWWrJCxk8l 5V7pODsZ/yc9eOjjzzDYYVZOj0eARjShnLhuwb+9dSlZj0q5jXFj1ptHehOdDjYT 2gfl8FbFRIdTQ5gMPO+uA2/XIDfzSdJbf3ZcDtI2EDQDx6ImVDfIasBLFopNoOpD mlUKzx318wbYcOxI6nwo7E3hw3xydvQIMRA3qnNhsoJkC/Bk+TysLEF5aIaXUw3A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddtvddgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthho sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnheptefhffffke eukeevleelgeelhfegfeejueegteekjeekgfdthfehhedvheehvdfhnecuffhomhgrihhn pehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E8A211800C1; Mon, 21 Dec 2020 10:32:15 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: <95c63702-66a5-4720-8737-7f9e7218e560@www.fastmail.com> In-Reply-To: References: <57f81335-b7a9-6a9f-df5f-bab580689a33@fastmail.com> <9595a7c0-2fb8-4e68-cd45-ce97bc13532f@fastmail.com> <6eb94ffd-2d3f-4e42-88bb-ef352495351d@www.fastmail.com> <385d8dec-09ce-8884-d9cc-0eeb792d692e@fastmail.com> <971461a9-6327-4f2b-a1c9-1c6a7c9a3f97@www.fastmail.com> Date: Mon, 21 Dec 2020 16:31:55 +0100 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=b7ffa456b9634d85a363dd727484ee9e Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar-icalendar-02 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, 21 Dec 2020 15:32:19 -0000 --b7ffa456b9634d85a363dd727484ee9e Content-Type: text/plain I have updated the RFC draft on Github. Here is the excerpt, I appreciate any feedback: 2.1. SUBSECOND parameter Parameter name: SUBSECOND Purpose: To specify fractional seconds for time values and durations. Description: This parameter MAY be specified on properties of type DATE-TIME, DURATION and TIME. It MUST be a FLOAT value less than 1.0 and MUST NOT be negative. Implementations MUST ignore presence of the SUBSECOND parameter on RECURRENCE-ID properties when determining recurrence overrides. Format Definition: This parameter is defined by the following notation: subsecond-param = "SUBSECOND" "=" float Example: DTSTART;SUBSECOND=0.0123:20111205T040506 On Mon, Dec 21, 2020, at 2:03 PM, Ken Murchison wrote: > > On 12/21/20 7:54 AM, Robert Stepanek wrote: >> On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote: >>> On 12/21/20 7:31 AM, Robert Stepanek wrote: >>>> As noted in my previous email: we already agreed to not set the complete timestamp in the FRACTIONAL parameter value. >>>> >>>> Instead we will set a SUBSECONDS parameter which will be defined to a FLOAT value with MUST be positive and less than 1.0. >>> OK, but if it MUST be positive, don't we still have the issue that Mike brought up regarding rounding? Or we will state that the property value MUST NOT be rounded up. >> >> It MUST NOT be rounded, because any client aware of SUBSECONDS would then calculate with a wrong value. The SUBSECONDS parameter only defines the fractional seconds part. > > OK. WFM > -- Kenneth Murchison Senior Software Developer Fastmail US LLC > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --b7ffa456b9634d85a363dd727484ee9e Content-Type: text/html
I have updated the RFC draft on Github. Here is the excerpt, I appreciate any feedback:

2.1.  SUBSECOND parameter

   Parameter name:  SUBSECOND

   Purpose:  To specify fractional seconds for time values and
      durations.

   Description:  This parameter MAY be specified on properties of type
      DATE-TIME, DURATION and TIME.  It MUST be a FLOAT value less than
      1.0 and MUST NOT be negative.  Implementations MUST ignore
      presence of the SUBSECOND parameter on RECURRENCE-ID properties
      when determining recurrence overrides.

   Format Definition:

   This parameter is defined by the following notation:

       subsecond-param = "SUBSECOND" "=" float

   Example:

       DTSTART;SUBSECOND=0.0123:20111205T040506

On Mon, Dec 21, 2020, at 2:03 PM, Ken Murchison wrote:


On 12/21/20 7:54 AM, Robert Stepanek wrote:
On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote:
On 12/21/20 7:31 AM, Robert Stepanek wrote:
As noted in my previous email: we already agreed to not set the complete timestamp in the FRACTIONAL parameter value.

Instead we will set a SUBSECONDS parameter which will be defined to a FLOAT value with MUST be positive and less than 1.0.

OK, but if it MUST be positive, don't we still have the issue that Mike brought up regarding rounding?  Or we will state that the property value MUST NOT be rounded up.


It MUST NOT be rounded, because any client aware of SUBSECONDS would then calculate with a wrong value. The SUBSECONDS parameter only defines the fractional seconds part.


OK.  WFM

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
_______________________________________________
calsify mailing list


--b7ffa456b9634d85a363dd727484ee9e-- From nobody Mon Dec 21 08:13:34 2020 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2823A1218 for ; Mon, 21 Dec 2020 08:13:32 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oJrZW_aVhRV for ; Mon, 21 Dec 2020 08:13:31 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 D25D03A121A for ; Mon, 21 Dec 2020 08:13:30 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id z11so9194959qkj.7 for ; Mon, 21 Dec 2020 08:13:30 -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=MDcQCOah2+Wu3CBM7oWMYJvBbV4VfGvTLMOP+kGZF+Y=; b=nyKqne5b1dYko/oNQNIEyEh0cxEJLM0myacbLlAllDFSKPnEbBVdRLLnv+CHjTObJB j+YNZunMlrTz4I+DZ/qCnXPNVOfXoN1Q2HhRqoEP/U1avimsWz1gVcoXrO5j1y1++o81 JtN1IITqlPiIeftYXDV7La2EnpxhvDI3NL+eg3TC0NDwZ08nzOpaIxqtdNvmiazoUSoA 3aCYpZGLrj4ZCv9mU6rxQREsMt4UpR5BMk1o/dGrFUomtGSzSB1WYZ8UO1ABUXuXm8lr +eexlJCcadcyQ6C2/s5Ozat5bsI8LeQM+RtSJpL3V4SFCQkzRMocZQ2c6tJTbuKbSN7a lAPw== 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=MDcQCOah2+Wu3CBM7oWMYJvBbV4VfGvTLMOP+kGZF+Y=; b=b5ubnqyftnEMWgIC6W8Nvz1mWrKABL57+mykfHJpQFrAqRY0nTNUplG5tSts96CxdI LZWK//iQKN+mu2gr4Vbc8d+ul1T7mYG4KMphdZG01U7E2NAgj1bdoYLHmxIY26VZyAuQ pRYWlf7z8z4llaTJOMubHqXE+2gxIemMApjXEi1Ugoj+3bDMcUs3A4xXBdd/kBEgfU1o iiX23lxW4kGP0Bppcr4rZzsSc2nPSd3uI5zQBL8J8GmpbaU01HfnaEzMJCrP52jrBmSU q/2R1fxPiit0XauTz30Nn02Mz94cOUimOffvLJ+BEiQHHD+VyB19tQ7oGti+Cm2kfj/O NTSA== X-Gm-Message-State: AOAM531ZA6Q910QPqbRsWnnwLuCJFoVnXgKlU6eGRL023CmpgFUsGUxT R2jfMcY14TbddXz4uSZxcpcTg8pMIQw3WA== X-Google-Smtp-Source: ABdhPJz9UKjzRcGKsbubxQhkQwDtvZPunJLExdhVz82SPSFC33/vNTB0FdGBLYmclroWTp/4whZJZw== X-Received: by 2002:a37:2c82:: with SMTP id s124mr17560370qkh.130.1608567209353; Mon, 21 Dec 2020 08:13:29 -0800 (PST) Received: from [192.168.1.151] (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id f19sm9933087qta.80.2020.12.21.08.13.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Dec 2020 08:13:28 -0800 (PST) To: Robert Stepanek , calsify@ietf.org References: <57f81335-b7a9-6a9f-df5f-bab580689a33@fastmail.com> <9595a7c0-2fb8-4e68-cd45-ce97bc13532f@fastmail.com> <6eb94ffd-2d3f-4e42-88bb-ef352495351d@www.fastmail.com> <385d8dec-09ce-8884-d9cc-0eeb792d692e@fastmail.com> <971461a9-6327-4f2b-a1c9-1c6a7c9a3f97@www.fastmail.com> <95c63702-66a5-4720-8737-7f9e7218e560@www.fastmail.com> From: Michael Douglass Message-ID: Date: Mon, 21 Dec 2020 11:13:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <95c63702-66a5-4720-8737-7f9e7218e560@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------C778F8B5DE94393A8677F0FA" Content-Language: en-US Archived-At: Subject: Re: [calsify] draft-ietf-calext-jscalendar-icalendar-02 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, 21 Dec 2020 16:13:33 -0000 This is a multi-part message in MIME format. --------------C778F8B5DE94393A8677F0FA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Now I'm confused: The draft 1 had a SUBSECOND parameter: From version 1: Example: DTSTART;SUBSECOND=0.03:20190605T133015 The discussion around April this year included this: >> [...] Also what about fractional values > 0.5? Really we should round >> to nearest? Would it be better to have e.g. a FRACTIONAL parameter >> with the whole date-time and allow the value to be the rounded value.? >> > > As discussed in our call a couple of weeks ago, it would be best if we > could just allow fractional seconds in DATE-TIME values. But that will > break loads of iCalendar parser, so it will have to remain wishful > thinking. > > Both FRACTIONAL and SUBSECONDS have their flaws. I originally thought > that the SUBSECONDS parameter is the better choice, but now that we > talk about it, I come to prefer your FRACTIONAL idea. > > We could define the FRACTIONAL parameter to contain the complete > datetime including fractional seconds. A client that is aware of that > parameter must both set the FRACTIONAL parameter and the date-time > property value. The property value must contain the rounded value of > FRACTIONAL. Time values with fractional seconds always round up to the > next second. The value of the FRACTIONAL parameter must be ignored, if > its rounded value does not match the property value. So I updated the draft so that version 2 had the full value. I still felt this is the best approach. By having the full value in the parameter we avoid implementors needing to know if the property value is a rounded or truncated number. On 12/21/20 10:31, Robert Stepanek wrote: > I have updated the RFC draft on Github. Here is the excerpt, I > appreciate any feedback: > > 2.1. SUBSECOND parameter > > Parameter name: SUBSECOND > > Purpose: To specify fractional seconds for time values and > durations. > > Description: This parameter MAY be specified on properties of type > DATE-TIME, DURATION and TIME. It MUST be a FLOAT value less than > 1.0 and MUST NOT be negative. Implementations MUST ignore > presence of the SUBSECOND parameter on RECURRENCE-ID properties > when determining recurrence overrides. > > Format Definition: > > This parameter is defined by the following notation: > > subsecond-param = "SUBSECOND" "=" float > > Example: > > DTSTART;SUBSECOND=0.0123:20111205T040506 > > On Mon, Dec 21, 2020, at 2:03 PM, Ken Murchison wrote: >> >> >> On 12/21/20 7:54 AM, Robert Stepanek wrote: >>> On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote: >>>> On 12/21/20 7:31 AM, Robert Stepanek wrote: >>>>> As noted in my previous email: we already agreed to not set the >>>>> complete timestamp in the FRACTIONAL parameter value. >>>>> >>>>> Instead we will set a SUBSECONDS parameter which will be defined >>>>> to a FLOAT value with MUST be positive and less than 1.0. >>>> >>>> OK, but if it MUST be positive, don't we still have the issue that >>>> Mike brought up regarding rounding?  Or we will state that the >>>> property value MUST NOT be rounded up. >>>> >>> >>> It MUST NOT be rounded, because any client aware of SUBSECONDS would >>> then calculate with a wrong value. The SUBSECONDS parameter only >>> defines the fractional seconds part. >> >> >> OK.  WFM >> >> -- >> Kenneth Murchison >> Senior Software Developer >> Fastmail US LLC >> _______________________________________________ >> 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 --------------C778F8B5DE94393A8677F0FA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Now I'm confused:

The draft 1 had a SUBSECOND parameter:

From version 1:

  Example:  DTSTART;SUBSECOND=0.03:20190605T133015

The discussion around April this year included this:


          
[...] Also what about fractional values > 0.5? Really we
            should round to nearest? Would it be better to have e.g. a
            FRACTIONAL parameter with the whole date-time and allow the
            value to be the rounded value.?

          

        

        


        

        
As discussed in our call a couple of weeks ago, it would be
          best if we could just allow fractional seconds in DATE-TIME
          values. But that will break loads of iCalendar parser, so it
          will have to remain wishful thinking.

        

        


        

        
Both FRACTIONAL and SUBSECONDS have their flaws. I
          originally thought that the SUBSECONDS parameter is the better
          choice, but now that we talk about it, I come to prefer your
          FRACTIONAL idea.

        

        


        

        We could define the FRACTIONAL parameter to contain the complete
        datetime including fractional seconds. A client that is aware of
        that parameter must both set the FRACTIONAL parameter and the
        date-time property value. The property value must contain the
        rounded value of FRACTIONAL. Time values with fractional seconds
        always round up to the next second. The value of the FRACTIONAL
        parameter must be ignored, if its rounded value does not match
        the property value.

    

    
So I updated the draft so that version 2 had the full value.

    
I still felt this is the best approach.

    
By having the full value in the parameter we avoid implementors
      needing to know if the property value is a rounded or truncated
      number.

    
On 12/21/20 10:31, Robert Stepanek
      wrote:

    

    

      
      
      
      
I have updated the RFC draft on Github. Here is the excerpt,
        I appreciate any feedback:

      

      


      

      
2.1.  SUBSECOND parameter

   Parameter name:  SUBSECOND

   Purpose:  To specify fractional seconds for time values and
      durations.

   Description:  This parameter MAY be specified on properties of type
      DATE-TIME, DURATION and TIME.  It MUST be a FLOAT value less than
      1.0 and MUST NOT be negative.  Implementations MUST ignore
      presence of the SUBSECOND parameter on RECURRENCE-ID properties
      when determining recurrence overrides.

   Format Definition:

   This parameter is defined by the following notation:

       subsecond-param = "SUBSECOND" "=" float

   Example:

       DTSTART;SUBSECOND=0.0123:20111205T040506


      


      

      
On Mon, Dec 21, 2020, at 2:03 PM, Ken Murchison wrote:

      

      

        


        

        
On 12/21/20 7:54 AM, Robert
          Stepanek wrote:

        

        

          
On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote:

          

          

            
On 12/21/20 7:31 AM,
              Robert Stepanek wrote:

            

            

              
As noted in my previous email: we already agreed to
                not set the complete timestamp in the FRACTIONAL
                parameter value. 

              

              


              

              
Instead we will set a SUBSECONDS parameter which will
                be defined to a FLOAT value with MUST be positive and
                less than 1.0.

              

            

            
OK, but if it MUST be positive, don't we still have the
              issue that Mike brought up regarding rounding?  Or we will
              state that the property value MUST NOT be rounded up.

            

          

          


          

          
It MUST NOT be rounded, because any client aware of
            SUBSECONDS would then calculate with a wrong value. The
            SUBSECONDS parameter only defines the fractional seconds
            part.

          

        

        


        

        
OK.  WFM

        

        
-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC


        
_______________________________________________

        

        
calsify mailing list

        

        
        
        


        

      

      


      

      

      

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


    

  


--------------C778F8B5DE94393A8677F0FA--


From nobody Mon Dec 21 08:25: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 CCF573A1232 for ; Mon, 21 Dec 2020 08:25:44 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwwtJkLARfKq for ; Mon, 21 Dec 2020 08:25:43 -0800 (PST)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7FA3A121B for ; Mon, 21 Dec 2020 08:25:43 -0800 (PST)
Received: by mail-qv1-xf2d.google.com with SMTP id 4so4674443qvh.1 for ; Mon, 21 Dec 2020 08:25:43 -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=e46/zoS4IXsj8r3nPy5fxiP8gmR0JsYmCoIVlsgdASE=; b=ueW0+1bD7nIeFswk6jRV18OtQDpzNbS+nf+no2BQUXdpEoaWeNOUrCkmsWpqlp+1oH tLxlEngI1FWOvsZr7HrasYbtsAqnL97bgEAB/A/3rS9Y/A0XPJgMbOls+hfX5XM4L6Zs Wxvu8Goy/fVIAU1g0Zd3R7LcF1CCNTT/MilSEYKs2UQriGbtXNQbUa4L+ff/ffHIZV8U IzaiIj9VIvx6CadY8Hd8yQgXMqEm5VE+7ZXPOkDTcETaYpLOZHgvTEThTzG/VY47Ww3Y /Wkvob57/o5BHaBM/RR252LlRLCpGaBa5dR8xv1Gzwn1sA8I+V7HG1kaWVLkkQRStBjq 5fAA==
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=e46/zoS4IXsj8r3nPy5fxiP8gmR0JsYmCoIVlsgdASE=; b=UhyLhEatmEKZCsmKVfq6QS7/ZXmZqsmIZCCHzsDtQ1T8KIWjMjWvWIbOlJlQm8Q6VL YwFrrpBsFHsaWucdrrB2OVYSnieAxoh1fjmqozSfH3sqe+t8BLZXRYYiGKqPL827Oij0 od4iGATbZGoAZg9pr914jJd6CM90B/HUphqOTs0aF8nFM4mpZDEb02vC8HX9WAiyY44Z cgs5K8DLXG7GDb4/mFObqILSbxG16Rh6n1IilMQ4VWbUlo/DE+lgVe9rIk3CIyiTaa7F TECo1jdv3Q3oB1xGdyQDjeSRsE0WfrHLkRHvTGpKvWnyl1be4TmhjllV+HfXRiVBoJE2 Xh7w==
X-Gm-Message-State: AOAM530Sz4EDuhjzPq1CX2ZaY0/hLzoW7NwUE5a2Aeo2+NFf7BooxVVp uoM5ppAOVVm5gvC+M7GIzO3whrYIU/NOOw==
X-Google-Smtp-Source: ABdhPJyQCzCgzbEIXy3Nz6s5bU+jft+WOUysDpVq49OHS9hJ6wRfJyrIIkbs5UoSWvyjBVeoUImg3w==
X-Received: by 2002:a0c:fe04:: with SMTP id x4mr18032911qvr.13.1608567941711;  Mon, 21 Dec 2020 08:25:41 -0800 (PST)
Received: from [192.168.1.151] (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id u26sm11054014qkm.69.2020.12.21.08.25.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Dec 2020 08:25:41 -0800 (PST)
To: Robert Stepanek , calsify@ietf.org
References: <57f81335-b7a9-6a9f-df5f-bab580689a33@fastmail.com>  <9595a7c0-2fb8-4e68-cd45-ce97bc13532f@fastmail.com> <6eb94ffd-2d3f-4e42-88bb-ef352495351d@www.fastmail.com> <385d8dec-09ce-8884-d9cc-0eeb792d692e@fastmail.com> <971461a9-6327-4f2b-a1c9-1c6a7c9a3f97@www.fastmail.com>  <95c63702-66a5-4720-8737-7f9e7218e560@www.fastmail.com>
From: Michael Douglass 
Message-ID: <4651382b-3bd6-da95-cc18-7554b853ad96@gmail.com>
Date: Mon, 21 Dec 2020 11:25:39 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <95c63702-66a5-4720-8737-7f9e7218e560@www.fastmail.com>
Content-Type: multipart/alternative; boundary="------------E3EEC5A2A9FC77E9E9D79788"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-jscalendar-icalendar-02
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, 21 Dec 2020 16:25:45 -0000

This is a multi-part message in MIME format.
--------------E3EEC5A2A9FC77E9E9D79788
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

There's another issue which is touched on in the FRACTIONAL form of the 
spec -

how does a client figure out that the property value no longer matches 
the parameter?

e.g jscalendar aware system sends

DTSTART;SUBSECOND=0.0123:20201205T040506

Old client updates DTSTART but does as it should and preserves the SUBSECOND

DTSTART;SUBSECOND=0.0123:20201205T050000


The SUBSECOND parameter was for the old value. I guess we can see it 
changed but we need to have wording in there such as I added to the 
FRACTIONAL version.

On 12/21/20 10:31, Robert Stepanek wrote:
> I have updated the RFC draft on Github. Here is the excerpt, I 
> appreciate any feedback:
>
> 2.1.  SUBSECOND parameter
>
>     Parameter name:  SUBSECOND
>
>     Purpose:  To specify fractional seconds for time values and
>        durations.
>
>     Description:  This parameter MAY be specified on properties of type
>        DATE-TIME, DURATION and TIME.  It MUST be a FLOAT value less than
>        1.0 and MUST NOT be negative.  Implementations MUST ignore
>        presence of the SUBSECOND parameter on RECURRENCE-ID properties
>        when determining recurrence overrides.
>
>     Format Definition:
>
>     This parameter is defined by the following notation:
>
>         subsecond-param = "SUBSECOND" "=" float
>
>     Example:
>
>         DTSTART;SUBSECOND=0.0123:20111205T040506
>
> On Mon, Dec 21, 2020, at 2:03 PM, Ken Murchison wrote:
>>
>>
>> On 12/21/20 7:54 AM, Robert Stepanek wrote:
>>> On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote:
>>>> On 12/21/20 7:31 AM, Robert Stepanek wrote:
>>>>> As noted in my previous email: we already agreed to not set the 
>>>>> complete timestamp in the FRACTIONAL parameter value.
>>>>>
>>>>> Instead we will set a SUBSECONDS parameter which will be defined 
>>>>> to a FLOAT value with MUST be positive and less than 1.0.
>>>>
>>>> OK, but if it MUST be positive, don't we still have the issue that 
>>>> Mike brought up regarding rounding?  Or we will state that the 
>>>> property value MUST NOT be rounded up.
>>>>
>>>
>>> It MUST NOT be rounded, because any client aware of SUBSECONDS would 
>>> then calculate with a wrong value. The SUBSECONDS parameter only 
>>> defines the fractional seconds part.
>>
>>
>> OK.  WFM
>>
>> -- 
>> Kenneth Murchison
>> Senior Software Developer
>> Fastmail US LLC
>> _______________________________________________
>> 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

--------------E3EEC5A2A9FC77E9E9D79788
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
There's another issue which is touched on in the FRACTIONAL form
      of the spec - 

    

    
how does a client figure out that the property value no longer
      matches the parameter?

    
e.g jscalendar aware system sends 

    

    
DTSTART;SUBSECOND=0.0123:20201205T040506

    
Old client updates DTSTART but does as
      it should and preserves the SUBSECOND

    

    


    

    

      
DTSTART;SUBSECOND=0.0123:20201205T050000


    

    


    

    
The SUBSECOND parameter was for the old
      value. I guess we can see it changed but we need to have wording
      in there such as I added to the FRACTIONAL version.

    

    


    

    
On 12/21/20 10:31, Robert Stepanek
      wrote:

    

    

      
      
      
      
I have updated the RFC draft on Github. Here is the excerpt,
        I appreciate any feedback:

      

      


      

      
2.1.  SUBSECOND parameter

   Parameter name:  SUBSECOND

   Purpose:  To specify fractional seconds for time values and
      durations.

   Description:  This parameter MAY be specified on properties of type
      DATE-TIME, DURATION and TIME.  It MUST be a FLOAT value less than
      1.0 and MUST NOT be negative.  Implementations MUST ignore
      presence of the SUBSECOND parameter on RECURRENCE-ID properties
      when determining recurrence overrides.

   Format Definition:

   This parameter is defined by the following notation:

       subsecond-param = "SUBSECOND" "=" float

   Example:

       DTSTART;SUBSECOND=0.0123:20111205T040506


      


      

      
On Mon, Dec 21, 2020, at 2:03 PM, Ken Murchison wrote:

      

      

        


        

        
On 12/21/20 7:54 AM, Robert
          Stepanek wrote:

        

        

          
On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote:

          

          

            
On 12/21/20 7:31 AM,
              Robert Stepanek wrote:

            

            

              
As noted in my previous email: we already agreed to
                not set the complete timestamp in the FRACTIONAL
                parameter value. 

              

              


              

              
Instead we will set a SUBSECONDS parameter which will
                be defined to a FLOAT value with MUST be positive and
                less than 1.0.

              

            

            
OK, but if it MUST be positive, don't we still have the
              issue that Mike brought up regarding rounding?  Or we will
              state that the property value MUST NOT be rounded up.

            

          

          


          

          
It MUST NOT be rounded, because any client aware of
            SUBSECONDS would then calculate with a wrong value. The
            SUBSECONDS parameter only defines the fractional seconds
            part.

          

        

        


        

        
OK.  WFM

        

        
-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC


        
_______________________________________________

        

        
calsify mailing list

        

        
        
        


        

      

      


      

      

      

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


    

  


--------------E3EEC5A2A9FC77E9E9D79788--


From nobody Mon Dec 21 11:45:09 2020
Return-Path: 
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9203A1352 for ; Mon, 21 Dec 2020 11:45:07 -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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=cTjbG8Bk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EG1QPEII
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 emvuJuk4P6Da for ; Mon, 21 Dec 2020 11:45:05 -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 9B4313A1349 for ; Mon, 21 Dec 2020 11:45:05 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B04BC5C01A5 for ; Mon, 21 Dec 2020 14:45:02 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 21 Dec 2020 14:45:02 -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=fm1; bh=ZPd7bnkAddfJqVmA02c/StduIbA Y60C2EQ3oQumU/TM=; b=cTjbG8BkspS8Xg3nK83AgnxlVq4UxMsMiO01ZBl4jY5 K0U+qW4w3F5fBpL5pCJUa1Y+wDWzQKndbESnf1vtxccWCjp7l8N6HahC9b26yjWG Lkejpii9ZC8UMNC3nkwneQNxlgW43H2rTb/NJRXKP59V1sei8t1GkvA/8eeOGOIM gKpCAgCukk06st8uSvb7vVa2duXebcOAny5Jp8I64Nt7IaPaWWQz1DWcPEGA+TL6 /V8m05qIcu9AMFU4a5a/wJWRqORGC0TmMIW3DmS8+ksRrnOIUg3S81BPVfk9lQeG Uw4sgx3SQHBiMCvdXAqFOylMkiD0mmoqGUcq/1rpEgQ==
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=fm1; bh=ZPd7bn kAddfJqVmA02c/StduIbAY60C2EQ3oQumU/TM=; b=EG1QPEIIu4/zlKtAExmq8j eI0j77XPY0J447+pCqhWcp28fD3Pkk3r33iG/U5GHf5lWYdZZqNcM/7uZYHEXE22 Q11n4gXTlhIItet9qq3Omutog7338w0kIrpIUeDtsn6Lx2VKzrl0C8ijU+DmweQR yyx91lL4i3Zkyls/JvE8/QY9UQvMUq+vbncZOoPsKUun2FoVJ2Sv/mSbWWeDagN2 nvzNFqBQrPidxbhWwqCX4uWu1w0oaFyBTWoDsS2gPWGl9PfOoHBz0fI83lNWpi8k DhAzYrpLwC3RqAhzcPVI90Cjux9i6g18M8m5P/JUFspGtN7lESq8IRHf42xas78Q ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddtvddgudefvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtd erredtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgr shhtmhgrihhlrdgtohhmqeenucggtffrrghtthgvrhhnpeffuefhvefggfdvudeuvdetie ejuedvvdekudeggedvffevgfduffeuieelgeeggeenucffohhmrghinhepihgvthhfrdho rhhgnecukfhppeejgedrjeejrdekhedrvdehtdenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtghomh
X-ME-Proxy:    
Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 47FEF24006C for ; Mon, 21 Dec 2020 14:45:02 -0500 (EST)
To: calsify@ietf.org
References: <57f81335-b7a9-6a9f-df5f-bab580689a33@fastmail.com>  <9595a7c0-2fb8-4e68-cd45-ce97bc13532f@fastmail.com> <6eb94ffd-2d3f-4e42-88bb-ef352495351d@www.fastmail.com> <385d8dec-09ce-8884-d9cc-0eeb792d692e@fastmail.com> <971461a9-6327-4f2b-a1c9-1c6a7c9a3f97@www.fastmail.com>  <95c63702-66a5-4720-8737-7f9e7218e560@www.fastmail.com>
From: Ken Murchison 
Message-ID: 
Date: Mon, 21 Dec 2020 14:45:01 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <95c63702-66a5-4720-8737-7f9e7218e560@www.fastmail.com>
Content-Type: multipart/alternative; boundary="------------55A597C0836ACE4CBF98F1E7"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-jscalendar-icalendar-02
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, 21 Dec 2020 19:45:08 -0000

This is a multi-part message in MIME format.
--------------55A597C0836ACE4CBF98F1E7
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit


On 12/21/20 10:31 AM, Robert Stepanek wrote:
> I have updated the RFC draft on Github. Here is the excerpt, I 
> appreciate any feedback:
>
> 2.1.  SUBSECOND parameter
>
>     Parameter name:  SUBSECOND
>
>     Purpose:  To specify fractional seconds for time values and
>        durations.
>
>     Description:  This parameter MAY be specified on properties of type
>        DATE-TIME, DURATION and TIME.  It MUST be a FLOAT value less than
>        1.0 and MUST NOT be negative.  Implementations MUST ignore
>        presence of the SUBSECOND parameter on RECURRENCE-ID properties
>        when determining recurrence overrides.


This last sentence could be a problem if we ever have support for 
sub-seconds in RRULEs.  In fact, there is a PR in libical for adding 
support for recurrences with millisecond precision.  In this case, the 
SUBSECOND parameter on RECURRENCE-ID would be critical in determining 
the correct instance to override.

As an aside, I'm considering writing a draft which documents a variation 
of what is in the PR.



>     Format Definition:
>
>     This parameter is defined by the following notation:
>
>         subsecond-param = "SUBSECOND" "=" float


Does it make sense to use the float type here if we have to qualify that 
its range is (0.0, 1.0)?  We could just use

"." 1*DIGIT



>
>     Example:
>
>         DTSTART;SUBSECOND=0.0123:20111205T040506
>
> On Mon, Dec 21, 2020, at 2:03 PM, Ken Murchison wrote:
>>
>>
>> On 12/21/20 7:54 AM, Robert Stepanek wrote:
>>> On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote:
>>>> On 12/21/20 7:31 AM, Robert Stepanek wrote:
>>>>> As noted in my previous email: we already agreed to not set the 
>>>>> complete timestamp in the FRACTIONAL parameter value.
>>>>>
>>>>> Instead we will set a SUBSECONDS parameter which will be defined 
>>>>> to a FLOAT value with MUST be positive and less than 1.0.
>>>>
>>>> OK, but if it MUST be positive, don't we still have the issue that 
>>>> Mike brought up regarding rounding?  Or we will state that the 
>>>> property value MUST NOT be rounded up.
>>>>
>>>
>>> It MUST NOT be rounded, because any client aware of SUBSECONDS would 
>>> then calculate with a wrong value. The SUBSECONDS parameter only 
>>> defines the fractional seconds part.
>>
>>
>> OK.  WFM
>>
>> -- 
>> Kenneth Murchison
>> Senior Software Developer
>> Fastmail US LLC
>> _______________________________________________
>> 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

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC


--------------55A597C0836ACE4CBF98F1E7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
On 12/21/20 10:31 AM, Robert Stepanek
      wrote:

    

    

      
      
      
      
I have updated the RFC draft on Github. Here is the excerpt,
        I appreciate any feedback:

      

      


      

      
2.1.  SUBSECOND parameter

   Parameter name:  SUBSECOND

   Purpose:  To specify fractional seconds for time values and
      durations.

   Description:  This parameter MAY be specified on properties of type
      DATE-TIME, DURATION and TIME.  It MUST be a FLOAT value less than
      1.0 and MUST NOT be negative.  Implementations MUST ignore
      presence of the SUBSECOND parameter on RECURRENCE-ID properties
      when determining recurrence overrides.

    

    


    

    
This last sentence could be a problem if we ever have support for
      sub-seconds in RRULEs.  In fact, there is a PR in libical for
      adding support for recurrences with millisecond precision.  In
      this case, the SUBSECOND parameter on RECURRENCE-ID would be
      critical in determining the correct instance to override.

    
As an aside, I'm considering writing a draft which documents a
      variation of what is in the PR.

    

    


    

    


    

    

    

    

      
   Format Definition:

   This parameter is defined by the following notation:

       subsecond-param = "SUBSECOND" "=" float

    

    


    

    
Does it make sense to use the float type here if we have to
      qualify that its range is (0.0, 1.0)?  We could just use 

    

    
"." 1*DIGIT

    

    


    

    


    

    

      

   Example:

       DTSTART;SUBSECOND=0.0123:20111205T040506


      


      

      
On Mon, Dec 21, 2020, at 2:03 PM, Ken Murchison wrote:

      

      

        


        

        
On 12/21/20 7:54 AM, Robert
          Stepanek wrote:

        

        

          
On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote:

          

          

            
On 12/21/20 7:31 AM,
              Robert Stepanek wrote:

            

            

              
As noted in my previous email: we already agreed to
                not set the complete timestamp in the FRACTIONAL
                parameter value. 

              

              


              

              
Instead we will set a SUBSECONDS parameter which will
                be defined to a FLOAT value with MUST be positive and
                less than 1.0.

              

            

            
OK, but if it MUST be positive, don't we still have the
              issue that Mike brought up regarding rounding?  Or we will
              state that the property value MUST NOT be rounded up.

            

          

          


          

          
It MUST NOT be rounded, because any client aware of
            SUBSECONDS would then calculate with a wrong value. The
            SUBSECONDS parameter only defines the fractional seconds
            part.

          

        

        


        

        
OK.  WFM

        

        
-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC


        
_______________________________________________

        

        
calsify mailing list

        

        
        
        


        

      

      


      

      

      

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


    

    
-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

  


--------------55A597C0836ACE4CBF98F1E7--


From nobody Mon Dec 21 11:51: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 900F43A135F for ; Mon, 21 Dec 2020 11:51:39 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIr0UpzakaFo for ; Mon, 21 Dec 2020 11:51:37 -0800 (PST)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 8B3AD3A1364 for ; Mon, 21 Dec 2020 11:51:37 -0800 (PST)
Received: by mail-qt1-x82b.google.com with SMTP id g24so7420921qtq.12 for ; Mon, 21 Dec 2020 11:51:37 -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=qCpOHpEfGH9kJjknHuwLfXNvvEB1LbV42AGMrHYGXxY=; b=FZ+u18Ia/LuK4HBxoDUIVCmkULd7HAO8htHF4DtQDMytEJYONZCGwNaRArX2cj6lYN onrDNdODywZXREvqbPZs6X9qxaDeyyvYqIRqI35N/ZHY0tg2GzC0q6Goeb7BJtfxvqRJ JrEKra3j1ZtsBdXSkL9tHOfqDzohMaxr5TfNNDXx9RU+tojC+grn79ckGawu/Atf7Ov5 vJXLSElyQoJaZ2ggY92FcErDmA+4qk/V3ntD9SQpHqRaG8tcBMZuCOS8M0CHlzvb/sCT T9Z1qQp3H2Fq3R0lW1R5JUZE81VKoSGCQfYN8LxTDRZXW7hY5gIt3NIq+36t6puNBuBc DwnQ==
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=qCpOHpEfGH9kJjknHuwLfXNvvEB1LbV42AGMrHYGXxY=; b=aRIBZQWYE9D5PGH71K5LsDCbT1IrFle4ORseWRiFNG1QvOdW9mdjzDVXEKyGSCfv0C JmQnrLOGpvsngZbAu72ovyPdvW4HOWzjB3OSgLUBC4J5SQBB0LXukopChRyyhVopiZIG EaAU/NPEoC1G2FhJXXG77cwedH9oooHKyxb7RjmwTqsgGhQpzicsLW0fo/hx2xhwvHre rekt6PvQ81L4jQQ5cPOLqkYXfteZL0gGAsTkicp92DUjw9UMzTCFOXrenLQXPI/Jx/GH 9y21KSerN/D800eG83hILOd51YEQE4RgPhrIvX9HM61qcR/6Mv9v1LrwImvKXT7Oh8Hw PL0Q==
X-Gm-Message-State: AOAM533akLVMEi1RJx2IgmNKHZCK2xaKLLhBq31lh2FH0EeCOlrwvEX5 d6oyXhqKMiVzCoQDjNPZsHFbsz1OX2XNPg==
X-Google-Smtp-Source: ABdhPJwQ1B86m3fA7dBRe+PNJufyQcCc3ya2DEukEcSVM5HemjcOCFEl2l3zCXOH54R5iVASQGE+Hw==
X-Received: by 2002:ac8:1386:: with SMTP id h6mr17934192qtj.95.1608580296319;  Mon, 21 Dec 2020 11:51:36 -0800 (PST)
Received: from MacBook-Pro-2019.local (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id c8sm11431373qkc.12.2020.12.21.11.51.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Dec 2020 11:51:35 -0800 (PST)
To: Ken Murchison , calsify@ietf.org
References: <57f81335-b7a9-6a9f-df5f-bab580689a33@fastmail.com>  <9595a7c0-2fb8-4e68-cd45-ce97bc13532f@fastmail.com> <6eb94ffd-2d3f-4e42-88bb-ef352495351d@www.fastmail.com> <385d8dec-09ce-8884-d9cc-0eeb792d692e@fastmail.com> <971461a9-6327-4f2b-a1c9-1c6a7c9a3f97@www.fastmail.com>  <95c63702-66a5-4720-8737-7f9e7218e560@www.fastmail.com> 
From: Michael Douglass 
Message-ID: <0d7d27e5-70f3-f070-aba2-ef4666048b2c@gmail.com>
Date: Mon, 21 Dec 2020 14:51:34 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------3F76ECC20E8F7EC9E992E362"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-jscalendar-icalendar-02
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, 21 Dec 2020 19:51:40 -0000

This is a multi-part message in MIME format.
--------------3F76ECC20E8F7EC9E992E362
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit


On 12/21/20 14:45, Ken Murchison wrote:
>
>
> On 12/21/20 10:31 AM, Robert Stepanek wrote:
>> I have updated the RFC draft on Github. Here is the excerpt, I 
>> appreciate any feedback:
>>
>> 2.1.  SUBSECOND parameter
>>
>>     Parameter name:  SUBSECOND
>>
>>     Purpose:  To specify fractional seconds for time values and
>>        durations.
>>
>>     Description:  This parameter MAY be specified on properties of type
>>        DATE-TIME, DURATION and TIME.  It MUST be a FLOAT value less than
>>        1.0 and MUST NOT be negative.  Implementations MUST ignore
>>        presence of the SUBSECOND parameter on RECURRENCE-ID properties
>>        when determining recurrence overrides.
>
>
> This last sentence could be a problem if we ever have support for 
> sub-seconds in RRULEs.  In fact, there is a PR in libical for adding 
> support for recurrences with millisecond precision. In this case, the 
> SUBSECOND parameter on RECURRENCE-ID would be critical in determining 
> the correct instance to override.
>
True - the smart grid people have been asking for the same and they use 
recurrences also. RDATE, EXDATE as well. Possibly anywhere there's a 
date-time.

I've also had conversations about issues around logging - that means 
create dates, modification dates etc.

The one second precision in timestamps is already a problem. It's 
perfectly possible for multiple systems to pass many scheduling messages 
within the space of a second.

> As an aside, I'm considering writing a draft which documents a 
> variation of what is in the PR.
>
>
>
>>     Format Definition:
>>
>>     This parameter is defined by the following notation:
>>
>>         subsecond-param = "SUBSECOND" "=" float
>
>
> Does it make sense to use the float type here if we have to qualify 
> that its range is (0.0, 1.0)?  We could just use
>
> "." 1*DIGIT
>
>
>
>>     Example:
>>
>>         DTSTART;SUBSECOND=0.0123:20111205T040506
>>
>> On Mon, Dec 21, 2020, at 2:03 PM, Ken Murchison wrote:
>>>
>>>
>>> On 12/21/20 7:54 AM, Robert Stepanek wrote:
>>>> On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote:
>>>>> On 12/21/20 7:31 AM, Robert Stepanek wrote:
>>>>>> As noted in my previous email: we already agreed to not set the 
>>>>>> complete timestamp in the FRACTIONAL parameter value.
>>>>>>
>>>>>> Instead we will set a SUBSECONDS parameter which will be defined 
>>>>>> to a FLOAT value with MUST be positive and less than 1.0.
>>>>>
>>>>> OK, but if it MUST be positive, don't we still have the issue that 
>>>>> Mike brought up regarding rounding?  Or we will state that the 
>>>>> property value MUST NOT be rounded up.
>>>>>
>>>>
>>>> It MUST NOT be rounded, because any client aware of SUBSECONDS 
>>>> would then calculate with a wrong value. The SUBSECONDS parameter 
>>>> only defines the fractional seconds part.
>>>
>>>
>>> OK.  WFM
>>>
>>> -- 
>>> Kenneth Murchison
>>> Senior Software Developer
>>> Fastmail US LLC
>>> _______________________________________________
>>> 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
> -- 
> Kenneth Murchison
> Senior Software Developer
> Fastmail US LLC
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify

--------------3F76ECC20E8F7EC9E992E362
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    
On 12/21/20 14:45, Ken Murchison wrote:

    

    

      
      


      

      
On 12/21/20 10:31 AM, Robert Stepanek
        wrote:

      

      

        
        
        
        
I have updated the RFC draft on Github. Here is the
          excerpt, I appreciate any feedback:

        

        


        

        
2.1.  SUBSECOND parameter

   Parameter name:  SUBSECOND

   Purpose:  To specify fractional seconds for time values and
      durations.

   Description:  This parameter MAY be specified on properties of type
      DATE-TIME, DURATION and TIME.  It MUST be a FLOAT value less than
      1.0 and MUST NOT be negative.  Implementations MUST ignore
      presence of the SUBSECOND parameter on RECURRENCE-ID properties
      when determining recurrence overrides.

      

      


      

      
This last sentence could be a problem if we ever have support
        for sub-seconds in RRULEs.  In fact, there is a PR in libical
        for adding support for recurrences with millisecond precision. 
        In this case, the SUBSECOND parameter on RECURRENCE-ID would be
        critical in determining the correct instance to override.

    

    
True - the smart grid people have been asking for the same and
      they use recurrences also. RDATE, EXDATE as well. Possibly
      anywhere there's a date-time.

    
I've also had conversations about issues around logging - that
      means create dates, modification dates etc.

    
The one second precision in timestamps is already a problem. It's
      perfectly possible for multiple systems to pass many scheduling
      messages within the space of a second.

    

    

      
As an aside, I'm considering writing a draft which documents a
        variation of what is in the PR.

      

      


      

      


      

      
 

      

        
   Format Definition:

   This parameter is defined by the following notation:

       subsecond-param = "SUBSECOND" "=" float

      

      


      

      
Does it make sense to use the float type here if we have to
        qualify that its range is (0.0, 1.0)?  We could just use 

      

      
"." 1*DIGIT

      

      


      

      


      

      

        
   Example:

       DTSTART;SUBSECOND=0.0123:20111205T040506


        


        

        
On Mon, Dec 21, 2020, at 2:03 PM, Ken Murchison wrote:

        

        

          


          

          
On 12/21/20 7:54 AM, Robert
            Stepanek wrote:

          

          

            
On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote:

            

            

              
On 12/21/20 7:31 AM,
                Robert Stepanek wrote:

              

              

                
As noted in my previous email: we already agreed to
                  not set the complete timestamp in the FRACTIONAL
                  parameter value. 

                

                


                

                
Instead we will set a SUBSECONDS parameter which
                  will be defined to a FLOAT value with MUST be positive
                  and less than 1.0.

                

              

              
OK, but if it MUST be positive, don't we still have the
                issue that Mike brought up regarding rounding?  Or we
                will state that the property value MUST NOT be rounded
                up.

              

            

            


            

            
It MUST NOT be rounded, because any client aware of
              SUBSECONDS would then calculate with a wrong value. The
              SUBSECONDS parameter only defines the fractional seconds
              part.

            

          

          


          

          
OK.  WFM

          

          
-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC


          
_______________________________________________

          

          
calsify mailing list

          

          
          
          


          

        

        


        

        

        

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


      

      
-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

      

      

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


    

  


--------------3F76ECC20E8F7EC9E992E362--


From nobody Tue Dec 22 00:33:54 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 0B19D3A0E7C for ; Tue, 22 Dec 2020 00:33:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=HPxYbiRw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hyUovnWh
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 duaZX5offAph for ; Tue, 22 Dec 2020 00:33:49 -0800 (PST)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8FA3A0E6C for ; Tue, 22 Dec 2020 00:33:49 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 931C0871 for ; Tue, 22 Dec 2020 03:33:47 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Tue, 22 Dec 2020 03:33:47 -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=fm1; bh=dceu17z 8sqT8ycp/AsATSISdPC2QH40giKtwJKL8apU=; b=HPxYbiRw+/D8HvsHFS5g0+s L7ZRzFRUON9lW8/cpoBElcjRVr+w5JMAmNf6MGGkud93yFgQzk1OBlycVHuCqHhk MmkzMJWL8AX6+CIPW6DCkE6nRAN72rmInWKUEoAT11STD27cEuSp7UKJLHB6o74/ eQMQUQBFFd1ftNPi0ufr/J7LBCu7m5EeR26afwndz8R5u4yYmc20oiZ7iD5lal0G emqudZ6fk5k561rBOLRXGuPsPdhlwNbNAEOU+LDyuXKLfTapV0GFj607F9BdQKyA RRvZhISTaoagYiRAbnnqA/4IMzyVVeJBjgtTeF5PAOZPxw3MBWZ5t6VzTG8Jq0A= =
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=fm1; bh=dceu17 z8sqT8ycp/AsATSISdPC2QH40giKtwJKL8apU=; b=hyUovnWhVjUS03lByVcInr 4SvSHDZfYKQGDkarjiSW4BHj3YplVGAsndIyXy6rfpBdj+0azHhJsaocoUpU0ZDj KElK+bTKRU0qVSiVkGN1on815dkAwqSl6yORqAjcvlMautw9AOK2VL/yesk/kFs+ P/S/8ajx4dxipO2yVqYpZA8VQ9E2wLuKT85dUxrG3RCKH3x2Pz06G963eZd8irC2 hRe9GowqTA6JZ2lbRQgN5wHNTXPzlaXPxEGCygguye1xgzopFB4DYKy1QOYYNhTl 1cdHmjecbBhJnIPJHqqbMPsjj5F2T+fa09y6uBM5IXcGG16TztDfGOHBpMxbQxiw ==
X-ME-Sender:  
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvddtfedguddvfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshht ohesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeethfffff ekueekveelleeglefhgeefjeeugeetkeejkefgtdfhheehvdehhedvhfenucffohhmrghi nhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheprhhsthhosehfrghsthhmrghilhhtvggrmhdrtghomh
X-ME-Proxy:    
Received: by mailuser.nyi.internal (Postfix, from userid 501) id CD2051800C1; Tue, 22 Dec 2020 03:33:46 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396
Mime-Version: 1.0
Message-Id: <4bac0140-f572-436e-a3b4-cf5d21dd47af@www.fastmail.com>
In-Reply-To: <0d7d27e5-70f3-f070-aba2-ef4666048b2c@gmail.com>
References: <57f81335-b7a9-6a9f-df5f-bab580689a33@fastmail.com>  <9595a7c0-2fb8-4e68-cd45-ce97bc13532f@fastmail.com> <6eb94ffd-2d3f-4e42-88bb-ef352495351d@www.fastmail.com> <385d8dec-09ce-8884-d9cc-0eeb792d692e@fastmail.com> <971461a9-6327-4f2b-a1c9-1c6a7c9a3f97@www.fastmail.com>  <95c63702-66a5-4720-8737-7f9e7218e560@www.fastmail.com>  <0d7d27e5-70f3-f070-aba2-ef4666048b2c@gmail.com>
Date: Tue, 22 Dec 2020 09:33:26 +0100
From: "Robert Stepanek" 
To: calsify@ietf.org
Content-Type: multipart/alternative; boundary=98521c6b6269433db161e9e295f247b3
Archived-At: 
Subject: Re: [calsify] draft-ietf-calext-jscalendar-icalendar-02
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, 22 Dec 2020 08:33:52 -0000

--98521c6b6269433db161e9e295f247b3
Content-Type: text/plain

I thought we had reversed the FRACTIONAL idea earlier this year, but probably I am not remembering that right. In any case, it's great to continue that conversation because it seems clear that neither approach currently covers all of our requirements.

If there is demand for subsecond precision in iCalendar in addition to what we need for JSCalendar, then a separate draft looks like the right next step to me. This is then also the place where we define the FRACTIONAL or SUBSECOND or other parameters, in addition to how to deal with recurrences. The JSCalendar mapping can then build on that.

Cheers,
Robert




On Mon, Dec 21, 2020, at 8:51 PM, Michael Douglass wrote:
> 

> On 12/21/20 14:45, Ken Murchison wrote:
>> 

>> On 12/21/20 10:31 AM, Robert Stepanek wrote:
>>> I have updated the RFC draft on Github. Here is the excerpt, I appreciate any feedback:
>>> 
>>> 2.1.  SUBSECOND parameter

   Parameter name:  SUBSECOND

   Purpose:  To specify fractional seconds for time values and
      durations.

   Description:  This parameter MAY be specified on properties of type
      DATE-TIME, DURATION and TIME.  It MUST be a FLOAT value less than
      1.0 and MUST NOT be negative.  Implementations MUST ignore
      presence of the SUBSECOND parameter on RECURRENCE-ID properties
      when determining recurrence overrides.
>> 

>> This last sentence could be a problem if we ever have support for sub-seconds in RRULEs.  In fact, there is a PR in libical for adding support for recurrences with millisecond precision.  In this case, the SUBSECOND parameter on RECURRENCE-ID would be critical in determining the correct instance to override.

> True - the smart grid people have been asking for the same and they use recurrences also. RDATE, EXDATE as well. Possibly anywhere there's a date-time.

> I've also had conversations about issues around logging - that means create dates, modification dates etc.

> The one second precision in timestamps is already a problem. It's perfectly possible for multiple systems to pass many scheduling messages within the space of a second.

>> As an aside, I'm considering writing a draft which documents a variation of what is in the PR.

>> 

>> 

>> 

>>>    Format Definition:

   This parameter is defined by the following notation:

       subsecond-param = "SUBSECOND" "=" float
>> 

>> Does it make sense to use the float type here if we have to qualify that its range is (0.0, 1.0)?  We could just use 

>> "." 1*DIGIT

>> 

>> 

>>>    Example:

       DTSTART;SUBSECOND=0.0123:20111205T040506
>>> 
>>> 
>>> On Mon, Dec 21, 2020, at 2:03 PM, Ken Murchison wrote:
>>>> 

>>>> On 12/21/20 7:54 AM, Robert Stepanek wrote:
>>>>> On Mon, Dec 21, 2020, at 1:42 PM, Ken Murchison wrote:
>>>>>> On 12/21/20 7:31 AM, Robert Stepanek wrote:
>>>>>>> As noted in my previous email: we already agreed to not set the complete timestamp in the FRACTIONAL parameter value. 
>>>>>>> 
>>>>>>> Instead we will set a SUBSECONDS parameter which will be defined to a FLOAT value with MUST be positive and less than 1.0.
>>>>>> OK, but if it MUST be positive, don't we still have the issue that Mike brought up regarding rounding?  Or we will state that the property value MUST NOT be rounded up.

>>>>> 
>>>>> It MUST NOT be rounded, because any client aware of SUBSECONDS would then calculate with a wrong value. The SUBSECONDS parameter only defines the fractional seconds part.
>>>> 

>>>> OK.  WFM

>>>> -- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
>>>> 
>>>> _______________________________________________
>>>> 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
>>> 
>> -- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC
>> 
>> _______________________________________________
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
> 

--98521c6b6269433db161e9e295f247b3
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable


I thought =
we had reversed the FRACTIONAL idea earlier this year, but probably I am=
 not remembering that right. In any case, it's great to continue that co=
nversation because it seems clear that neither approach currently covers=
 all of our requirements.

If there is =
demand for subsecond precision in iCalendar in addition to what we need =
for JSCalendar, then a separate draft looks like the right next step to =
me. This is then also the place where we define the FRACTIONAL or SUBSEC=
OND or other parameters, in addition to how to deal with recurrences. Th=
e JSCalendar mapping can then build on that.

Cheers,
Robert



 
On Mon, Dec 21, 2020, at 8:51 PM=
, Michael Douglass wrote:

On 12/21/20 14:45=
, Ken Murchison wrote:

On 12/21/20 10:31 AM, Robert Stepanek
        wrote:
I have updated the RFC=
 draft on Github. Here is the
          excerpt, I appreciate any feedback:

2.1.  SUBSECOND parameter

   Parameter name:  SUBSECOND

   Purpose:  To specify fractional seconds for time values and
      durations.

   Description:  This parameter MAY be specified on properties of type
      DATE-TIME, DURATION and TIME.  It MUST be a FLOAT value less than
      1.0 and MUST NOT be negative.  Implementations MUST ignore
      presence of the SUBSECOND parameter on RECURRENCE-ID properties
      when determining recurrence overrides.
This last sentence could be a problem if we ever have support
        for sub-seconds in RRULEs.  In fact, there is a PR in libic=
al
        for adding support for recurrences with millisecond precision.&n=
bsp;
        In this case, the SUBSECOND parameter on RECURRENCE-ID would be
        critical in determining the correct instance to override.
True - the smart grid people have been asking for the s=
ame and
      they use recurrences also. RDATE, EXDATE as well. Possibly
      anywhere there's a date-time.
I've also had conversation=
s about issues around logging - that
      means create dates, modification dates etc.
The one seco=
nd precision in timestamps is already a problem. It's
      perfectly possible for multiple systems to pass many scheduling
      messages within the space of a second.
=
As an aside, I'm considering writing a draft which documents a
        variation of what is in the PR.


=

   Format Definition:

   This parameter is defined by the following notation:

       subsecond-param =3D "SUBSECOND" "=3D" float

Does it make sense to use the float type here if we have =
to
        qualify that its range is (0.0, 1.0)?  We could just use 
"." 1*DIG=
IT


   Exam=
ple:

       DTSTART;SUBSECOND=3D0.0123:20111205T040506


On Mon, Dec 21, 2020, at 2:03 PM, Ken Murc=
hison wrote:
=


On 12/21/20 7:54 AM, Rob=
ert
            Stepanek wrote:
On Mon, D=
ec 21, 2020, at 1:42 PM, Ken Murchison wrote:
On 12/21/20 7:31 AM,
                Robert Stepanek wrote:
As noted in my previous email: we already agreed to
                  not set the complete timestamp in the FRACTIONAL
                  parameter value. 

Instead=
 we will set a SUBSECONDS parameter which
                  will be defined to a FLOAT value with MUST be positive=

                  and less than 1.0.
OK, but if=
 it MUST be positive, don't we still have the
                issue that Mike brought up regarding rounding?  Or =
we
                will state that the property value MUST NOT be rounded
                up.

It MUST NOT =
be rounded, because any client aware of
              SUBSECONDS would then calculate with a wrong value. The
              SUBSECONDS parameter only defines the fractional seconds
              part.

OK.  WFM
--=20
Kenneth Murchison
Senior Software Developer
Fastmail US LLC

_______________________________________________
=

calsify mailing list



__________________________________________=
_____
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify

--=20=

Kenneth Murchison
Senior Software Developer
Fastmail US LLC

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

____________________________________________=
___
calsify mailing list



--98521c6b6269433db161e9e295f247b3--


From nobody Tue Dec 22 12:27:46 2020
Return-Path: 
X-Original-To: calsify@ietf.org
Delivered-To: calsify@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 826353A1289; Tue, 22 Dec 2020 12:27:44 -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: barryleiba@computer.org, calext-chairs@ietf.org, calsify@ietf.org, mglt.ietf@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160866886445.8702.11526366210039941036@ietfa.amsl.com>
Date: Tue, 22 Dec 2020 12:27:44 -0800
Archived-At: 
Subject: [calsify] calext - New Meeting Session Request for IETF 110
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, 22 Dec 2020 20:27:45 -0000

A new meeting session request has just been submitted by Daniel Migault, a Chair of the calext working group.


---------------------------------------------------------
Working Group Name: Calendaring Extensions
Area Name: Applications and Real-Time Area
Session Requester: Daniel Migault


Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 20
Conflicts to Avoid: 
 Chair Conflict: ace tls add saag  homenet ipsecme dprive drip jmap extra







People who must be present:
  Barry Leiba
  Daniel Migault
  Bron Gondwana

Resources Requested:

Special Requests:
  
---------------------------------------------------------



From nobody Tue Dec 29 10:34:20 2020
Return-Path: 
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87063A0657; Tue, 29 Dec 2020 10:34:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level: 
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi3itrmN142Z; Tue, 29 Dec 2020 10:34:16 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9603A0688; Tue, 29 Dec 2020 10:34:12 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0BTIY3Zi007628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Dec 2020 13:34:08 -0500
Date: Tue, 29 Dec 2020 10:34:03 -0800
From: Benjamin Kaduk 
To: Michael Douglass 
Cc: The IESG , draft-ietf-calext-eventpub-extensions@ietf.org,  calext-chairs@ietf.org, calsify@ietf.org
Message-ID: <20201229183403.GZ89068@kduck.mit.edu>
References: <155908852723.25806.3708247030243239163.idtracker@ietfa.amsl.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
Archived-At: 
Subject: Re: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-eventpub-extensions-13: (with DISCUSS and COMMENT)
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Dec 2020 18:34:19 -0000

Hi Michael,

An only somewhat less delayed counter-response, inline.

On Fri, Oct 16, 2020 at 02:35:10PM -0400, Michael Douglass wrote:
> A rather delayed reply to your original message:
> 
> Thank you for the suggestions.
> 
> I'll submit a version 16 to refresh the draft and, I hope, fix the 
> remaining issues
> 
> Note that I'd like in particular some feedback on the security/privacy 
> section.
> 
> On 5/28/19 20:08, Benjamin Kaduk via Datatracker wrote:
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-calext-eventpub-extensions-13: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > I want to talk some about the redefinition of SOURCE.  While I agree
> > that the original definition's applicability is more narrow than it
> > needs to be, that doesn't seem to be enough to convince me that there's
> > enough justification to make it so broad as to provide vcard information
> > about a participant or an event link-back, as opposed to just the
> > canonical source of updates for a given object/component.  I must
> > apologize for having essentially not done a search of the WG discussion
> > archives for this topic, and pointers into the archive could help to
> > convince me that this redefinition is a stable, interoperable, and
> > backwards-compatible choice.
> 
> This one I fixed with version 14. My comment and your reply at the time was:
> 
> > On this particular issue I've come round to agreeing with the points
> > made here and in other messages. As an alternative i was considering
> > suggesting dropping the VALUE=TEXT. Having a vcard inline can always be
> > handled with a data uri.
> >
> > However, it seems to me that I can come closer to the intent by using
> > the STRUCTURED-DATA property - it is intended to provide supporting data
> > and of course there's no backwards compatibility issues.
> >
> > Does this seem an appropriate way forward?
> Your reply...
> > It seems appropriate to me (with the caveat that I am not a domain expert
> > here).
> 
> >
> > The example in Section 5.4:
> >
> >       STRUCTURED-DATA;FMTTYPE=application/ld+json;
> >        SCHEMA="https://schema.org/FlightReservation";
> >        ENCODING=BASE64;VALUE=BINARY:Zm9vYmFy
> >
> > contains an inline value that doesn't seem to decode to a valid
> > FlightReservation JSON object.
> You were correct - fixed the example in version 14
> >
> > Perhaps I'm misreading, but the ABNF in Section 7.6 does not seem to
> > allow for an explicit VALUE=TEXT parameter to be given, and the
> > description does not list TEXT as the default value type.  (I note that
> > the listed example does include VALUE=TEXT, causing this to rise to a
> > Discuss-level internal inconsistency.)
> This I missed - updated ABNF to make VALUE=TEXT required
> >
> > Similarly, the examples in Section 8.1 seem incomplete, since they omit
> > the REQUIRED dtstamp and uid properties.
> In v16 I made dtstamp optional. It is only needed for scheduling. Added 
> UID to the examples.

Thanks for these; I think we're all set on the Discuss front, now, and I'll
update my ballot position in the datatracker after I send this message.

> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 3
> >
> >     The properties defined here can all reference external meta-data
> >     which may be used by applications to provide enhanced value to users.
> >
> > This sentence seems to raise my hackles for two reasons: (1) it reads
> > like marketing copy and not a technical specification, and (2) it calls
> > to mind analogies to all the privacy-harming technologies that have
> > become pervasive in HTML mail and the web ecosystem: tracking pixels,
> > call-home URLs, etc..  While I agree that loading remote content can be
> > helpful, it is definitely a dual-use technology; I appreciate that the
> > privacy considerations attempt to cover the risks of remote content.
> > Perhaps there is additional room to nod to those risks at this point in
> > the document.
> OK - toned it down a bit and added a caution.

Thanks; the new formulation is much easier on my eyes.

> >     Using STRUCTURED-LOCATION, information about a number of interesting
> >     locations can be communicated, for example, address, region, country,
> >     postal code as well as other informations such as the parking,
> >     restaurants and the venue.  [...]
> >
> > nit: "the parking" is incomplete; perhaps "parking availability"?
> > nit: "restaurants" is also incomplete; perhaps "nearby restaurants"?
> >
> >                             In social calendaring it is often important
> >     to identify the active participants in the event, for example a
> >     school sports team, and the inactive participants, for example the
> >     parents.
> >
> > I share the directorate reviewer's confusion as to what "social
> > calendaring" is.
> Added a section to describe what was meant
> >
> > Section 3.1.1
> >
> >              In addition, there will be sponsorship information for
> >     sponsors of the event and perhaps paid sponsorship properties
> >     essentially advertising local establishments.
> >
> > I'm not sure how much precedent the IETF has for facilitating
> > advertising as a specific goal.
> 
> The IETF - like many organizations - welcomes sponsorship and provides 
> advertising:
> 
> https://ietf.org/about/support/meeting-sponsorship/
> 
> Having the opportunity to highlight that information is useful to event 
> organizers.
> 
> >
> > Section 3.1.2.1
> >
> >     A meeting may have 10 attendees non of which are co-located.  The
> >
> > nit: s/non/none/
> >
> >     current ATTENDEE property does not allow for the addition of such
> >     meta-data.  The PARTICIPANT property allows attendees to specify
> >     their location.
> >
> > nit: PARTICIPANT is a component, not a property.
> Fixed:
> >
> > Section 4
> >
> > Please be more concrete about what actually is changing, e.g., the
> > addition of participantc to eventc/todoc/journalc, as well as the more
> > obvious incremental addition to the properties' ABNF.
> > Making the reader cross-reference to RFC 5545 for each ABNF production is
> > rather unfriendly.
> Added comments to the ABNF
> >
> > Section 5.2
> >
> > Is a video remote conferencing facility assumed to also provide audio
> > functionality?
> >
> > Section 5.3
> >
> > nit: "lowest level of ordering" is perhaps ambiguous (though the
> > subsequent clarification is not); I'd suggest just "as being ordered
> > last".
> >
> >     Example uses:  The ORDER may be applied to the PARTICIPANT-TYPE
> >        property to indicate the relative importance of the participant,
> >        for example as a sponsor or a performer.  For example, ORDER=1
> >        could define the principal performer or soloist.
> >
> > side note: It's not very clear to me that it's going to be possible to
> > assign a complete ordering to all participants once events start getting
> > complicated.  There is the option of just leaving a single low-priority
> > "everybody else" bucket and not worrying too hard, but this feels like
> > something easy that gets a quick win but will not be a full solution.
> > (Which, to be clear, is not necessarily bad.)
> >
> > Section 5.5
> >
> > While I'm sympathetic to not actually putting a full HTML styled
> > description in the example, I'd suggest at least putting in the closing
> >  tag.
> Done.
> >
> > Section 7.1
> >
> > nit: is there a reason for active participants to be taking a "role" but
> > inactive ones taking a "part"?
> no -p changed
> >
> > Section 7.3
> >
> > It's not clear to me when one would attach an alternative representation
> > to a STYLED-DESCRIPTION rather than just adding the other representation
> > as another STYLED-DESCRIPTION in its own right.  Presumably this just
> > means I'm not an iCalendar expert, but maybe there is something more
> > subtle going on here.
> >
> > Section 7.4
> >
> > Do we want a reference to RFC 7986 again for the LABEL parameter?
> Added a bunch
> >
> >        When used in a component the value of this property provides
> >        information about the event venue or of related services such as
> >        parking, dining, stations etc..
> >
> > Does this hold universally for all components (e.g., even PARTICIPANT) or
> > only some of them?
> >
> > I don't understand all the discussion about the "Use of the related
> > parameter", which is presumably just my lack of familiarity with
> > iCalendar in general.  But it's surprising that we'd have to worry about
> > timezones and such for events/todos related to a structured *location*.
> This is to align with jscalendar
> >
> > Section 7.5
> >
> >       strucewaval   = ( uri / text )
> >
> > "strucewaval" seems like a typo and does not appear elsewhere in the
> > document.
> It was - corrected
> >
> > Section 8.1
> >
> >     Conformance:  This component can be specified multiple times in a
> >        "VEVENT", "VTODO", "VJOURNAL", or "VFREEBUSY" calendar component.
> >
> >     Description:  This component provides information about a participant
> >        in an event, task or poll.  [...]
> >
> > Why do these two lists have different cardinality?
> Changed wording
> >
> >     Privacy Issues:  When a LOCATION is supplied it provides information
> >        about the location of a participant at a given time or times.
> >        This may represent an unacceptable privacy risk for some
> >        participants.  User agents MUST NOT include this information
> >        without informing the participant.
> >
> > How is this "informing" supposed to work when the participant is not a
> > human (e.g., an organizational SPONSOR or a sports team)?
> >
> > Also, it seems likely that there may be attributes (parameters) other
> > than location that a given individual may not wish to be disclosed, or
> > at least disclosed globally.
> I've added a comment in the privacy section and referred to that. Could 
> you take a look at that please?

Yes, the new privacy (and security) considerations are much-improved!
(Unrelated to this particular comment,) I would suggest one other
improvement: currently we just say that "any network access of the URI data
can be tracked", which as a phrase suggests to me that the tracking occurs
"in the network", but of course the remote endpoint hosting the referenced
resource will have a very authoritative view of who is accessing it and
when.  So perhaps "can be tracked both by a network observer and by the
entity hosting the remote resource" (or similar)?

> > In the last example:
> >
> >                       BEGIN: PARTICIPANT
> >                       SOURCE;FMTTYPE=text/vcard;
> >
> > this last semicolon should be a colon?
> Gone as a result of other changes
> >
> >                        http://dir.example.com/vcard/contacts/contact1.vcf
> >                       PARTICIPANT-TYPE:CONTACT
> >                       DESCRIPTION:A contact:
> >
> > The last colon here is superflous?
> >
> >                       END:PARTICIPANT
> Yes
> >
> > Section 8.2
> >
> > It's not entirely clear to me that we need this much discussion about
> > schedulable PARTICPANTs -- can't we get most of the way with the
> > status quo of ATTENDEE properties being schedulable, and just noting
> > that for such ATTENDEEs, the matching PARTICIPANT may have additional
> > (e.g., location) information?
> We lack a place in the 5545 spec for the SEQUENCE and DTSTAMP for the 
> attendee. I wanted to point out this particular use.
> >
> > Section 9.1
> >
> > This example seems to illustrate a weakness of STRUCTURED-LOCATION,
> > namely that it relies upon the human readaing the LABEL parameter to
> > understand what type of relationship the location has to the event.  It
> > seems that calendaring software would be able to present a better
> > interface if there was some structured information available about the
> > type of location, as well as the freeform string of the label.
> That's the point of the LOCTYPE parameter
> >
> > Section 9.2
> >
> > The time gap between DTSTAMP and CREATED is rather large; is that
> > intended?
> No - all the dates are getting old - refreshed them
> >
> > It might also be helpful to give some indication of the meeting room
> > where the event is nominally occurring, so as to make the "At home"
> > location more clearly a remote location.
> >
> > Section 10
> >
> > Potential additional security considerations: the target of the
> > CALENDAR-ADDRESS URLs may have access control on them, and not all
> > recipients of the property may be authorized to access the referenced
> > calendar.  Such access control is properly a matter for the owner of the
> > calendar in question, but it may still be appropriate to mention it
> > here.
> >
> >     Security considerations relating to the "ATTACH" property, as
> >     described in [RFC5545], are applicable to the "STRUCTURED-DATA"
> >     property.
> >
> > I had a quick look in RFC 5545, and neither the labelled Security
> > Considerations section nor any mention of "ATTACH" (with quotes) seemed
> > to cover such security considerations.  What am I missing?
> You are correct. I used a variant of the wording for managed attachments.
> >     When processing HTML content applications need to be aware of the
> >     many security and privacy issues as described in the IANA
> >     considerations section of [W3C.REC-html51-20171003]
> >
> > nits: this needs at least a comma after "content", and possibly another
> > comma before "as described".
> >
> > Section 11
> >
> > There may be some privacy considerations relating to the ORDER
> > parameter, as it provides an indication of some entity (the
> > organizer's?) perception of the relative importance of other
> > participants.
> >
> >     The addition of location information to the new participant component
> >     provides information about the location of participants at a given
> >     time.
> >
> > We probably should go a little further and note that this may facilitate
> > tracking of individuals or malicious actions targeted against them at
> > the known location/time pair.
> I've added more text and aligned this to some extent with jscalendar.

As mentioned above, I do appreciate the added text, but it doesn't seem to
capture my intended point here.  Specifically, calendaring rather
intrinsically has the property that it provides information about a future
time when a given individual will be at a particular location, which could
enable further (targeted) attacks against that individual.  Most other
sources of tracking information about people are retrospective, not
future-looking, so I wanted to have this aspect emphasized.

Thanks again for the updates!

-Ben


From nobody Tue Dec 29 11:18:58 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 931E33A089C; Tue, 29 Dec 2020 11:18:54 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Benjamin Kaduk via Datatracker 
To: "The IESG" 
Cc: draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org, calsify@ietf.org, Daniel Migault , daniel.migault@ericsson.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk 
Message-ID: <160926953451.18847.18350091640255494614@ietfa.amsl.com>
Date: Tue, 29 Dec 2020 11:18:54 -0800
Archived-At: 
Subject: [calsify] Benjamin Kaduk's No Objection on draft-ietf-calext-eventpub-extensions-16: (with COMMENT)
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, 29 Dec 2020 19:18:56 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-calext-eventpub-extensions-16: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing my Discuss points!

The new FlightReservation in §5.4 looks much more plausible; thanks.  I
guess I shouldn't complain that the dates are in 2017...

Section 5.1

While I can't fault the move from param-value to [list of quoted
string], I don't remember what the motivation was for that change.

Section 6.2

   If there is a related ATTENDEE proeprty then all parameters must

nit: s/proeprty/property/

Section 7.2

   For backwards compatibility wuth existing clients and servers when
   used to schedule events and tasks the ATTENDEE property MUST be used
   to specify the sheduling parameters as defined for that property.

nit: s/sheduling/scheduling/

   For other, future uses the CALENDAR-ADDRESS property MUST be used to
   specify those parameters.

I trust the responsible AD to ensure that this new requirement has
received the appropriate level of (WG and community) review.

Section 9

Thanks for the updates to the Security Considerations; they're a big
help!  I did make one further suggested improvement in my response
to my previous ballot's email thread.

Appendix B

At least some of the new versions are in 2020, not 2019




From nobody Tue Dec 29 12:39: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 B28973A09C5; Tue, 29 Dec 2020 12:39:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xSWE2ASlp09; Tue, 29 Dec 2020 12:39:40 -0800 (PST)
Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (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 0D3D73A09C3; Tue, 29 Dec 2020 12:39:39 -0800 (PST)
Received: by mail-qv1-xf35.google.com with SMTP id l7so6887477qvt.4; Tue, 29 Dec 2020 12:39:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=Q1kAmfgDBJvpytZiLZnTh7w4Qkr8ylhOeyZOOxPH8fk=; b=jyNKaYt//IrOxej+ntdgBxfIxbmQj4R+djRZo2vIIjzEop4W91+1YFa6WEEsZHtI85 4AFz0lsRelRV/vpNaunwdIC6dgt7WNl9bcC/Oixru/huE50Jll3ei7FFScWzvvqdHAM1 ojFHx0hvyfkkNDZgvobrN6KKTFa0Cf2MrbyStLox60TVTsfmHu05k9sp/0V9ZQIkr2Qr gwZ+8Q6Efn/mUMv1MBSOpvAHQNIJrUIPbQ0mbYTvKWB94QV8YgLN6N1R+0Q5GLU3NcmD qumVuSOePoEZSsrFpC7lNTDkI7KDBfc8i3UURDYkn9eIiM12pdGSZgsB0iu40aPGgKS0 MAxQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Q1kAmfgDBJvpytZiLZnTh7w4Qkr8ylhOeyZOOxPH8fk=; b=gZXnibyD9GPyUFBEXW7DiFac8QhTSY1lW5sF1T1oNAazBY2Z2aIsISLHf0vX6uLLlZ CIPH7LVCK9qucOkbtgQmA73Ugzkco6roj55/BDFOai0DGYxYP0xwOPqGfDIhCnpD+f8x CoGwKVf/NFdj4fgWIEwtqYCngO/uA1tcifmjTza30hC2HESwajxrDodgphjs48LfLpfU bn7Wz0qs1JG3Qa4kjid2R6jnY6m8T2QtWYEKL0YZCxJuPbIwqhfHXAYy4z9XXQ9+RH6X t82w1feHowKbt+Zpo7i/ng6yOT6ZOpGodjapSu/avYU/tDba7vheKihy4sJCK1rgoXBG Jo5Q==
X-Gm-Message-State: AOAM530Y25472JFILlsWyG6h97J52gMbRN9V2g+HUQaqK7II5KNUZc3k vfjTh8iTZlRGvezLa0NTxiK9KwUQb/PByg==
X-Google-Smtp-Source: ABdhPJwCqdbN3kPzehOTFsLhAfDXuwJh7z9aYKV1cAVmwmheNrUtUkMuovi9e6YF8TX9NMmhTAo9tg==
X-Received: by 2002:a05:6214:2b2:: with SMTP id m18mr52710008qvv.40.1609274378597;  Tue, 29 Dec 2020 12:39:38 -0800 (PST)
Received: from MacBook-Pro-2019.local (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id s19sm22262013qta.35.2020.12.29.12.39.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Dec 2020 12:39:37 -0800 (PST)
To: Benjamin Kaduk 
Cc: The IESG , draft-ietf-calext-eventpub-extensions@ietf.org,  calext-chairs@ietf.org, calsify@ietf.org
References: <155908852723.25806.3708247030243239163.idtracker@ietfa.amsl.com>  <20201229183403.GZ89068@kduck.mit.edu>
From: Michael Douglass 
Message-ID: <8a7f12ad-8903-9bc5-9482-8e6cc1fd02a4@gmail.com>
Date: Tue, 29 Dec 2020 15:39:36 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <20201229183403.GZ89068@kduck.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-eventpub-extensions-13: (with DISCUSS and COMMENT)
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Dec 2020 20:39:42 -0000

Thanks Benjamin.

I'm in the process of producing a new draft with fixes to some points 
raised by Barry and others.

Further comments on your suggestions...

On 12/29/20 13:34, Benjamin Kaduk wrote:
> Hi Michael,
>
> ...

> Thanks for these; I think we're all set on the Discuss front, now, and I'll
> update my ballot position in the datatracker after I send this message.
That's grerat.
> ...
>> I've added a comment in the privacy section and referred to that. Could
>> you take a look at that please?
> Yes, the new privacy (and security) considerations are much-improved!
> (Unrelated to this particular comment,) I would suggest one other
> improvement: currently we just say that "any network access of the URI data
> can be tracked", which as a phrase suggests to me that the tracking occurs
> "in the network", but of course the remote endpoint hosting the referenced
> resource will have a very authoritative view of who is accessing it and
> when.  So perhaps "can be tracked both by a network observer and by the
> entity hosting the remote resource" (or similar)?
I'll take a look
> ...
>
> We probably should go a little further and note that this may facilitate
> tracking of individuals or malicious actions targeted against them at
> the known location/time pair.
>> I've added more text and aligned this to some extent with jscalendar.
> As mentioned above, I do appreciate the added text, but it doesn't seem to
> capture my intended point here.  Specifically, calendaring rather
> intrinsically has the property that it provides information about a future
> time when a given individual will be at a particular location, which could
> enable further (targeted) attacks against that individual.  Most other
> sources of tracking information about people are retrospective, not
> future-looking, so I wanted to have this aspect emphasized.

Good point and happy to do so. Events of late have served to make me 
more concerned about privacy issues.

I guess it's a bit of a side issue but I'm pretty convinced that these 
are more protocol issues than data schema and representation. For 
example, it's undeniably (I believe) a good thing to have a place to 
store the expected location of an attendee. It's also a good thing for 
an organizer to be able to have that information when trying to come up 
with a good meeting time.

However, it's not a good thing for the organizer to have free access to 
that information without the attendee being aware of how it is to be 
used and stored and shared. Those issues are related to how we design 
protocols and services. I'm pretty much convinced that the client/server 
model is inherently unsafe and a more peer-to-peer model is the only 
safe approach. Given our always online world I believe we can build 
those services without handing over the data to 3rd parties (who then 
wittingly or unwittingly hand them on to 4th, 5th etc parties).


> Thanks again for the updates!
>
> -Ben


From nobody Thu Dec 31 13:11:30 2020
Return-Path: 
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54823A0B5A; Thu, 31 Dec 2020 13:11:29 -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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utBnyygrumIy; Thu, 31 Dec 2020 13:11:27 -0800 (PST)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 B03243A0B58; Thu, 31 Dec 2020 13:11:26 -0800 (PST)
Received: by mail-qt1-x82e.google.com with SMTP id a6so13492100qtw.6; Thu, 31 Dec 2020 13:11:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=WfHlJciXYV9zypQ7sp3pgvU5uZiyzBJQDD9eylW1Heo=; b=gcHr+F3jmbKdSFr/2OZhubjqnuXJYGbdKj1CgmOMUHHCMmBw/98vmOFdMhNyKa0dsh 5UNmfJQietdLLNSiJS/lc152vLnSWe1c6+VEUh3CpkD9EDn0h1FiM+CZusm8GrVxGFTx ClX9HQ4SjcY0+dldoLgoi37u2f4/R/M394al7Q0uyVaba4Jvts4C3C5mpEg0VYuAxFiC tcc7NKI3pC/m5ZnQDVKJsTzTxTKybuIIKgS0Nt0RmLwhwFGSWJjAIV2rG331T6HR5+di lpbnDOcUxGVjtYiasy7YMFkB+8h9DKIwEn/J7QTKK1S2Fz+3PlTpLSi2UbpsG0SXdssl XFkw==
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-language; bh=WfHlJciXYV9zypQ7sp3pgvU5uZiyzBJQDD9eylW1Heo=; b=OeyMrDt1POudfrq7xBksf4Lq7ZMoDHibUtCCAx5S8RRQ5y/oq5JdtbXqv2GQCDNVM6 BkXCYXrMNWZWx6EO2bd0gd8cbXImvSqagjzffdIDplW2iw9rCmv4gxBGUOdXflu+1COT LumodGNSKYvj33+nSze/LYMtaLjeL3r4foGrkEHzh07aRmRdHLjj5WqYVDjSKvaOfdQC 5dxy5oiogrK5tJmJqEv2rpevyxFun7C/a3GIl2Py7plH0dEqvBWrq9qoLsmygFi2YT9i 03lTtSSYgyhMB+hQISSR4DKclOljP7a6uC5lZMkl3Pn0THAUro1CJDETQbmzbtDiGfe9 krFg==
X-Gm-Message-State: AOAM530/o6LAjMTTLwRFPMTlGDdDaaAj8yryt2R/vdCvK/LEUYDBto2S TUv0Ov4MMlHsT5JuRwUpYCDvTgvgLqQlpg==
X-Google-Smtp-Source: ABdhPJwSAr0PgwWktMFJoIdZgFSnW4WmWe5X523e5eNWVgDBOd7/izjPBYAe2Vr0DvXaAuonsKLDUw==
X-Received: by 2002:ac8:1249:: with SMTP id g9mr59928908qtj.377.1609449085289;  Thu, 31 Dec 2020 13:11:25 -0800 (PST)
Received: from [192.168.1.151] (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id c8sm30170859qkc.12.2020.12.31.13.11.23 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Dec 2020 13:11:24 -0800 (PST)
From: Michael Douglass 
To: Barry Leiba , draft-ietf-calext-ical-relations.all@ietf.org
Cc: calsify@ietf.org
References: 
Message-ID: 
Date: Thu, 31 Dec 2020 16:11:22 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------F101E012D70E7848F0A34AC0"
Content-Language: en-US
Archived-At: 
Subject: Re: [calsify] AD review of draft-ietf-calext-ical-relations-05
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Dec 2020 21:11:30 -0000

This is a multi-part message in MIME format.
--------------F101E012D70E7848F0A34AC0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Thanks for your comments: I'll work through them below.

I'll submit an update in a short while.

On 11/19/20 14:08, Barry Leiba wrote:
> Hi, Michael and the working group,
>
> As we discussed the ical-relations doc during the IETF 109 session, I
> though I'd get a jump on the publication request and do an AD review
> now.  Here it is below.
>
> — Section 1 —
>
>     associated meta-data.  These relationships can take the following
>     forms
>
> Nit: That needs a colon at the end of it.
>
>        CATEGORIES are often used for this purpose but are
>        problematic for application developers.
>
> It’s a small thing, but it might be good to briefly say why it’s problematic.

Replaced with

Grouped iCalendar:  iCalendar entities can be related to each other
    as a group.  CATEGORIES are often used for this purpose but are
    problematic for application developers due to their lack of
    consistency and use as a free-form tag.

>
>     Linked:  Entities are linked to each other through typed references.
>
> Can you be a little less terse here, or explain what you mean by
> “typed references” in this context?
How about the following:


> — Section 1.1 —
>
>     and lag values and RELATED-TO is extended to allow URI values.
>
> This particular sentence would benefit from the Oxford comma after “lag values”.
Yes - done
> — Section 1.2 —
>
>     This may be, for example, to identify
>     the tasks associated with a given project without having to
>     communicate the task structure of the project, or, for example, in a
>     package delivery system all tasks associated to a specific package.
>
> Another small suggestion for rephrasing (to avoid the awkward
> repetition of “for example”):
>
> NEW
>     Two examples of how this may be used are to identify the tasks
>     associated with a given project without having to communicate the
>     task structure of the project, and to group all tasks associated to
>     a specific package in a package delivery system.
> END
Thank you - done
> 

— Section 1.3 —
>
>     This more accurately
>     defines what we mean by a category.  It's not the words but the
>     meaning.
>
> Two things here:
> 1. I’m not sure what “this” refers to.  Is it “the name CONCEPT”?  Or
> is it the Simple Knowledge Organization System?
> 2. The sentence “It's not the words but the meaning,” is just sort of
> hanging around without being connected to anything.

Is this better?

The term "concept" more accurately defines what we often
mean by a category. It's not the text string that is important
but the meaning attached to it. For example, the term
"football" can mean very different sports.

> I’d really like to see this paragraph reworded.
>
>     Rather than attempt to add semantics to the current property it
>     seeems best to continue its usage as an informal tag and establish a
>     new property with more constraints.
>
> I think this would be clearer with names on the properties (and one
> "e" fewer in "seems"):
>
> NEW
>     Rather than attempt to add semantics to the existing CATEGORY
>     property, it seems best to continue its usage as an informal tag
>     and to establish a new CONCEPT property with more constraints.
> END
Done.
> — Section 1.4 —
>
>     It is often necessary to relate calendar components.
>
> To what?  To each other?  Something else?  Please say.

Does this work?

It is also often necessary to reference calendar components
in other collections. For example, a VEVENT might refer to
a VTODO from which it was derived.


> — Section 1.6 —
> Please use the new BCP 14 boilerplate and add a normative reference to RFC 8174.
Done.
> — Section 2 —
>
>     UID:  This allows for linking within a single collection and the
>        value is assumed to be another component within that collection.
>
> Why “assumed to be”?  Is this any different to “the value is the UID
> of another component within that collection”?

Changed to:

This allows for linking within a single collection and the value
MUST be another component within that collection.

> For “xpointer”, please be consistent in capitalizing the term.  I
> suggest using “XPointer” here and in Section 6, to match usage in the
> reference doc.
Done
> — Section 3 —
>
>     [RFC5988] defines two forms of relation type, registered and
>     extension.  Registered relation types are added to a registry defined
>     by [RFC5988] while extension relation types are specified as unique
>     unregistered URIs, (at least unregistered in the [RFC5988] registry).
>
> First, RFC 8288 replaced 5988 three years ago; please change to using
> that as the reference.
>
> Second, the parenthetical seems odd.  I suggest, “while extension
> relation types are specified as unique URIs that are not registered in
> the registry.”
>
> Third, I strongly suggest adding section references here.  So the
> result might be this:
>
> NEW
>     [RFC8288] defines two forms of relation type: registered and
>     extension.  Registered relation types are added to the Link
>     Relations registry as specified in Section 2.1.1 of [RFC8288].
>     Extension relation types, defined in Section 2.1.2 of [RFC8288],
>     are specified as unique URIs that are not registered in the registry.
> END
Done
> — Section 4 —
>
>     Relationship parameter type values are defined in section 3.2.15. of
>     [RFC5545].
>
> Nit: remove the dot at the end of “3.2.15” (and capitalize “Section”,
> to be consistent with how we do section references).
Done
> This is probably a good time to pay attention to BCP 178 (RFC 6648) by
> removing the x-name construction from the ABNF (also in Section 5.1).

I ended up reworking this section.

First I realized I didn't have to redefine the parameter anyway - just 
define new values. I broke it into 2 new sections - one defining the 
temporal values and one the rest - simply because the temporal values 
seemed to justify their own section.

>        The GAP parameter specifies the
>        lead or lag time between the predecessor and the successor.
>
> This would benefit from a forward reference: “The GAP parameter,
> defined in Section 5.2, specifies”
done
>        the description of each temporal relationship below we refer to
>        Task-A which contains and controls the relationship and Task-B the
>        target of the relationship.
>
> Nit: this needs commas: “Task-A, which contains and controls the
> relationship, and Task-B, the target”.  (There are a lot of missing
> commas throughout, and I’m not calling them all out; we’ll leave most
> to the RFC Editor.)
I'll take a read through looking for that
> — Section 5.2 —
>
>     Purpose:  To specify the length of the gap, positive or negative
>        between two temporaly related components.
>
> Another example of a missing comma that rates mention: after “negative”.
Thanks
> — Section 7.1 —
>
>        Possible category resources are the various proprietary systems,
>        for example Library of Congress, or an open source derived from
>        something like the dmoz.org data.
>
> dmoz.org died 3.5 years ago; do we really still want to use it as an example?
I have a copy of their categorizations... - but I'll cut it out of this spec
>       conceptparam = *(
>                     ;
>                     ; The following is OPTIONAL,
>                     ; and MAY occur more than once.
>                     ;
>                     (";" other-param)
>                     ;
>                     )
>
> The ABNF already says that it can occur zero or more times, so the
> comment is supefluous.  I think the comments and the nested grouping
> makes this more confusing than helpful, and suggest just changing it
> to this:
>
> NEW
>       conceptparam = *(";" other-param)
> END
Agreed
>
>       SCONCEPT:http://example.com/event-types/sports
>       CONCEPT:http://example.com/event-types/arts/music
>       CONCEPT:http://example.com/task-types/delivery
>
> Is “SCONCEPT” a typo?  (And is there really value in three essentially
> indistinguishable examples?)
Yes and no - removed 2
>
> — Section 7.2 —
>
>       link            = "LINK" linkparam  /
>                         (
>                           ";" "VALUE" "=" "TEXT"
>                           ":" text
>                         )
>                         (
>                           ";" "VALUE" "=" "REFERENCE"
>                           ":" text
>                         )
>                         (
>                           ";" "VALUE" "=" "URI"
>                           ":" uri
>                         )
>                         CRLF
>
> This ABNF doesn’t make any sense.  Are you missing some alternative operators?
>
>       linkparam       = *(
>
>                       ; the following is MANDATORY
>                       ; and MAY occur more than once
>
>                       (";" relparam) /
>
>                       ; the following are MANDATORY
>                       ; but MUST NOT occur more than once
>
>                       (";" fmttypeparam) /
>                       (";" labelparam) /
>                       ; labelparam is defined in ...
>
>                       ; the following is OPTIONAL
>                       ; and MAY occur more than once
>
>                       (";" xparam)
>
>                       )
>
> And there are multiple problems here:
> - Where is labelparam defined?
> - Where is xparam defined?
> - All elements of linkparam are optional, because you use “*”, so how
> can any elements be MANDATORY?
> - The ABNF should make it clear, without comments, whether things are
> optional or mandatory and whether they can appear once or multiple
> times.
>
> Please re-work this ABNF, and get help from an ABNF expert if you need that.

OLD

link            = "LINK" linkparam  /
                   (
                     ";" "VALUE" "=" "TEXT"
                     ":" text
                   )
                   (
                     ";" "VALUE" "=" "REFERENCE"
                     ":" text
                   )
                   (
                     ";" "VALUE" "=" "URI"
                     ":" uri
                   )
                   CRLF


linkparam       = *(

                 ; the following is MANDATORY
                 ; and MAY occur more than once

                 (";" relparam) /

                 ; the following are MANDATORY
                 ; but MUST NOT occur more than once

                 (";" fmttypeparam) /
                 (";" labelparam) /
                 ; labelparam is defined in ...

                 ; the following is OPTIONAL
                 ; and MAY occur more than once

                 (";" xparam)

                 )

NEW

link           = "LINK" linkparam ":"
                    ( text /  ; for VALUE=REFERENCE
                      uri /  ; for VALUE=URI
                      text ) ; for VALUE=TEXT
                  CRLF

linkparam      = ; the elements herein may appear in any order,
                  ; and the order is not significant.

                  (";" "VALUE" "=" ("UID" /
                                    "URI" /
                                    "TEXT"))
                  1*(";" linkrelparam)
                  (";" fmttypeparam)
                  (";" labelparam)
                  *(";" other-param)

END

Also added paragraph providing reference to labelparam

>
> Also, this section is exactly one that *can* benefit from multiple
> examples, each showing a different set of value types and parameters.

Yes. Additionally, the example is incorrect. The abnf doesn't allow for 
a default value type so it should specify VALUE=URI

Also , "The Egg" is a real place. Changed to "The Venue".

>
> — Section 7.3 —
>
>     Description:  The value of this property is a text identifier that
>        allows associated components to be located or retrieved as a
>        whole.  For example all of the events in a travel itinerary would
>        have the same REFID value.
>
> This seems to be more vague than necessary.  May I suggest an update?:
>
> NEW
>     Description:  The value of this property is free-form text that
>        creates an identifier for associated components.  All components
>        that use the same REFID value are associated through that value
>        and can be located or retrieved as a group.  For example, all of
>        the events in a travel itinerary would have the same REFID value,
>        so as to be grouped together.
> END
Done.
> 
     refidparam      = *(
>
>                       ; the following is OPTIONAL
>                       ; and MAY occur more than once
>
>                       (";" xparam)
>
>                       )

Changed to

refidparam      = *(";" other-param)

> Same comment as with conceptparam.  And, again, where is xparam defined?
other-param (and xparam) are defined in 5545. Do we require an explicit 
reference to that spec.
>
> — Section 8.1 —
>
>        definition here extends the definition in Section 3.8.4.5. of
>        [RFC5545]
>
> Also here: remove the dot at the end of the section number.

done. I also added the following paragraph to the description:

To preserve backwards compatibility the value type MUST be UID
when the PARENT, SIBLING or CHILD relationships are specified.

>
> For the ABNF in this section I have the same comments as for the ABNF
> in Section 7.1.  In addition, this defines “relparam”, but “relparam”
> is already defined in Section 5.1.  That needs to be fixed.

Changed the section 5.1 definition to be linkrelparam and changed its name

For related:

OLD

related    = "RELATED-TO" relparam ( ":" text ) /
              (
                ";" "VALUE" "=" "UID"
                ":" uid
              )
              (
                ";" "VALUE" "=" "URI"
                ":" uri
              )
              CRLF

relparam   = *(
             ;
             ; The following are OPTIONAL,
             ; but MUST NOT occur more than once.
             ;
             (";" reltypeparam) /
             (";" gapparam) /
             ;
             ; The following is OPTIONAL,
             ; and MAY occur more than once.
             ;
             (";" other-param)
             ;
             )

NEW

related    = "RELATED-TO" relparam ":"
              ( uid /  ; for VALUE=UID
                uri /  ; for VALUE=URI
                text ) ; for VALUE=TEXT or default
              CRLF

relparam   = ; the elements herein may appear in any order,
              ; and the order is not significant.
              [";" "VALUE" "=" ("UID" /
                                "URI" /
                                "TEXT")]
              [";" reltypeparam]
              [";" gapparam]
              *(";" other-param)

END


>

--------------F101E012D70E7848F0A34AC0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Thanks for your comments: I'll work through them below.

    
I'll submit an update in a short while.

    

    On 11/19/20 14:08, Barry Leiba wrote:

    

      
Hi, Michael and the working group,

As we discussed the ical-relations doc during the IETF 109 session, I
though I'd get a jump on the publication request and do an AD review
now.  Here it is below.

— Section 1 —

   associated meta-data.  These relationships can take the following
   forms

Nit: That needs a colon at the end of it.

      CATEGORIES are often used for this purpose but are
      problematic for application developers.

It’s a small thing, but it might be good to briefly say why it’s problematic.

    

    
Replaced with 

    

    
Grouped iCalendar:  iCalendar entities can be related to each other
   as a group.  CATEGORIES are often used for this purpose but are
   problematic for application developers due to their lack of
   consistency and use as a free-form tag.

    

      

   Linked:  Entities are linked to each other through typed references.

Can you be a little less terse here, or explain what you mean by
“typed references” in this context?

    

    How about the following:
    


    

    

      
— Section 1.1 —

   and lag values and RELATED-TO is extended to allow URI values.

This particular sentence would benefit from the Oxford comma after “lag values”.

    

    Yes - done

    

      
— Section 1.2 —

   This may be, for example, to identify
   the tasks associated with a given project without having to
   communicate the task structure of the project, or, for example, in a
   package delivery system all tasks associated to a specific package.

Another small suggestion for rephrasing (to avoid the awkward
repetition of “for example”):

NEW
   Two examples of how this may be used are to identify the tasks
   associated with a given project without having to communicate the
   task structure of the project, and to group all tasks associated to
   a specific package in a package delivery system.
END

    

    Thank you - done

    

      


— Section 1.3 —

   This more accurately
   defines what we mean by a category.  It's not the words but the
   meaning.

Two things here:
1. I’m not sure what “this” refers to.  Is it “the name CONCEPT”?  Or
is it the Simple Knowledge Organization System?
2. The sentence “It's not the words but the meaning,” is just sort of
hanging around without being connected to anything.

    

    
Is this better?

    
The term "concept" more accurately defines what we often
mean by a category. It's not the text string that is important
but the meaning attached to it. For example, the term
"football" can mean very different sports.

    

      
I’d really like to see this paragraph reworded.

   Rather than attempt to add semantics to the current property it
   seeems best to continue its usage as an informal tag and establish a
   new property with more constraints.

I think this would be clearer with names on the properties (and one
"e" fewer in "seems"):

NEW
   Rather than attempt to add semantics to the existing CATEGORY
   property, it seems best to continue its usage as an informal tag
   and to establish a new CONCEPT property with more constraints.
END

    

    Done.

    

      
— Section 1.4 —

   It is often necessary to relate calendar components.

To what?  To each other?  Something else?  Please say.

    

    
Does this work?

    
It is also often necessary to reference calendar components 
in other collections. For example, a VEVENT might refer to
a VTODO from which it was derived. 

    


    

    

      
— Section 1.6 —
Please use the new BCP 14 boilerplate and add a normative reference to RFC 8174.


    

    Done.

    

      
— Section 2 —

   UID:  This allows for linking within a single collection and the
      value is assumed to be another component within that collection.

Why “assumed to be”?  Is this any different to “the value is the UID
of another component within that collection”?

    

    
Changed to:

    
This allows for linking within a single collection and the value
MUST be another component within that collection.

    

      
For “xpointer”, please be consistent in capitalizing the term.  I
suggest using “XPointer” here and in Section 6, to match usage in the
reference doc.

    

    Done

    

      
— Section 3 —

   [RFC5988] defines two forms of relation type, registered and
   extension.  Registered relation types are added to a registry defined
   by [RFC5988] while extension relation types are specified as unique
   unregistered URIs, (at least unregistered in the [RFC5988] registry).

First, RFC 8288 replaced 5988 three years ago; please change to using
that as the reference.

Second, the parenthetical seems odd.  I suggest, “while extension
relation types are specified as unique URIs that are not registered in
the registry.”

Third, I strongly suggest adding section references here.  So the
result might be this:

NEW
   [RFC8288] defines two forms of relation type: registered and
   extension.  Registered relation types are added to the Link
   Relations registry as specified in Section 2.1.1 of [RFC8288].
   Extension relation types, defined in Section 2.1.2 of [RFC8288],
   are specified as unique URIs that are not registered in the registry.
END


    

    Done

    

      
— Section 4 —

   Relationship parameter type values are defined in section 3.2.15. of
   [RFC5545].

Nit: remove the dot at the end of “3.2.15” (and capitalize “Section”,
to be consistent with how we do section references).

    

    Done

    

      
This is probably a good time to pay attention to BCP 178 (RFC 6648) by
removing the x-name construction from the ABNF (also in Section 5.1).

    

    
I ended up reworking this section.

    
First I realized I didn't have to redefine the parameter anyway -
      just define new values. I broke it into 2 new sections - one
      defining the temporal values and one the rest - simply because the
      temporal values seemed to justify their own section. 

    

    

      
      The GAP parameter specifies the
      lead or lag time between the predecessor and the successor.

This would benefit from a forward reference: “The GAP parameter,
defined in Section 5.2, specifies”

    

    done

    

      
      the description of each temporal relationship below we refer to
      Task-A which contains and controls the relationship and Task-B the
      target of the relationship.

Nit: this needs commas: “Task-A, which contains and controls the
relationship, and Task-B, the target”.  (There are a lot of missing
commas throughout, and I’m not calling them all out; we’ll leave most
to the RFC Editor.)

    

    I'll take a read through looking for that 

    

      
— Section 5.2 —

   Purpose:  To specify the length of the gap, positive or negative
      between two temporaly related components.

Another example of a missing comma that rates mention: after “negative”.

    

    Thanks

    

      
— Section 7.1 —

      Possible category resources are the various proprietary systems,
      for example Library of Congress, or an open source derived from
      something like the dmoz.org data.

dmoz.org died 3.5 years ago; do we really still want to use it as an example?

    

    I have a copy of their categorizations... - but I'll cut it out of
    this spec

    

      
     conceptparam = *(
                   ;
                   ; The following is OPTIONAL,
                   ; and MAY occur more than once.
                   ;
                   (";" other-param)
                   ;
                   )

The ABNF already says that it can occur zero or more times, so the
comment is supefluous.  I think the comments and the nested grouping
makes this more confusing than helpful, and suggest just changing it
to this:

NEW
     conceptparam = *(";" other-param)
END

    

    Agreed

    

      

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

Is “SCONCEPT” a typo?  (And is there really value in three essentially
indistinguishable examples?)

    

    Yes and no - removed 2

    

      

— Section 7.2 —

     link            = "LINK" linkparam  /
                       (
                         ";" "VALUE" "=" "TEXT"
                         ":" text
                       )
                       (
                         ";" "VALUE" "=" "REFERENCE"
                         ":" text
                       )
                       (
                         ";" "VALUE" "=" "URI"
                         ":" uri
                       )
                       CRLF

This ABNF doesn’t make any sense.  Are you missing some alternative operators?

     linkparam       = *(

                     ; the following is MANDATORY
                     ; and MAY occur more than once

                     (";" relparam) /

                     ; the following are MANDATORY
                     ; but MUST NOT occur more than once

                     (";" fmttypeparam) /
                     (";" labelparam) /
                     ; labelparam is defined in ...

                     ; the following is OPTIONAL
                     ; and MAY occur more than once

                     (";" xparam)

                     )

And there are multiple problems here:
- Where is labelparam defined?
- Where is xparam defined?
- All elements of linkparam are optional, because you use “*”, so how
can any elements be MANDATORY?
- The ABNF should make it clear, without comments, whether things are
optional or mandatory and whether they can appear once or multiple
times.

Please re-work this ABNF, and get help from an ABNF expert if you need that.

    

    
OLD

    
link            = "LINK" linkparam  /
                  (
                    ";" "VALUE" "=" "TEXT"
                    ":" text
                  )
                  (
                    ";" "VALUE" "=" "REFERENCE"
                    ":" text
                  )
                  (
                    ";" "VALUE" "=" "URI"
                    ":" uri
                  )
                  CRLF


linkparam       = *(

                ; the following is MANDATORY
                ; and MAY occur more than once

                (";" relparam) /

                ; the following are MANDATORY
                ; but MUST NOT occur more than once

                (";" fmttypeparam) /
                (";" labelparam) /
                ; labelparam is defined in ...

                ; the following is OPTIONAL
                ; and MAY occur more than once

                (";" xparam)

                )


    
NEW

    
link           = "LINK" linkparam ":"
                   ( text /  ; for VALUE=REFERENCE
                     uri /  ; for VALUE=URI
                     text ) ; for VALUE=TEXT
                 CRLF

linkparam      = ; the elements herein may appear in any order,
                 ; and the order is not significant.

                 (";" "VALUE" "=" ("UID" /
                                   "URI" /
                                   "TEXT"))
                 1*(";" linkrelparam)
                 (";" fmttypeparam)
                 (";" labelparam)
                 *(";" other-param)


    
END

    
Also added paragraph providing reference to labelparam

    

    

      

Also, this section is exactly one that *can* benefit from multiple
examples, each showing a different set of value types and parameters.

    

    
Yes. Additionally, the example is incorrect. The abnf doesn't
      allow for a default value type so it should specify VALUE=URI

    
Also , "The Egg" is a real place. Changed to "The Venue".

    

      

— Section 7.3 —

   Description:  The value of this property is a text identifier that
      allows associated components to be located or retrieved as a
      whole.  For example all of the events in a travel itinerary would
      have the same REFID value.

This seems to be more vague than necessary.  May I suggest an update?:

NEW
   Description:  The value of this property is free-form text that
      creates an identifier for associated components.  All components
      that use the same REFID value are associated through that value
      and can be located or retrieved as a group.  For example, all of
      the events in a travel itinerary would have the same REFID value,
      so as to be grouped together.
END

    

    Done.

    

      

     refidparam      = *(

                     ; the following is OPTIONAL
                     ; and MAY occur more than once

                     (";" xparam)

                     )

    

    
Changed to 

    

    
refidparam      = *(";" other-param)


    

      
Same comment as with conceptparam.  And, again, where is xparam defined?

    

    other-param (and xparam) are defined in 5545. Do we require an
    explicit reference to that spec.

    

      

— Section 8.1 —

      definition here extends the definition in Section 3.8.4.5. of
      [RFC5545]

Also here: remove the dot at the end of the section number.

    

    
done. I also added the following paragraph to the description:

    
To preserve backwards compatibility the value type MUST be UID
when the PARENT, SIBLING or CHILD relationships are specified.


    

      

For the ABNF in this section I have the same comments as for the ABNF
in Section 7.1.  In addition, this defines “relparam”, but “relparam”
is already defined in Section 5.1.  That needs to be fixed.

    

    
Changed the section 5.1 definition to be linkrelparam and changed
      its name

    
For related:

    
OLD

    
related    = "RELATED-TO" relparam ( ":" text ) /
             (
               ";" "VALUE" "=" "UID"
               ":" uid
             ) 
             (
               ";" "VALUE" "=" "URI"
               ":" uri
             )
             CRLF

relparam   = *(
            ;
            ; The following are OPTIONAL,
            ; but MUST NOT occur more than once.
            ;
            (";" reltypeparam) /
            (";" gapparam) /
            ;
            ; The following is OPTIONAL,
            ; and MAY occur more than once.
            ;
            (";" other-param)
            ;
            )


    
NEW

    
related    = "RELATED-TO" relparam ":"
             ( uid /  ; for VALUE=UID
               uri /  ; for VALUE=URI
               text ) ; for VALUE=TEXT or default 
             CRLF

relparam   = ; the elements herein may appear in any order,
             ; and the order is not significant.
             [";" "VALUE" "=" ("UID" /
                               "URI" /
                               "TEXT")]
             [";" reltypeparam]
             [";" gapparam]
             *(";" other-param)


    END

    


    

    

      



    

  


--------------F101E012D70E7848F0A34AC0--


From nobody Thu Dec 31 13:38:24 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 6A64B3A0BEF; Thu, 31 Dec 2020 13:38:22 -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, HTML_MESSAGE=0.001, 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 0TvcH8t7-L2n; Thu, 31 Dec 2020 13:38:19 -0800 (PST)
Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com [209.85.167.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 456C33A005C; Thu, 31 Dec 2020 13:38:19 -0800 (PST)
Received: by mail-lf1-f46.google.com with SMTP id o13so46316130lfr.3; Thu, 31 Dec 2020 13:38:19 -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=n0P/4VxY6r2kv8gQHsIeJMe0TmPfNQQLYG2TwtxhDCc=; b=UE4a6tBb177hiZIJ1Vwt1GqXPOdQ5vtVQuooSYyflnwp50P10uQLa2cfxJRxbCmX6T nhJ1abxxNsUXDT9/INIUfBMnonN7/e3OaWhV1JrnL3i/rnz0OI2agw4AhCufL5/tz//M e3c4F08DqdLfRS/29DfEt+629ILAOZj5b6Nq/OerQdLmD/4WFBXUXmJ/+wLO10W4ogzc QVmG85u0zaSsejJANcBG72YuuI5gYgbqKoNF10kcXUBNJhbO5X+oGYw6FLMsIPSd4zQo g4ez6RmzudTpyp54teeGPg4DM9FKyv5LRsBnDdqCOwc5jfNmzP/kUDcN9/xbq4E8D5lV 9Caw==
X-Gm-Message-State: AOAM531I83uPQ1I1f0IwqAR2yGDV/vSxrOJbe8MkoFsj9HPYIYN1R28S saTaMXB1CkG7/2kcO/fdQ/w36Qk9NcyHwo72U1w=
X-Google-Smtp-Source: ABdhPJyXmUxBv6CEwGuILD8Fy3mpKbG+P7oMxfHmPg7EUICSzjapv/O98gA67ePgzrw5/EPKNx3055wNZ3IuO3QpbXY=
X-Received: by 2002:a2e:b047:: with SMTP id d7mr27914353ljl.467.1609450697165;  Thu, 31 Dec 2020 13:38:17 -0800 (PST)
MIME-Version: 1.0
References:  
In-Reply-To: 
From: Barry Leiba 
Date: Thu, 31 Dec 2020 16:38:05 -0500
Message-ID: 
To: Michael Douglass 
Cc: calsify@ietf.org, draft-ietf-calext-ical-relations.all@ietf.org
Content-Type: multipart/alternative; boundary="00000000000016901305b7c97148"
Archived-At: 
Subject: Re: [calsify] AD review of draft-ietf-calext-ical-relations-05
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Dec 2020 21:38:22 -0000

--00000000000016901305b7c97148
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

All this looks good, and thanks.  Post the update when ready.

On your question:

> other-param (and xparam) are defined in 5545. Do we require an
> explicit reference to that spec.

I think =E2=80=9Cxparam=E2=80=9D is not defined there (=E2=80=9Cx-param=E2=
=80=9D is).  And I guess we don=E2=80=99t
have to be explicit, but I think it would help to have a comment that says
where it=E2=80=99s defined, or perhaps a general comment that some items ar=
e
defined in 5545.

Barry

On Thu, Dec 31, 2020 at 4:11 PM Michael Douglass 
wrote:

> Thanks for your comments: I'll work through them below.
>
> I'll submit an update in a short while.
> On 11/19/20 14:08, Barry Leiba wrote:
>
> Hi, Michael and the working group,
>
> As we discussed the ical-relations doc during the IETF 109 session, I
> though I'd get a jump on the publication request and do an AD review
> now.  Here it is below.
>
> =E2=80=94 Section 1 =E2=80=94
>
>    associated meta-data.  These relationships can take the following
>    forms
>
> Nit: That needs a colon at the end of it.
>
>       CATEGORIES are often used for this purpose but are
>       problematic for application developers.
>
> It=E2=80=99s a small thing, but it might be good to briefly say why it=E2=
=80=99s problematic.
>
> Replaced with
>
> Grouped iCalendar:  iCalendar entities can be related to each other
>    as a group.  CATEGORIES are often used for this purpose but are
>    problematic for application developers due to their lack of
>    consistency and use as a free-form tag.
>
>    Linked:  Entities are linked to each other through typed references.
>
> Can you be a little less terse here, or explain what you mean by
> =E2=80=9Ctyped references=E2=80=9D in this context?
>
> How about the following:
>
>
> =E2=80=94 Section 1.1 =E2=80=94
>
>    and lag values and RELATED-TO is extended to allow URI values.
>
> This particular sentence would benefit from the Oxford comma after =E2=80=
=9Clag values=E2=80=9D.
>
> Yes - done
>
> =E2=80=94 Section 1.2 =E2=80=94
>
>    This may be, for example, to identify
>    the tasks associated with a given project without having to
>    communicate the task structure of the project, or, for example, in a
>    package delivery system all tasks associated to a specific package.
>
> Another small suggestion for rephrasing (to avoid the awkward
> repetition of =E2=80=9Cfor example=E2=80=9D):
>
> NEW
>    Two examples of how this may be used are to identify the tasks
>    associated with a given project without having to communicate the
>    task structure of the project, and to group all tasks associated to
>    a specific package in a package delivery system.
> END
>
> Thank you - done
>
> =E2=80=94 Section 1.3 =E2=80=94
>
>    This more accurately
>    defines what we mean by a category.  It's not the words but the
>    meaning.
>
> Two things here:
> 1. I=E2=80=99m not sure what =E2=80=9Cthis=E2=80=9D refers to.  Is it =E2=
=80=9Cthe name CONCEPT=E2=80=9D?  Or
> is it the Simple Knowledge Organization System?
> 2. The sentence =E2=80=9CIt's not the words but the meaning,=E2=80=9D is =
just sort of
> hanging around without being connected to anything.
>
> Is this better?
>
> The term "concept" more accurately defines what we often
> mean by a category. It's not the text string that is important
> but the meaning attached to it. For example, the term
> "football" can mean very different sports.
>
> I=E2=80=99d really like to see this paragraph reworded.
>
>    Rather than attempt to add semantics to the current property it
>    seeems best to continue its usage as an informal tag and establish a
>    new property with more constraints.
>
> I think this would be clearer with names on the properties (and one
> "e" fewer in "seems"):
>
> NEW
>    Rather than attempt to add semantics to the existing CATEGORY
>    property, it seems best to continue its usage as an informal tag
>    and to establish a new CONCEPT property with more constraints.
> END
>
> Done.
>
> =E2=80=94 Section 1.4 =E2=80=94
>
>    It is often necessary to relate calendar components.
>
> To what?  To each other?  Something else?  Please say.
>
> Does this work?
>
> It is also often necessary to reference calendar components
> in other collections. For example, a VEVENT might refer to
> a VTODO from which it was derived.
>
>
> =E2=80=94 Section 1.6 =E2=80=94
> Please use the new BCP 14 boilerplate and add a normative reference to RF=
C 8174.
>
> Done.
>
> =E2=80=94 Section 2 =E2=80=94
>
>    UID:  This allows for linking within a single collection and the
>       value is assumed to be another component within that collection.
>
> Why =E2=80=9Cassumed to be=E2=80=9D?  Is this any different to =E2=80=9Ct=
he value is the UID
> of another component within that collection=E2=80=9D?
>
> Changed to:
>
> This allows for linking within a single collection and the value
> MUST be another component within that collection.
>
> For =E2=80=9Cxpointer=E2=80=9D, please be consistent in capitalizing the =
term.  I
> suggest using =E2=80=9CXPointer=E2=80=9D here and in Section 6, to match =
usage in the
> reference doc.
>
> Done
>
> =E2=80=94 Section 3 =E2=80=94
>
>    [RFC5988] defines two forms of relation type, registered and
>    extension.  Registered relation types are added to a registry defined
>    by [RFC5988] while extension relation types are specified as unique
>    unregistered URIs, (at least unregistered in the [RFC5988] registry).
>
> First, RFC 8288 replaced 5988 three years ago; please change to using
> that as the reference.
>
> Second, the parenthetical seems odd.  I suggest, =E2=80=9Cwhile extension
> relation types are specified as unique URIs that are not registered in
> the registry.=E2=80=9D
>
> Third, I strongly suggest adding section references here.  So the
> result might be this:
>
> NEW
>    [RFC8288] defines two forms of relation type: registered and
>    extension.  Registered relation types are added to the Link
>    Relations registry as specified in Section 2.1.1 of [RFC8288].
>    Extension relation types, defined in Section 2.1.2 of [RFC8288],
>    are specified as unique URIs that are not registered in the registry.
> END
>
> Done
>
> =E2=80=94 Section 4 =E2=80=94
>
>    Relationship parameter type values are defined in section 3.2.15. of
>    [RFC5545].
>
> Nit: remove the dot at the end of =E2=80=9C3.2.15=E2=80=9D (and capitaliz=
e =E2=80=9CSection=E2=80=9D,
> to be consistent with how we do section references).
>
> Done
>
> This is probably a good time to pay attention to BCP 178 (RFC 6648) by
> removing the x-name construction from the ABNF (also in Section 5.1).
>
> I ended up reworking this section.
>
> First I realized I didn't have to redefine the parameter anyway - just
> define new values. I broke it into 2 new sections - one defining the
> temporal values and one the rest - simply because the temporal values
> seemed to justify their own section.
>
>       The GAP parameter specifies the
>       lead or lag time between the predecessor and the successor.
>
> This would benefit from a forward reference: =E2=80=9CThe GAP parameter,
> defined in Section 5.2, specifies=E2=80=9D
>
> done
>
>       the description of each temporal relationship below we refer to
>       Task-A which contains and controls the relationship and Task-B the
>       target of the relationship.
>
> Nit: this needs commas: =E2=80=9CTask-A, which contains and controls the
> relationship, and Task-B, the target=E2=80=9D.  (There are a lot of missi=
ng
> commas throughout, and I=E2=80=99m not calling them all out; we=E2=80=99l=
l leave most
> to the RFC Editor.)
>
> I'll take a read through looking for that
>
> =E2=80=94 Section 5.2 =E2=80=94
>
>    Purpose:  To specify the length of the gap, positive or negative
>       between two temporaly related components.
>
> Another example of a missing comma that rates mention: after =E2=80=9Cneg=
ative=E2=80=9D.
>
> Thanks
>
> =E2=80=94 Section 7.1 =E2=80=94
>
>       Possible category resources are the various proprietary systems,
>       for example Library of Congress, or an open source derived from
>       something like the dmoz.org data.
> dmoz.org died 3.5 years ago; do we really still want to use it as an exam=
ple?
>
> I have a copy of their categorizations... - but I'll cut it out of this
> spec
>
>      conceptparam =3D *(
>                    ;
>                    ; The following is OPTIONAL,
>                    ; and MAY occur more than once.
>                    ;
>                    (";" other-param)
>                    ;
>                    )
>
> The ABNF already says that it can occur zero or more times, so the
> comment is supefluous.  I think the comments and the nested grouping
> makes this more confusing than helpful, and suggest just changing it
> to this:
>
> NEW
>      conceptparam =3D *(";" other-param)
> END
>
> Agreed
>
>      SCONCEPT:http://example.com/event-types/sports
>      CONCEPT:http://example.com/event-types/arts/music
>      CONCEPT:http://example.com/task-types/delivery
>
> Is =E2=80=9CSCONCEPT=E2=80=9D a typo?  (And is there really value in thre=
e essentially
> indistinguishable examples?)
>
> Yes and no - removed 2
>
> =E2=80=94 Section 7.2 =E2=80=94
>
>      link            =3D "LINK" linkparam  /
>                        (
>                          ";" "VALUE" "=3D" "TEXT"
>                          ":" text
>                        )
>                        (
>                          ";" "VALUE" "=3D" "REFERENCE"
>                          ":" text
>                        )
>                        (
>                          ";" "VALUE" "=3D" "URI"
>                          ":" uri
>                        )
>                        CRLF
>
> This ABNF doesn=E2=80=99t make any sense.  Are you missing some alternati=
ve operators?
>
>      linkparam       =3D *(
>
>                      ; the following is MANDATORY
>                      ; and MAY occur more than once
>
>                      (";" relparam) /
>
>                      ; the following are MANDATORY
>                      ; but MUST NOT occur more than once
>
>                      (";" fmttypeparam) /
>                      (";" labelparam) /
>                      ; labelparam is defined in ...
>
>                      ; the following is OPTIONAL
>                      ; and MAY occur more than once
>
>                      (";" xparam)
>
>                      )
>
> And there are multiple problems here:
> - Where is labelparam defined?
> - Where is xparam defined?
> - All elements of linkparam are optional, because you use =E2=80=9C*=E2=
=80=9D, so how
> can any elements be MANDATORY?
> - The ABNF should make it clear, without comments, whether things are
> optional or mandatory and whether they can appear once or multiple
> times.
>
> Please re-work this ABNF, and get help from an ABNF expert if you need th=
at.
>
> OLD
>
> link            =3D "LINK" linkparam  /
>                   (
>                     ";" "VALUE" "=3D" "TEXT"
>                     ":" text
>                   )
>                   (
>                     ";" "VALUE" "=3D" "REFERENCE"
>                     ":" text
>                   )
>                   (
>                     ";" "VALUE" "=3D" "URI"
>                     ":" uri
>                   )
>                   CRLF
>
>
> linkparam       =3D *(
>
>                 ; the following is MANDATORY
>                 ; and MAY occur more than once
>
>                 (";" relparam) /
>
>                 ; the following are MANDATORY
>                 ; but MUST NOT occur more than once
>
>                 (";" fmttypeparam) /
>                 (";" labelparam) /
>                 ; labelparam is defined in ...
>
>                 ; the following is OPTIONAL
>                 ; and MAY occur more than once
>
>                 (";" xparam)
>
>                 )
>
> NEW
>
> link           =3D "LINK" linkparam ":"
>                    ( text /  ; for VALUE=3DREFERENCE
>                      uri /  ; for VALUE=3DURI
>                      text ) ; for VALUE=3DTEXT
>                  CRLF
>
> linkparam      =3D ; the elements herein may appear in any order,
>                  ; and the order is not significant.
>
>                  (";" "VALUE" "=3D" ("UID" /
>                                    "URI" /
>                                    "TEXT"))
>                  1*(";" linkrelparam)
>                  (";" fmttypeparam)
>                  (";" labelparam)
>                  *(";" other-param)
>
> END
>
> Also added paragraph providing reference to labelparam
>
> Also, this section is exactly one that *can* benefit from multiple
> examples, each showing a different set of value types and parameters.
>
> Yes. Additionally, the example is incorrect. The abnf doesn't allow for a
> default value type so it should specify VALUE=3DURI
>
> Also , "The Egg" is a real place. Changed to "The Venue".
>
> =E2=80=94 Section 7.3 =E2=80=94
>
>    Description:  The value of this property is a text identifier that
>       allows associated components to be located or retrieved as a
>       whole.  For example all of the events in a travel itinerary would
>       have the same REFID value.
>
> This seems to be more vague than necessary.  May I suggest an update?:
>
> NEW
>    Description:  The value of this property is free-form text that
>       creates an identifier for associated components.  All components
>       that use the same REFID value are associated through that value
>       and can be located or retrieved as a group.  For example, all of
>       the events in a travel itinerary would have the same REFID value,
>       so as to be grouped together.
> END
>
> Done.
>
>      refidparam      =3D *(
>
>                      ; the following is OPTIONAL
>                      ; and MAY occur more than once
>
>                      (";" xparam)
>
>                      )
>
> Changed to
>
> refidparam      =3D *(";" other-param)
>
> Same comment as with conceptparam.  And, again, where is xparam defined?
>
> other-param (and xparam) are defined in 5545. Do we require an explicit
> reference to that spec.
>
> =E2=80=94 Section 8.1 =E2=80=94
>
>       definition here extends the definition in Section 3.8.4.5. of
>       [RFC5545]
>
> Also here: remove the dot at the end of the section number.
>
> done. I also added the following paragraph to the description:
>
> To preserve backwards compatibility the value type MUST be UID
> when the PARENT, SIBLING or CHILD relationships are specified.
>
> For the ABNF in this section I have the same comments as for the ABNF
> in Section 7.1.  In addition, this defines =E2=80=9Crelparam=E2=80=9D, bu=
t =E2=80=9Crelparam=E2=80=9D
> is already defined in Section 5.1.  That needs to be fixed.
>
> Changed the section 5.1 definition to be linkrelparam and changed its nam=
e
>
> For related:
>
> OLD
>
> related    =3D "RELATED-TO" relparam ( ":" text ) /
>              (
>                ";" "VALUE" "=3D" "UID"
>                ":" uid
>              )
>              (
>                ";" "VALUE" "=3D" "URI"
>                ":" uri
>              )
>              CRLF
>
> relparam   =3D *(
>             ;
>             ; The following are OPTIONAL,
>             ; but MUST NOT occur more than once.
>             ;
>             (";" reltypeparam) /
>             (";" gapparam) /
>             ;
>             ; The following is OPTIONAL,
>             ; and MAY occur more than once.
>             ;
>             (";" other-param)
>             ;
>             )
>
> NEW
>
> related    =3D "RELATED-TO" relparam ":"
>              ( uid /  ; for VALUE=3DUID
>                uri /  ; for VALUE=3DURI
>                text ) ; for VALUE=3DTEXT or default
>              CRLF
>
> relparam   =3D ; the elements herein may appear in any order,
>              ; and the order is not significant.
>              [";" "VALUE" "=3D" ("UID" /
>                                "URI" /
>                                "TEXT")]
>              [";" reltypeparam]
>              [";" gapparam]
>              *(";" other-param)
>
> END
>
>
>

--00000000000016901305b7c97148
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


All this looks good, and thanks.=C2=A0 Post the upda=
te when ready.

On your q=
uestion:

> other-param (and xpar=
am) are defined in 5545. Do we require an
> explicit reference t=
o that spec.

I think =E2=80=9Cxparam=E2=80=9D is n=
ot defined there (=E2=80=9Cx-param=E2=80=9D is).=C2=A0 And I guess we don=
=E2=80=99t have to be explicit, but I think it would help to have a comment=
 that says where it=E2=80=99s defined, or perhaps a general comment that so=
me items are defined in 5545.

Barry

On Thu, Dec 31, 2020 at 4:11 PM Michael Douglass <=
;mikeadouglass=
@gmail.com> wrote:

 =20
   =20
 =20
  

    
Thanks for your comments: I'll work through them below.

    
I'll submit an update in a short while.

    

    On 11/19/20 14:08, Barry Leiba wrote:

    

      
Hi, Michael and the working grou=
p,

As we discussed the ical-relations doc during the IETF 109 session, I
though I'd get a jump on the publication request and do an AD review
now.  Here it is below.

=E2=80=94 Section 1 =E2=80=94

   associated meta-data.  These relationships can take the following
   forms

Nit: That needs a colon at the end of it.

      CATEGORIES are often used for this purpose but are
      problematic for application developers.

It=E2=80=99s a small thing, but it might be good to briefly say why it=E2=
=80=99s problematic.

    

    
Replaced with 

    

    
Grouped iCalend=
ar:  iCalendar entities can be related to each other
   as a group.  CATEGORIES are often used for this purpose but are
   problematic for application developers due to their lack of
   consistency and use as a free-form tag.

    

      
   Linked:  Entities are linked =
to each other through typed references.

Can you be a little less terse here, or explain what you mean by
=E2=80=9Ctyped references=E2=80=9D in this context?

    

    How about the following:
    


    

    

      
=E2=80=94 Section 1.1 =E2=80=94

   and lag values and RELATED-TO is extended to allow URI values.

This particular sentence would benefit from the Oxford comma after =E2=80=
=9Clag values=E2=80=9D.

    

    Yes - done

    

      
=E2=80=94 Section 1.2 =E2=80=94

   This may be, for example, to identify
   the tasks associated with a given project without having to
   communicate the task structure of the project, or, for example, in a
   package delivery system all tasks associated to a specific package.

Another small suggestion for rephrasing (to avoid the awkward
repetition of =E2=80=9Cfor example=E2=80=9D):

NEW
   Two examples of how this may be used are to identify the tasks
   associated with a given project without having to communicate the
   task structure of the project, and to group all tasks associated to
   a specific package in a package delivery system.
END

    

    Thank you - done

    

      
=E2=80=94 Section 1.3 =E2=80=94

   This more accurately
   defines what we mean by a category.  It's not the words but the
   meaning.

Two things here:
1. I=E2=80=99m not sure what =E2=80=9Cthis=E2=80=9D refers to.  Is it =E2=
=80=9Cthe name CONCEPT=E2=80=9D?  Or
is it the Simple Knowledge Organization System?
2. The sentence =E2=80=9CIt's not the words but the meaning,=E2=80=9D i=
s just sort of
hanging around without being connected to anything.

    

    
Is this better?

    
The term "=
concept" more accurately defines what we often
mean by a category. It's not the text string that is important
but the meaning attached to it. For example, the term
"football" can mean very different sports.

    

      
I=E2=80=99d really like to see t=
his paragraph reworded.

   Rather than attempt to add semantics to the current property it
   seeems best to continue its usage as an informal tag and establish a
   new property with more constraints.

I think this would be clearer with names on the properties (and one
"e" fewer in "seems"):

NEW
   Rather than attempt to add semantics to the existing CATEGORY
   property, it seems best to continue its usage as an informal tag
   and to establish a new CONCEPT property with more constraints.
END

    

    Done.

    

      
=E2=80=94 Section 1.4 =E2=80=94

   It is often necessary to relate calendar components.

To what?  To each other?  Something else?  Please say.

    

    
Does this work?

    
It is also often necessary to refe=
rence calendar components=20
in other collections. For example, a VEVENT might refer to
a VTODO from which it was derived. 

    


    

    

      
=E2=80=94 Section 1.6 =E2=80=94
Please use the new BCP 14 boilerplate and add a normative reference to RFC =
8174.


    

    Done.

    

      
=E2=80=94 Section 2 =E2=80=94

   UID:  This allows for linking within a single collection and the
      value is assumed to be another component within that collection.

Why =E2=80=9Cassumed to be=E2=80=9D?  Is this any different to =E2=80=9Cthe=
 value is the UID
of another component within that collection=E2=80=9D?

    

    
Changed to:

    
This allows for=
 linking within a single collection and the value
MUST be another component within that collection.

    

      
For =E2=80=9Cxpointer=E2=80=9D, =
please be consistent in capitalizing the term.  I
suggest using =E2=80=9CXPointer=E2=80=9D here and in Section 6, to match us=
age in the
reference doc.

    

    Done

    

      
=E2=80=94 Section 3 =E2=80=94

   [RFC5988] defines two forms of relation type, registered and
   extension.  Registered relation types are added to a registry defined
   by [RFC5988] while extension relation types are specified as unique
   unregistered URIs, (at least unregistered in the [RFC5988] registry).

First, RFC 8288 replaced 5988 three years ago; please change to using
that as the reference.

Second, the parenthetical seems odd.  I suggest, =E2=80=9Cwhile extension
relation types are specified as unique URIs that are not registered in
the registry.=E2=80=9D

Third, I strongly suggest adding section references here.  So the
result might be this:

NEW
   [RFC8288] defines two forms of relation type: registered and
   extension.  Registered relation types are added to the Link
   Relations registry as specified in Section 2.1.1 of [RFC8288].
   Extension relation types, defined in Section 2.1.2 of [RFC8288],
   are specified as unique URIs that are not registered in the registry.
END


    

    Done

    

      
=E2=80=94 Section 4 =E2=80=94

   Relationship parameter type values are defined in section 3.2.15. of
   [RFC5545].

Nit: remove the dot at the end of =E2=80=9C3.2.15=E2=80=9D (and capitalize =
=E2=80=9CSection=E2=80=9D,
to be consistent with how we do section references).

    

    Done

    

      
This is probably a good time to =
pay attention to BCP 178 (RFC 6648) by
removing the x-name construction from the ABNF (also in Section 5.1).

    

    
I ended up reworking this section.

    
First I realized I didn't have to redefine the parameter anyway =
-
      just define new values. I broke it into 2 new sections - one
      defining the temporal values and one the rest - simply because the
      temporal values seemed to justify their own section. 

    

    

      
      The GAP parameter specifie=
s the
      lead or lag time between the predecessor and the successor.

This would benefit from a forward reference: =E2=80=9CThe GAP parameter,
defined in Section 5.2, specifies=E2=80=9D

    

    done

    

      
      the description of each te=
mporal relationship below we refer to
      Task-A which contains and controls the relationship and Task-B the
      target of the relationship.

Nit: this needs commas: =E2=80=9CTask-A, which contains and controls the
relationship, and Task-B, the target=E2=80=9D.  (There are a lot of missing
commas throughout, and I=E2=80=99m not calling them all out; we=E2=80=99ll =
leave most
to the RFC Editor.)

    

    I'll take a read through looking for that 

    

      
=E2=80=94 Section 5.2 =E2=80=94

   Purpose:  To specify the length of the gap, positive or negative
      between two temporaly related components.

Another example of a missing comma that rates mention: after =E2=80=9Cnegat=
ive=E2=80=9D.

    

    Thanks

    

      
=E2=80=94 Section 7.1 =E2=80=94

      Possible category resources are the various proprietary systems,
      for example Library of Congress, or an open source derived from
      something like the dmoz.org data.

dmoz.org died 3.5 years ago; do we really still want to use it as an=
 example?

    

    I have a copy of their categorizations... - but I'll cut it out of
    this spec

    

      
     conceptparam =3D *(
                   ;
                   ; The following is OPTIONAL,
                   ; and MAY occur more than once.
                   ;
                   (";" other-param)
                   ;
                   )

The ABNF already says that it can occur zero or more times, so the
comment is supefluous.  I think the comments and the nested grouping
makes this more confusing than helpful, and suggest just changing it
to this:

NEW
     conceptparam =3D *(";" other-param)
END

    

    Agreed

    

      
     SCONCEPT:http://example.com/event-types/sports
     CONCEPT:http://example.com/event-types/ar=
ts/music
     CONCEPT:http://example.com/task-types/delive=
ry

Is =E2=80=9CSCONCEPT=E2=80=9D a typo?  (And is there really value in three =
essentially
indistinguishable examples?)

    

    Yes and no - removed 2


    

      
=E2=80=94 Section 7.2 =E2=80=94

     link            =3D "LINK" linkparam  /
                       (
                         ";" "VALUE" "=3D" &q=
uot;TEXT"
                         ":" text
                       )
                       (
                         ";" "VALUE" "=3D" &q=
uot;REFERENCE"
                         ":" text
                       )
                       (
                         ";" "VALUE" "=3D" &q=
uot;URI"
                         ":" uri
                       )
                       CRLF

This ABNF doesn=E2=80=99t make any sense.  Are you missing some alternative=
 operators?

     linkparam       =3D *(

                     ; the following is MANDATORY
                     ; and MAY occur more than once

                     (";" relparam) /

                     ; the following are MANDATORY
                     ; but MUST NOT occur more than once

                     (";" fmttypeparam) /
                     (";" labelparam) /
                     ; labelparam is defined in ...

                     ; the following is OPTIONAL
                     ; and MAY occur more than once

                     (";" xparam)

                     )

And there are multiple problems here:
- Where is labelparam defined?
- Where is xparam defined?
- All elements of linkparam are optional, because you use =E2=80=9C*=E2=80=
=9D, so how
can any elements be MANDATORY?
- The ABNF should make it clear, without comments, whether things are
optional or mandatory and whether they can appear once or multiple
times.

Please re-work this ABNF, and get help from an ABNF expert if you need that=
.

    

    
OLD

    
link            =3D "LINK&quo=
t; linkparam  /
                  (
                    ";" "VALUE" "=3D" "T=
EXT"
                    ":" text
                  )
                  (
                    ";" "VALUE" "=3D" "R=
EFERENCE"
                    ":" text
                  )
                  (
                    ";" "VALUE" "=3D" "U=
RI"
                    ":" uri
                  )
                  CRLF


linkparam       =3D *(

                ; the following is MANDATORY
                ; and MAY occur more than once

                (";" relparam) /

                ; the following are MANDATORY
                ; but MUST NOT occur more than once

                (";" fmttypeparam) /
                (";" labelparam) /
                ; labelparam is defined in ...

                ; the following is OPTIONAL
                ; and MAY occur more than once

                (";" xparam)

                )


    
NEW

    
link           =3D "LINK"=
; linkparam ":"
                   ( text /  ; for VALUE=3DREFERENCE
                     uri /  ; for VALUE=3DURI
                     text ) ; for VALUE=3DTEXT
                 CRLF

linkparam      =3D ; the elements herein may appear in any order,
                 ; and the order is not significant.

                 (";" "VALUE" "=3D" ("UI=
D" /
                                   "URI" /
                                   "TEXT"))
                 1*(";" linkrelparam)
                 (";" fmttypeparam)
                 (";" labelparam)
                 *(";" other-param)


    
END

    
Also added paragraph providing reference to labelparam

    

    

      
Also, this section is exactly on=
e that *can* benefit from multiple
examples, each showing a different set of value types and parameters.

    

    
Yes. Additionally, the example is incorrect. The abnf doesn't
      allow for a default value type so it should specify VALUE=3DURI

    
Also , "The Egg" is a real place. Changed to "The Ven=
ue".

    

      
=E2=80=94 Section 7.3 =E2=80=94

   Description:  The value of this property is a text identifier that
      allows associated components to be located or retrieved as a
      whole.  For example all of the events in a travel itinerary would
      have the same REFID value.

This seems to be more vague than necessary.  May I suggest an update?:

NEW
   Description:  The value of this property is free-form text that
      creates an identifier for associated components.  All components
      that use the same REFID value are associated through that value
      and can be located or retrieved as a group.  For example, all of
      the events in a travel itinerary would have the same REFID value,
      so as to be grouped together.
END

    

    Done.

    

      
     refidparam      =3D *(

                     ; the following is OPTIONAL
                     ; and MAY occur more than once

                     (";" xparam)

                     )

    

    
Changed to 

    

    
refidparam      =3D *(";"=
; other-param)


    

      
Same comment as with conceptpara=
m.  And, again, where is xparam defined?

    

    other-param (and xparam) are defined in 5545. Do we require an
    explicit reference to that spec.

    

      
=E2=80=94 Section 8.1 =E2=80=94

      definition here extends the definition in Section 3.8.4.5. of
      [RFC5545]

Also here: remove the dot at the end of the section number.

    

    
done. I also added the following paragraph to the description:

    
To preserve bac=
kwards compatibility the value type MUST be UID
when the PARENT, SIBLING or CHILD relationships are specified.


    

      
For the ABNF in this section I h=
ave the same comments as for the ABNF
in Section 7.1.  In addition, this defines =E2=80=9Crelparam=E2=80=9D, but =
=E2=80=9Crelparam=E2=80=9D
is already defined in Section 5.1.  That needs to be fixed.

    

    
Changed the section 5.1 definition to be linkrelparam and changed
      its name

    
For related:

    
OLD

    
related    =3D "RELATED-TO&qu=
ot; relparam ( ":" text ) /
             (
               ";" "VALUE" "=3D" "UID&qu=
ot;
               ":" uid
             )=20
             (
               ";" "VALUE" "=3D" "URI&qu=
ot;
               ":" uri
             )
             CRLF

relparam   =3D *(
            ;
            ; The following are OPTIONAL,
            ; but MUST NOT occur more than once.
            ;
            (";" reltypeparam) /
            (";" gapparam) /
            ;
            ; The following is OPTIONAL,
            ; and MAY occur more than once.
            ;
            (";" other-param)
            ;
            )


    
NEW

    
related    =3D "RELATED-TO&qu=
ot; relparam ":"
            =C2=A0( uid /  ; for VALUE=3DUID
               uri /  ; for VALUE=3DURI
               text ) ; for VALUE=3DTEXT or default=20
             CRLF

relparam   =3D ; the elements herein may appear in any order,
             ; and the order is not significant.
             [";" "VALUE" "=3D" ("UID&qu=
ot; /
                               "URI" /
                               "TEXT")]
             [";" reltypeparam]
             [";" gapparam]
             *(";" other-param)


    END

    


    

    

      

    

  







--00000000000016901305b7c97148--


From nobody Thu Dec 31 13:59:37 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 54D2D3A0C12; Thu, 31 Dec 2020 13:59:29 -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: 7.24.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: calsify@ietf.org
Message-ID: <160945196930.22062.1265221056603729215@ietfa.amsl.com>
Date: Thu, 31 Dec 2020 13:59:29 -0800
Archived-At: 
Subject: [calsify] I-D Action: draft-ietf-calext-ical-relations-06.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, 31 Dec 2020 21:59: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           : Support for iCalendar Relationships
        Author          : Michael Douglass
	Filename        : draft-ietf-calext-ical-relations-06.txt
	Pages           : 17
	Date            : 2020-12-31

Abstract:
   This specification updates RELATED-TO defined in [RFC5545] and
   introduces new iCalendar properties LINK, CONCEPT and REFID to allow
   better linking and grouping of iCalendar components and related data.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-calext-ical-relations/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-calext-ical-relations-06
https://datatracker.ietf.org/doc/html/draft-ietf-calext-ical-relations-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-ical-relations-06


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/