From nobody Sat May 5 19:02:29 2018 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 2EE821201FA; Sat, 5 May 2018 19:02:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152557214808.26780.14458282737730003696@ietfa.amsl.com> Date: Sat, 05 May 2018 19:02:28 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2018 02:02:28 -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-04.txt Pages : 19 Date : 2018-05-05 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-calext-ical-relations-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-ical-relations-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 5 19:20:37 2018 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 BA47C1201FA; Sat, 5 May 2018 19:20:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152557323572.26681.1466351398334547861@ietfa.amsl.com> Date: Sat, 05 May 2018 19:20:35 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-06.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2018 02:20:36 -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 : Event Publishing Extensions to iCalendar Author : Michael Douglass Filename : draft-ietf-calext-eventpub-extensions-06.txt Pages : 31 Date : 2018-05-05 Abstract: This specification introduces a number of new iCalendar properties and components which are of particular use for event publishers and in social networking. This specification also defines a new STRUCTURED-DATA property for iCalendar [RFC5545] to allow for data that is directly pertinent to an event or task to be included with the calendar data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-06 https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-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/ From nobody Mon May 7 07:21:39 2018 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 9291B1205D3 for ; Mon, 7 May 2018 07:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Bkp-1hgs0vhN for ; Mon, 7 May 2018 07:21:36 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 DF1FF1252BA for ; Mon, 7 May 2018 07:21:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525702893; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jK/Ub42dp4lqBCMAdvlbsvyO2z7yFfcMYM7gUCjl2g8=; b=FjxOHpyGvLG/lLM/KnqQUN3J6yQUvkM71lCeqKReJ5W+9hyZVumBeToKmbAu23Hm tsibCE72XnzCLr1AczubriKhUi6810YPknZ68sgV4f79j0bnYjQ3WQgSlSKNtUyY ZywbVuFoOc+hndrat2wXpQK0sfc5l4VT+zrQatnt2lk=; X-AuditID: c6180641-1d3ff70000003b41-ba-5af060ed4c78 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 2E.CB.15169.DE060FA5; Mon, 7 May 2018 16:21:33 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0382.000; Mon, 7 May 2018 10:21:32 -0400 From: Daniel Migault To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" CC: "calsify@ietf.org" Thread-Topic: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-06.txt Thread-Index: AQHT5ODV0OVk+MJmwUyU+G6x1qP8SaQkUiPA Date: Mon, 7 May 2018 14:21:32 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFD1@eusaamb107.ericsson.se> References: <152557323572.26681.1466351398334547861@ietfa.amsl.com> In-Reply-To: <152557323572.26681.1466351398334547861@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.223] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyuXRPlO7bhA9RBpfXWllsetHMarFk13Nm iw93cx2YPZYs+ckUwBjFZZOSmpNZllqkb5fAlfGo7zd7wS3Bivb7j5gaGLfzdTFyckgImEjc PPubvYuRi0NI4CijxLmfp1ggnGWMEv3felhBqtgEjCTaDvWzg9giAjkSd38/ZQGxmQU0JV7s fA9WIywQKHGtcyoTRE2QxLXPl6HqjSQ2XL7FDGKzCKhIvJu8FKyXV8BX4tfGl2wgtpCAs8S7 K3vB6jkFXCSe3zgLFmcUEJP4fmoNE8QucYlbT+YzQVwtILFkz3lmCFtU4uXjf6wQtrLEo4U/ GCHqdSQW7P7EBmFrSyxb+JoZYq+gxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsoqRo7S4ICc3 3chwEyMwGo5JsDnuYNzb63mIUYCDUYmH93nghygh1sSy4srcQ4wSHMxKIrxsykAh3pTEyqrU ovz4otKc1OJDjNIcLErivOc8eaOEBNITS1KzU1MLUotgskwcnFINjDHR1y5kX9/eGaxxQFno lGZ2T4Gbf+TF1wW3DNb2Hl2fze/Fv6m9I+/ONkXvT72vP/XnZDTdzFfQLNA6d+qliWf3kpXB evFTmTiyDzz+L+xluEV5SYmY2JysyjupB884PF73JJ1zMVtjZsXEpolNORyXJV7aBn4+Jxvn GbL4q3xFabVte9p8JZbijERDLeai4kQA6WRQsYICAAA= Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-06.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 14:21:37 -0000 Hi everyone,=20 Pleas find the new version of draft-ietf-calext-eventpub-extensions. The do= cument was in WGLC. As discussed in London, it would be helpful to get feed= backs to understand if the draft is ready to be submit to the IESG. We wou= ld appreciate comments/supports on the mailing list by May 15. Yours,=20 Daniel=20 -----Original Message----- From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Saturday, May 05, 2018 10:21 PM To: i-d-announce@ietf.org Cc: calsify@ietf.org Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : Event Publishing Extensions to iCalendar Author : Michael Douglass Filename : draft-ietf-calext-eventpub-extensions-06.txt Pages : 31 Date : 2018-05-05 Abstract: This specification introduces a number of new iCalendar properties and components which are of particular use for event publishers and in social networking. This specification also defines a new STRUCTURED-DATA property for iCalendar [RFC5545] to allow for data that is directly pertinent to an event or task to be included with the calendar data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-06 https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions= -06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-calext-eventpub-extensions-0= 6 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From nobody Mon May 7 07:22:57 2018 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 2FC2C124239 for ; Mon, 7 May 2018 07:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 KwvT81Oc3phH for ; Mon, 7 May 2018 07:22:54 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 3F7BC1205D3 for ; Mon, 7 May 2018 07:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1525702973; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6VyHGRl+fwy8LjglTQr686+enQ2ulR25HzSKX1150mE=; b=bCW+wn21kFWEuKJ/62g1zfFOyTgdDe7BQKuviFAoHn+NttnvAzJULvKl7yS6Sr93 CTY0EXK92mGHLl2/oGpSrCop7Cd8usf+tfViqzneyiIOWNmo9LzghxkLDVC9l8GJ wHBTJkVZHeft7qUQSe5qKUsQqO8FKA1VKoPmQW1tFoI=; X-AuditID: c6180641-1ebff70000003b41-91-5af0613d3ea3 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 60.0C.15169.D3160FA5; Mon, 7 May 2018 16:22:53 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0382.000; Mon, 7 May 2018 10:22:52 -0400 From: Daniel Migault To: "calsify@ietf.org" Thread-Topic: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt Thread-Index: AQHT5N5NPyhulRv540O6O2+BmKg8M6QkU7Fg Date: Mon, 7 May 2018 14:22:51 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFF3@eusaamb107.ericsson.se> References: <152557214808.26780.14458282737730003696@ietfa.amsl.com> In-Reply-To: <152557214808.26780.14458282737730003696@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.223] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyuXRPuK5t4ocog8ZrWhabXjSzOjB6LFny kymAMYrLJiU1J7MstUjfLoEr49HWBUwFd/grNsz4zNzA+JGni5GDQ0LAROLb9+wuRi4OIYGj jBLvfq1kg3CWMUq03H7N2MXIycEmYCTRdqifHcQWEdCU2H21hxXEFhbwkph9ax0LRNxb4t6R A1A1RhJvHy5hArFZBFQkvpw7zAiyjFfAV+LOF26QsJCAi8TB1iawVk4BV4nzk86CrWIUEJP4 fmoNWCuzgLjErSfzwWwJAQGJJXvOM0PYohIvH/9jhbCVJR4t/MEIUa8jsWD3JzYIW1ti2cLX YPW8AoISJ2c+YZnAKDILydhZSFpmIWmZhaRlASPLKkaO0uKCnNx0I8NNjMDwPibB5riDcW+v 5yFGAQ5GJR7e54EfooRYE8uKK3MPMUpwMCuJ8LIpA4V4UxIrq1KL8uOLSnNSiw8xSnOwKInz nvPkjRISSE8sSc1OTS1ILYLJMnFwSjUwzr7T9a1vn7T7Y45wXfPXK3hklQs+OW5bOfPJwSvi z4TLporzZS9VffXCS/BF0pHws4YH5LbVyPMeOhg9Q3Ni+SO9WVO9RexXlAXu9D/Ndqk7ZlPH 6e0rn52ROOTn1GhUULhegecb07ZDpmeNFdzPrv1gY3lKa3aFxssLRV8bTqpOd3G7M2WrvxJL cUaioRZzUXEiAGYdCdRrAgAA Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 14:22:56 -0000 Hi everyone,=20 Pleas find the new version of draft-ietf-calext-ical-relations. As discusse= d in London, it would be helpful to get feed backs to understand if the dra= ft is for a WGLC. We would appreciate comments/supports on the mailing list= by May 15. Yours,=20 Daniel=20 -----Original Message----- From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Saturday, May 05, 2018 10:02 PM To: i-d-announce@ietf.org Cc: calsify@ietf.org Subject: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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-04.txt Pages : 19 Date : 2018-05-05 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-calext-ical-relations-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-calext-ical-relations-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From nobody Mon May 7 10:29:07 2018 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 023B412785F for ; Mon, 7 May 2018 10:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 g3HIBgoVrmEW for ; Mon, 7 May 2018 10:29:01 -0700 (PDT) Received: from maple.morsemedia.net (maple.morsemedia.net [72.51.43.139]) (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 5DD9112D95A for ; Mon, 7 May 2018 10:29:01 -0700 (PDT) Received: from 47-208-67-174.erkacmtk02.res.dyn.suddenlink.net ([47.208.67.174]:41459 helo=[192.168.0.218]) by maple.morsemedia.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1fFjwY-000G2O-LR; Mon, 07 May 2018 10:28:58 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Dave.Thewlis@calconnect.org In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFD1@eusaamb107.ericsson.se> Date: Mon, 7 May 2018 10:28:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <522C3C7B-3BF0-403E-957D-5A9F92ED644F@calconnect.org> References: <152557323572.26681.1466351398334547861@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFD1@eusaamb107.ericsson.se> To: "calsify@ietf.org" X-Mailer: Apple Mail (2.3445.6.18) X-MorseMedia-MailScanner-Information: Please contact the ISP for more information X-MorseMedia-MailScanner-ID: 1fFjwY-000G2O-LR X-MorseMedia-MailScanner: Found to be clean X-MorseMedia-MailScanner-SpamCheck: X-MorseMedia-MailScanner-From: dave.thewlis@calconnect.org X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - maple.morsemedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Get-Message-Sender-Via: maple.morsemedia.net: authenticated_id: dave@dcta.com X-Authenticated-Sender: maple.morsemedia.net: dave@dcta.com Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-06.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 17:29:04 -0000 I strongly support submitting this draft to the IESG. =20 Best, Dave Thewlis > On May 7, 2018, at 07:21, Daniel Migault = wrote: >=20 > Hi everyone,=20 >=20 > Pleas find the new version of draft-ietf-calext-eventpub-extensions. = The document was in WGLC. As discussed in London, it would be helpful to = get feed backs to understand if the draft is ready to be submit to the = IESG. We would appreciate comments/supports on the mailing list by May = 15. >=20 > Yours,=20 > Daniel=20 >=20 >=20 >=20 > -----Original Message----- > From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > Sent: Saturday, May 05, 2018 10:21 PM > To: i-d-announce@ietf.org > Cc: calsify@ietf.org > Subject: [calsify] I-D Action: = draft-ietf-calext-eventpub-extensions-06.txt >=20 >=20 > 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. >=20 > Title : Event Publishing Extensions to iCalendar > Author : Michael Douglass > Filename : draft-ietf-calext-eventpub-extensions-06.txt > Pages : 31 > Date : 2018-05-05 >=20 > Abstract: > This specification introduces a number of new iCalendar properties > and components which are of particular use for event publishers and > in social networking. >=20 > This specification also defines a new STRUCTURED-DATA property for > iCalendar [RFC5545] to allow for data that is directly pertinent to > an event or task to be included with the calendar data. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-06 > = https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extension= s-06 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-calext-eventpub-extensions-= 06 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify >=20 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Mon May 7 10:30:27 2018 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 5A7511275AB for ; Mon, 7 May 2018 10:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 mbFvOwnDi2b1 for ; Mon, 7 May 2018 10:30:24 -0700 (PDT) Received: from maple.morsemedia.net (maple.morsemedia.net [72.51.43.139]) (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 C70FB120724 for ; Mon, 7 May 2018 10:30:24 -0700 (PDT) Received: from 47-208-67-174.erkacmtk02.res.dyn.suddenlink.net ([47.208.67.174]:38756 helo=[192.168.0.218]) by maple.morsemedia.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1fFjxs-000G9Q-Ft; Mon, 07 May 2018 10:30:20 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) From: Dave.Thewlis@calconnect.org In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFF3@eusaamb107.ericsson.se> Date: Mon, 7 May 2018 10:30:19 -0700 Cc: "calsify@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <96F21A2D-42E1-4FE3-B9BD-5FA117D6FB16@calconnect.org> References: <152557214808.26780.14458282737730003696@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFF3@eusaamb107.ericsson.se> To: Daniel Migault X-Mailer: Apple Mail (2.3445.6.18) X-MorseMedia-MailScanner-Information: Please contact the ISP for more information X-MorseMedia-MailScanner-ID: 1fFjxs-000G9Q-Ft X-MorseMedia-MailScanner: Found to be clean X-MorseMedia-MailScanner-SpamCheck: X-MorseMedia-MailScanner-From: dave.thewlis@calconnect.org X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - maple.morsemedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - calconnect.org X-Get-Message-Sender-Via: maple.morsemedia.net: authenticated_id: dave@dcta.com X-Authenticated-Sender: maple.morsemedia.net: dave@dcta.com Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 17:30:26 -0000 I support going to WGLC for the ical-relations draft. =20 Best, Dave Thewlis > On May 7, 2018, at 07:22, Daniel Migault = wrote: >=20 > Hi everyone,=20 >=20 > Pleas find the new version of draft-ietf-calext-ical-relations. As = discussed in London, it would be helpful to get feed backs to understand = if the draft is for a WGLC. We would appreciate comments/supports on the = mailing list by May 15. >=20 > Yours,=20 > Daniel=20 >=20 >=20 > -----Original Message----- > From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org > Sent: Saturday, May 05, 2018 10:02 PM > To: i-d-announce@ietf.org > Cc: calsify@ietf.org > Subject: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt >=20 >=20 > 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. >=20 > Title : Support for iCalendar Relationships > Author : Michael Douglass > Filename : draft-ietf-calext-ical-relations-04.txt > Pages : 19 > Date : 2018-05-05 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-calext-ical-relations/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-calext-ical-relations-04 > = https://datatracker.ietf.org/doc/html/draft-ietf-calext-ical-relations-04 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-calext-ical-relations-04 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify >=20 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Mon May 7 14:06:42 2018 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 C12A812D95E for ; Mon, 7 May 2018 14:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=d/GVeLym; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=luUIzMUH 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 ujakPPDCrCv7 for ; Mon, 7 May 2018 14:06:35 -0700 (PDT) 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 31F1E12D7E6 for ; Mon, 7 May 2018 14:06:35 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 83CA1213F1 for ; Mon, 7 May 2018 17:06:34 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute6.internal (MEProxy); Mon, 07 May 2018 17:06:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=waXTbYa0rplVhCxQW xqSeRfCK+CGmPaRNRGqgGRhodk=; b=d/GVeLymRdt0a4gTHyBN6tCUvsA0TnJp0 oTSQ9FiIpXlgJl24UXxjlplO4jbrzUTb3BW/cJOuXa+DJf35rpBpN3JRn9BF22S0 GBVrlgwbiokCAemA47FpP5E6BF91SnAH1tBTEVi7R/DAb12XZIj7vD+jTMd2MRPZ dEuK3pQmxD6/E7gZIPJFzJ8d9mkwBHReEdsY0l2F5cGmdrEB1tsbYuwlIvNvbAKK 4mYM+KdjpFO2rG5BmHx/vsOJadaT8Yp84zS5mZG04+W+rgCcZhLXHcYHr3QElv67 R1mPfOLPxzXsxel0GjZgn7QHicforK2Ir9uw5Y+UAfxm9+xJPIO7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=waXTbY a0rplVhCxQWxqSeRfCK+CGmPaRNRGqgGRhodk=; b=luUIzMUHPaFU/LUYjKtUEV QNXhteIhzFQVP5MpUP2t8J41neBIDmZ6IYkCVAADBwjdiXcfLFcOZzTOENwnNDGO 74N5qHcK/xnYpkgP88AmCGerzv5vGTvqyhpEL4y9s4PisnDqoqUIVXkXfTi2+8j6 vLJR2UBlmOgzwJDztvLbDixUqqNGgsMvNlELFEsoqdZ5A4FiM2tIyZ7SOoZHgfSG foYlAzZsDAEv5NK5a/klq5pT66WZdXdy0Zl0IkuQIaXrUiqrgL6PUDL9NtjsJGNp fXL5UZlPlIFmQ5aBe8yL7SibwC73AvnuF5FJBZvzqJM4Z+lZ+fnF4JUTQLhI2GdQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 219A09E3D4; Mon, 7 May 2018 17:06:34 -0400 (EDT) Message-Id: <1525727193.92702.1363975040.7A7AF0E0@webmail.messagingengine.com> From: Bron Gondwana To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_1525727194927022" X-Mailer: MessagingEngine.com Webmail Interface - ajax-62b61488 References: <152557214808.26780.14458282737730003696@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFF3@eusaamb107.ericsson.se> Date: Tue, 08 May 2018 07:06:33 +1000 In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFF3@eusaamb107.ericsson.se> Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 21:06:41 -0000 This is a multi-part message in MIME format. --_----------=_1525727194927022 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" I've actually read it now - though I admit not at the proof-reading level that might catch every inconsistency! I'm on the train on my way to work. Here's some things I noticed: Section 2 - reference types: I don't know enough about xpointer to know if there should be a security considerations section for the usage of xpointer and access to the surrounding XML environment. Section 7.1 example: SCONCEPT:http://example.com/event-types/sports CONCEPT: http://example.com/event-types/arts/music CONCEPT: http://example.com/task-types/delivery It appears there's a leading S that shouldn't be there on the first example. "SCONCEPT" is not defined nor present anywhere else on the document. Otherwise I'm in favour of this document being progressed to WGLC. Cheers, Bron. On Tue, 8 May 2018, at 00:22, Daniel Migault wrote: > Hi everyone, > > Pleas find the new version of draft-ietf-calext-ical-relations. As > discussed in London, it would be helpful to get feed backs to > understand if the draft is for a WGLC. We would appreciate > comments/supports on the mailing list by May 15.> > Yours, > Daniel > > > -----Original Message----- > From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org> Sent: Saturday, May 05, 2018 10:02 PM > To: i-d-announce@ietf.org > Cc: calsify@ietf.org > Subject: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt> > > 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-04.txt > Pages : 19 > Date : 2018-05-05 > > 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-04 > https://datatracker.ietf.org/doc/html/draft-ietf-calext-ical-relations-04> > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-ical-relations-04> > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org.> > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _________________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > _________________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_1525727194927022 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
I've actually read it now - though I admit not at the proof-reading level that might catch every inconsistency!  I'm on the train on my way to work.  Here's some things I noticed:

Section 2 - reference types:

I don't know enough about xpointer to know if there should be a security considerations section for the usage of xpointer and access to the surrounding XML environment.

Section 7.1 example:

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

It appears there's a leading S that shouldn't be there on the first example. "SCONCEPT" is not defined nor present anywhere else on the document.

Otherwise I'm in favour of this document being progressed to WGLC.

Cheers,

Bron.


On Tue, 8 May 2018, at 00:22, Daniel Migault wrote:
Hi everyone,

Pleas find the new version of draft-ietf-calext-ical-relations. As discussed in London, it would be helpful to get feed backs to understand if the draft is for a WGLC. We would appreciate comments/supports on the mailing list by May 15.

Yours,
Daniel


-----Original Message-----
Sent: Saturday, May 05, 2018 10:02 PM
Subject: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt


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-04.txt
Pages           : 19
Date            : 2018-05-05

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:

There are also htmlized versions available at:

A diff from the previous version is available at:


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:

_______________________________________________
calsify mailing list

_______________________________________________
calsify mailing list

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


--_----------=_1525727194927022-- From nobody Wed May 9 07:08:52 2018 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 206501241FC; Wed, 9 May 2018 07:08:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152587493107.3989.17700727190028501545@ietfa.amsl.com> Date: Wed, 09 May 2018 07:08:51 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-03.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 14:08:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : JSCalendar: A JSON representation of calendar data Authors : Neil Jenkins Robert Stepanek Filename : draft-ietf-calext-jscalendar-03.txt Pages : 51 Date : 2018-05-09 Abstract: This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative to the widely deployed iCalendar data format and to be unambiguous, extendable and simple to process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-03 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 9 07:23:48 2018 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 4C4EF126CE8 for ; Wed, 9 May 2018 07:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 Br0UuhQHBGU3 for ; Wed, 9 May 2018 07:23:45 -0700 (PDT) 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 73009126CD8 for ; Wed, 9 May 2018 07:23:45 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A0CD321B95 for ; Wed, 9 May 2018 10:23:44 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute1.internal (MEProxy); Wed, 09 May 2018 10:23:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=RPYqpzP+cfFHE84qSN5aARPLTE6kA o91pHRaQqVaRug=; b=Lo/SpR3xKdKYhhlBn8FNojuKyZ9mPJ6eCi6MRDTYiqgZM 6tKJn1FJ6kitMnbEWvyY/wYhubcapatjmL41XWfsSjA5ishZ7v8OcKM8TdpzpIgW 6McIqvrUy5CuVXs8BterAeMnHoj/bukwyAllXfx5LAqpJSnW4GqBRpdozcCWYefW DzvCAdCvncVUYkWp9lxnsn1vwMHngDn1pgwdUyzQCqxALd9pr1gXG3O68uBMTP1A HrFMVqUYXSb6Hn1Zw1PsGzOQjVnmfhScVyL1fgE9RQlpPygp0z3mqUqAJPvfdzBY g6ojMoF0xOhqeg46+XZDbpey9TjlaF1fbqAGKH08g== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7B3E5412B; Wed, 9 May 2018 10:23:44 -0400 (EDT) Message-Id: <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> From: Robert Stepanek To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152587582421956032" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 Date: Wed, 09 May 2018 16:23:44 +0200 Archived-At: Subject: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 14:23:47 -0000 This is a multi-part message in MIME format. --_----------=_152587582421956032 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi, I have just submitted version 03[1] of the JSCalendar RFC draft. This version mainly includes updates after implementing the latest spec version in the Cyrus IMAP project. Notable changes are: * *iCalendar Translation*: The section for mapping between JSCalendar iCalendar has been updated, including a new mapping table for the Location object. * *Alert mediaLinks and attachments*: these properties have been redefined from a list of linkIds to a map of Links. That is, alerts now maintain their own set of links, rather than pointing into the enclosing JSCalendar object link map. * *Object ids*: the values for the uid and productId properties must comply with the restrictions of their iCalendar equivalents. The allowed values for JSCalendar object-internal ids are restricted to valid JSON pointer format. * *localizations*: this property and its related requirements have been removed. The reasons for removal are: * It Is unclear if embedding multi-lingual translations in the object is the right solution, as opposed to using either external links or translation APIs. * The risk of getting the various translations out of sync on partial updates is significant. * Mapping localizations between JSCalendar and iCalendar is barely supported with standard properties, increasing the risk of getting out-of-sync data. * If required, localizations can be re-introduced as an extension, once the requirements are better understood. * *htmlDescription*: the mapping for HTML description to iCalendar has been defined to either use the ALTREP parameter (for legacy clients) or the upcoming STYLED-DESCRIPTION property (see eventpub- extensions[2]). * *Location*: the available Location feature values are now aligned with the definition of the CONFERENCE iCalendar property (RFC7986). The location description, URI and coordinates fields are now optional, name and rel have default values. As always, we look forward to any feedback! Cheers, Robert Links: 1. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-03 2. https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions --_----------=_152587582421956032 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi, 

I have just submitted version 03 of the JSCalendar RFC draft. This ve= rsion mainly includes updates after implementing the latest spec version in= the Cyrus IMAP project.

Notable changes are:

  • iCalendar Translation: The section for mapping between JSCal= endar iCalendar has been updated, including a new mapping table for the Loc= ation object.
  • Alert mediaLinks and attachments: these pr= operties have been redefined from a list of linkIds to a map of Links. That= is, alerts now maintain their own set of links, rather than pointing into = the enclosing JSCalendar object link map.
  • Object ids: th= e values for the uid and productId properties must comply with the restrict= ions of their iCalendar equivalents. The allowed values for JSCalendar obje= ct-internal ids are restricted to valid JSON pointer format.
  • localizations: this property and its related requirements have been re= moved. The reasons for removal are:
    • It Is unclear if embedd= ing multi-lingual translations in the object is the right solution, as oppo= sed to using either external links or translation APIs.
    • The ris= k of getting the various translations out of sync on partial updates is sig= nificant.
    • Mapping localizations between JSCalendar and iCalenda= r is barely supported with standard properties, increasing the risk of gett= ing out-of-sync data.
    • If required, localizations can be re-intr= oduced as an extension, once the requirements are better understood.
  • htmlDescription: the mapping for HTML description to iCal= endar has been defined to either use the ALTREP parameter (for legacy clien= ts) or the upcoming STYLED-DESCRIPTION property (see eventpub-extensions= ).
  • Location: the available Location feature values a= re now aligned with the definition of the CONFERENCE iCalendar property (RF= C7986). The location description, URI and coordinates fields are now option= al, name and rel have default values.

As always, we look forward to any feedback!

Cheers,
Robert

--_----------=_152587582421956032-- From nobody Wed May 9 10:07:18 2018 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 548521200F1 for ; Wed, 9 May 2018 10:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 yjSLORxU_-L7 for ; Wed, 9 May 2018 10:07:13 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 9D9B1126E01 for ; Wed, 9 May 2018 10:07:13 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id f5-v6so33247916qth.2 for ; Wed, 09 May 2018 10:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=KdvkP6nEgkcYogiD7ssJgRJxonFugGyXOL2xGqrV6HQ=; b=jiRAbehEQX6kzSxQib6hVbON8Bd0SNo8hZiw758whRJBjUoiFurqFZWQ1oj6cpCBLg XShULVoYhRo/G5EE9+TgzytUFh/O6BjXJS3LWNaXNrrwh6iu/fBBjw22C/bCUkGHVtZH 8KVO6fZyw1dslwgIUGV7E+2cZWNFfN5bJV7T5rfnh7263zrOd7SgrQdzmyyT3U3tYL1O YGweZfQLE5JxtH9sg+pKZSWhgfEbiMsfslhF5lVHY0JHEJcsBW12Oi6CiXLAVRymTEWx oDXGldMZO2zmmyeho6OctrwAX0/aQKLXAbeMoneDN+3A4u4eIpIcGnO8o/xlJGIV1NK0 x+wA== 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=KdvkP6nEgkcYogiD7ssJgRJxonFugGyXOL2xGqrV6HQ=; b=h8J8/vzxkfAyxb0Lt1Bsx7OXPi2sMLpLwyN7tdI7exqqoIBdEuO4IRiPk6ebPtqqdN rwYxgOvlurPsbpUY5YytAIt5FM4PolIsC1jEkkve1FRghQM310NC/7o7oMo2z6QWyGOf kNzMdzJv158Ke4oPtFWLA/OxipnrI0+P/WAIFFB18H7Qk0E7wIIY5jQxyYsZZ5Ksy+98 1JXbgjPVfVab6//34cVLgi9vrn8Q00om7K1rvvHNsw9qZFoltRQxub/PrPMeSu3oZyz5 eapSqYB5vt5qxZN8ne7Vg0Pl9xqOPpmjdVXAZMy6g5rUBu7yRTB7QahI5BvJr2iDoiaO Epew== X-Gm-Message-State: ALQs6tBQLc08Yk+DfJBjvTJqEx1IjzQ9eZIAxWGSI7Io1IZzOVl7tkx5 tCwP8jzzxEPWby+Xe70d4np2iQ== X-Google-Smtp-Source: AB8JxZo40narZm/w5EcvjR58VF1YkrU0692eI1n2ztWzO4HOPhtUsx27KHbrJjD8YrB8LZ/GihIjvg== X-Received: by 2002:a0c:b40b:: with SMTP id u11-v6mr26385097qve.131.1525885632610; Wed, 09 May 2018 10:07:12 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id s192sm319856qke.96.2018.05.09.10.07.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 May 2018 10:07:12 -0700 (PDT) To: calsify@ietf.org References: <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> From: Michael Douglass Message-ID: <96676354-12c5-32f7-443e-eba13d74225f@gmail.com> Date: Wed, 9 May 2018 13:07:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------EEB7F62E96DE3A22AC328344" Content-Language: en-US Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 17:07:16 -0000 This is a multi-part message in MIME format. --------------EEB7F62E96DE3A22AC328344 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit See below On 5/9/18 10:23, Robert Stepanek wrote: > Hi, > > I have just submitted version 03 > of the > JSCalendar RFC draft. This version mainly includes updates after > implementing the latest spec version in the Cyrus IMAP project. > > Notable changes are: > > * *iCalendar Translation*: The section for mapping between > JSCalendar iCalendar has been updated, including a new mapping > table for the Location object. > * *Alert mediaLinks and attachments*: these properties have been > redefined from a list of linkIds to a map of Links. That is, > alerts now maintain their own set of links, rather than pointing > into the enclosing JSCalendar object link map. > * *Object ids*: the values for the uid and productId properties must > comply with the restrictions of their iCalendar equivalents. The > allowed values for JSCalendar object-internal ids are restricted > to valid JSON pointer format. > * *localizations*: this property and its related requirements have > been removed. The reasons for removal are: > o It Is unclear if embedding multi-lingual translations in the > object is the right solution, as opposed to using either > external links or translation APIs. > o The risk of getting the various translations out of sync on > partial updates is significant. > o Mapping localizations between JSCalendar and iCalendar is > barely supported with standard properties, increasing the risk > of getting out-of-sync data. > o If required, localizations can be re-introduced as an > extension, once the requirements are better understood. > Multi-language support is very important - indeed a legal requirement in some places. When publishing events there is no knowledge of the end recipient. It may pass through a number of aggregators and other intermediaries. Delivering one package with all required languages is absolutely the best way. While there is indeed an issue with localizations being out of date that is something for workflow to deal with - pointing to external resources doesn't make that any easier. Sequence numbers can flag the need to check. Translation APIs do a mediocre job - watch the Jimmy Fallon sketch on translating carols to another language and back again After much discussion on how to achieve this in iCalendar it seemed a localization component was the best approach - while that may not happen in iCalendar I had hopes of seeing that appear in jscalendar. Either defining a localization component in iCalendar or simply dropping the localizations on translation (no worse than we are now) is better IMO than dropping the idea in jscalendar > > * *htmlDescription*: the mapping for HTML description to iCalendar > has been defined to either use the ALTREP parameter (for legacy > clients) or the upcoming STYLED-DESCRIPTION property (see > eventpub-extensions > ). > * *Location*: the available Location feature values are now aligned > with the definition of the CONFERENCE iCalendar property > (RFC7986). The location description, URI and coordinates fields > are now optional, name and rel have default values. > > > As always, we look forward to any feedback! > > Cheers, > Robert > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------EEB7F62E96DE3A22AC328344 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

See below


On 5/9/18 10:23, Robert Stepanek wrote:
Hi, 

I have just submitted version 03 of the JSCalendar RFC draft. This version mainly includes updates after implementing the latest spec version in the Cyrus IMAP project.

Notable changes are:

  • iCalendar Translation: The section for mapping between JSCalendar iCalendar has been updated, including a new mapping table for the Location object.
  • Alert mediaLinks and attachments: these properties have been redefined from a list of linkIds to a map of Links. That is, alerts now maintain their own set of links, rather than pointing into the enclosing JSCalendar object link map.
  • Object ids: the values for the uid and productId properties must comply with the restrictions of their iCalendar equivalents. The allowed values for JSCalendar object-internal ids are restricted to valid JSON pointer format.
  • localizations: this property and its related requirements have been removed. The reasons for removal are:
    • It Is unclear if embedding multi-lingual translations in the object is the right solution, as opposed to using either external links or translation APIs.
    • The risk of getting the various translations out of sync on partial updates is significant.
    • Mapping localizations between JSCalendar and iCalendar is barely supported with standard properties, increasing the risk of getting out-of-sync data.
    • If required, localizations can be re-introduced as an extension, once the requirements are better understood.
Multi-language support is very important - indeed a legal requirement in some places.
When publishing events there is no knowledge of the end recipient. It may pass through a number of aggregators and other intermediaries.  Delivering one package with all required languages is absolutely the best way.
While there is indeed an issue with localizations being out of date that is something for workflow to deal with - pointing to external resources doesn't make that any easier. Sequence numbers can flag the need to check.
Translation APIs do a mediocre job - watch the Jimmy Fallon sketch on translating carols to another language and back again

After much discussion on how to achieve this in iCalendar it seemed a localization component was the best approach - while that may not happen in iCalendar I had hopes of seeing that appear in jscalendar. Either defining a localization component in iCalendar or simply dropping the localizations on translation (no worse than we are now) is better IMO than dropping the idea in jscalendar
  • htmlDescription: the mapping for HTML description to iCalendar has been defined to either use the ALTREP parameter (for legacy clients) or the upcoming STYLED-DESCRIPTION property (see eventpub-extensions).
  • Location: the available Location feature values are now aligned with the definition of the CONFERENCE iCalendar property (RFC7986). The location description, URI and coordinates fields are now optional, name and rel have default values.

As always, we look forward to any feedback!

Cheers,
Robert



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

--------------EEB7F62E96DE3A22AC328344-- From nobody Wed May 9 14:31:39 2018 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 23E56129C6B for ; Wed, 9 May 2018 14:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org 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 Rp78JjuQ7gU2 for ; Wed, 9 May 2018 14:31:35 -0700 (PDT) Received: from mailrelay4-1.pub.mailoutpod1-cph3.one.com (mailrelay4-1.pub.mailoutpod1-cph3.one.com [46.30.210.185]) (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 ED916129C51 for ; Wed, 9 May 2018 14:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=XEno+NgL8G5oFt4JW542VdBiEmjETfIzZ6l/ihYYmKY=; b=e8aI15Qc3NU4yjmFwkN2QMJFnsC26pXUxVutyMqrCyfSUOhkaUJhUAR8jyFtpolDfZnyLWQEECoRC dGRgNDkCH6kL+WTEfNCn+q9gbWDyRFYTro1fZk4qjEbxB//bHtDV+cZCcOKoosljvDZ7F87LNbX5NR fxGuxoaPcc6CrHyw= X-HalOne-Cookie: 8b2c3ebc28ddeb12389fce26dd4ba7aacb328672 X-HalOne-ID: 56e44d83-53d0-11e8-bfaf-d0431ea8bb10 Received: from smtp.dmfs.org (unknown [91.47.32.197]) by mailrelay4.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 56e44d83-53d0-11e8-bfaf-d0431ea8bb10; Wed, 09 May 2018 21:31:31 +0000 (UTC) Received: from boss.localdomain (boss [192.168.2.105]) by smtp.dmfs.org (Postfix) with ESMTPSA id E99AB122 for ; Wed, 9 May 2018 23:31:30 +0200 (CEST) To: calsify@ietf.org References: <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> From: Marten Gajda Message-ID: Date: Wed, 9 May 2018 23:31:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------DA0E61BF8C74B8D1F88F2D51" Content-Language: en-US Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2018 21:31:38 -0000 This is a multi-part message in MIME format. --------------DA0E61BF8C74B8D1F88F2D51 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Robert, a few questions came to my mind while scanning the new version, see below. *Section 3.2.3. Duration* Is |PT3600S| a valid duration string? According to the ABNF it is. Maybe add a paragraph about normalization. *Section 4.3.1. Recurrence* How does do clients have to treat start dates which are not in sync with the recurrence rule? RFC 5545 says the recurrence set is “undefined”. Can we be more specific in this spec? *Section 4.3.2. Recurrence Overrides* Are overrides allowed to predate the |start| property? Is it valid to add a new instance (which doesn’t match an instance created by a recurrence rule) and override the start at the same time (to a different value)? Or to put it in other words, is it valid to add an “RDATE” and override the start at the same time like this? |"recurrenceOverrides": { "2018-05-09T23:00:00": { "start": "2018-05-10T23:00:00" } } | *Section 4.4.4. replyTo* Method “web”: It’s 2018, can we ditch support for plain, insecure “http”, and only support the secure version? A JSCalendar object with an insecure replyTo address is invalid and MUST be rejected. Cheers, Marten Am 09.05.2018 um 16:23 schrieb Robert Stepanek: > Hi,  > > I have just submitted version 03 > of the > JSCalendar RFC draft. This version mainly includes updates after > implementing the latest spec version in the Cyrus IMAP project. > > Notable changes are: > > * *iCalendar Translation*: The section for mapping between > JSCalendar iCalendar has been updated, including a new mapping > table for the Location object. > * *Alert mediaLinks and attachments*: these properties have been > redefined from a list of linkIds to a map of Links. That is, > alerts now maintain their own set of links, rather than pointing > into the enclosing JSCalendar object link map. > * *Object ids*: the values for the uid and productId properties must > comply with the restrictions of their iCalendar equivalents. The > allowed values for JSCalendar object-internal ids are restricted > to valid JSON pointer format. > * *localizations*: this property and its related requirements have > been removed. The reasons for removal are: > o It Is unclear if embedding multi-lingual translations in the > object is the right solution, as opposed to using either > external links or translation APIs. > o The risk of getting the various translations out of sync on > partial updates is significant. > o Mapping localizations between JSCalendar and iCalendar is > barely supported with standard properties, increasing the risk > of getting out-of-sync data. > o If required, localizations can be re-introduced as an > extension, once the requirements are better understood. > * *htmlDescription*: the mapping for HTML description to iCalendar > has been defined to either use the ALTREP parameter (for legacy > clients) or the upcoming STYLED-DESCRIPTION property (see > eventpub-extensions > ). > * *Location*: the available Location feature values are now aligned > with the definition of the CONFERENCE iCalendar property > (RFC7986). The location description, URI and coordinates fields > are now optional, name and rel have default values. > > > As always, we look forward to any feedback! > > Cheers, > Robert > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify ​ -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------DA0E61BF8C74B8D1F88F2D51 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Robert,

a few questions came to my mind while scanning the new version, see below.

Section 3.2.3. Duration

Is PT3600S a valid duration string? According to the ABNF it is. Maybe add a paragraph about normalization.

Section 4.3.1. Recurrence

How does do clients have to treat start dates which are not in sync with the recurrence rule? RFC 5545 says the recurrence set is “undefined”. Can we be more specific in this spec?

Section 4.3.2. Recurrence Overrides

Are overrides allowed to predate the start property?

Is it valid to add a new instance (which doesn’t match an instance created by a recurrence rule) and override the start at the same time (to a different value)? Or to put it in other words, is it valid to add an “RDATE” and override the start at the same time like this?

"recurrenceOverrides": {
    "2018-05-09T23:00:00": {
        "start": "2018-05-10T23:00:00"
   }
}

Section 4.4.4. replyTo

Method “web”: It’s 2018, can we ditch support for plain, insecure “http”, and only support the secure version? A JSCalendar object with an insecure replyTo address is invalid and MUST be rejected.

Cheers,

Marten

Am 09.05.2018 um 16:23 schrieb Robert Stepanek:

Hi, 

I have just submitted version 03 of the JSCalendar RFC draft. This version mainly includes updates after implementing the latest spec version in the Cyrus IMAP project.

Notable changes are:

  • iCalendar Translation: The section for mapping between JSCalendar iCalendar has been updated, including a new mapping table for the Location object.
  • Alert mediaLinks and attachments: these properties have been redefined from a list of linkIds to a map of Links. That is, alerts now maintain their own set of links, rather than pointing into the enclosing JSCalendar object link map.
  • Object ids: the values for the uid and productId properties must comply with the restrictions of their iCalendar equivalents. The allowed values for JSCalendar object-internal ids are restricted to valid JSON pointer format.
  • localizations: this property and its related requirements have been removed. The reasons for removal are:
    • It Is unclear if embedding multi-lingual translations in the object is the right solution, as opposed to using either external links or translation APIs.
    • The risk of getting the various translations out of sync on partial updates is significant.
    • Mapping localizations between JSCalendar and iCalendar is barely supported with standard properties, increasing the risk of getting out-of-sync data.
    • If required, localizations can be re-introduced as an extension, once the requirements are better understood.
  • htmlDescription: the mapping for HTML description to iCalendar has been defined to either use the ALTREP parameter (for legacy clients) or the upcoming STYLED-DESCRIPTION property (see eventpub-extensions).
  • Location: the available Location feature values are now aligned with the definition of the CONFERENCE iCalendar property (RFC7986). The location description, URI and coordinates fields are now optional, name and rel have default values.

As always, we look forward to any feedback!

Cheers,
Robert



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

​
-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
--------------DA0E61BF8C74B8D1F88F2D51-- From nobody Fri May 11 13:53:40 2018 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 EDDBC127869 for ; Fri, 11 May 2018 13:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vXb5s2C9-5-F for ; Fri, 11 May 2018 13:53:37 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 51BB7126DD9 for ; Fri, 11 May 2018 13:53:37 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id r2-v6so9729985lff.4 for ; Fri, 11 May 2018 13:53:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=UJb2YyvZO8zV/QQ455saox/+eqJklPwhcKEECS5SRnQ=; b=s7RFj7BcKT/575qHEswljUs5kHNnpEUjiRPA/lWxRKjUssvH7B3iV6ZfsQFiRXa1sq DZaf7XIw4bz06Griq7BoyH5TRuXsb0ePwMGsQz2urOlINNGKfMlTYGHQ0Tiq5ahkUoUL Y/jAk2PiWwy8hqAtkLFu9eo+7RANpK+pmfS0t6mKa8C5K5O98zlJqAIJCnpVKdcHjHyZ 6Ru8dW5XV4XGaE/559bAogGBNtt04OlMDg8mJMPHWBarlOZal18pQOrmi2cUeaWh95Gx KUUx9w9yl0bRcI7xSY9nEQDwK9Q8iZM5mER5Q4DIG8z9zfqxWcuJTGnL28JGhF6IH1ID gDWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=UJb2YyvZO8zV/QQ455saox/+eqJklPwhcKEECS5SRnQ=; b=iwBt2VeFJvoSOdlvd1anp2CPpIbOMN2Wqd1y5R4ogjOYOoCOJq0Vd6kQVJ1OeUeQgv fLeynBpdFWXRFYXNWA6w0OqP7H0QG8YMYlwn/9SlkPVF6Xy2DVfoQa3Atsl6AQSQdqB9 YdunKf6AYBQctYiw6YOJzNt9JLDoIGapEtjcShdueomakgJyTOTtjZ1CGdSYPAUaKdqF BEFecOZSFBfwJyvJq+YElvM+rI02PAqSHl0bfnqD6Rb4vihYKh3klool+cQohZqzAfH3 VP7yV+MBF/AX+hLtXVALTXCPPvPh+A1R4PDMaXeZ8B4fD1VDjUx7g0YMfWOkgs5s0iNo 4ooA== X-Gm-Message-State: ALKqPwdgV2pa2dyzbHare4b9PScfRjTa8rL9FsCZNsLs6OYIfMCD9wV2 wUA7vJlbmZl99KweFecXwgYCTbCYV70s4olF8Gk= X-Google-Smtp-Source: AB8JxZo4LwjNaQeBcOm2MSkSXJ5wYMr/DgnEbLC3eJkNNiL0WdqHjv1OHS12CMWRFRHWgeto/oHp6zrAWV6yApxe1ZE= X-Received: by 2002:a19:ea5a:: with SMTP id i87-v6mr2212644lfh.118.1526072015442; Fri, 11 May 2018 13:53:35 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.158.88 with HTTP; Fri, 11 May 2018 13:53:34 -0700 (PDT) From: Daniel Migault Date: Fri, 11 May 2018 16:53:34 -0400 X-Google-Sender-Auth: pbOMWnjvxnygW9lT3s0BmaPmln4 Message-ID: To: calsify@ietf.org Content-Type: multipart/alternative; boundary="00000000000061d83a056bf4541e" Archived-At: Subject: [calsify] IETF102 session X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 20:53:39 -0000 --00000000000061d83a056bf4541e Content-Type: text/plain; charset="UTF-8" Hi, We are asking the WG whether it is willing to meet at the IETF102 in Montreal. If you believe the WG should meet, please let us know by Wednesday May 16. Yours, Daniel --00000000000061d83a056bf4541e Content-Type: text/html; charset="UTF-8"
Hi,

We are asking the WG whether it is willing to meet at the IETF102 in Montreal. If you believe the WG should meet, please let us know by Wednesday May 16.

Yours,
Daniel
--00000000000061d83a056bf4541e-- From nobody Sun May 13 18:50:31 2018 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 D8F041241F5 for ; Sun, 13 May 2018 18:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, 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 rJ-APnxACvBu for ; Sun, 13 May 2018 18:50:28 -0700 (PDT) Received: from forward3-smtp.messagingengine.com (forward3-smtp.messagingengine.com [66.111.4.237]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E81E120724 for ; Sun, 13 May 2018 18:50:28 -0700 (PDT) Received: from mailredirect.nyi.internal (imap22.nyi.internal [10.202.2.72]) by mailforward.nyi.internal (Postfix) with ESMTP id 3338910F7 for ; Sun, 13 May 2018 21:50:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mailredirect.nyi.internal (Postfix) with ESMTP id 24783CA190 for ; Sun, 13 May 2018 21:50:27 -0400 (EDT) Message-Id: <77373506-ec5c-4541-b133-83dc9605d0eb@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-565-g1e559eb-next x-jmap-identity-id: 64588216 In-Reply-To: References: <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> Date: Sun, 13 May 2018 21:50:25 -0400 From: Neil Jenkins To: calsify@ietf.org Content-Type: multipart/alternative; boundary=ee5644104b944847915e0ad3adef775a Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 01:50:30 -0000 --ee5644104b944847915e0ad3adef775a Content-Type: multipart/related; boundary=66379299f07148159f0d425a7bbbf505 --66379299f07148159f0d425a7bbbf505 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Thu, 10= May 2018, at 7:31 AM, Marten Gajda wrote:

Section 3.2.3. Duration

Is PT3600S a= valid duration string? According to the ABNF it is. Maybe add a paragraph about normalization.

=
Yes, this is valid. What do you suggest regarding normali= zation? Just a comment to say that the same durations may be represented= by different strings, and this is something clients have to handle? Or = define a normalization algorithm and specify clients MUST use the normal= ized form?

Section 4.3.1. Recurrence

How does do clients have to treat start dates which are not in sync with the recurrence rule? RFC 5545 says the recurrence set is =E2=80=9Cundefined=E2=80=9D. Can we be more specific in this spe= c?


Given (pretty much) all= clients handle this the same way these days, I agree this is worth spec= ifying.

Section 4.3.2. Recurrence Overrides

Are overrides allowed to predate the start property?


I'd say ye= s. They can in iCalendar I believe, although client support may not be 1= 00%.

Is it valid to add a new instance (which doesn=E2=80=99t match an instance created by= a recurrence rule) and override the start at the same time (to a different value)?


I would again say yes, so that the validity of the recurrenceOverrides = object can be easily checked syntactically, rather than having to do sem= antic checks against the recurrenceRule property of the parent object.

It's probably worth having an example in the= spec that covers these two cases to make sure clients remember to handl= e them!

Section 4.4.4. replyTo

Method =E2=80=9Cweb=E2=80=9D: It=E2=80=99s 2018, can we ditch support for plain, insecure =E2=80=9Chttp=E2=80= =9D, and only support the secure version? A JSCalendar object with an insecure= replyTo address is invalid and MUST be rejected.


Seems reasonable to me, although in pract= ice I wonder how many implementations will actually reject the whole obj= ect because of an http: replyTo property.

Neil.
--66379299f07148159f0d425a7bbbf505-- --ee5644104b944847915e0ad3adef775a Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 10 May 2018, at 7:31 AM, Marten Gajda wrote: > *Section 3.2.3. Duration* > Is PT3600S a valid duration string? According to the ABNF it is. Maybe= add a paragraph about normalization. Yes, this is valid. What do you suggest regarding normalization? Just a = comment to say that the same durations may be represented by different s= trings, and this is something clients have to handle? Or define a normal= ization algorithm and specify clients MUST use the normalized form? > *Section 4.3.1. Recurrence* > How does do clients have to treat start dates which are not in sync with the recurrence rule? RFC 5545 says the recurrence set is =E2=80=9Cundefined=E2=80=9D. Can we be more specific in this spe= c? Given (pretty much) all clients handle this the same way these days, I a= gree this is worth specifying. > *Section 4.3.2. Recurrence Overrides* > Are overrides allowed to predate the start property? I'd say yes. They can in iCalendar I believe, although client support ma= y not be 100%. > Is it valid to add a new instance (which doesn=E2=80=99t match an instance created by= a recurrence rule) and override the start at the same time (to a different value)?=20 I would again say yes, so that the validity of the recurrenceOverrides o= bject can be easily checked syntactically, rather than having to do sema= ntic checks against the recurrenceRule property of the parent object. It's probably worth having an example in the spec that covers these two = cases to make sure clients remember to handle them! > *Section 4.4.4. replyTo* > Method =E2=80=9Cweb=E2=80=9D: It=E2=80=99s 2018, can we ditch support for plain, insecure =E2=80=9Chttp=E2=80= =9D, and only support the secure version? A JSCalendar object with an insecure= replyTo address is invalid and MUST be rejected. Seems reasonable to me, although in practice I wonder how many implement= ations will actually reject the whole object because of an http: *replyT= o* property. Neil. --ee5644104b944847915e0ad3adef775a-- From nobody Sun May 13 18:57:12 2018 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 ACF1A12DA42 for ; Sun, 13 May 2018 18:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, 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 xBKel3TJtDrR for ; Sun, 13 May 2018 18:56:50 -0700 (PDT) Received: from forward3-smtp.messagingengine.com (forward3-smtp.messagingengine.com [66.111.4.237]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5945712D7E8 for ; Sun, 13 May 2018 18:56:50 -0700 (PDT) Received: from mailredirect.nyi.internal (imap22.nyi.internal [10.202.2.72]) by mailforward.nyi.internal (Postfix) with ESMTP id 7185DA75; Sun, 13 May 2018 21:56:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mailredirect.nyi.internal (Postfix) with ESMTP id 5C87FCA190; Sun, 13 May 2018 21:56:49 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.3-565-g1e559eb-next x-jmap-identity-id: 64588216 In-Reply-To: <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> References: <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> Date: Sun, 13 May 2018 21:56:49 -0400 From: Neil Jenkins To: calsify@ietf.org, Robert Stepanek Content-Type: multipart/alternative; boundary=6a5783228ba24be884139db873b0289c Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 01:56:54 -0000 --6a5783228ba24be884139db873b0289c Content-Type: multipart/related; boundary=ebf95ec5462546b9abf12837e6e12c16 --ebf95ec5462546b9abf12837e6e12c16 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Looking at= this again, I realised today the EXDATE representation is problematic i= n that it is incompatible with the JMAP patch format. Specifically, by a= pplying semantic meaning to mapping to `null`, you can't then use mappin= g to `null` in a patch as a means of removing that property, as that's a= different action.

I suggest we instead rep= resent EXDATE like so:
"recurrenceOverrides": {
    "2018-05-14T11:53:00": {
        "method": "cancel"
   }
}
This is both more obvious if you are looking at an ob= ject and have never seen the spec, and is consistent with the way this i= s represented in the iTIP messages sent out. I suggest the method=  property MUST NOT appear in an override if it's not a cancellation= ; if it is a cancellation it MUST be the only property in the object.

Neil.
--ebf95ec5462546b9abf12837e6e12c16-- --6a5783228ba24be884139db873b0289c Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Looking at this again, I realised today the EXDATE representation is pro= blematic in that it is incompatible with the JMAP patch format. Specific= ally, by applying semantic meaning to mapping to `null`, you can't then = use mapping to `null` in a patch as a means of removing that property, a= s that's a different action. I suggest we instead represent EXDATE like so: "recurrenceOverrides": { "2018-05-14T11:53:00": { "method": "cancel" } } This is both more obvious if you are looking at an object and have never= seen the spec, and is consistent with the way this is represented in th= e iTIP messages sent out. I suggest the *method*=C2=A0property MUST NOT = appear in an override if it's not a cancellation; if it is a cancellatio= n it MUST be the only property in the object. Neil. --6a5783228ba24be884139db873b0289c-- From nobody Sun May 13 22:10:19 2018 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 6A6D1129C6E for ; Sun, 13 May 2018 22:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 7zSynRIqqz9C for ; Sun, 13 May 2018 22:10:15 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 7B4A61200A0 for ; Sun, 13 May 2018 22:10:15 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id h19-v6so8997604qkj.10 for ; Sun, 13 May 2018 22:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+pQ4PQAucNy/qsoAj/aW4JUE51wxQWg+0LdSH+dEXZo=; b=p3UhoHMpW9MEHjj6sjQhTXpUsq60YuBI9rfuy+LvwF0JxA2r9KXzCFMmE8oncHvcIh U69PsBhMG/FdguLMQuw6kZxbjlH5fMrQW5u9nueDvyL4SAvje5NG2Mba+MqOb176PEOT 77zbVX8Ki9PruZcZsWxelZBn4te/vbNWkI8WFojF6umMoGDnCxhIfdVcjkxvmay2XFOc WVW/pbN0YqIK+nQXX6JOP3/uy6FjKmmrWGi3lHMxS5L8mvzEIQYy5ayRMKhZBjBpvydt ixEKHzO4yP8rEgVRYZLmAWNyAgtwu9xQwNjH2KB+efMrsoyBm6iauTh3XsQEzRo9KiYE 6Xxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+pQ4PQAucNy/qsoAj/aW4JUE51wxQWg+0LdSH+dEXZo=; b=VQ1P44aVUsu1y6NJ0+DcahgW1Fin9qqEFnDABXYZb0ua00+qb6ouZ1Yd2/xrrFbhem DnpYbuV2o6593OqRs8sCyxHQm9R5d2Wz5cET2O12GHUUniA0J+t9h/5ZNGGlHzIazNQC QshoXbBfPz8xbVWWEdTEQ8vZZIFc8PqweCVumagCiBb+36SV7Agn2ib2m+3K9aSzuJ7w h6LOTt+w8Qd80SdT03PkYPJeDhchc7K/I1cYh21zPAbHCxLt7yQEEcgFoirUjuBXzIZE vD6xWi+5IZWAWqO6PmupmIqFNpK7fGcxzbOKoHm40bBN6HQdF4jQ7KsG2W0agp5ztXmC /J8A== X-Gm-Message-State: ALKqPwe0/TiiFcKrqvtL854PXQQDu87QnltFQORNpu/yBak9yl+uUdaZ L8AGaWTY1sMHdkn+uUqaeypVYhMf X-Google-Smtp-Source: AB8JxZoHr34zTCK5p882b/gUus5bwIq1Rr9Jd0aZfo0yzYIpEA+kT4m7nRBlF7+EV5jtDe1OvU6vKA== X-Received: by 2002:a37:7f46:: with SMTP id a67-v6mr2532447qkd.351.1526274614494; Sun, 13 May 2018 22:10:14 -0700 (PDT) Received: from [192.168.1.129] (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.gmail.com with ESMTPSA id m67-v6sm4154511qkd.30.2018.05.13.22.10.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 May 2018 22:10:14 -0700 (PDT) From: Mike Douglass X-Google-Original-From: Mike Douglass Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Mon, 14 May 2018 01:10:13 -0400 Cc: calsify@ietf.org, Robert Stepanek Content-Transfer-Encoding: quoted-printable Message-Id: References: <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> To: Neil Jenkins Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 05:10:17 -0000 Sent from my iPhone > On May 13, 2018, at 9:56 PM, Neil Jenkins wrote: >=20 > Looking at this again, I realised today the EXDATE representation is probl= ematic in that it is incompatible with the JMAP patch format. Specifically, b= y applying semantic meaning to mapping to `null`, you can't then use mapping= to `null` in a patch as a means of removing that property, as that's a diff= erent action. >=20 > I suggest we instead represent EXDATE like so: > "recurrenceOverrides": { > "2018-05-14T11:53:00": { > "method": "cancel" > } > } I think we should introduce method: delete There=E2=80=99s a difference between a deletion - which is what an exdate is= - and a cancellation which should be an override with status cancelled.=20 The second one should not be deleted - you need to tell the consumer that th= e event was canceled > This is both more obvious if you are looking at an object and have never s= een the spec, and is consistent with the way this is represented in the iTIP= messages sent out. I suggest the *method* property MUST NOT appear in an ov= erride if it's not a cancellation; if it is a cancellation it MUST be the on= ly property in the object. >=20 > Neil. > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Mon May 14 05:40:38 2018 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 BB4C912DB6B for ; Mon, 14 May 2018 05:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 Wykkq0d1xEWk for ; Mon, 14 May 2018 05:40:35 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA93E12DB6C for ; Mon, 14 May 2018 05:40:34 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 21545220CB for ; Mon, 14 May 2018 08:40:34 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute1.internal (MEProxy); Mon, 14 May 2018 08:40:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=SwvRgG Kq5MEPAjNKz8e/05nYoh+4nBQchmgH49u32yo=; b=BfLvtRgqvMo9QcSzYrYAhH US6uqI3o5EPUqy3a/8w8TvuUby8dL672RoMUVW9SaE4y8WEU+xZ8Qpz9bX8rCFi4 UqLB+RSgHR0yg9sBOlKVHn70Ncfez8QkxzejPVsX2BA75uBXngW88Wh6dU3xDPBi oOzHOcvtE3xo7gZQhQWoZS/1FvChz8shaYwJNRtPCmLs35h9U9TWlJM4OHRU9duF WfEd2pp+exK3bn4ZpDDpZCWU9K2cFkiMAHnLAmAZ/3UaMT84aPWmUIZlGeg5Yc6g HYyd8SN4tK3e0Z+OEfLW5y+a3D+ze/rHHVqAtb7atluyXSDFu2KGC0RXwH6vNmYA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 0148F422D; Mon, 14 May 2018 08:40:33 -0400 (EDT) Message-Id: <1526301633.2355518.1371292664.496BA737@webmail.messagingengine.com> From: Robert Stepanek To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152630163323555180" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 Date: Mon, 14 May 2018 14:40:33 +0200 In-Reply-To: <77373506-ec5c-4541-b133-83dc9605d0eb@sloti22d1t06> References: <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> <77373506-ec5c-4541-b133-83dc9605d0eb@sloti22d1t06> Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 12:40:37 -0000 This is a multi-part message in MIME format. --_----------=_152630163323555180 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Mon, May 14, 2018, at 03:50, Neil Jenkins wrote: > *Section 4.3.1. Recurrence* >> How does do clients have to treat start dates which are not in sync >> with the recurrence rule? RFC 5545 says the recurrence set is >> =E2=80=9Cundefined=E2=80=9D. Can we be more specific in this spec?>=20 > Given (pretty much) all clients handle this the same way these days, I > agree this is worth specifying. The relevant section in RFC 5545 defines: "The "DTSTART" property value SHOULD be synchronized with the recurrence rule, if specified. The recurrence set generated with a "DTSTART" property value not synchronized with the recurrence rule is undefined." Let's change SHOULD to MUST for JSCalendar. This causes a potential difference in how iCalendar and JSCalendar clients might display the same event, but it's the same issue for two iCalendar clients, anyways. >> *Section 4.3.2. Recurrence Overrides* >> Are overrides allowed to predate the start property? >=20 > I'd say yes. They can in iCalendar I believe, although client support > may not be 100%. Agreed. >> Is it valid to add a new instance (which doesn=E2=80=99t match an instan= ce >> created by a recurrence rule) and override the start at the same time >> (to a different value)?>=20 > I would again say yes, so that the validity of the > recurrenceOverrides object can be easily checked syntactically, > rather than having to do semantic checks against the recurrenceRule > property of the parent object.>=20 > It's probably worth having an example in the spec that covers these > two cases to make sure clients remember to handle them! Agreed. >> *Section 4.4.4. replyTo* >> Method =E2=80=9Cweb=E2=80=9D: It=E2=80=99s 2018, can we ditch support fo= r plain, insecure >> =E2=80=9Chttp=E2=80=9D, and only support the secure version? A JSCalenda= r object with >> an insecure replyTo address is invalid and MUST be rejected.>=20 > Seems reasonable to me, although in practice I wonder how many > implementations will actually reject the whole object because of an > http: *replyTo* property. I'm OK with enforcing https but I wonder if there's a general guideline at IETF for new RFCs around HTTPS or allowing fallback to HTTP? Did this by chance already pop up during the security reviews of the JMAP spec? Cheers, Robert --_----------=_152630163323555180 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Mon, May 14, 2018, at 03:50, Neil Jenkins wrote:
Section 4.3.1. Recurrence

How does do clients have to treat start dates which are not in sync with the recurrence rule? RFC 5545 says the recurrence set is =E2=80=9Cundefined=E2=80=9D. Can we be more specific in this spec?<= br>


Given (pretty much) all clients handle this the same way these days, I= agree this is worth specifying.

The relevant section in RFC 5545 defines: "The "DTSTART" property valu= e SHOULD be synchronized with the recurrence rule, if specified. The r= ecurrence set generated with a "DTSTART" property value not synchronized wi= th the recurrence rule is undefined."

Let's change SHOULD to MUST for JSCalendar. This causes a potential di= fference in how iCalendar and JSCalendar clients might display the same ev= ent, but it's the same issue for two iCalendar clients, anyways.

Section 4.3.2. Recurrence Overrides

Are overrides allowed to predate the start property?


I'd say yes. They can in iCalendar I believe, although client support = may not be 100%.

Agreed.

Is it valid to add a new instance (which doesn=E2=80=99t match an instance created by a recurrence rule) and override the start at the same time (to a different value)?


I would again say yes, so that the validity of the recurrenceOverrides= object can be easily checked syntactically, rather than having to do seman= tic checks against the recurrenceRule property of the parent object.

It's probably worth having an example in the spec that covers these tw= o cases to make sure clients remember to handle them!

Agreed.

Section 4.4.4. replyTo

Method =E2=80=9Cweb=E2=80=9D: It=E2=80=99s 2018, can we ditch support for plain, insecure =E2=80=9Chttp=E2=80= =9D, and only support the secure version? A JSCalendar object with an insecure replyTo address is invalid and MUST be rejected.


Seems reasonable to me, although in practice I wonder how many impleme= ntations will actually reject the whole object because of an http: replyTo property.

I'm OK with enforcing https but I wonder if there's a general guidelin= e at IETF for new RFCs around HTTPS or allowing fallback to HTTP? Did this = by chance already pop up during the security reviews of the JMAP spec?
<= /div>

Cheers,
Robert
--_----------=_152630163323555180-- From nobody Mon May 14 05:48:43 2018 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 8E53712DB6B for ; Mon, 14 May 2018 05:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 Vm9pddcEQoMn for ; Mon, 14 May 2018 05:48:41 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63CE4124239 for ; Mon, 14 May 2018 05:48:41 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B74C02232F; Mon, 14 May 2018 08:48:40 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute1.internal (MEProxy); Mon, 14 May 2018 08:48:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=lRS37r 0i0BW8P8f2qJdWJl85t9T+ijJdAhePUG92j3w=; b=nbe2x0sJ2x9YEGCLHyDoa5 Tdva26iiV938tp6PMRmEXhFzkqc15JijAPAFt3TVOwW7VmfbrPhO37dcDwFWzoqz fCALqMOI9XVK/qLyphWyNjTikpLwbSPPD0nQTpeQec3Sf5NGwtUnMbirFjoHkm6F VudG3B2dXIHzLzHbyId7Ij8oiFR4BjJrWWAeRJY5cezyBr9Rg1HaDxMV4s661l8f ukYZk613JRM4MPtETCnbUKBlS9dXOe3V+OKTc8zwDsP/MvmO22Uk2Hq30ThD/abu mAKr2ZCHPeZGyZ9q+GtR4O3sdCX7/oUpcU1N/2kZypsjLVY9rFUEC2IO9x8EyTAA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 872004276; Mon, 14 May 2018 08:48:40 -0400 (EDT) Message-Id: <1526302120.2359806.1371303536.14330E61@webmail.messagingengine.com> From: Robert Stepanek To: Mike Douglass , Neil Jenkins Cc: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 References: <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> Date: Mon, 14 May 2018 14:48:40 +0200 In-Reply-To: Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 12:48:42 -0000 On Mon, May 14, 2018, at 07:10, Mike Douglass wrote: > > On May 13, 2018, at 9:56 PM, Neil Jenkins wrote: > > > > Looking at this again, I realised today the EXDATE representation is problematic in that it is incompatible with the JMAP patch format. Specifically, by applying semantic meaning to mapping to `null`, you can't then use mapping to `null` in a patch as a means of removing that property, as that's a different action. > > > > I suggest we instead represent EXDATE like so: > > "recurrenceOverrides": { > > "2018-05-14T11:53:00": { > > "method": "cancel" > > } > > } > > I think we should introduce method: delete DELETE is problematic, as the current definition of the `method` property is required to match the allowed iTIP method values. If using DELETE, I wonder if that also would make sense for iTIP. Alternatively, to express EXDATE and RDATE equivalents in JSCalendar, while keeping JMAP patch syntax in mind, we might just as well split the recurrenceOverrides property into - recurrenceOverrides: for exceptions and RDATE - recurrenceDeletions: for EXDATES. The value of this property is a map of recurrence-id to JSON true. Cheers, Robert From nobody Mon May 14 06:04:38 2018 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 537B012E034 for ; Mon, 14 May 2018 06:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 ixToB8c0W2yX for ; Mon, 14 May 2018 06:04:35 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF04412E045 for ; Mon, 14 May 2018 06:04:34 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0D60D22158 for ; Mon, 14 May 2018 09:04:34 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute1.internal (MEProxy); Mon, 14 May 2018 09:04:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=YD2E4R T3MezVz8O8sL6rRw+alfeW5SLF/9dEW21gYmE=; b=l16Dd/MjBhqXSDzWPi5hY7 eUOisOX7GZBXbrMz70dFz9vkGw64G7gq1YG9DFxBLMDudEkJw9y1W/fWg08PQdkD FQ0N+yzLIDnD48iwkAbpYOdgmj4QKsumuvbXNUIxe1Z7QLT21BkQtW+OeHVuIxTV lYVa2BE//V27jV+usrKLCK1KMkPNVPSFk9UZBlpYEW+Pn8I0J5p9oJb3E7uwhZAB AssYfiYcsu2jeYv8uT1Rx7kqt28MROLjEDltSGtP8sPDiObpDoH0OLtB5tkPZGbx hPKni6lczIdsI7Lidb6/zWSGoXjtkGSZXMYt+4GOpMCDP8sRDLMP+p17D7vXLbhA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C7F32422D; Mon, 14 May 2018 09:04:33 -0400 (EDT) Message-Id: <1526303073.2368442.1371315048.7F470423@webmail.messagingengine.com> From: Robert Stepanek To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152630307323684420" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 In-Reply-To: <96676354-12c5-32f7-443e-eba13d74225f@gmail.com> Date: Mon, 14 May 2018 15:04:33 +0200 References: <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> <96676354-12c5-32f7-443e-eba13d74225f@gmail.com> Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 13:04:37 -0000 This is a multi-part message in MIME format. --_----------=_152630307323684420 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, May 9, 2018, at 19:07, Michael Douglass wrote: > Multi-language support is very important - indeed a legal requirement > in some places. How are these places are dealing with this now in terms of calendaring? > When publishing events there is no knowledge of the end recipient. It > may pass through a number of aggregators and other intermediaries. > Delivering one package with all required languages is absolutely the > best way.> While there is indeed an issue with localizations being out of date > that is something for workflow to deal with - pointing to external > resources doesn't make that any easier. Sequence numbers can flag the > need to check.> Translation APIs do a mediocre job - watch the Jimmy Fallon sketch on > translating carols to another language and back again> > After much discussion on how to achieve this in iCalendar it seemed a > localization component was the best approach - while that may not > happen in iCalendar I had hopes of seeing that appear in jscalendar. > Either defining a localization component in iCalendar or simply > dropping the localizations on translation (no worse than we are now) > is better IMO than dropping the idea in jscalendar There's clearly a value in localization support for some calendaring users. OTOH it sounds as if the design issues were similar to what we came to realize for JSCalendar, and there isn't one good answer? This probably is a good occasion to put the claim of JSCalendar "to be unambiguous, extendable and simple to process" to the test, and make localizations an extension. Clients that choose to implement this extension will benefit from localizations, we'll have more insight into how defining a JSCalendar extension actually works out; and implementations that don't bother can just ignore all of it. Cheers, Robert --_----------=_152630307323684420 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, May 9, 2018, at 19:07, Michael Douglass wrote:

Multi-language support is very important - indeed a legal requirement in some places.


How are these places are dealing with this now in terms of calendaring?

When publishing events there is no knowledge of the end recipient. It may pass through a number of aggregators and other intermediaries.  Delivering one package with all required languages is absolutely the best way.
While there is indeed an issue with localizations being out of date that is something for workflow to deal with - pointing to external resources doesn't make that any easier. Sequence numbers can flag the need to check.
Translation APIs do a mediocre job - watch the Jimmy Fallon sketch on translating carols to another language and back again

After much discussion on how to achieve this in iCalendar it seemed a localization component was the best approach - while that may not happen in iCalendar I had hopes of seeing that appear in jscalendar. Either defining a localization component in iCalendar or simply dropping the localizations on translation (no worse than we are now) is better IMO than dropping the idea in jscalendar

There's clearly a value in localization support for some calendaring users. OTOH it sounds as if the design issues were similar to what we came to realize for JSCalendar, and there isn't one good answer?

This probably is a good occasion to put the claim of JSCalendar "to be unambiguous, extendable and simple to process" to the test, and make localizations an extension. Clients that choose to implement this extension will benefit from localizations, we'll have more insight into how defining a JSCalendar extension actually works out; and implementations that don't bother can just ignore all of it.

Cheers,
Robert
--_----------=_152630307323684420-- From nobody Mon May 14 06:39:13 2018 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 AFE4312E76A for ; Mon, 14 May 2018 06:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 0iKbFAR-RdKy for ; Mon, 14 May 2018 06:39:10 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1C512E6A3 for ; Mon, 14 May 2018 06:39:10 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 19EC721D20 for ; Mon, 14 May 2018 09:39:10 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute1.internal (MEProxy); Mon, 14 May 2018 09:39:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=b6ahNI 6NObF831wEf8U1yo2ojzDLxNIi6mB5mu418FI=; b=hWRg+tpUg5/uwuPI5/cr6P 9xoHJym+ipNlwCSkdRfMpYMqErrAKV/PepZ4GSSDFwyzEAXEtcg7095vgXRPzmPF LNAxmmXr5H9iuhli3tG5LESrOUT9npAy7IgQZ+lkYQ7sJMjT4zl+oiCHWNiihS/c zSJSJb4S2n1G3jWc4dDkLj2/gFzeNfC+2UAIQAziQSdCbQsh7bePCxq5FLI6Tamq 2WJr0OvZSuIL6Fs+Rq9Tt8chJkyf/ubKTpsRjj5yP3q3ypemYiUWTnfg+cjfKUG8 fkQHZ7uxyE6TFwTE/VB3GHunxqPmnliifASzL7Sj5i+zYWmu7X0ayAgiR1ld7IbA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id CB63E422D; Mon, 14 May 2018 09:39:09 -0400 (EDT) Message-Id: <1526305149.2385151.1371368184.3BA1B70B@webmail.messagingengine.com> From: Robert Stepanek To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 Date: Mon, 14 May 2018 15:39:09 +0200 In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFD1@eusaamb107.ericsson.se> References: <152557323572.26681.1466351398334547861@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFD1@eusaamb107.ericsson.se> Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-06.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 13:39:12 -0000 Sorry, for late reply. Section 5.3 does not specify how to handle multiple occurrences of the same ORDER value. Should implementations reject that or may they choose how to sort same-ordered properties. Sections 8.1 and 8.2: The description of the PARTICIPANT component mentions the STRUCTURED-ADDRESS, CALENDAR-ADDRESS and LOCATION properties, but these properties are not listed in the definition of the partprop ABNF. Am I just reading that not right? Besides that, I'm in favour of this document being progressed to WGLC. On Mon, May 7, 2018, at 16:21, Daniel Migault wrote: > Hi everyone, > > Pleas find the new version of draft-ietf-calext-eventpub-extensions. The > document was in WGLC. As discussed in London, it would be helpful to get > feed backs to understand if the draft is ready to be submit to the IESG. > We would appreciate comments/supports on the mailing list by May 15. > > Yours, > Daniel > > > > -----Original Message----- > From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Saturday, May 05, 2018 10:21 PM > To: i-d-announce@ietf.org > Cc: calsify@ietf.org > Subject: [calsify] I-D Action: draft-ietf-calext-eventpub- > extensions-06.txt > > > 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 : Event Publishing Extensions to iCalendar > Author : Michael Douglass > Filename : draft-ietf-calext-eventpub-extensions-06.txt > Pages : 31 > Date : 2018-05-05 > > Abstract: > This specification introduces a number of new iCalendar properties > and components which are of particular use for event publishers and > in social networking. > > This specification also defines a new STRUCTURED-DATA property for > iCalendar [RFC5545] to allow for data that is directly pertinent to > an event or task to be included with the calendar data. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-06 > https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-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/ > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Mon May 14 08:34:06 2018 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 103DA126BF7 for ; Mon, 14 May 2018 08:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.922 X-Spam-Level: X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, 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 D6t2KuaHKQ6s for ; Mon, 14 May 2018 08:34:03 -0700 (PDT) Received: from moint.1and1.com (moint.1and1.com [212.227.15.7]) (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 527DC12E876 for ; Mon, 14 May 2018 08:34:00 -0700 (PDT) Received: from [172.19.76.173] (helo=BAPPEX005-MBX.webde.local) by mrint.1and1.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fIFU5-0003sB-E4; Mon, 14 May 2018 17:33:57 +0200 Received: from KAPPEX004-MBX.webde.local (172.19.70.207) by BAPPEX005-MBX.webde.local (172.19.76.173) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 14 May 2018 17:33:55 +0200 Received: from KAPPEX004-MBX.webde.local ([fe80::c2b:a698:499a:2609]) by KAPPEX004-MBX.webde.local ([fe80::c2b:a698:499a:2609%15]) with mapi id 15.00.1365.000; Mon, 14 May 2018 17:33:55 +0200 From: =?utf-8?B?VGhvbWFzIFNjaMOkZmVy?= To: Daniel Migault , "calsify@ietf.org" Thread-Topic: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt Thread-Index: AQHT5N5ZtAIqdQSBWkqTdNviHt8h8KQkMn+AgAtGdgA= Date: Mon, 14 May 2018 15:33:54 +0000 Message-ID: <644086C2-701A-4272-B967-DC2DB99D2A79@1und1.de> References: <152557214808.26780.14458282737730003696@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFF3@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFF3@eusaamb107.ericsson.se> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.c.0.180410 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.76.220] Content-Type: text/plain; charset="utf-8" Content-ID: <082B8CF0E4D1D1409268955C4A6870B5@united.domain> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Virus-Scanned: ClamAV@mvs-ha-bs Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 15:34:05 -0000 SSBzdXBwb3J0IGdvaW5nIHRvIFdHTEMgZm9yIHRoZSBpY2FsLXJlbGF0aW9ucyBkcmFmdC4NCg0K QmVzdCwNClRob21hcyBTY2jDpGZlcg0KDQrvu79BbSAwNy4wNS4xOCwgMTY6MjMgc2NocmllYiAi Y2Fsc2lmeSBpbSBBdWZ0cmFnIHZvbiBEYW5pZWwgTWlnYXVsdCIgPGNhbHNpZnktYm91bmNlc0Bp ZXRmLm9yZyBpbSBBdWZ0cmFnIHZvbiBkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb20+Og0KDQog ICAgSGkgZXZlcnlvbmUsIA0KICAgIA0KICAgIFBsZWFzIGZpbmQgdGhlIG5ldyB2ZXJzaW9uIG9m IGRyYWZ0LWlldGYtY2FsZXh0LWljYWwtcmVsYXRpb25zLiBBcyBkaXNjdXNzZWQgaW4gTG9uZG9u LCBpdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGdldCBmZWVkIGJhY2tzIHRvIHVuZGVyc3RhbmQgaWYg dGhlIGRyYWZ0IGlzIGZvciBhIFdHTEMuIFdlIHdvdWxkIGFwcHJlY2lhdGUgY29tbWVudHMvc3Vw cG9ydHMgb24gdGhlIG1haWxpbmcgbGlzdCBieSBNYXkgMTUuDQogICAgDQogICAgWW91cnMsIA0K ICAgIERhbmllbCANCiAgICANCiAgICANCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K ICAgIEZyb206IGNhbHNpZnkgW21haWx0bzpjYWxzaWZ5LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCiAgICBTZW50OiBTYXR1cmRheSwgTWF5 IDA1LCAyMDE4IDEwOjAyIFBNDQogICAgVG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KICAgIENj OiBjYWxzaWZ5QGlldGYub3JnDQogICAgU3ViamVjdDogW2NhbHNpZnldIEktRCBBY3Rpb246IGRy YWZ0LWlldGYtY2FsZXh0LWljYWwtcmVsYXRpb25zLTA0LnR4dA0KICAgIA0KICAgIA0KICAgIEEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRo ZSBDYWxlbmRhcmluZyBFeHRlbnNpb25zIFdHIG9mIHRoZSBJRVRGLg0KICAgIA0KICAgICAgICAg ICAgVGl0bGUgICAgICAgICAgIDogU3VwcG9ydCBmb3IgaUNhbGVuZGFyIFJlbGF0aW9uc2hpcHMN CiAgICAgICAgICAgIEF1dGhvciAgICAgICAgICA6IE1pY2hhZWwgRG91Z2xhc3MNCiAgICAJRmls ZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1jYWxleHQtaWNhbC1yZWxhdGlvbnMtMDQudHh0DQog ICAgCVBhZ2VzICAgICAgICAgICA6IDE5DQogICAgCURhdGUgICAgICAgICAgICA6IDIwMTgtMDUt MDUNCiAgICANCiAgICBBYnN0cmFjdDoNCiAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gdXBkYXRl cyBSRUxBVEVELVRPIGRlZmluZWQgaW4gW1JGQzU1NDVdIGFuZA0KICAgICAgIGludHJvZHVjZXMg bmV3IGlDYWxlbmRhciBwcm9wZXJ0aWVzIExJTkssIENPTkNFUFQgYW5kIFJFRklEIHRvIGFsbG93 DQogICAgICAgYmV0dGVyIGxpbmtpbmcgYW5kIGdyb3VwaW5nIG9mIGlDYWxlbmRhciBjb21wb25l bnRzIGFuZCByZWxhdGVkIGRhdGEuDQogICAgDQogICAgDQogICAgVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jYWxleHQtaWNhbC1yZWxhdGlvbnMvDQogICAgDQog ICAgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNhbGV4dC1pY2FsLXJlbGF0aW9u cy0wNA0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0 Zi1jYWxleHQtaWNhbC1yZWxhdGlvbnMtMDQNCiAgICANCiAgICBBIGRpZmYgZnJvbSB0aGUgcHJl dmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtY2FsZXh0LWljYWwtcmVsYXRpb25zLTA0DQogICAgDQog ICAgDQogICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgIA0KICAgIEludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCiAgICBm dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KICAgIA0KICAgIF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgY2Fsc2lmeSBtYWlsaW5n IGxpc3QNCiAgICBjYWxzaWZ5QGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jYWxzaWZ5DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCiAgICBjYWxzaWZ5IG1haWxpbmcgbGlzdA0KICAgIGNh bHNpZnlAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NhbHNpZnkNCiAgICANCg0K From nobody Mon May 14 08:34:43 2018 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 EC8B212D952; Mon, 14 May 2018 08:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.922 X-Spam-Level: X-Spam-Status: No, score=-0.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, 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 97z1pfmmPiLG; Mon, 14 May 2018 08:34:39 -0700 (PDT) Received: from moint.1and1.com (moint.1and1.com [212.227.15.8]) (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 51910126BF7; Mon, 14 May 2018 08:34:39 -0700 (PDT) Received: from [172.19.70.206] (helo=KAPPEX003-MBX.webde.local) by mrint.1and1.com with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fIFUh-0000zU-Jh; Mon, 14 May 2018 17:34:35 +0200 Received: from KAPPEX004-MBX.webde.local (172.19.70.207) by KAPPEX003-MBX.webde.local (172.19.70.206) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 14 May 2018 17:34:34 +0200 Received: from KAPPEX004-MBX.webde.local ([fe80::c2b:a698:499a:2609]) by KAPPEX004-MBX.webde.local ([fe80::c2b:a698:499a:2609%15]) with mapi id 15.00.1365.000; Mon, 14 May 2018 17:34:34 +0200 From: =?utf-8?B?VGhvbWFzIFNjaMOkZmVy?= To: Daniel Migault , "internet-drafts@ietf.org" , "i-d-announce@ietf.org" CC: "calsify@ietf.org" Thread-Topic: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-06.txt Thread-Index: AQHT5ODYtf33h0tPA0mAvrMKi6y71KQkMhsAgAtHBQA= Date: Mon, 14 May 2018 15:34:33 +0000 Message-ID: References: <152557323572.26681.1466351398334547861@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFD1@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFD1@eusaamb107.ericsson.se> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.c.0.180410 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.76.220] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Virus-Scanned: ClamAV@mvs-ha-bs Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-06.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 15:34:41 -0000 SSBzdXBwb3J0IGdvaW5nIHRvIFdHTEMgZm9yIHRoZSBldmVudHB1YiBleHRlbnNpb25zIGRyYWZ0 Lg0KDQpCZXN0LA0KVGhvbWFzIFNjaMOkZmVyDQoNCu+7v0FtIDA3LjA1LjE4LCAxNjoyMSBzY2hy aWViICJjYWxzaWZ5IGltIEF1ZnRyYWcgdm9uIERhbmllbCBNaWdhdWx0IiA8Y2Fsc2lmeS1ib3Vu Y2VzQGlldGYub3JnIGltIEF1ZnRyYWcgdm9uIGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbT46 DQoNCiAgICBIaSBldmVyeW9uZSwgDQogICAgDQogICAgUGxlYXMgZmluZCB0aGUgbmV3IHZlcnNp b24gb2YgZHJhZnQtaWV0Zi1jYWxleHQtZXZlbnRwdWItZXh0ZW5zaW9ucy4gVGhlIGRvY3VtZW50 IHdhcyBpbiBXR0xDLiBBcyBkaXNjdXNzZWQgaW4gTG9uZG9uLCBpdCB3b3VsZCBiZSBoZWxwZnVs IHRvIGdldCBmZWVkIGJhY2tzIHRvIHVuZGVyc3RhbmQgaWYgdGhlIGRyYWZ0IGlzIHJlYWR5IHRv IGJlIHN1Ym1pdCB0byB0aGUgSUVTRy4gV2Ugd291bGQgYXBwcmVjaWF0ZSBjb21tZW50cy9zdXBw b3J0cyBvbiB0aGUgbWFpbGluZyBsaXN0IGJ5IE1heSAxNS4NCiAgICANCiAgICBZb3VycywgDQog ICAgRGFuaWVsIA0KICAgIA0KICAgIA0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQogICAgRnJvbTogY2Fsc2lmeSBbbWFpbHRvOmNhbHNpZnktYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KICAgIFNlbnQ6IFNhdHVyZGF5 LCBNYXkgMDUsIDIwMTggMTA6MjEgUE0NCiAgICBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQog ICAgQ2M6IGNhbHNpZnlAaWV0Zi5vcmcNCiAgICBTdWJqZWN0OiBbY2Fsc2lmeV0gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi1jYWxleHQtZXZlbnRwdWItZXh0ZW5zaW9ucy0wNi50eHQNCiAgICANCiAg ICANCiAgICBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogICAgVGhpcyBkcmFmdCBpcyBhIHdvcmsg aXRlbSBvZiB0aGUgQ2FsZW5kYXJpbmcgRXh0ZW5zaW9ucyBXRyBvZiB0aGUgSUVURi4NCiAgICAN CiAgICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IEV2ZW50IFB1Ymxpc2hpbmcgRXh0ZW5zaW9u cyB0byBpQ2FsZW5kYXINCiAgICAgICAgICAgIEF1dGhvciAgICAgICAgICA6IE1pY2hhZWwgRG91 Z2xhc3MNCiAgICAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1jYWxleHQtZXZlbnRwdWIt ZXh0ZW5zaW9ucy0wNi50eHQNCiAgICAJUGFnZXMgICAgICAgICAgIDogMzENCiAgICAJRGF0ZSAg ICAgICAgICAgIDogMjAxOC0wNS0wNQ0KICAgIA0KICAgIEFic3RyYWN0Og0KICAgICAgIFRoaXMg c3BlY2lmaWNhdGlvbiBpbnRyb2R1Y2VzIGEgbnVtYmVyIG9mIG5ldyBpQ2FsZW5kYXIgcHJvcGVy dGllcw0KICAgICAgIGFuZCBjb21wb25lbnRzIHdoaWNoIGFyZSBvZiBwYXJ0aWN1bGFyIHVzZSBm b3IgZXZlbnQgcHVibGlzaGVycyBhbmQNCiAgICAgICBpbiBzb2NpYWwgbmV0d29ya2luZy4NCiAg ICANCiAgICAgICBUaGlzIHNwZWNpZmljYXRpb24gYWxzbyBkZWZpbmVzIGEgbmV3IFNUUlVDVFVS RUQtREFUQSBwcm9wZXJ0eSBmb3INCiAgICAgICBpQ2FsZW5kYXIgW1JGQzU1NDVdIHRvIGFsbG93 IGZvciBkYXRhIHRoYXQgaXMgZGlyZWN0bHkgcGVydGluZW50IHRvDQogICAgICAgYW4gZXZlbnQg b3IgdGFzayB0byBiZSBpbmNsdWRlZCB3aXRoIHRoZSBjYWxlbmRhciBkYXRhLg0KICAgIA0KICAg IA0KICAgIFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlz Og0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtY2FsZXh0 LWV2ZW50cHViLWV4dGVuc2lvbnMvDQogICAgDQogICAgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQg dmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWNhbGV4dC1ldmVudHB1Yi1leHRlbnNpb25zLTA2DQogICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWNhbGV4dC1ldmVudHB1Yi1leHRl bnNpb25zLTA2DQogICAgDQogICAgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMg YXZhaWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLWNhbGV4dC1ldmVudHB1Yi1leHRlbnNpb25zLTA2DQogICAgDQogICAgDQogICAgUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgIA0KICAgIEludGVybmV0LURyYWZ0cyBh cmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCiAgICBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgY2Fsc2lmeSBtYWlsaW5nIGxpc3QNCiAgICBj YWxzaWZ5QGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jYWxzaWZ5DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgICBjYWxzaWZ5IG1haWxpbmcgbGlzdA0KICAgIGNhbHNpZnlAaWV0Zi5v cmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NhbHNpZnkNCiAg ICANCg0K From nobody Mon May 14 08:51:08 2018 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 5084512D952 for ; Mon, 14 May 2018 08:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=b4S9vcoJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Pr2zuO45 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 t_tMXfudRnTx for ; Mon, 14 May 2018 08:51:05 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A968126BF7 for ; Mon, 14 May 2018 08:51:05 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C4C6E223BF for ; Mon, 14 May 2018 11:51:04 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 14 May 2018 11:51:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=32LZr3bPyh+WpRoNbwp54KGWoL39n0H1u86uvNMTjPE=; b=b4S9vcoJ +1jSsMKH1REExuKDNk23JpAnEmacMTT8g66hc6nq+LYS0jgW+vtJqcvpXg001zM3 +IS8rhNqZ9ydFrymPueEKhXlMnEOr0iyh+0cIX10ISoSXTFA2SbiC3kUJI0dKI2j 08e54y5kLD48hI1ioySXhMV1qKjLZqW5S41EczdEGstKTfnkJUO2I/g4zEVWnc+O i1D85mdHwZgw7vB+0cLN1QLCcqhNf5G9fm1ELx+8+F5VhVIUuie1+PGcZslxDqrp TX1UyfFUDJC3oqz9g4FFPbJKie07Jnt/p5rlRd4FffFfJ2JMyiVquwYU80xXPqiP Owx26cBSUJvg1w== 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-sender :x-me-sender:x-sasl-enc; s=fm2; bh=32LZr3bPyh+WpRoNbwp54KGWoL39n 0H1u86uvNMTjPE=; b=Pr2zuO453OC6ntgg4V4nvDoDmeiQvfZg8K9t3FdbktV7n wqI7/toM6wv40GBORAI7KhWbyBELsMLecaBa6HmEPpt+kIXj+p89l1M5WtCGUor7 AV4M3dt8vAZPn9/QJMd+PyooI1hxGCFaEHBXXNRRjRGQ0Fje1km6SXVhDUWuETvB FkY1d2Mlr0BRTElXysntJpLG0N4jnY2QLRa6bwLS/2jg8uexHjkRuErNi1UOAAH5 aFyBuvwggjwxHWwTulEB9/wLsA1IYS8vL1x9FUOkUcZT7N18DVXC5yeG66FsX2Ph G9gvooZYU5CdxrnsIN1P7sWzLRmFVzSJdcPx4AODA== X-ME-Sender: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 765C7E50A4 for ; Mon, 14 May 2018 11:51:04 -0400 (EDT) To: calsify@ietf.org References: <152557323572.26681.1466351398334547861@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFD1@eusaamb107.ericsson.se> From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Mon, 14 May 2018 11:51:03 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFD1@eusaamb107.ericsson.se> Content-Type: multipart/mixed; boundary="------------F4B7EC77408838CD8CAAE627" Content-Language: en-US Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-06.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 15:51:07 -0000 This is a multi-part message in MIME format. --------------F4B7EC77408838CD8CAAE627 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I support moving this to IESG, provided any nits have been addressed. On 05/07/2018 10:21 AM, Daniel Migault wrote: > Hi everyone, > > Pleas find the new version of draft-ietf-calext-eventpub-extensions. The document was in WGLC. As discussed in London, it would be helpful to get feed backs to understand if the draft is ready to be submit to the IESG. We would appreciate comments/supports on the mailing list by May 15. > > Yours, > Daniel > > > > -----Original Message----- > From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Saturday, May 05, 2018 10:21 PM > To: i-d-announce@ietf.org > Cc: calsify@ietf.org > Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-06.txt > > > 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 : Event Publishing Extensions to iCalendar > Author : Michael Douglass > Filename : draft-ietf-calext-eventpub-extensions-06.txt > Pages : 31 > Date : 2018-05-05 > > Abstract: > This specification introduces a number of new iCalendar properties > and components which are of particular use for event publishers and > in social networking. > > This specification also defines a new STRUCTURED-DATA property for > iCalendar [RFC5545] to allow for data that is directly pertinent to > an event or task to be included with the calendar data. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-06 > https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-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/ > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Ken Murchison Cyrus Development Team FastMail US LLC --------------F4B7EC77408838CD8CAAE627 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------F4B7EC77408838CD8CAAE627-- From nobody Mon May 14 08:51:29 2018 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 02F4A12D952 for ; Mon, 14 May 2018 08:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=b/t41aCV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KttLc7gz 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 wf0GWnKOpETp for ; Mon, 14 May 2018 08:51:26 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96EE126BF7 for ; Mon, 14 May 2018 08:51:25 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 4E01C220F9 for ; Mon, 14 May 2018 11:51:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 14 May 2018 11:51:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=pVrjfc91XQ2Y4ns8vPC0mSi1pW8nDy1nFdV1My9lLKw=; b=b/t41aCV erp/h87m7UG7oVGD6g+XUfF31fz8eAIcrFb+WiKSedveo59ZvcZalz3mqQFWwWF6 /U62dD0ND57Bask5t7/0itgIDlyhCZsh7eylIROZY8b1IFgemFRCUPYnf12AP2jC 3aPkbW1G/56pmGV3LDDi5N0XmAJv2dHRpcY28Im6889SI1LwJPjtRIAp75FCgG2O zQfrq9LbTFpZ8MMuqczvTu/xqzXmn0sPzpza7HpqYRvLvFVhOx480Rc9v6wxD3PI GfG8l6V5Ifg9AWdq7iO2ld8awnTtXgj7msmTtORgEz8jwiQ6lS1UjkFgStKeSDL/ zLeiOJs/BFFXUQ== 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-sender :x-me-sender:x-sasl-enc; s=fm2; bh=pVrjfc91XQ2Y4ns8vPC0mSi1pW8nD y1nFdV1My9lLKw=; b=KttLc7gzCCfuyZU6mfNHsRUUwM7cEifMF0zlf6Og5j8h9 XXXbItKvjzLHNPdA+2ULQW1kVXQNRhCmuGbkoliKidltcWj+W20/VychGILMHoqf E8CtferzItUr/zkKO27umGyunqdh9Y0Yg/VFXzeD7ge6/Y4y2dXvivZ+ebPvqA9t hydzPXkWExBLlnEXXhfnZ2xB58Dfx6l2Be3BPyxVWmLY/6E+nY0XGBUN+63Elmxr Lhz7tw/sx8ytZH/Ou30mjUQRBgnDAO6DCUXfXx+pUkCl7BwqNzoJ0kOK3+Y81LnO A7FQdPvjvB3kU3QRInCkjIZ5mJj1MRhi7piPKj8Zw== X-ME-Sender: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 0424FE509F for ; Mon, 14 May 2018 11:51:24 -0400 (EDT) To: calsify@ietf.org References: <152557214808.26780.14458282737730003696@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFF3@eusaamb107.ericsson.se> From: Ken Murchison Organization: FastMail US LLC Message-ID: <1380abfc-8239-1460-645a-4110c6d035f2@fastmail.com> Date: Mon, 14 May 2018 11:51:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFF3@eusaamb107.ericsson.se> Content-Type: multipart/mixed; boundary="------------2FE9044E4AA9DE0D6363B6EC" Content-Language: en-US Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 15:51:28 -0000 This is a multi-part message in MIME format. --------------2FE9044E4AA9DE0D6363B6EC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I support moving this to WGLC. On 05/07/2018 10:22 AM, Daniel Migault wrote: > Hi everyone, > > Pleas find the new version of draft-ietf-calext-ical-relations. As discussed in London, it would be helpful to get feed backs to understand if the draft is for a WGLC. We would appreciate comments/supports on the mailing list by May 15. > > Yours, > Daniel > > > -----Original Message----- > From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Saturday, May 05, 2018 10:02 PM > To: i-d-announce@ietf.org > Cc: calsify@ietf.org > Subject: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt > > > 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-04.txt > Pages : 19 > Date : 2018-05-05 > > 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-04 > https://datatracker.ietf.org/doc/html/draft-ietf-calext-ical-relations-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-ical-relations-04 > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Ken Murchison Cyrus Development Team FastMail US LLC --------------2FE9044E4AA9DE0D6363B6EC Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------2FE9044E4AA9DE0D6363B6EC-- From nobody Mon May 14 09:57:33 2018 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 ED8E712E892 for ; Mon, 14 May 2018 09:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 SjEXV8LcfxUQ for ; Mon, 14 May 2018 09:57:24 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 A76DC12E895 for ; Mon, 14 May 2018 09:57:24 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id e8-v6so17033560qth.0 for ; Mon, 14 May 2018 09:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=FUFRQipmPyeayKrO3hckwardf5boYHe5SXyEL0dVXFk=; b=exZu6Zk/zJR+Pk6QQ+JzWZd2GnRe2tmmaazVFxpugDaV//QNeEvuPlAS8Pojv85yE5 jaGOesB+WvW0lsEe2l+ygZAGdEB2MwnjBDOOcBKH/vKuOMVaGcevyox2GX/Og1CpFspo YvwkvkJF7g7R5+C96TVkeuZFW5IIPCz1Do4tRXgkbU2nATV5UFBCmuHrs6QMqZ2LgZyy ZzTvvyM1nYbowQ/nhFtqrv2LrjpPNJ2UFW0Ajt2swcuRurv9+3VMvj7T3wQAOiQpcTXi L+YywcDevlmo9PHGTZJo6WwExH72EgEGTBNb0ppRng8r+nOT/FzIieL1pc6S2M9y1Y7V y1jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FUFRQipmPyeayKrO3hckwardf5boYHe5SXyEL0dVXFk=; b=bXniZjzxK2nqfZcuQMYB1qBk3dCpa7op40wLiLDsvjIgq8KIP9sbQAO0Ekb5SvXDR9 DcrbwORqhW6dOVnaifZbL/2XXNjx8hcyI3NRvFj1AC96FA45wfN6kyp847YzVjmTDY0g pZ8W9P4ElgJX5qTYykyWdp/0ysGV9oHUWZNXrS7q3M5ZC+Pxv/PLrF5QNb5K6rOi5BkV XP8m0Wg5wS4XywkYmWsWcGDpe0Wnt4JOKkoCJ4IuQ8gNgR2VNN16ph+O4jb2G4Kq+jsu KHfevkWv374fiFQJiBLVyD2qYQYMSqoLkHPmAXq34kr0ebZX9HwilAxj5bhVkXRvf2WG 68HA== X-Gm-Message-State: ALKqPwepFde9ZhnkzsDgHkcLplKv/aWo5031kcE4WCLHSmv7zeK2ObgO 77QRiZxJH9Is2iiljWBVrjYxGw== X-Google-Smtp-Source: AB8JxZpWeZMYsKLpP6ei5ypzJtUVyZ7I8s9HlVCInF2dFcLtDLGNJm8fyCwGjzNwulvWcv/84CPYmw== X-Received: by 2002:aed:24c2:: with SMTP id u2-v6mr9507139qtc.235.1526317043743; Mon, 14 May 2018 09:57:23 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id w51-v6sm7802989qtc.97.2018.05.14.09.57.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 May 2018 09:57:22 -0700 (PDT) To: calsify@ietf.org References: <152557323572.26681.1466351398334547861@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFD1@eusaamb107.ericsson.se> <1526305149.2385151.1371368184.3BA1B70B@webmail.messagingengine.com> From: Michael Douglass Message-ID: <246033ef-f42d-363e-65af-8c0eefdcb4ed@gmail.com> Date: Mon, 14 May 2018 12:57:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1526305149.2385151.1371368184.3BA1B70B@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-06.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 16:57:27 -0000 On 5/14/18 09:39, Robert Stepanek wrote: > Sorry, for late reply. > > Section 5.3 does not specify how to handle multiple occurrences of the same ORDER value. Should implementations reject that or may they choose how to sort same-ordered properties. > > Sections 8.1 and 8.2: The description of the PARTICIPANT component mentions the STRUCTURED-ADDRESS, CALENDAR-ADDRESS and LOCATION properties, but these properties are not listed in the definition of the partprop ABNF. Am I just reading that not right? I'd forgotten about this one. What I want to say is what properties are required in participant - what properties, if any, are not allowed and that any other properties can be included. Ditto for components. I'll take another look > > Besides that, I'm in favour of this document being progressed to WGLC. > > On Mon, May 7, 2018, at 16:21, Daniel Migault wrote: >> Hi everyone, >> >> Pleas find the new version of draft-ietf-calext-eventpub-extensions. The >> document was in WGLC. As discussed in London, it would be helpful to get >> feed backs to understand if the draft is ready to be submit to the IESG. >> We would appreciate comments/supports on the mailing list by May 15. >> >> Yours, >> Daniel >> >> >> >> -----Original Message----- >> From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Saturday, May 05, 2018 10:21 PM >> To: i-d-announce@ietf.org >> Cc: calsify@ietf.org >> Subject: [calsify] I-D Action: draft-ietf-calext-eventpub- >> extensions-06.txt >> >> >> 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 : Event Publishing Extensions to iCalendar >> Author : Michael Douglass >> Filename : draft-ietf-calext-eventpub-extensions-06.txt >> Pages : 31 >> Date : 2018-05-05 >> >> Abstract: >> This specification introduces a number of new iCalendar properties >> and components which are of particular use for event publishers and >> in social networking. >> >> This specification also defines a new STRUCTURED-DATA property for >> iCalendar [RFC5545] to allow for data that is directly pertinent to >> an event or task to be included with the calendar data. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-06 >> https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-06 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-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/ >> >> _______________________________________________ >> 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 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Mon May 14 16:16:18 2018 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 56BCE12E8FA for ; Mon, 14 May 2018 16:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, 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 x45BXDOsI49s for ; Mon, 14 May 2018 16:16:16 -0700 (PDT) Received: from forward3-smtp.messagingengine.com (forward3-smtp.messagingengine.com [66.111.4.237]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3640F12E8E7 for ; Mon, 14 May 2018 16:16:16 -0700 (PDT) Received: from mailredirect.nyi.internal (imap22.nyi.internal [10.202.2.72]) by mailforward.nyi.internal (Postfix) with ESMTP id 8440B1243; Mon, 14 May 2018 19:16:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mailredirect.nyi.internal (Postfix) with ESMTP id 7BD52CA2B7; Mon, 14 May 2018 19:16:15 -0400 (EDT) Message-Id: <2d2e532d-9924-4e84-8150-fa7938c1820c@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-565-g1e559eb-next x-jmap-identity-id: 64588216 In-Reply-To: <1526301633.2355518.1371292664.496BA737@webmail.messagingengine.com> References: <1526301633.2355518.1371292664.496BA737@webmail.messagingengine.com> <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> <77373506-ec5c-4541-b133-83dc9605d0eb@sloti22d1t06> Date: Mon, 14 May 2018 19:16:15 -0400 From: Neil Jenkins To: calsify@ietf.org, Robert Stepanek Content-Type: multipart/alternative; boundary=5e797b77b49b494a881d14ae30360c8c Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 23:16:17 -0000 --5e797b77b49b494a881d14ae30360c8c Content-Type: multipart/related; boundary=0ac14ba0b52d490c93155348e1331368 --0ac14ba0b52d490c93155348e1331368 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Mon, 14= May 2018, at 10:40 PM, Robert Stepanek wrote:
The relevant section in RFC 5545 d= efines: "The "DTSTART" property value SHOULD be synchronized with the re= currence rule, if specified. The recurrence set generated with a "D= TSTART" property value not synchronized with the recurrence rule is unde= fined."

Let's change SHOULD to MUST for JSC= alendar. This causes a potential difference in how iCalendar and JSCale= ndar clients might display the same event, but it's the same issue for t= wo iCalendar clients, anyways.

No, strongly disagree! The point Marten and I are making is that this&n= bsp;is handled the same way by most (all?) existing clients, and = so we should document that rather than leaving it undefined. Just changi= ng the spec to say the rule MUST be synchronised with the start will onl= y lead to interop issues.

I'm OK with enforcing https but I wonder= if there's a general guideline at IETF for new RFCs around HTTPS or all= owing fallback to HTTP? Did this by chance already pop up during the sec= urity reviews of the JMAP spec?

JMAP has always said HTTPS only since the beginning I think.
=

Neil.
--0ac14ba0b52d490c93155348e1331368-- --5e797b77b49b494a881d14ae30360c8c Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, 14 May 2018, at 10:40 PM, Robert Stepanek wrote: > The relevant section in RFC 5545 defines: "The "DTSTART" property valu= e SHOULD be synchronized with the recurrence rule, if specified.=C2=A0Th= e recurrence set generated with a "DTSTART" property value not synchroni= zed with the recurrence rule is undefined." >=20 > Let's change SHOULD to MUST for JSCalendar. This causes a potential di= fference in how iCalendar and JSCalendar clients might display the same= event, but it's the same issue for two iCalendar clients, anyways. No, strongly disagree! The point Marten and I are making is that this=C2= =A0*is* handled the same way by most (all?) existing clients, and so we = should document that rather than leaving it undefined. Just changing the= spec to say the rule MUST be synchronised with the start will only lead= to interop issues. > I'm OK with enforcing https but I wonder if there's a general guidelin= e at IETF for new RFCs around HTTPS or allowing fallback to HTTP? Did th= is by chance already pop up during the security reviews of the JMAP spec= ? JMAP has always said HTTPS only since the beginning I think. Neil. --5e797b77b49b494a881d14ae30360c8c-- From nobody Mon May 14 16:25:58 2018 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 EBD0712E8FA for ; Mon, 14 May 2018 16:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, 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 sLga3U_1ZiWU for ; Mon, 14 May 2018 16:25:55 -0700 (PDT) Received: from forward3-smtp.messagingengine.com (forward3-smtp.messagingengine.com [66.111.4.237]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCDDC12E8E7 for ; Mon, 14 May 2018 16:25:54 -0700 (PDT) Received: from mailredirect.nyi.internal (imap22.nyi.internal [10.202.2.72]) by mailforward.nyi.internal (Postfix) with ESMTP id 14866AD9; Mon, 14 May 2018 19:25:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mailredirect.nyi.internal (Postfix) with ESMTP id 03025CA2B7; Mon, 14 May 2018 19:25:54 -0400 (EDT) Message-Id: <47cf1e10-a814-4cc7-9b2b-1ddad800a789@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-565-g1e559eb-next x-jmap-identity-id: 64588216 In-Reply-To: <1526302120.2359806.1371303536.14330E61@webmail.messagingengine.com> References: <1526302120.2359806.1371303536.14330E61@webmail.messagingengine.com> <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> Date: Mon, 14 May 2018 19:25:52 -0400 From: Neil Jenkins To: Michael Douglass , Robert Stepanek Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary=1b4555f4d3bd4ca2956509f70f36e343 Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 23:25:57 -0000 --1b4555f4d3bd4ca2956509f70f36e343 Content-Type: multipart/related; boundary=88be771ea5f2410b9948f117c7c285b5 --88be771ea5f2410b9948f117c7c285b5 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Mon, 14 May = 2018, at 10:48 PM, Robert Stepanek wrote:
Alternatively, to express EXDATE and RD= ATE equivalents in JSCalendar, while keeping JMAP patch syntax in mind, = we might just as well split the recurrenceOverrides property into

- recurrenceOverrides: for exceptions and RDATE
- recurrenceDeletions: for EXDATES. The value of this prope= rty is a map of recurrence-id to JSON true.
<= br>
I don't like this idea. We deliberately chose to have a si= ngle property as it made it syntactically impossible to have an RDATE an= d and an EXDATE for the same time, reducing the chance of making mistake= s and producing weird data. I think the { method: "cancel" } solution is= much cleaner.

In relation to Mike's commen= t:

There=E2=80=99= s a difference between a deletion - which is what an exdate is - and a c= ancellation which should be an override with status cancelled.
=

Yes, but you can already override the <= a href=3D"https://tools.ietf.org/html/draft-ietf-calext-jscalendar-03#se= ction-5.1.5">status property to "cancelled" to indicate an event is = cancelled. If you create an EXDATE in an iCalendar system though, this w= ill send out an iTIP message with method=3D"cancel", so it seems reasona= ble to reuse that semantics here. I don't think we need to define a new = method value.

Neil.
--88be771ea5f2410b9948f117c7c285b5-- --1b4555f4d3bd4ca2956509f70f36e343 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Mon, 14 May 2018, at 10:48 PM, Robert Stepanek wrote: > Alternatively, to express EXDATE and RDATE equivalents in JSCalendar, = while keeping JMAP patch syntax in mind, we might just as well split the= recurrenceOverrides property into >=20 > - recurrenceOverrides: for exceptions and RDATE > - recurrenceDeletions: for EXDATES. The value of this property is a ma= p of recurrence-id to JSON true. I don't like this idea. We deliberately chose to have a single property = as it made it syntactically impossible to have an RDATE and and an EXDAT= E for the same time, reducing the chance of making mistakes and producin= g weird data. I think the { method: "cancel" } solution is much cleaner.= In relation to Mike's comment: > There=E2=80=99s a difference between a deletion - which is what an exd= ate is - and a cancellation which should be an override with status canc= elled. Yes, but you can already override the status property to "cancelled"= to indicate an event is cancelled. If you create an EXDATE in an iCalen= dar system though, this will send out an iTIP message with method=3D"can= cel", so it seems reasonable to reuse that semantics here. I don't think= we need to define a new method value. Neil. --1b4555f4d3bd4ca2956509f70f36e343-- From nobody Mon May 14 18:50:55 2018 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 433F512EAA9 for ; Mon, 14 May 2018 18:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=HDcA5hPU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YV+76L/L 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 a-95rPXnHokk for ; Mon, 14 May 2018 18:50:51 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECEF512EAA1 for ; Mon, 14 May 2018 18:50:50 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1FCDC225A0 for ; Mon, 14 May 2018 21:50:49 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 14 May 2018 21:50:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=RoM1tbJtq/BFwOO08 rrTBhlP+LnmnJf2KxCsgG6Ayq4=; b=HDcA5hPUM986cNSDgDukA+zzovug5oqdj pwhZJWZxRCsfBifcXNAhyERiKfpWbxbqhwqSu1QaBkBMolHkZcCrVkbKckz591ck 7ezo3a/23HKlxC0lNd5tct3wPXTDZlfUw7mRscFqXLBTYBdeDjcjqaTgK0RZEkcD wyyoKjEwzLf6MzwW003ZYgA9CFfMIfVYnn11UNJ+0SG/TJXhS6Il7PMt0/RkQMHW xkE/2x9nBrMGn/yIRyzcF5Lk0t9V8o6jx58u1n8ivwvewLeZiPEa57SCSOvg5prH S0r/uLcGmg3cjDZXuULjzdYRZbmWX+w77ckrb+tLSiKhhk4azx0TQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=RoM1tb Jtq/BFwOO08rrTBhlP+LnmnJf2KxCsgG6Ayq4=; b=YV+76L/LAwExbjjdwP/mBf v2palLjt7IuGBo71ux3cdDBcEd2GI3KFxIt3mx7RuJjnf1mGt4F7u0bRyTooFVMU gcR7SvQARea1/QPrz0qac6lkG8OsnhTlVQrLKmqttVT6wnvJD2601dHTB3tT/veG +GlPramsymrjII8WYW6Sl6hUsWx4m2QovUYEB9x9Q9o8p21HpVH3mkZoNwaZkBaC wmno+hkJSa/zOKOsrVLZC7J5Jo0T7Npn+BOkigUheUIqucMmAoccLT2zj64xQkgE fndR81KLYVeMg5rV8CnWTRcg72Mt32dw3mm4kZ0R+5+AARPDBkzbRE8S945WKOGg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id AB6029E0E7; Mon, 14 May 2018 21:50:49 -0400 (EDT) Message-Id: <1526349049.1928575.1372173792.3F4BD2C4@webmail.messagingengine.com> From: Bron Gondwana To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152634904919285753" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 References: <1526301633.2355518.1371292664.496BA737@webmail.messagingengine.com> <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> <77373506-ec5c-4541-b133-83dc9605d0eb@sloti22d1t06> <2d2e532d-9924-4e84-8150-fa7938c1820c@sloti22d1t06> In-Reply-To: <2d2e532d-9924-4e84-8150-fa7938c1820c@sloti22d1t06> Date: Tue, 15 May 2018 11:50:49 +1000 Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 01:50:53 -0000 This is a multi-part message in MIME format. --_----------=_152634904919285753 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, May 15, 2018, at 09:16, Neil Jenkins wrote: > On Mon, 14 May 2018, at 10:40 PM, Robert Stepanek wrote: >> The relevant section in RFC 5545 defines: "The "DTSTART" property >> value SHOULD be synchronized with the recurrence rule, if specified. >> The recurrence set generated with a "DTSTART" property value not >> synchronized with the recurrence rule is undefined.">> >> Let's change SHOULD to MUST for JSCalendar. This causes a potential >> difference in how iCalendar and JSCalendar clients might display the >> same event, but it's the same issue for two iCalendar clients, >> anyways.> > No, strongly disagree! The point Marten and I are making is that this > *is* handled the same way by most (all?) existing clients, and so we > should document that rather than leaving it undefined. Just changing > the spec to say the rule MUST be synchronised with the start will only > lead to interop issues. We discussed this in the Cyrus dev team meeting last night. In the same way that JMAP is leading to attempts in EXTRA to backfill some of the best improvements in to the existing IMAP protocol, it makes sense to do an iCalendar bis (iCalendar 2.1!) which does nothing but nail down undefined behaviour such that new implementations have a guideline. I think the SHOULD to MUST came out of a comment by Ken, and I missed that. I agree with Neil here that the right thing is to document existing behaviour and mandate the most popular existing approach. >> I'm OK with enforcing https but I wonder if there's a general >> guideline at IETF for new RFCs around HTTPS or allowing fallback to >> HTTP? Did this by chance already pop up during the security reviews >> of the JMAP spec?> > JMAP has always said HTTPS only since the beginning I think. I still think it's a layering violation to specify the specifics of the transport layer in the payload spec. However, there seems a very strong IETF insistence towards mandating HTTPS everywhere, so explicitly doing so increases the chance of passing review. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152634904919285753 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, May 15, 2018, at 09:16, Neil Jenkins wrote:
On Mon, 14 May 2018, at 10:40 PM, Robert Stepanek wrote:
The relevant section in RFC 5545 defines: "The "DTSTART" property value SHOULD be synchronized with the recurrence rule, if specified. The recurrence set generated with a "DTSTART" property value not synchronized with the recurrence rule is undefined."

Let's change SHOULD to MUST for JSCalendar. This causes a potential difference in how iCalendar and JSCalendar clients might display the same event, but it's the same issue for two iCalendar clients, anyways.

No, strongly disagree! The point Marten and I are making is that this is handled the same way by most (all?) existing clients, and so we should document that rather than leaving it undefined. Just changing the spec to say the rule MUST be synchronised with the start will only lead to interop issues.

We discussed this in the Cyrus dev team meeting last night.  In the same way that JMAP is leading to attempts in EXTRA to backfill some of the best improvements in to the existing IMAP protocol, it makes sense to do an iCalendar bis (iCalendar 2.1!) which does nothing but nail down undefined behaviour such that new implementations have a guideline.

I think the SHOULD to MUST came out of a comment by Ken, and I missed that. I agree with Neil here that the right thing is to document existing behaviour and mandate the most popular existing approach.

I'm OK with enforcing https but I wonder if there's a general guideline at IETF for new RFCs around HTTPS or allowing fallback to HTTP? Did this by chance already pop up during the security reviews of the JMAP spec?

JMAP has always said HTTPS only since the beginning I think.

I still think it's a layering violation to specify the specifics of the transport layer in the payload spec.

However, there seems a very strong IETF insistence towards mandating HTTPS everywhere, so explicitly doing so increases the chance of passing review.

Bron.

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


--_----------=_152634904919285753-- From nobody Mon May 14 20:02:03 2018 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 88F64127909 for ; Mon, 14 May 2018 20:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=LeOv2OSd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=O8OEeMYL 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 MgeopIpqRlmz for ; Mon, 14 May 2018 20:01:58 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87036127863 for ; Mon, 14 May 2018 20:01:58 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C97A121CD2 for ; Mon, 14 May 2018 23:01:57 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 14 May 2018 23:01:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=T2BWTPVVi960f1/ltAgElzhnPV3mgirsWZyaij7HftM=; b=LeOv2OSd fCIlOA7VKr3UMQmn60BnA5YGp9sS/f14jYDjIK/eHZVmN7gYclhAX7V8j2J8WaJn G3j5Au7s6TLRYyt2wRfAAu59dFIsCQooVQiemCkXa+Nt/6scnYhKx02vO6u0XIzt YcEEZEuSX1br/pA/O0sBsc8P908MUGPmkpUoJ5g8Mpfam3Ky0G1++AorhZz2yqEc OtJ5m0V0lH3RuxkwAHndpqQ6CWcP1AXtNocf6DAwbqAUw2xNn4lmNpnFvKYNq7yk 6MVj47v4nnZHAN6oVmnXXmJXIA6SnjV45sQ5KhjuNotvhITvJjJ9jn9KbFSnKTxn in9LrGJaaXKRJA== 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-sender :x-me-sender:x-sasl-enc; s=fm2; bh=T2BWTPVVi960f1/ltAgElzhnPV3mg irsWZyaij7HftM=; b=O8OEeMYLOi//VOr1N5nlVFKRT42S4bqpbuTsZSkBFquPi NIy5ZX8ipJaef5hIfHJDqkWivpEZiv2rNzyJd3eh7Gi6vxYtxYvcwq7MjDPLX1HZ sdt6uXmCeyeR/mnCJaJO/h0+uDOvM1sy8zcOn7tVrkVCtfe7NsMyo43RZzy47Czh 12pzqhaBUewJ42S2j7kqTwW9qiJ2X1P29begd0B/K3eUYqxSwbniPnNMf3eMZWN2 3aVZ9t6qDBkBBXf6DT8fpVx7JrZ4TwtA2rv/qupZUm/KeGNi/mlb+x3E52Qel+UW Yn1+yT4IXtX7IM3NcayxmzMk/dNG64+LMwbJJ574A== X-ME-Sender: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 7BD6C10256 for ; Mon, 14 May 2018 23:01:57 -0400 (EDT) To: calsify@ietf.org References: <1526301633.2355518.1371292664.496BA737@webmail.messagingengine.com> <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> <77373506-ec5c-4541-b133-83dc9605d0eb@sloti22d1t06> <2d2e532d-9924-4e84-8150-fa7938c1820c@sloti22d1t06> <1526349049.1928575.1372173792.3F4BD2C4@webmail.messagingengine.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Mon, 14 May 2018 23:01:56 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1526349049.1928575.1372173792.3F4BD2C4@webmail.messagingengine.com> Content-Type: multipart/mixed; boundary="------------C486CDFBD4B718206C78AE11" Content-Language: en-US Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 03:02:01 -0000 This is a multi-part message in MIME format. --------------C486CDFBD4B718206C78AE11 Content-Type: multipart/alternative; boundary="------------DA4244FC84F29A91B94A1776" --------------DA4244FC84F29A91B94A1776 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 05/14/2018 09:50 PM, Bron Gondwana wrote: > On Tue, May 15, 2018, at 09:16, Neil Jenkins wrote: >> On Mon, 14 May 2018, at 10:40 PM, Robert Stepanek wrote: >>> The relevant section in RFC 5545 defines: "The "DTSTART" property >>> value SHOULD be synchronized with the recurrence rule, if >>> specified. The recurrence set generated with a "DTSTART" property >>> value not synchronized with the recurrence rule is undefined." >>> >>> Let's change SHOULD to MUST for JSCalendar. This causes a potential >>> difference in how iCalendar and JSCalendar clients might display the >>> same event, but it's the same issue for two iCalendar clients, anyways. >> >> No, strongly disagree! The point Marten and I are making is that this >> /is/ handled the same way by most (all?) existing clients, and so we >> should document that rather than leaving it undefined. Just changing >> the spec to say the rule MUST be synchronised with the start will >> only lead to interop issues. > > We discussed this in the Cyrus dev team meeting last night.  In the > same way that JMAP is leading to attempts in EXTRA to backfill some of > the best improvements in to the existing IMAP protocol, it makes sense > to do an iCalendar bis (iCalendar 2.1!) which does nothing but nail > down undefined behaviour such that new implementations have a guideline. > > I think the SHOULD to MUST came out of a comment by Ken, and I missed > that. I agree with Neil here that the right thing is to document > existing behaviour and mandate the most popular existing approach. And what is existing behavior?  If most implementations ignored a SHOULD, then apparently SHOULD doesn't carry much weight. -- Ken Murchison Cyrus Development Team FastMail US LLC --------------DA4244FC84F29A91B94A1776 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 05/14/2018 09:50 PM, Bron Gondwana wrote:
On Tue, May 15, 2018, at 09:16, Neil Jenkins wrote:
On Mon, 14 May 2018, at 10:40 PM, Robert Stepanek wrote:
The relevant section in RFC 5545 defines: "The "DTSTART" property value SHOULD be synchronized with the recurrence rule, if specified. The recurrence set generated with a "DTSTART" property value not synchronized with the recurrence rule is undefined."

Let's change SHOULD to MUST for JSCalendar. This causes a potential difference in how iCalendar and JSCalendar clients might display the same event, but it's the same issue for two iCalendar clients, anyways.

No, strongly disagree! The point Marten and I are making is that this is handled the same way by most (all?) existing clients, and so we should document that rather than leaving it undefined. Just changing the spec to say the rule MUST be synchronised with the start will only lead to interop issues.

We discussed this in the Cyrus dev team meeting last night.  In the same way that JMAP is leading to attempts in EXTRA to backfill some of the best improvements in to the existing IMAP protocol, it makes sense to do an iCalendar bis (iCalendar 2.1!) which does nothing but nail down undefined behaviour such that new implementations have a guideline.

I think the SHOULD to MUST came out of a comment by Ken, and I missed that. I agree with Neil here that the right thing is to document existing behaviour and mandate the most popular existing approach.

And what is existing behavior?  If most implementations ignored a SHOULD, then apparently SHOULD doesn't carry much weight.


-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
--------------DA4244FC84F29A91B94A1776-- --------------C486CDFBD4B718206C78AE11 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------C486CDFBD4B718206C78AE11-- From nobody Tue May 15 00:11:19 2018 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 BD84A12D0C3 for ; Tue, 15 May 2018 00:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 SlOicnlZf8mm for ; Tue, 15 May 2018 00:11:16 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51CDE127023 for ; Tue, 15 May 2018 00:11:16 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 41329219DC for ; Tue, 15 May 2018 03:11:15 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute1.internal (MEProxy); Tue, 15 May 2018 03:11:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=XtYWxo Duf/LHLkatjSmJ9BYMg6KrtPYLyJEnCuBu79U=; b=WrwU6RFKJi0hi8ZLo2U1xg 6/lfA8HCN9ag+tYSzXeFT3qnqADjI+gLjGOCSWTdoS4AiI8klw/D1hbERaqqvLjx rdMDnnbbbRNyvOz1V4MJaORt/tTXZJI7rqm7WRaFcbYo3NNJ+o3LBGV3Dxfrny1o bu0Dk0EOiD2o936B/5rfiu6h54zMzyZoMHTBKP8DqZu3ytjN/x2c9F60pe01v2zO 7AIryltozyfTXiGrvCXfHUehisj40/fGpOemHr5yJmYN6LafXQ4bF4/WWbrM+upR oI1Cx3QZvzenTLNm6QhWBIOUb23W2tTkkaqhYlgi6weypzoPVMW0k9Yif0r0KTxg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id C08264185; Tue, 15 May 2018 03:11:14 -0400 (EDT) Message-Id: <1526368274.3606723.1372383296.1DF94A05@webmail.messagingengine.com> From: Robert Stepanek To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152636827436067230" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 References: <1526301633.2355518.1371292664.496BA737@webmail.messagingengine.com> <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> <77373506-ec5c-4541-b133-83dc9605d0eb@sloti22d1t06> <2d2e532d-9924-4e84-8150-fa7938c1820c@sloti22d1t06> <1526349049.1928575.1372173792.3F4BD2C4@webmail.messagingengine.com> In-Reply-To: Date: Tue, 15 May 2018 09:11:14 +0200 Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 07:11:18 -0000 This is a multi-part message in MIME format. --_----------=_152636827436067230 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, May 15, 2018, at 05:01, Ken Murchison wrote: > On 05/14/2018 09:50 PM, Bron Gondwana wrote: >> On Tue, May 15, 2018, at 09:16, Neil Jenkins wrote: >>> On Mon, 14 May 2018, at 10:40 PM, Robert Stepanek wrote: >>>> The relevant section in RFC 5545 defines: "The "DTSTART" property >>>> value SHOULD be synchronized with the recurrence rule, if >>>> specified. The recurrence set generated with a "DTSTART" property >>>> value not synchronized with the recurrence rule is undefined.">>>> >>>> Let's change SHOULD to MUST for JSCalendar. This causes a potential >>>> difference in how iCalendar and JSCalendar clients might display >>>> the same event, but it's the same issue for two iCalendar clients, >>>> anyways.>>> >>> No, strongly disagree! The point Marten and I are making is that >>> this *is* handled the same way by most (all?) existing clients[..]>> >> [...] I agree with Neil here that the right thing is to document >> existing behaviour and mandate the most popular existing approach.> > And what is existing behavior? If most implementations ignored a > SHOULD, then apparently SHOULD doesn't carry much weight. It also was my understanding, that the SHOULD approach is the one chosen by most current implementations? If it's the other way round, I agree it doesn't make sense to enforce a rule that's ignored in practice. --_----------=_152636827436067230 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, May 15, 2018, at 05:01, Ken Murchison wrote:
On 05/14/2018 09:50 PM, Bron Gondwana wrote:
On Tue, May 15, 2018, at 09:16, Neil Jenkins wrote:
On Mon, 14 May 2018, at 10:40 PM, Robert Stepanek wrote:
The relevant section in RFC 5545 defines: "The "DTSTART" property value SHOULD be synchronized with the recurrence rule, if specified. The recurrence set generated with a "DTSTART" property value not synchronized with the recurrence rule is undefined."

Let's change SHOULD to MUST for JSCalendar. This causes a potential difference in how iCalendar and JSCalendar clients might display the same event, but it's the same issue for two iCalendar clients, anyways.

No, strongly disagree! The point Marten and I are making is that this is handled the same way by most (all?) existing clients[..]

[...] I agree with Neil here that the right thing is to document existing behaviour and mandate the most popular existing approach.

And what is existing behavior?  If most implementations ignored a SHOULD, then apparently SHOULD doesn't carry much weight.

It also was my understanding, that the SHOULD approach is the one chosen by most current implementations? If it's the other way round, I agree it doesn't make sense to enforce a rule that's ignored in practice.
--_----------=_152636827436067230-- From nobody Tue May 15 01:16:21 2018 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 D307F12D778 for ; Tue, 15 May 2018 01:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=cronofy.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 ZgmYf5UpRw2E for ; Tue, 15 May 2018 01:16:12 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 A323D12D7E2 for ; Tue, 15 May 2018 01:16:11 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id g9-v6so10230219uak.7 for ; Tue, 15 May 2018 01:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cronofy.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=f92Xjrslmau6yLbF09Hnbu98rb6R5Fjml7qzWYd8gn0=; b=Uc78Uvy0h1iHxIhH4nlKauDKI/24zM53SgC1ozn3DZRit65zr77n0JhSmbqAx35g2/ nIyFVBql67utEqVr7yrJh2NouB882wXyBPU5BSrxqn/rhWbExauMH9BXH+1tagf5nhaa JULzNwFpNjrXaHx7z02eW0+aRa8IWFBUutxNs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=f92Xjrslmau6yLbF09Hnbu98rb6R5Fjml7qzWYd8gn0=; b=nG6Jl/N+Coewtqo7Tt9k4YXlCYytkha+cFcr78t3OPJd8hY+Yd+CLGoT6+N8BT0/xi Y0X4/KncTf2djpPqxuzXWdy0aN2vmJN/fSYvG6mhxMGQd7LAOFk4Ow+Fqe6Js5nWRsDP s7SLoAngjj3iq+mldhSAC/pK1h8lui2O3oZZyu8D7LK/FhidE4sByOdc5XhgA8M9BRot 0RhhJqdQFkHsL+dP0+8EAJq5Wz7qwd88MJulrkEDjtdrObDJ63gRxdYSvVC7dDr8SWfK lX2ac8A5aEV54c18l3teLnSKtaHLaII90veeVqC+45/NBJJZiCWc2UFH/wZ7QSuSlmRC cRWw== X-Gm-Message-State: ALKqPwecjGROBfF1DVXxCFtLRMkGewgeyJZGjRWSKnMQujURkuGESh5s Ads85zcKv6t9XkSqoJAxGziypi2yvgamKMnLGF7qqaTvLM4= X-Google-Smtp-Source: AB8JxZpeOQB/OIYBp5vqgVqHjEWoOhDgMu/hlEtGiMpHogFGfVBfs7AWeCKh6/pYHykcL9u/Nj896GN/i2jwdf1hZOc= X-Received: by 2002:ab0:15c9:: with SMTP id j9-v6mr2362170uae.199.1526372170307; Tue, 15 May 2018 01:16:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.180.66 with HTTP; Tue, 15 May 2018 01:16:09 -0700 (PDT) In-Reply-To: <1526368274.3606723.1372383296.1DF94A05@webmail.messagingengine.com> References: <1526301633.2355518.1371292664.496BA737@webmail.messagingengine.com> <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> <77373506-ec5c-4541-b133-83dc9605d0eb@sloti22d1t06> <2d2e532d-9924-4e84-8150-fa7938c1820c@sloti22d1t06> <1526349049.1928575.1372173792.3F4BD2C4@webmail.messagingengine.com> <1526368274.3606723.1372383296.1DF94A05@webmail.messagingengine.com> From: Garry Shutler Date: Tue, 15 May 2018 09:16:09 +0100 Message-ID: To: calsify@ietf.org Content-Type: multipart/alternative; boundary="00000000000001ab75056c3a371f" Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 08:16:20 -0000 --00000000000001ab75056c3a371f Content-Type: text/plain; charset="UTF-8" > The "DTSTART" property value SHOULD be synchronized with the recurrence rule, if specified. I think this is fine and correct for what you are currently allowed to do. Generally recurrence rules do align with the DTSTART (which sits ok with SHOULD) but they do not have to, and in practice do not always, which means it can't be changed to a MUST. The problem is more with: > The recurrence set generated with a "DTSTART" property value not synchronized with the recurrence rule is undefined. In practice, this has become defined by how everyone has ended up implementing it. Broadly speaking it is something like: "DTSTART MUST be considered a member of any recurrence rule, whether it aligns with it or not". That's likely too inaccurate a statement but I thought a stab at it would help. *Garry Shutler* | CTO On 15 May 2018 at 08:11, Robert Stepanek wrote: > On Tue, May 15, 2018, at 05:01, Ken Murchison wrote: > > On 05/14/2018 09:50 PM, Bron Gondwana wrote: > > On Tue, May 15, 2018, at 09:16, Neil Jenkins wrote: > > On Mon, 14 May 2018, at 10:40 PM, Robert Stepanek wrote: > > The relevant section in RFC 5545 defines: "The "DTSTART" property value > SHOULD be synchronized with the recurrence rule, if specified. The > recurrence set generated with a "DTSTART" property value not synchronized > with the recurrence rule is undefined." > > Let's change SHOULD to MUST for JSCalendar. This causes a potential > difference in how iCalendar and JSCalendar clients might display the same > event, but it's the same issue for two iCalendar clients, anyways. > > > No, strongly disagree! The point Marten and I are making is that this *is* > handled the same way by most (all?) existing clients[..] > > > [...] I agree with Neil here that the right thing is to document existing > behaviour and mandate the most popular existing approach. > > > And what is existing behavior? If most implementations ignored a SHOULD, > then apparently SHOULD doesn't carry much weight. > > > It also was my understanding, that the SHOULD approach is the one chosen > by most current implementations? If it's the other way round, I agree it > doesn't make sense to enforce a rule that's ignored in practice. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > --00000000000001ab75056c3a371f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> The &quo= t;DTSTART" property value SHOULD be synchronized with the recurrence rule, if specified.

I think this is fine an= d correct for what you are currently allowed to do. Generally recurrence ru= les do align with the DTSTART (which sits ok with SHOULD) but they do not h= ave to, and in practice do not always, which means it can't be changed = to a MUST.

The problem is more with:

> The recurrence set generated with a "DTSTART" property value not synchronized with the recurrence rule is undefined.

In practice, = this has become defined by how everyone has ended up implementing it. Broad= ly speaking it is something like: "DTSTART MUST be considered a member= of any recurrence rule, whether it aligns with it or not". That's= likely too inaccurate a statement but I thought a stab at it would help.


Garry Shutler=C2=A0= |=C2=A0CTO=

On 15 May 2018 at 08:11, Robert Stepanek <rsto@fastmailteam.com> wrote:
On Tue, May 15, 2018, at 05:01, Ken Murchison wr= ote:
On 05/14/2018 09:50 = PM, Bron Gondwana wrote:
On Tue, May 15, 2018, at 09:16, Neil Jenkins wrote:
On Mon, 14 May 2018,= at 10:40 PM, Robert Stepanek wrote:
The relevant section in RFC 5545 defines: &q= uot;The "DTSTART" property value SHOULD be synchronized with the recurrence rule, if specified.=C2=A0The recurrence set generated with a "DTSTART" property value not synchronized with the recurrence rule is undefined."

Let's change SHOULD to MUST for JSCalendar. This causes a potential difference in how iCalendar and JSCalendar clients might display the same event, but it's the same issue for two iCalendar clients, anyways.

No, strongly disagree! The point Marten and I are making is that this=C2=A0is handled the same way by most (all?) existing clients[..]

[...] I agree with Neil here that the right thing is to document existing behaviour and mandate the most popular existing approach.

And what is existing behavior?=C2=A0 If most implementations ignored a SHOULD, then apparently SHOULD doesn't carry much weight.

It also was my understanding, that the SHOULD approach is the one chos= en by most current implementations? If it's the other way round, I agre= e it doesn't make sense to enforce a rule that's ignored in practic= e.

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

--00000000000001ab75056c3a371f-- From nobody Tue May 15 02:28:15 2018 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 8449012D7F1 for ; Tue, 15 May 2018 02:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ribose.onmicrosoft.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 TpQdoq8m8gU5 for ; Tue, 15 May 2018 02:28:11 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-hk2apc01on0040.outbound.protection.outlook.com [104.47.124.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2AF112D77A for ; Tue, 15 May 2018 02:28:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ribose.onmicrosoft.com; s=selector1-ribose-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=r1RMfx0eCF0RVXdMOT4f7kaFrKTW66qLWgWlCNUbAqA=; b=PlLxjpC6QTfOO/eNRC+cljOj1MFFOQ5b2+054z0QA8sdIQsg/i7Lk2Xb17G7sJdTcsEfs1WiwpoGNV/dO8omChhjvZElBxmkvik+/Heh0hDfy8Uye+5PjESKDhRf9dAJXbPChKO6ozccNpdC0OAAjJZgPYtatLsfxJUbgLt9toY= Received: from HK0PR01MB2067.apcprd01.prod.exchangelabs.com (52.133.158.138) by HK0PR01MB1873.apcprd01.prod.exchangelabs.com (52.133.156.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.776.11; Tue, 15 May 2018 09:28:06 +0000 Received: from HK0PR01MB2067.apcprd01.prod.exchangelabs.com ([fe80::4583:bf5b:9ad8:993]) by HK0PR01MB2067.apcprd01.prod.exchangelabs.com ([fe80::4583:bf5b:9ad8:993%13]) with mapi id 15.20.0755.018; Tue, 15 May 2018 09:28:06 +0000 From: Ronald Tse To: "calsify@ietf.org" Thread-Topic: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-06.txt Thread-Index: AQHT5ODXKitdhBUxcUibQW1lo8Rat6QkU6MAgAsZVICAASdVgA== Date: Tue, 15 May 2018 09:28:05 +0000 Message-ID: References: <152557323572.26681.1466351398334547861@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFD1@eusaamb107.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tse@ribose.com; x-originating-ip: [118.140.121.70] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HK0PR01MB1873; 7:0ehV0kOe1iup6UBY2vJMB44FxLE8LtyljNaY3vUyueqF0Y/n8ENheHVDJ7KZwNPlpbaHsH7Sbn75KEWdK29Ypvp5jY+MDXZH9ZIknJZuAn8DVTbExTwCk6Me2bclki3DJtgHAKgUu4QbOkngb7ohZqefDyRPQ3KNZqCLEA2vgn+pbNcDTQePUTORvMS7IAhLvhEKpFbrptWln7sTQS87Xp/4yQvWEl3iYn4xCzPPvbSrBkBqudzMHtJDdcJ5IiYG x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:HK0PR01MB1873; x-ms-traffictypediagnostic: HK0PR01MB1873: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149027)(150027)(6041310)(2016111802025)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(6043046)(201708071742011); SRVR:HK0PR01MB1873; BCL:0; PCL:0; RULEID:; SRVR:HK0PR01MB1873; x-forefront-prvs: 0673F5BE31 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39380400002)(39830400003)(396003)(366004)(13464003)(53754006)(377424004)(189003)(199004)(105586002)(53936002)(6306002)(97736004)(236005)(6512007)(54896002)(6916009)(5640700003)(2351001)(6436002)(6486002)(345774005)(106356001)(36756003)(5250100002)(6116002)(2501003)(5660300001)(229853002)(14454004)(99286004)(83716003)(81166006)(186003)(3846002)(26005)(316002)(86362001)(82746002)(606006)(1730700003)(81156014)(102836004)(966005)(2900100001)(8676002)(7736002)(446003)(478600001)(33656002)(476003)(3660700001)(3280700002)(66066001)(6246003)(2616005)(68736007)(76176011)(8936002)(11346002)(53546011)(2906002)(486006)(6506007)(25786009)(59450400001); DIR:OUT; SFP:1101; SCL:1; SRVR:HK0PR01MB1873; H:HK0PR01MB2067.apcprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:3; A:1; received-spf: None (protection.outlook.com: ribose.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: nH3Z6XSPOfkprCx7Iz49Q5wTRtqNKvN11zxAhtKNTHzFwJcmOHQ7d8Kb4jlvieot0Tb80gYZjVvIYcNXcn05sfKutcFD8Ctnq7Ywarz+seHbdi/EhW1X1jXclrYkFI+hD48if1yyPDZ1Gno2+Asx1wBVuJKj7JrDQ70XGkfC23fCvUnCZy5Ie3HlafZGxcZe spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E5131F5AA1A34CEEB3E7822A067B9481ribosecom_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c5310674-be9b-4c48-5a0e-08d5ba462a45 X-OriginatorOrg: ribose.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5310674-be9b-4c48-5a0e-08d5ba462a45 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2018 09:28:05.9958 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK0PR01MB1873 Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-06.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 09:28:14 -0000 --_000_E5131F5AA1A34CEEB3E7822A067B9481ribosecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We strongly support the submission of this draft to the IESG given its rela= tive maturity, and necessity for interoperability amongst calendar implemen= ters / users. 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 May 14, 2018, at 11:51 PM, Ken Murchison > wrote: I support moving this to IESG, provided any nits have been addressed. On 05/07/2018 10:21 AM, Daniel Migault wrote: Hi everyone, Pleas find the new version of draft-ietf-calext-eventpub-extensions. The do= cument was in WGLC. As discussed in London, it would be helpful to get feed= backs to understand if the draft is ready to be submit to the IESG. We wou= ld appreciate comments/supports on the mailing list by May 15. Yours, Daniel -----Original Message----- From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Saturday, May 05, 2018 10:21 PM To: i-d-announce@ietf.org Cc: calsify@ietf.org Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : Event Publishing Extensions to iCalendar Author : Michael Douglass Filename : draft-ietf-calext-eventpub-extensions-06.txt Pages : 31 Date : 2018-05-05 Abstract: This specification introduces a number of new iCalendar properties and components which are of particular use for event publishers and in social networking. This specification also defines a new STRUCTURED-DATA property for iCalendar [RFC5545] to allow for data that is directly pertinent to an event or task to be included with the calendar data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-06 https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions= -06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-calext-eventpub-extensions-0= 6 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify -- Ken Murchison Cyrus Development Team FastMail US LLC _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify --_000_E5131F5AA1A34CEEB3E7822A067B9481ribosecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4602A1A3EF82C3488C375290B1F52D09@apcprd01.prod.exchangelabs.com> Content-Transfer-Encoding: quoted-printable We strongly support the submission of this draft to the IESG given its rela= tive maturity, and necessity for interoperability amongst calendar implemen= ters / users.

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 May 14, 2018, at 11:51 PM, Ken Murchison <murch@fastmail.com> wrote:
I support moving this to IESG, provided any nits have been = addressed.


On 05/07/2018 10:21 AM, Daniel Migault wrote:
Hi everyone,

Pleas find the new version of draft-ietf-calext-eventpub-extensions. The do= cument was in WGLC. As discussed in London, it would be helpful to get feed= backs to understand if the draft is ready to be submit to the IESG. We wou= ld appreciate comments/supports on the mailing list by May 15.

Yours,
Daniel



-----Original Message-----
From: calsify [mailt= o:calsify-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org
Sent: Saturday, May 05, 2018 10:21 PM
To: i-d-announce@ietf.o= rg
Cc: calsify@ietf.org
Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-06.txt=


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Calendaring Extensions WG of the IETF.

        Title    &nb= sp;      : Event Publishing Extensions to iCa= lendar
        Author    &n= bsp;     : Michael Douglass
Filename &n= bsp;      : draft-ietf-calext-eventpub-extens= ions-06.txt
Pages  = ;         : 31
Date  =           : 2018-05-05
Abstract:
   This specification introduces a number of new iCalendar p= roperties
   and components which are of particular use for event publ= ishers and
   in social networking.

   This specification also defines a new STRUCTURED-DATA pro= perty for
   iCalendar [RFC5545] to allow for data that is directly pe= rtinent to
   an event or task to be included with the calendar data.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-calext-even= tpub-extensions/

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-calext-eventpub-extensions-0= 6


Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

--
Ken Murchison
Cyrus Development Team
FastMail US LLC

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

--_000_E5131F5AA1A34CEEB3E7822A067B9481ribosecom_-- From nobody Tue May 15 02:29:22 2018 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 C112A12D7F1 for ; Tue, 15 May 2018 02:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ribose.onmicrosoft.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 xrVtP6FvRK4N for ; Tue, 15 May 2018 02:29:19 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0081.outbound.protection.outlook.com [104.47.125.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5FE312D77A for ; Tue, 15 May 2018 02:29:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ribose.onmicrosoft.com; s=selector1-ribose-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/D2uGvl7EOWwJpUABH1mu36PUDBqltAvG1gloQwOu9c=; b=Xjh53SFIFqx1+oQQO6QT9GEyfvuSpbIUZxf90EKKjECnCG/ScLrMpbQxJeleBx3iaknpeILf/ehGMLRtXrd4Yupfk13GYIu/5N/k68xm7H9qoZZgDivggpqIMogCddCvRxe4UXuOvr2tzKyD3rWepRYWOuSNdXWiYoNKBu61n50= Received: from HK0PR01MB2067.apcprd01.prod.exchangelabs.com (52.133.158.138) by HK0PR01MB2148.apcprd01.prod.exchangelabs.com (52.133.212.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.755.16; Tue, 15 May 2018 09:29:13 +0000 Received: from HK0PR01MB2067.apcprd01.prod.exchangelabs.com ([fe80::4583:bf5b:9ad8:993]) by HK0PR01MB2067.apcprd01.prod.exchangelabs.com ([fe80::4583:bf5b:9ad8:993%13]) with mapi id 15.20.0755.018; Tue, 15 May 2018 09:29:13 +0000 From: Ronald Tse To: "calsify@ietf.org" Thread-Topic: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt Thread-Index: AQHT5N5OA/XOqL6GQEOXy4Gm42wHrKQkVAaAgAxAmwA= Date: Tue, 15 May 2018 09:29:13 +0000 Message-ID: References: <152557214808.26780.14458282737730003696@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFF3@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118E4AFF3@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tse@ribose.com; x-originating-ip: [118.140.121.70] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HK0PR01MB2148; 7:y4iCTuzh5OpBPhjZKixbZX8KGzqQTSczYQbXf1SWoR2I4Po/QIDPWL/a0PP2r8ZWB5jpE5NB5JNUcXCbaqlmQk8P0lELWF8Gv6zgUbjk1NZYNt8SkP4ggowWKMXZnGnlXoYasuQKJ2k62Q5B2QBBKHVt392+gFsjfFgpTz48vJ8myDQDwCpnYTkL4UpqU0MpO7q47pVgMLs9K/I7KKETvEU3kwpYYbf8dwG21PB0eeRz+KtwLfw/mygaqXdsf39B x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:HK0PR01MB2148; x-ms-traffictypediagnostic: HK0PR01MB2148: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231254)(944501410)(52105095)(10201501046)(149027)(150027)(6041310)(2016111802025)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(6072148)(6043046)(201708071742011); SRVR:HK0PR01MB2148; BCL:0; PCL:0; RULEID:; SRVR:HK0PR01MB2148; x-forefront-prvs: 0673F5BE31 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39830400003)(39380400002)(346002)(396003)(366004)(189003)(377424004)(199004)(53754006)(13464003)(36756003)(2616005)(11346002)(1730700003)(97736004)(486006)(8676002)(446003)(606006)(476003)(81156014)(2351001)(6916009)(99286004)(81166006)(478600001)(8936002)(33656002)(229853002)(966005)(316002)(68736007)(5660300001)(6512007)(54896002)(6306002)(5640700003)(186003)(6246003)(53936002)(6486002)(86362001)(25786009)(2906002)(3846002)(6116002)(2501003)(6506007)(76176011)(3660700001)(3280700002)(26005)(106356001)(105586002)(102836004)(66066001)(14454004)(5250100002)(7736002)(6436002)(82746002)(2900100001)(53546011)(83716003)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:HK0PR01MB2148; H:HK0PR01MB2067.apcprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ribose.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: m3XkVhMLzukfTPeT9fPXIZF8litBkROkAlnlIWgd03NdkN6GFJEYv+TjRFCRWeq7QkLA9SVWMoC70YN0mzgGokH6XUdaGc6hgPgtL4rMUKz4fteWMDhFY9COGu+34LpDC6pyY1TlIg6ncqOTY4hd4e0tw1aiQ4LyzjMlRYN3XjMhY0ducRxNOASkYWEkdxNK spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A06D38595AF14BC982564326FD0B9EDDribosecom_" MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 99530014-a30e-45cf-7b54-08d5ba46527c X-OriginatorOrg: ribose.com X-MS-Exchange-CrossTenant-Network-Message-Id: 99530014-a30e-45cf-7b54-08d5ba46527c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2018 09:29:13.5597 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK0PR01MB2148 Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 09:29:22 -0000 --_000_A06D38595AF14BC982564326FD0B9EDDribosecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree that this draft should proceed to WGLC. Kind regards, Ron _____________________________________ Ronald Tse Ribose Inc. On May 7, 2018, at 10:22 PM, Daniel Migault > wrote: Hi everyone, Pleas find the new version of draft-ietf-calext-ical-relations. As discusse= d in London, it would be helpful to get feed backs to understand if the dra= ft is for a WGLC. We would appreciate comments/supports on the mailing list= by May 15. Yours, Daniel -----Original Message----- From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Saturday, May 05, 2018 10:02 PM To: i-d-announce@ietf.org Cc: calsify@ietf.org Subject: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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-04.txt Pages : 19 Date : 2018-05-05 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-calext-ical-relations-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-calext-ical-relations-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify --_000_A06D38595AF14BC982564326FD0B9EDDribosecom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable I agree that this draft should proceed to WGLC.

Kind regards,
Ron

_____________________________________

Ronald Tse
Ribose Inc.

On May 7, 2018, at 10:22 PM, Daniel Migault <daniel.migault@ericsson.com<= /a>> wrote:

Hi everyone,

Pleas find the new version of draft-ietf-calext-ical-relations. As discusse= d in London, it would be helpful to get feed backs to understand if the dra= ft is for a WGLC. We would appreciate comments/supports on the mailing list= by May 15.

Yours,
Daniel


-----Original Message-----
From: calsify [mailt= o:calsify-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org
Sent: Saturday, May 05, 2018 10:02 PM
To: i-d-announce@ietf.o= rg
Cc: calsify@ietf.org
Subject: [calsify] I-D Action: draft-ietf-calext-ical-relations-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Calendaring Extensions WG of the IETF.

       Title     &nb= sp;     : Support for iCalendar Relationships
       Author     &n= bsp;    : Michael Douglass
Filename &n= bsp;      : draft-ietf-calext-ical-relations-= 04.txt
Pages  = ;         : 19
Date  =           : 2018-05-05
Abstract:
  This specification updates RELATED-TO defined in [RFC5545] and<= br class=3D"">   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-rela= tions/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-calext-ical-relations-04
https://datatracker.ietf.org/doc/html/draft-ietf-calext-ical-relations-04
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-calext-ical-relations-04


Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

--_000_A06D38595AF14BC982564326FD0B9EDDribosecom_-- From nobody Tue May 15 10:12:46 2018 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 F015E126D3F for ; Tue, 15 May 2018 10:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 iq9gPP-C9uNe for ; Tue, 15 May 2018 10:12:43 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 1582F12DA72 for ; Tue, 15 May 2018 10:12:40 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id y72-v6so1371570lfd.2 for ; Tue, 15 May 2018 10:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=X0FqGJ9uykISGyd6Srf8dmYVWhboG9VgzvDMxK9HxmA=; b=TjqDyFREEH5MipKr1yS2Gcf9Mtb5j2xeOVhhmcPT1rQ1Owu+U6akUY2FAE9v0WNi4V dNit6ZCzhxhl78OjBeqEycJbc4MZtI0jQgFphElCPE9Dqj1EIfRTB2hPRiOIXLTt1lhl bQ5Xx0cxdxnMQ1GmWS266CyuVCMttl+4RjD8K3Qu3Ii0C6ynYLFCFi8SBH2rFjDs68FR xspfL0+j9OW6ReazLJSBaI/pGZcSnUtm3QjCRb6V2qyJndOpfvraHMAhLoSMKkaMJSTD 5XaWIYcLbvnYNkFpHu/pJUvpsDUaKT4exmBFk5RBKfPtnlY50okcvaK8RPOEliCxm0Xz 8JZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=X0FqGJ9uykISGyd6Srf8dmYVWhboG9VgzvDMxK9HxmA=; b=BPvRtLfzwr6NUafckZFJKEL42TZcaCgxp5JLxx/bGNb9AKaCAjYEK4Hg/p77eGd3zD ohmOBsv1xW6vIHFo+w6MsH4t+YmNmCkIbe+XHNb7FXnYR4BdvCQI4KYVFxP3CABB3gGT xw1eKzmhYNctqIrYsVGUHPqyZbqNnEGWhdrJXlXbugjyaAH7o9Hd1gBqaVbQT1cxQaFt SWn0F9Q4amuqruthoCXLfURPrNHy2cDU/o4i24myPSPxemSw4L5UPwZEGn+1+SQyqupJ GasIu0kt9w/3CT8NfByE/EN6Qzdk8G3dwANtykXAJrDnkLW+eBQLp+JpI5ahaR5UIZ2D hAVQ== X-Gm-Message-State: ALKqPwfwWF+Ot3Pb3bDm8KqjkRhJRyQjK6tnmtAi/AXD7ZIl0tb3C2c7 UA3NgoIKmUJ/C2rD2D0STnVa8j9zy6VNzxCWVMY0Rw== X-Google-Smtp-Source: AB8JxZqtLbDTzgvFRxS1qKiZ/n/9ENj1+5IlLgl32EeRbFCM6rxdzyUSRXWZWoXwzV3LUIajxsvaZB8mvCRGacr2PfU= X-Received: by 2002:a19:c6c1:: with SMTP id w184-v6mr12932383lff.126.1526404358198; Tue, 15 May 2018 10:12:38 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.158.88 with HTTP; Tue, 15 May 2018 10:12:37 -0700 (PDT) From: Daniel Migault Date: Tue, 15 May 2018 13:12:37 -0400 X-Google-Sender-Auth: 4_fTdbeg0nrbzuGHAHMHhQcb69A Message-ID: To: calsify@ietf.org Content-Type: multipart/alternative; boundary="0000000000008dde23056c41b5b9" Archived-At: Subject: [calsify] draft-ietf-calext-eventpub-extensions-06 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 17:12:45 -0000 --0000000000008dde23056c41b5b9 Content-Type: text/plain; charset="UTF-8" Hi, draft-ietf-calext-eventpub-extensions [1] is already on WGLC. We would like to sufficient reviews to move the document to the IESG. If you have not yet commented the document, please provide your feedbacks by May 29 so we can move the document forward. Yours, Calext co-chairs. [1] https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ --0000000000008dde23056c41b5b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

draft-ietf-calext-e= ventpub-extensions [1] is already on WGLC. We would like to sufficient revi= ews to move the document to the IESG. If you have not yet commented the doc= ument, please provide your feedbacks by May 29 so we can move the document = forward.

Yours,
Calext co-chai= rs.



--0000000000008dde23056c41b5b9-- From nobody Tue May 15 10:12:54 2018 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 1314512E86E for ; Tue, 15 May 2018 10:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 OE05M8YKp3Nr for ; Tue, 15 May 2018 10:12:45 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 4233812DA6E for ; Tue, 15 May 2018 10:12:42 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id 16-v6so1323772lfs.13 for ; Tue, 15 May 2018 10:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=WxlKh4HkIIENcbUgD5kVwctrNNkEHT+VxAo1Kfmfz7E=; b=K4Nz99gguDX98IX8sE4MKjwIgP3HXmmuRqPwEea1bRgLIginKocyecFf2B+dZIuvQj 4uPiHX/VyWG5EdEYdB+6a8CALGGXutfUB9wsfVaEqm6h18PCCCU9rCsp+llagJt0DGhH TLWDe/uAqjNlmXdJywvBLH25qNENgMklIwQ3QVGQFA9ugk6C+2eBpsFgQ2huEA/pmnq7 OKJE0KF4VUh//pCXjnh3JUOpjGnLqziYlSFRF07RieIS6QD9hI2lKV2EfmjID0FViv7p YngUSDdYs6u8klz7NWyGvVtC/BXxeRx+z1uw3e4rihbx9AIVYtDZPPgS0Pr1mwl1m0KG MA6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=WxlKh4HkIIENcbUgD5kVwctrNNkEHT+VxAo1Kfmfz7E=; b=J6DRBfSmkMIPJ2Yu/4R2MhYMpQ61mBeZBtN0ANjuSgak3KB24Jv5OSLGPY+0WzO/pf gmjpIK5twGlTWIGZHpDMKKUulp8fG/gJehdpqkmEKQdWOfEsylYq+m6ilME6xi83anTF iO4iGgSMquOc7Thtuew6cXi0zwxbxD0iWUneTHWGoK0lnuLuozKet+szYTBm03SSrWi4 sbUOJ2kh2jXe84ZunTQhjdBLL1rs5ObDNf9KU4Hp3auDQXw95H3+WJv2mf6xFBly01rb Dh1nrrA72a4ysIYTnbLjyOdqp2bvZ7R73L7uN41oJBOj/DdAYCdh2VYAF1l0E2mU5W/B wZDA== X-Gm-Message-State: ALKqPwer5NSavCOvFPiz/+AjXTcMNEv54ZsOk4t0Ev1OB5tY95kVoGLF jF7ow9Nc6HVAF2aghD8h23/78nGbSYLjuO5g6vtBIw== X-Google-Smtp-Source: AB8JxZoh4Fsv8Xr8btzuPprcqbP6VUVMbwy3Vks0/kfINEjvUPwe0RekhpLCw2wStnmFM6i/6lLewd3vIbTw4DRopZw= X-Received: by 2002:a19:ea48:: with SMTP id i69-v6mr8109486lfh.118.1526404360355; Tue, 15 May 2018 10:12:40 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.158.88 with HTTP; Tue, 15 May 2018 10:12:39 -0700 (PDT) From: Daniel Migault Date: Tue, 15 May 2018 13:12:39 -0400 X-Google-Sender-Auth: COlGbU-HDmg1KIaizweCACn4WRk Message-ID: To: calsify@ietf.org Content-Type: multipart/alternative; boundary="000000000000aec431056c41b541" Archived-At: Subject: [calsify] draft-ietf-calext-ical-relations-04 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 17:12:49 -0000 --000000000000aec431056c41b541 Content-Type: text/plain; charset="UTF-8" Hi, This email starts a 2 week WGLC for draft-ietf-calext-ical-relations-04 [1]. The WGLC call period ends on May 29. Please review the draft and indicate if the draft is ready to be sent to the IESG. Yours, Calext co-chairs [1] https://datatracker.ietf.org/doc/draft-ietf-calext-ical-relations/ --000000000000aec431056c41b541 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000aec431056c41b541-- From nobody Tue May 15 10:17:06 2018 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 5D6BA1270B4 for ; Tue, 15 May 2018 10:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 kL2jJyfu3ai8 for ; Tue, 15 May 2018 10:17:03 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 87319126D3F for ; Tue, 15 May 2018 10:17:03 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id n18-v6so1352018lfh.10 for ; Tue, 15 May 2018 10:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=uchPEaP/QtD+TWkVDFOV+0k9Y4jBml4lVljiZCBrEhA=; b=pB8/Mze3H9k3Igkb/PAGrTTXtezspG1mJ6Tsqj+IimWxA8UkwJueT4qtxTMuU1twua wrwEN993SSRV8zk7Al4ipi/RgQ1WdhXc+lA4Jobkga9vLtUsvTf+h6xh3o4kGbUBdoRU KlgqorvBTO52WYzonuhJlTVtKRYvRAwf1/IKcQdKXGL9AlxyTmnQA9pCUGffKzLp3yrp yXK52J9oSJDwd7PTUptcNdhzbsz7DfRUbtBFeHvlDobZ1GbcjeCQEC/P2GcNQD9lLDdx jZ4Y7y7w4JkwYf2XLFk2AeoH9d1s2ypDA9QOZGVmyjYf0sJUWYxnvdvXvpj+jX+faV/V q0rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=uchPEaP/QtD+TWkVDFOV+0k9Y4jBml4lVljiZCBrEhA=; b=iJ2V+QqYqkQpkRA4mjMfp3YbSKyckYaUksXdgpAOM/sCE7AAvO4AV8cuSMvOEW/MRv OygKCpC9XVexQUcTcEEYycTjq1Fm3rWhKP+PTS1gAXEUhjqoPa3QRMRzwZ50OSrvFoFG LNEQvWoIuYrhO2ohj8aj3KUPKx4tZtNIN0Ifk1xc9QqJwfDelEtc816NoTf1dn8WK9bQ h7GitayzdbttNgPqh+NFhbzseO1EMUj//PocJuc9rUbAnzA4iqKSPlRqw8d2BuoDQA2x 4jvx0KqIsWoIPOVCsKqdYHqRMrbbdcKtfJhXeczma8RxguvS3OMhBX+NAgK8a0cjl9Eh 5Lzg== X-Gm-Message-State: ALKqPwe+zWFX3RidSr8mUjX8wgUL9FvjmbgjC/J2ZcWcLXi+FnlYdfBQ ymenCc6bqmMFMTyvZ7LCaiaUOhUM9dwGGLsS5Ak= X-Google-Smtp-Source: AB8JxZr+oVluLisjIIpseikgU5kvTZJIqiaWso4qoRxmsO09xqre59cleQ/6e8mNsUfKYT4CAXxAJEl8lUbQTm8r6p4= X-Received: by 2002:a2e:9e57:: with SMTP id g23-v6mr7499601ljk.37.1526404621662; Tue, 15 May 2018 10:17:01 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.158.88 with HTTP; Tue, 15 May 2018 10:17:01 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Tue, 15 May 2018 13:17:01 -0400 X-Google-Sender-Auth: EHsMez8g48i2_Mjn6vStGMnYrGU Message-ID: To: calsify@ietf.org Content-Type: multipart/alternative; boundary="00000000000041fde0056c41c579" Archived-At: Subject: Re: [calsify] IETF102 session X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 17:17:05 -0000 --00000000000041fde0056c41c579 Content-Type: text/plain; charset="UTF-8" Hi, Our understanding is that there is no strong interest from the WG to meet during the IETF102 in Montreal. Unless being told otherwise, we will not schedule any session for Cal ext WG. Yours, Daniel On Fri, May 11, 2018 at 4:53 PM, Daniel Migault wrote: > Hi, > > We are asking the WG whether it is willing to meet at the IETF102 in > Montreal. If you believe the WG should meet, please let us know by > Wednesday May 16. > > Yours, > Daniel > --00000000000041fde0056c41c579 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Our understanding i= s that there is no strong interest from the WG to meet during the IETF102 i= n Montreal. Unless being told otherwise, we will not schedule any session f= or Cal ext WG.

Yours,
Daniel

On = Fri, May 11, 2018 at 4:53 PM, Daniel Migault <daniel.migault@er= icsson.com> wrote:
Hi,

We are asking the WG whether it i= s willing to meet at the IETF102 in Montreal. If you believe the WG should = meet, please let us know by Wednesday May 16.

Yours,
Daniel

--00000000000041fde0056c41c579-- From nobody Tue May 15 14:12:15 2018 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 9283612EB19 for ; Tue, 15 May 2018 14:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org 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 W8sx2CI2jXos for ; Tue, 15 May 2018 14:12:02 -0700 (PDT) Received: from mailrelay2-1.pub.mailoutpod1-cph3.one.com (mailrelay2-1.pub.mailoutpod1-cph3.one.com [46.30.210.183]) (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 76C0C120726 for ; Tue, 15 May 2018 14:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=B9Csthc9/CPMdsis922L3JSToB4bZQVy5ajMbBpzzFU=; b=p6lTGP1/6nQ3x8tEoCWK0fNS64Fk0C8WbjGLnoO9EvtDdAelURNT7HhBdcDjfnsm5MCG1IQPz0g6k YnPf1ISQHMYQ04Hp7BN79gnEzzC63Q5eEFFNYV4T1YAvfTToWJ0gYbhTBvEMU2/E+rzXqkdCm0WnCx a4MhdLIigqcpc1cE= X-HalOne-Cookie: b10fce0cd48727610f4ab94854c36e917917f8b7 X-HalOne-ID: 9a0fb8b3-5884-11e8-bb74-d0431ea8a290 Received: from smtp.dmfs.org (unknown [91.47.32.197]) by mailrelay2.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 9a0fb8b3-5884-11e8-bb74-d0431ea8a290; Tue, 15 May 2018 21:11:58 +0000 (UTC) Received: from boss.localdomain (boss [192.168.2.105]) by smtp.dmfs.org (Postfix) with ESMTPSA id B1D3326 for ; Tue, 15 May 2018 23:11:57 +0200 (CEST) To: calsify@ietf.org References: <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> From: Marten Gajda Message-ID: <478ec7b1-298d-06da-42ba-fa06c6fb396e@dmfs.org> Date: Tue, 15 May 2018 23:11:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------977208B1EED5EA32718548FF" Content-Language: en-US Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2018 21:12:11 -0000 This is a multi-part message in MIME format. --------------977208B1EED5EA32718548FF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit How about using |false| to identify exdates? |"recurrenceOverrides": { "2018-05-14T11:53:00": false } | I don’t really like varying types for object members but in this case it seems to be a reasonable solution which doesn’t bear any ambiguity. Marten Am 14.05.2018 um 03:56 schrieb Neil Jenkins: > Looking at this again, I realised today the EXDATE representation is > problematic in that it is incompatible with the JMAP patch format. > Specifically, by applying semantic meaning to mapping to `null`, you > can't then use mapping to `null` in a patch as a means of removing > that property, as that's a different action. > > I suggest we instead represent EXDATE like so: > |"recurrenceOverrides": { "2018-05-14T11:53:00": { "method": "cancel" } }| > This is both more obvious if you are looking at an object and have > never seen the spec, and is consistent with the way this is > represented in the iTIP messages sent out. I suggest the > /method/ property MUST NOT appear in an override if it's not a > cancellation; if it is a cancellation it MUST be the only property in > the object. > > Neil. > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify ​ -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------977208B1EED5EA32718548FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+CiAgPC9oZWFkPgogIDxib2R5IHRl eHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPgogICAgPGRpdiBjbGFzcz0ibWFya2Rv d24taGVyZS13cmFwcGVyIiBkYXRhLW1kLXVybD0iVGh1bmRlcmJpcmQiCiAgICAgIHN0eWxl PSIiIG1hcmtkb3duLWhlcmUtd3JhcHBlci1jb250ZW50LW1vZGlmaWVkPSJ0cnVlIj4KICAg ICAgPHAgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAxLjJlbSAhIGltcG9ydGFudDsiPkhvdyBh Ym91dCB1c2luZyA8Y29kZSBzdHlsZT0iZm9udC1zaXplOiAwLjg1ZW07IGZvbnQtZmFtaWx5 OiBDb25zb2xhcyxJbmNvbnNvbGF0YSxDb3VyaWVyLG1vbm9zcGFjZTttYXJnaW46IDBweCAw LjE1ZW07IHBhZGRpbmc6IDBweCAwLjNlbTsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyBib3Jk ZXI6IDFweCBzb2xpZCByZ2IoMjM0LCAyMzQsIDIzNCk7IGJhY2tncm91bmQtY29sb3I6IHJn YigyNDgsIDI0OCwgMjQ4KTsgYm9yZGVyLXJhZGl1czogM3B4OyBkaXNwbGF5OiBpbmxpbmU7 Ij5mYWxzZTwvY29kZT4KICAgICAgICB0byBpZGVudGlmeSBleGRhdGVzPzwvcD4KICAgICAg PHByZSBzdHlsZT0iZm9udC1zaXplOiAwLjg1ZW07IGZvbnQtZmFtaWx5OiBDb25zb2xhcyxJ bmNvbnNvbGF0YSxDb3VyaWVyLG1vbm9zcGFjZTtmb250LXNpemU6IDFlbTsgbGluZS1oZWln aHQ6IDEuMmVtO21hcmdpbjogMS4yZW0gMHB4OyI+PGNvZGUgc3R5bGU9ImZvbnQtc2l6ZTog MC44NWVtOyBmb250LWZhbWlseTogQ29uc29sYXMsSW5jb25zb2xhdGEsQ291cmllcixtb25v c3BhY2U7bWFyZ2luOiAwcHggMC4xNWVtOyBwYWRkaW5nOiAwcHggMC4zZW07IHdoaXRlLXNw YWNlOiBwcmUtd3JhcDsgYm9yZGVyOiAxcHggc29saWQgcmdiKDIzNCwgMjM0LCAyMzQpOyBi YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ4LCAyNDgsIDI0OCk7IGJvcmRlci1yYWRpdXM6IDNw eDsgZGlzcGxheTogaW5saW5lO3doaXRlLXNwYWNlOiBwcmU7IG92ZXJmbG93OiBhdXRvOyBi b3JkZXItcmFkaXVzOiAzcHg7IGJvcmRlcjogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0 KTsgcGFkZGluZzogMC41ZW0gMC43ZW07IGRpc3BsYXk6IGJsb2NrICEgaW1wb3J0YW50OyI+ InJlY3VycmVuY2VPdmVycmlkZXMiOiB7CiAgICAiMjAxOC0wNS0xNFQxMTo1MzowMCI6IGZh bHNlCn0KPC9jb2RlPjwvcHJlPgogICAgICA8cCBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDEu MmVtICEgaW1wb3J0YW50OyI+SSBkb27igJl0IHJlYWxseSBsaWtlCiAgICAgICAgdmFyeWlu ZyB0eXBlcyBmb3Igb2JqZWN0IG1lbWJlcnMgYnV0IGluIHRoaXMgY2FzZSBpdCBzZWVtcyB0 byBiZQogICAgICAgIGEgcmVhc29uYWJsZSBzb2x1dGlvbiB3aGljaCBkb2VzbuKAmXQgYmVh ciBhbnkgYW1iaWd1aXR5LjwvcD4KICAgICAgPHAgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAx LjJlbSAhIGltcG9ydGFudDsiPk1hcnRlbjxicj4KICAgICAgPC9wPgogICAgICA8cCBzdHls ZT0ibWFyZ2luOiAwcHggMHB4IDEuMmVtICEgaW1wb3J0YW50OyI+QW0gMTQuMDUuMjAxOCB1 bQogICAgICAgIDAzOjU2IHNjaHJpZWIgTmVpbCBKZW5raW5zOjwvcD4KICAgICAgPHAgc3R5 bGU9Im1hcmdpbjogMHB4IDBweCAxLjJlbSAhIGltcG9ydGFudDsiPjwvcD4KICAgICAgPGRp diBjbGFzcz0ibWFya2Rvd24taGVyZS1leGNsdWRlIj4KICAgICAgICA8cD48L3A+CiAgICAg ICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIKICAgICAgICAgIGNpdGU9Im1pZDpkMTQ5MWZk ZC1mZjNiLTQ4ZTItOWRhNS05Y2FiMTVmYTViM2ZAc2xvdGkyMmQxdDA2Ij4KICAgICAgICAg IDx0aXRsZT48L3RpdGxlPgogICAgICAgICAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4jZmFz dG1haWwtcXVvdGVkIHAuZmFzdG1haWwtcXVvdGVkLU1zb05vcm1hbCwjZmFzdG1haWwtcXVv dGVkICBwLmZhc3RtYWlsLXF1b3RlZC1Nc29Ob1NwYWNpbmd7bWFyZ2luLXRvcDowcHg7bWFy Z2luLXJpZ2h0OjBweDttYXJnaW4tYm90dG9tOjBweDttYXJnaW4tbGVmdDowcHg7fQoKcC5N c29Ob3JtYWwscC5Nc29Ob1NwYWNpbmd7bWFyZ2luOjB9PC9zdHlsZT4KICAgICAgICAgIDxk aXY+TG9va2luZyBhdCB0aGlzIGFnYWluLCBJIHJlYWxpc2VkIHRvZGF5IHRoZSBFWERBVEUK ICAgICAgICAgICAgcmVwcmVzZW50YXRpb24gaXMgcHJvYmxlbWF0aWMgaW4gdGhhdCBpdCBp cyBpbmNvbXBhdGlibGUKICAgICAgICAgICAgd2l0aCB0aGUgSk1BUCBwYXRjaCBmb3JtYXQu IFNwZWNpZmljYWxseSwgYnkgYXBwbHlpbmcKICAgICAgICAgICAgc2VtYW50aWMgbWVhbmlu ZyB0byBtYXBwaW5nIHRvIGBudWxsYCwgeW91IGNhbid0IHRoZW4gdXNlCiAgICAgICAgICAg IG1hcHBpbmcgdG8gYG51bGxgIGluIGEgcGF0Y2ggYXMgYSBtZWFucyBvZiByZW1vdmluZyB0 aGF0CiAgICAgICAgICAgIHByb3BlcnR5LCBhcyB0aGF0J3MgYSBkaWZmZXJlbnQgYWN0aW9u Ljxicj4KICAgICAgICAgIDwvZGl2PgogICAgICAgICAgPGRpdj48YnI+CiAgICAgICAgICA8 L2Rpdj4KICAgICAgICAgIDxkaXY+SSBzdWdnZXN0IHdlIGluc3RlYWQgcmVwcmVzZW50IEVY REFURSBsaWtlIHNvOjxicj4KICAgICAgICAgIDwvZGl2PgogICAgICAgICAgPHByZSBzdHls ZT0ibWFyZ2luLXRvcDoxLjJlbTttYXJnaW4tcmlnaHQ6MHB4O21hcmdpbi1ib3R0b206MS4y ZW07bWFyZ2luLWxlZnQ6MHB4O3BhZGRpbmctdG9wOjBweDtwYWRkaW5nLXJpZ2h0OjBweDtw YWRkaW5nLWJvdHRvbTowcHg7cGFkZGluZy1sZWZ0OjBweDtjb2xvcjpyZ2IoMzEsIDMxLCAz MSk7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC12YXJpYW50LWxpZ2F0dXJlczpub3JtYWw7Zm9u dC12YXJpYW50LWNhcHM6bm9ybWFsO2ZvbnQtdmFyaWFudC1udW1lcmljOmluaGVyaXQ7Zm9u dC12YXJpYW50LWVhc3QtYXNpYW46aW5oZXJpdDtmb250LXdlaWdodDo0MDA7Zm9udC1zdHJl dGNoOmluaGVyaXQ7Zm9udC1zaXplOjFlbTtsaW5lLWhlaWdodDoxLjJlbTtmb250LWZhbWls eTpDb25zb2xhcywgSW5jb25zb2xhdGEsIENvdXJpZXIsIG1vbm9zcGFjZTtsZXR0ZXItc3Bh Y2luZzotMC4xcHg7dGV4dC1hbGlnbjpzdGFydDt3aGl0ZS1zcGFjZTpwcmUtd3JhcDt3b3Jk LXdyYXA6YnJlYWstd29yZDtvdmVyZmxvdy13cmFwOmJyZWFrLXdvcmQ7b3JwaGFuczoyO3Rl eHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3dpZG93czoyO3dvcmQtc3BhY2lu ZzowcHg7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDowcHg7YmFja2dyb3VuZC1jb2xvcjpy Z2IoMjU1LCAyNTUsIDI1NSk7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1k ZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7Ij48Y29kZSBzdHlsZT0ibWFyZ2luLXRvcDowcHg7 bWFyZ2luLXJpZ2h0OjAuMTVlbTttYXJnaW4tYm90dG9tOjBweDttYXJnaW4tbGVmdDowLjE1 ZW07cGFkZGluZy10b3A6MC41ZW07cGFkZGluZy1yaWdodDowLjdlbTtwYWRkaW5nLWJvdHRv bTowLjVlbTtwYWRkaW5nLWxlZnQ6MC43ZW07Y29sb3I6aW5oZXJpdDtmb250LXN0eWxlOmlu aGVyaXQ7Zm9udC12YXJpYW50LWxpZ2F0dXJlczppbmhlcml0O2ZvbnQtdmFyaWFudC1jYXBz OmluaGVyaXQ7Zm9udC12YXJpYW50LW51bWVyaWM6aW5oZXJpdDtmb250LXZhcmlhbnQtZWFz dC1hc2lhbjppbmhlcml0O2ZvbnQtd2VpZ2h0OmluaGVyaXQ7Zm9udC1zdHJldGNoOmluaGVy aXQ7Zm9udC1zaXplOjAuODVlbTtsaW5lLWhlaWdodDppbmhlcml0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzLCBJbmNvbnNvbGF0YSwgQ291cmllciwgbW9ub3NwYWNlO2xldHRlci1zcGFjaW5n OmluaGVyaXQ7dGV4dC1hbGlnbjppbmhlcml0O2JhY2tncm91bmQtY29sb3I6cmdiKDI0OCwg MjQ4LCAyNDgpO3doaXRlLXNwYWNlOnByZTtvdmVyZmxvdy14OmF1dG87b3ZlcmZsb3cteTph dXRvO2JvcmRlci10b3AtbGVmdC1yYWRpdXM6M3B4O2JvcmRlci10b3AtcmlnaHQtcmFkaXVz OjNweDtib3JkZXItYm90dG9tLXJpZ2h0LXJhZGl1czozcHg7Ym9yZGVyLWJvdHRvbS1sZWZ0 LXJhZGl1czozcHg7Ym9yZGVyLXRvcC13aWR0aDoxcHg7Ym9yZGVyLXJpZ2h0LXdpZHRoOjFw eDtib3JkZXItYm90dG9tLXdpZHRoOjFweDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVy LXRvcC1zdHlsZTpzb2xpZDtib3JkZXItcmlnaHQtc3R5bGU6c29saWQ7Ym9yZGVyLWJvdHRv bS1zdHlsZTpzb2xpZDtib3JkZXItbGVmdC1zdHlsZTpzb2xpZDtib3JkZXItdG9wLWNvbG9y OnJnYigyMDQsIDIwNCwgMjA0KTtib3JkZXItcmlnaHQtY29sb3I6cmdiKDIwNCwgMjA0LCAy MDQpO2JvcmRlci1ib3R0b20tY29sb3I6cmdiKDIwNCwgMjA0LCAyMDQpO2JvcmRlci1sZWZ0 LWNvbG9yOnJnYigyMDQsIDIwNCwgMjA0KTtib3JkZXItaW1hZ2Utc291cmNlOmluaXRpYWw7 Ym9yZGVyLWltYWdlLXNsaWNlOmluaXRpYWw7Ym9yZGVyLWltYWdlLXdpZHRoOmluaXRpYWw7 Ym9yZGVyLWltYWdlLW91dHNldDppbml0aWFsO2JvcmRlci1pbWFnZS1yZXBlYXQ6aW5pdGlh bDtkaXNwbGF5OmJsb2NrICFpbXBvcnRhbnQ7Ij4icmVjdXJyZW5jZU92ZXJyaWRlcyI6IHsK ICAgICIyMDE4LTA1LTE0VDExOjUzOjAwIjogewogICAgICAgICJtZXRob2QiOiAiY2FuY2Vs IgogICB9Cn08L2NvZGU+PC9wcmU+CiAgICAgICAgICA8ZGl2PlRoaXMgaXMgYm90aCBtb3Jl IG9idmlvdXMgaWYgeW91IGFyZSBsb29raW5nIGF0IGFuIG9iamVjdAogICAgICAgICAgICBh bmQgaGF2ZSBuZXZlciBzZWVuIHRoZSBzcGVjLCBhbmQgaXMgY29uc2lzdGVudCB3aXRoIHRo ZSB3YXkKICAgICAgICAgICAgdGhpcyBpcyByZXByZXNlbnRlZCBpbiB0aGUgaVRJUCBtZXNz YWdlcyBzZW50IG91dC4gSSBzdWdnZXN0CiAgICAgICAgICAgIHRoZSA8aT5tZXRob2Q8L2k+ wqBwcm9wZXJ0eSBNVVNUIE5PVCBhcHBlYXIgaW4gYW4gb3ZlcnJpZGUKICAgICAgICAgICAg aWYgaXQncyBub3QgYSBjYW5jZWxsYXRpb247IGlmIGl0IGlzIGEgY2FuY2VsbGF0aW9uIGl0 IE1VU1QKICAgICAgICAgICAgYmUgdGhlIG9ubHkgcHJvcGVydHkgaW4gdGhlIG9iamVjdC48 YnI+CiAgICAgICAgICA8L2Rpdj4KICAgICAgICAgIDxkaXY+PGJyPgogICAgICAgICAgPC9k aXY+CiAgICAgICAgICA8ZGl2Pk5laWwuPGJyPgogICAgICAgICAgPC9kaXY+CiAgICAgICAg ICA8YnI+CiAgICAgICAgICA8ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVy Ij48L2ZpZWxkc2V0PgogICAgICAgICAgPGJyPgogICAgICAgICAgPHByZSB3cmFwPSIiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmNhbHNpZnkg bWFpbGluZyBsaXN0CjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9 Im1haWx0bzpjYWxzaWZ5QGlldGYub3JnIj5jYWxzaWZ5QGlldGYub3JnPC9hPgo8YSBjbGFz cz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2NhbHNpZnkiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2Fsc2lmeTwvYT4KPC9wcmU+CiAgICAgICAgPC9ibG9ja3F1b3RlPgogICAg ICAgIDxwPjwvcD4KICAgICAgPC9kaXY+CiAgICAgIDxwIHN0eWxlPSJtYXJnaW46IDBweCAw cHggMS4yZW0gISBpbXBvcnRhbnQ7Ij48L3A+CiAgICAgIDxkaXYKdGl0bGU9Ik1ESDpQSEEr U0c5M0lHRmliM1YwSUhWemFXNW5JR0JtWVd4elpXQWdkRzhnYVdSbGJuUnBabmtnWlhoa1lY Umxjejg4WW5JK1BDOXdQanh3UG1CZ1lEeGljajQ4WTI5a1pUNGljbVZqZFhKeVpXNWpaVTky WlhKeWFXUmxjeUk2SUhzOFluSStKbTVpYzNBN0ptNWljM0E3Sm01aQpjM0E3SUNJeU1ERTRM VEExTFRFMFZERXhPalV6T2pBd0lqb2dabUZzYzJVOFluSStmVHd2WTI5a1pUNDhZbkkrUEM5 d1BnbzhjRDVnCllHQThZbkkrUEM5d1Bra2daRzl1SjNRZ2NtVmhiR3g1SUd4cGEyVWdkbUZ5 ZVdsdVp5QjBlWEJsY3lCbWIzSWdiMkpxWldOMElHMWwKYldKbGNuTWdZblYwSUdsdUlIUm9h WE1nWTJGelpTQnBkQ0J6WldWdGN5QjBieUJpWlNCaElISmxZWE52Ym1GaWJHVWdjMjlzZFhS cApiMjRnZDJocFkyZ2daRzlsYzI0bmRDQmlaV0Z5SUdGdWVTQmhiV0pwWjNWcGRIa3VQR0p5 UGp4aWNqNDhZbkkrUEdScGRpQmpiR0Z6CmN6MGliVzk2TFdOcGRHVXRjSEpsWm1sNElqNUJi U0F4TkM0d05TNHlNREU0SUhWdElEQXpPalUySUhOamFISnBaV0lnVG1WcGJDQksKWlc1cmFX NXpPanhpY2o0OEwyUnBkajQ4WW14dlkydHhkVzkwWlNCMGVYQmxQU0pqYVhSbElpQmphWFJs UFNKdGFXUTZaREUwT1RGbQpaR1F0Wm1ZellpMDBPR1V5TFRsa1lUVXRPV05oWWpFMVptRTFZ ak5tUUhOc2IzUnBNakprTVhRd05pSStQSFJwZEd4bFBqd3ZkR2wwCmJHVStQSE4wZVd4bElI UjVjR1U5SW5SbGVIUXZZM056SWo0alptRnpkRzFoYVd3dGNYVnZkR1ZrSUhBdVptRnpkRzFo YVd3dGNYVnYKZEdWa0xVMXpiMDV2Y20xaGJDd2pabUZ6ZEcxaGFXd3RjWFZ2ZEdWa0lDQndM bVpoYzNSdFlXbHNMWEYxYjNSbFpDMU5jMjlPYjFOdwpZV05wYm1kN2JXRnlaMmx1TFhSdmNE b3djSGc3YldGeVoybHVMWEpwWjJoME9qQndlRHR0WVhKbmFXNHRZbTkwZEc5dE9qQndlRHR0 CllYSm5hVzR0YkdWbWREb3djSGc3ZlFvS2NDNU5jMjlPYjNKdFlXd3NjQzVOYzI5T2IxTndZ V05wYm1kN2JXRnlaMmx1T2pCOVBDOXoKZEhsc1pUNDhaR2wyUGt4dmIydHBibWNnWVhRZ2RH aHBjeUJoWjJGcGJpd2dTU0J5WldGc2FYTmxaQ0IwYjJSaGVTQjBhR1VnUlZoRQpRVlJGSUhK bGNISmxjMlZ1ZEdGMGFXOXVJR2x6SUhCeWIySnNaVzFoZEdsaklHbHVJSFJvWVhRZ2FYUWdh WE1nYVc1amIyMXdZWFJwCllteGxJSGRwZEdnZ2RHaGxJRXBOUVZBZ2NHRjBZMmdnWm05eWJX RjBMaUJUY0dWamFXWnBZMkZzYkhrc0lHSjVJR0Z3Y0d4NWFXNW4KSUhObGJXRnVkR2xqSUcx bFlXNXBibWNnZEc4Z2JXRndjR2x1WnlCMGJ5QmdiblZzYkdBc0lIbHZkU0JqWVc0bmRDQjBh R1Z1SUhWegpaU0J0WVhCd2FXNW5JSFJ2SUdCdWRXeHNZQ0JwYmlCaElIQmhkR05vSUdGeklH RWdiV1ZoYm5NZ2IyWWdjbVZ0YjNacGJtY2dkR2hoCmRDQndjbTl3WlhKMGVTd2dZWE1nZEdo aGRDZHpJR0VnWkdsbVptVnlaVzUwSUdGamRHbHZiaTQ4WW5JK1BDOWthWFkrUEdScGRqNDgK WW5JK1BDOWthWFkrUEdScGRqNUpJSE4xWjJkbGMzUWdkMlVnYVc1emRHVmhaQ0J5WlhCeVpY TmxiblFnUlZoRVFWUkZJR3hwYTJVZwpjMjg2UEdKeVBqd3ZaR2wyUGp4d2NtVWdjM1I1YkdV OUltMWhjbWRwYmkxMGIzQTZNUzR5WlcwN2JXRnlaMmx1TFhKcFoyaDBPakJ3CmVEdHRZWEpu YVc0dFltOTBkRzl0T2pFdU1tVnRPMjFoY21kcGJpMXNaV1owT2pCd2VEdHdZV1JrYVc1bkxY UnZjRG93Y0hnN2NHRmsKWkdsdVp5MXlhV2RvZERvd2NIZzdjR0ZrWkdsdVp5MWliM1IwYjIw Nk1IQjRPM0JoWkdScGJtY3RiR1ZtZERvd2NIZzdZMjlzYjNJNgpjbWRpS0RNeExDQXpNU3dn TXpFcE8yWnZiblF0YzNSNWJHVTZibTl5YldGc08yWnZiblF0ZG1GeWFXRnVkQzFzYVdkaGRI VnlaWE02CmJtOXliV0ZzTzJadmJuUXRkbUZ5YVdGdWRDMWpZWEJ6T201dmNtMWhiRHRtYjI1 MExYWmhjbWxoYm5RdGJuVnRaWEpwWXpwcGJtaGwKY21sME8yWnZiblF0ZG1GeWFXRnVkQzFs WVhOMExXRnphV0Z1T21sdWFHVnlhWFE3Wm05dWRDMTNaV2xuYUhRNk5EQXdPMlp2Ym5RdApj M1J5WlhSamFEcHBibWhsY21sME8yWnZiblF0YzJsNlpUb3haVzA3YkdsdVpTMW9aV2xuYUhR Nk1TNHlaVzA3Wm05dWRDMW1ZVzFwCmJIazZRMjl1YzI5c1lYTXNJRWx1WTI5dWMyOXNZWFJo TENCRGIzVnlhV1Z5TENCdGIyNXZjM0JoWTJVN2JHVjBkR1Z5TFhOd1lXTnAKYm1jNkxUQXVN WEI0TzNSbGVIUXRZV3hwWjI0NmMzUmhjblE3ZDJocGRHVXRjM0JoWTJVNmNISmxMWGR5WVhB N2QyOXlaQzEzY21GdwpPbUp5WldGckxYZHZjbVE3YjNabGNtWnNiM2N0ZDNKaGNEcGljbVZo YXkxM2IzSmtPMjl5Y0doaGJuTTZNanQwWlhoMExXbHVaR1Z1CmREb3djSGc3ZEdWNGRDMTBj bUZ1YzJadmNtMDZibTl1WlR0M2FXUnZkM002TWp0M2IzSmtMWE53WVdOcGJtYzZNSEI0T3kx M1pXSnIKYVhRdGRHVjRkQzF6ZEhKdmEyVXRkMmxrZEdnNk1IQjRPMkpoWTJ0bmNtOTFibVF0 WTI5c2IzSTZjbWRpS0RJMU5Td2dNalUxTENBeQpOVFVwTzNSbGVIUXRaR1ZqYjNKaGRHbHZi aTF6ZEhsc1pUcHBibWwwYVdGc08zUmxlSFF0WkdWamIzSmhkR2x2YmkxamIyeHZjanBwCmJt bDBhV0ZzT3lJK1BHTnZaR1VnYzNSNWJHVTlJbTFoY21kcGJpMTBiM0E2TUhCNE8yMWhjbWRw YmkxeWFXZG9kRG93TGpFMVpXMDcKYldGeVoybHVMV0p2ZEhSdmJUb3djSGc3YldGeVoybHVM V3hsWm5RNk1DNHhOV1Z0TzNCaFpHUnBibWN0ZEc5d09qQXVOV1Z0TzNCaApaR1JwYm1jdGNt bG5hSFE2TUM0M1pXMDdjR0ZrWkdsdVp5MWliM1IwYjIwNk1DNDFaVzA3Y0dGa1pHbHVaeTFz WldaME9qQXVOMlZ0Ck8yTnZiRzl5T21sdWFHVnlhWFE3Wm05dWRDMXpkSGxzWlRwcGJtaGxj bWwwTzJadmJuUXRkbUZ5YVdGdWRDMXNhV2RoZEhWeVpYTTYKYVc1b1pYSnBkRHRtYjI1MExY WmhjbWxoYm5RdFkyRndjenBwYm1obGNtbDBPMlp2Ym5RdGRtRnlhV0Z1ZEMxdWRXMWxjbWxq T21sdQphR1Z5YVhRN1ptOXVkQzEyWVhKcFlXNTBMV1ZoYzNRdFlYTnBZVzQ2YVc1b1pYSnBk RHRtYjI1MExYZGxhV2RvZERwcGJtaGxjbWwwCk8yWnZiblF0YzNSeVpYUmphRHBwYm1obGNt bDBPMlp2Ym5RdGMybDZaVG93TGpnMVpXMDdiR2x1WlMxb1pXbG5hSFE2YVc1b1pYSnAKZER0 bWIyNTBMV1poYldsc2VUcERiMjV6YjJ4aGN5d2dTVzVqYjI1emIyeGhkR0VzSUVOdmRYSnBa WElzSUcxdmJtOXpjR0ZqWlR0cwpaWFIwWlhJdGMzQmhZMmx1WnpwcGJtaGxjbWwwTzNSbGVI UXRZV3hwWjI0NmFXNW9aWEpwZER0aVlXTnJaM0p2ZFc1a0xXTnZiRzl5Ck9uSm5ZaWd5TkRn c0lESTBPQ3dnTWpRNEtUdDNhR2wwWlMxemNHRmpaVHB3Y21VN2IzWmxjbVpzYjNjdGVEcGhk WFJ2TzI5MlpYSm0KYkc5M0xYazZZWFYwYnp0aWIzSmtaWEl0ZEc5d0xXeGxablF0Y21Ga2FY VnpPak53ZUR0aWIzSmtaWEl0ZEc5d0xYSnBaMmgwTFhKaApaR2wxY3pvemNIZzdZbTl5WkdW eUxXSnZkSFJ2YlMxeWFXZG9kQzF5WVdScGRYTTZNM0I0TzJKdmNtUmxjaTFpYjNSMGIyMHRi R1ZtCmRDMXlZV1JwZFhNNk0zQjRPMkp2Y21SbGNpMTBiM0F0ZDJsa2RHZzZNWEI0TzJKdmNt UmxjaTF5YVdkb2RDMTNhV1IwYURveGNIZzcKWW05eVpHVnlMV0p2ZEhSdmJTMTNhV1IwYURv eGNIZzdZbTl5WkdWeUxXeGxablF0ZDJsa2RHZzZNWEI0TzJKdmNtUmxjaTEwYjNBdApjM1I1 YkdVNmMyOXNhV1E3WW05eVpHVnlMWEpwWjJoMExYTjBlV3hsT25OdmJHbGtPMkp2Y21SbGNp MWliM1IwYjIwdGMzUjViR1U2CmMyOXNhV1E3WW05eVpHVnlMV3hsWm5RdGMzUjViR1U2YzI5 c2FXUTdZbTl5WkdWeUxYUnZjQzFqYjJ4dmNqcHlaMklvTWpBMExDQXkKTURRc0lESXdOQ2s3 WW05eVpHVnlMWEpwWjJoMExXTnZiRzl5T25KbllpZ3lNRFFzSURJd05Dd2dNakEwS1R0aWIz SmtaWEl0WW05MApkRzl0TFdOdmJHOXlPbkpuWWlneU1EUXNJREl3TkN3Z01qQTBLVHRpYjNK a1pYSXRiR1ZtZEMxamIyeHZjanB5WjJJb01qQTBMQ0F5Ck1EUXNJREl3TkNrN1ltOXlaR1Z5 TFdsdFlXZGxMWE52ZFhKalpUcHBibWwwYVdGc08ySnZjbVJsY2kxcGJXRm5aUzF6YkdsalpU cHAKYm1sMGFXRnNPMkp2Y21SbGNpMXBiV0ZuWlMxM2FXUjBhRHBwYm1sMGFXRnNPMkp2Y21S bGNpMXBiV0ZuWlMxdmRYUnpaWFE2YVc1cApkR2xoYkR0aWIzSmtaWEl0YVcxaFoyVXRjbVZ3 WldGME9tbHVhWFJwWVd3N1pHbHpjR3hoZVRwaWJHOWpheUFoYVcxd2IzSjBZVzUwCk95SStJ bkpsWTNWeWNtVnVZMlZQZG1WeWNtbGtaWE1pT2lCN0NpQWdJQ0FpTWpBeE9DMHdOUzB4TkZR eE1UbzFNem93TUNJNklIc0sKSUNBZ0lDQWdJQ0FpYldWMGFHOWtJam9nSW1OaGJtTmxiQ0lL SUNBZ2ZRcDlQQzlqYjJSbFBqd3ZjSEpsUGp4a2FYWStWR2hwY3lCcApjeUJpYjNSb0lHMXZj bVVnYjJKMmFXOTFjeUJwWmlCNWIzVWdZWEpsSUd4dmIydHBibWNnWVhRZ1lXNGdiMkpxWldO MElHRnVaQ0JvCllYWmxJRzVsZG1WeUlITmxaVzRnZEdobElITndaV01zSUdGdVpDQnBjeUJq YjI1emFYTjBaVzUwSUhkcGRHZ2dkR2hsSUhkaGVTQjAKYUdseklHbHpJSEpsY0hKbGMyVnVk R1ZrSUdsdUlIUm9aU0JwVkVsUUlHMWxjM05oWjJWeklITmxiblFnYjNWMExpQkpJSE4xWjJk bApjM1FnZEdobElEeHBQbTFsZEdodlpEd3ZhVDRtYm1KemNEdHdjbTl3WlhKMGVTQk5WVk5V SUU1UFZDQmhjSEJsWVhJZ2FXNGdZVzRnCmIzWmxjbkpwWkdVZ2FXWWdhWFFuY3lCdWIzUWdZ U0JqWVc1alpXeHNZWFJwYjI0N0lHbG1JR2wwSUdseklHRWdZMkZ1WTJWc2JHRjAKYVc5dUlH bDBJRTFWVTFRZ1ltVWdkR2hsSUc5dWJIa2djSEp2Y0dWeWRIa2dhVzRnZEdobElHOWlhbVZq ZEM0OFluSStQQzlrYVhZKwpQR1JwZGo0OFluSStQQzlrYVhZK1BHUnBkajVPWldsc0xqeGlj ajQ4TDJScGRqNEtQR0p5UGp4bWFXVnNaSE5sZENCamJHRnpjejBpCmJXbHRaVUYwZEdGamFH MWxiblJJWldGa1pYSWlQand2Wm1sbGJHUnpaWFErUEdKeVBqeHdjbVVnZDNKaGNEMGlJajVm WDE5ZlgxOWYKWDE5ZlgxOWZYMTlmWDE5ZlgxOWZYMTlmWDE5ZlgxOWZYMTlmWDE5ZlgxOWZY MTlmWDE5Zlh3cGpZV3h6YVdaNUlHMWhhV3hwYm1jZwpiR2x6ZEFwallXeHphV1o1UUdsbGRH WXViM0puQ21oMGRIQnpPaTh2ZDNkM0xtbGxkR1l1YjNKbkwyMWhhV3h0WVc0dmJHbHpkR2x1 CiAgICAgICAgWm04dlkyRnNjMmxtZVFvOEwzQnlaVDRLQ2p3dllteHZZMnR4ZFc5MFpUNDhZ bkkrIgpzdHlsZT0iaGVpZ2h0OjA7d2lkdGg6MDttYXgtaGVpZ2h0OjA7bWF4LXdpZHRoOjA7 b3ZlcmZsb3c6aGlkZGVuO2ZvbnQtc2l6ZTowZW07cGFkZGluZzowO21hcmdpbjowOyI+4oCL PC9kaXY+CiAgICA8L2Rpdj4KICAgIDxwcmUgY2xhc3M9Im1vei1zaWduYXR1cmUgbWFya2Rv d24taGVyZS1zaWduYXR1cmUiIGNvbHM9IjcyIj4tLSAKTWFydGVuIEdhamRhCkNFTwoKZG1m cyBHbWJIClNjaGFuZGF1ZXIgU3RyYcOfZSAzNAowMTMwOSBEcmVzZGVuCkdFUk1BTlkKCnBo b25lOiArNDkgMTc3IDQ0MjcxNjcKZW1haWw6IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJi cmV2aWF0ZWQiIGhyZWY9Im1haWx0bzptYXJ0ZW5AZG1mcy5vcmciPm1hcnRlbkBkbWZzLm9y ZzwvYT4KCk1hbmFnaW5nIERpcmVjdG9yOiBNYXJ0ZW4gR2FqZGEKUmVnaXN0ZXJlZCBhZGRy ZXNzOiBEcmVzZGVuClJlZ2lzdGVyZWQgTm8uOiBBRyBEcmVzZGVuIEhSQiAzNDg4MQpWQVQg UmVnLiBOby46IERFMzAzMjQ4NzQzPC9wcmU+CiAgPC9ib2R5Pgo8L2h0bWw+Cg== --------------977208B1EED5EA32718548FF-- From nobody Tue May 15 19:45:58 2018 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 778E01274D2 for ; Tue, 15 May 2018 19:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.296 X-Spam-Level: * X-Spam-Status: No, score=1.296 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=1.996, RCVD_IN_DNSWL_LOW=-0.7, 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 uZQTgTQta9Hl for ; Tue, 15 May 2018 19:45:55 -0700 (PDT) Received: from forward3-smtp.messagingengine.com (forward3-smtp.messagingengine.com [66.111.4.237]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119EC124B18 for ; Tue, 15 May 2018 19:45:55 -0700 (PDT) Received: from mailredirect.nyi.internal (imap22.nyi.internal [10.202.2.72]) by mailforward.nyi.internal (Postfix) with ESMTP id C4EA217CD for ; Tue, 15 May 2018 22:45:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mailredirect.nyi.internal (Postfix) with ESMTP id A8336CA2B7 for ; Tue, 15 May 2018 22:45:51 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.3-600-gec03c65-next x-jmap-identity-id: 64588216 In-Reply-To: References: <1526301633.2355518.1371292664.496BA737@webmail.messagingengine.com> <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> <77373506-ec5c-4541-b133-83dc9605d0eb@sloti22d1t06> <2d2e532d-9924-4e84-8150-fa7938c1820c@sloti22d1t06> <1526349049.1928575.1372173792.3F4BD2C4@webmail.messagingengine.com> Date: Tue, 15 May 2018 22:45:51 -0400 From: Neil Jenkins To: calsify@ietf.org Content-Type: multipart/alternative; boundary=11978b484d50499084c84bffd247b668 Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 02:45:57 -0000 --11978b484d50499084c84bffd247b668 Content-Type: multipart/related; boundary=41483c8ba62643c2bc4f2aa1c57f37cc --41483c8ba62643c2bc4f2aa1c57f37cc Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, 15= May 2018, at 1:02 PM, Ken Murchison wrote:
And what is existing behavior?  If most implementations= ignored a SHOULD, then apparently SHOULD doesn't carry much weight.
<= /blockquote>

Testing this further, I may have to take= back my claim as I have seen some inconsistencies in various services (= although they seem to be more poor support of complex rules in general r= ather than an issue of alignment with start date). Regardless, I think r= ather than refer to the poor explanation of recurrence rules in RFC5545,= we should directly define the semantics in this spec and do so in a way= that does not require alignment with the start date since this is often= found in the wild.

Here is my attempt at t= hat definition. I believe this matches the semantics of RFC5545 as curre= ntly implemented in at least Apple's and FastMail's calendar clients.

------

A recurrence rule specifie= s a set of set of date-times for recurring calendar objects. A recurrenc= e rule has the following semantics:

  1. A set of candidates i= s generated. This is every second within a period defined by the freq= uency property:
    • yearly: every second from midnight o= n the 1st January (inclusive) to=20 midnight the following 1st January (exclusive)
    • monthly: ever= y second from midnight on the 1st of a month (inclusive) to midnight on the 1st of the following month (exclusive)
    • weekl= y: every second from midnight (inclusive) on the first day of the week=20= (as defined by the firstDayOfWeek property, or Monday if omitted)= , to midnight 7 days later (exclusive).
    • daily: every second= from midnight at the start of the day (inclusive) to midnight at the end of the day (exclusive).
    • hourly: every se= cond from the beginning of the hour (inclusive) to the beginning of the next hour (exclusive).
    • minutely: every seco= nd from the beginning of the minute (inclusive) to the beginning of the next minute (exclusive).
    • secondly: the seco= nd itself, only.

  2. Each date-time candidate is compare= d against all of the byX properties of=20 the rule except bySetPosition. If any property in the rule does n= ot match the date-time, it is eliminated. Each byX property is an= array; the date-time matches the property if it matches any of the valu= es in the array. The properties have the following semantics:

  3. byMonth: the date-time is in the given month.
  4. byMonthDa= y: the date-time is on the given day of the month. Negative=20 numbers mean the nth last day of the month.
  5. byDay: the date-= time is on the given day of the week. If the day is=20 prefixed by a number, it is the nth occurrence of that day of the week w= ithin the month (if frequency is monthly) or year (if frequency is yearl= y). Negative numbers means nth last occurrence within that period.
  6. byYearDay: the date-time is on the nth day of year. Negative numb= ers mean the nth last day of the year.
  7. byWeekNo: the date-time is in = the nth week of the year. Negative numbers=20 mean the nth last week of the year. This corresponds to weeks according = to=20 week numbering as defined in ISO.8601.2004, with a week defined as a sev= en=20 day period, starting on the firstDayOfWeek or Monday if omitted. Week number one of the calendar year is the first week that contains at=20= least four days in that calendar year.
  8. byHour: the date-time= has the given hour value.
  9. byMinute: the date-time has the g= iven minute value.
  10. bySecond: the date-time has the given sec= ond value.

  11. If a bySetPosition property i= s included, this is now applied to the=20 ordered list of remaining dates (this property specifies the indexes of = date-times to keep; all others should be eliminated. Negative numbers ar= e indexes from the end of the list, with -1 being the list item).

  12. Any date-times before the start date of the event ar= e eliminated (see=20 below for why this might be needed).

  13. If further dates= are required (we have not reached the until date, or count limit) skip the next (interval - 1) sets of candidates, then continue = from=20 step 1.

When determining the set of occurrence dates= for an event, the following extra rules must be applied:

    The start date-time is always the first occurrence in the exp= ansion (and=20 is counted if the recurrence is limited by a "count" property), even if = it=20 would normally not match the rule.

  1. The first set of c= andidates to consider is that which would contain the=20 start. This means the first set may include candidates before the start;= =20 such candidates are eliminated from the results in step (4).

  2. The following properties MUST be implicitly added to the rule un= der the=20 given conditions:

    If frequency > "secondly" and no bySecond= property:

    • Add a bySecond property with the sole v= alue being the seconds value of=20 the start date-time.

    If frequency > "minutely" and no= byMinute property:

    • Add a byMinute property with t= he sole value being the minutes value of=20 the start date-time.

    If frequency > "hourly" and no b= yHour property:

    • Add a byHour property with the sol= e value being the hours value of=20 the start date-time.

    If frequency is "weekly" and no byD= ay property:

    • Add a byDay property with the sole va= lue being the day-of-the-week of the start date-time.

    If frequency is "monthly" and no by= Day property and no byMonthDay property:

    • Add a byMonth= Day property with the sole value being the day-of-the-month of the start date-time.

    If frequency is "yearly" and no = byDay, byYearDay or byWeekNo properties:

  • if there is no byMonthDate property:
    • Add a byMonthDay property with the sole value being th= e day-of-the-month of the start date-time.
  • if there is no byMont= h property:
    • Add a byMonth property with the sol= e value being the month of the start date-time.

------

Neil.
--41483c8ba62643c2bc4f2aa1c57f37cc-- --11978b484d50499084c84bffd247b668 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, 15 May 2018, at 1:02 PM, Ken Murchison wrote: > And what is existing behavior?=C2=A0 If most implementations ignored a= SHOULD, then apparently SHOULD doesn't carry much weight. Testing this further, I may have to take back my claim as I have seen so= me inconsistencies in various services (although they seem to be more po= or support of complex rules in general rather than an issue of alignment= with start date). Regardless, I think rather than refer to the poor exp= lanation of recurrence rules in RFC5545, we should directly define the s= emantics in this spec and do so in a way that does not require alignment= with the start date since this is often found in the wild. Here is my attempt at that definition. I believe this matches the semant= ics of RFC5545 as currently implemented in at least Apple's and FastMail= 's calendar clients. ------ A recurrence rule specifies a set of set of date-times for recurring cal= endar objects. A recurrence rule has the following semantics: 1. A set of candidates is generated. This is every second within a peri= od defined by the *frequency* property: * yearly: every second from midnight on the 1st January (inclusive) t= o=20 midnight the following 1st January (exclusive) * monthly: every second from midnight on the 1st of a month (inclusiv= e) to midnight on the 1st of the following month (exclusive) * weekly: every second from midnight (inclusive) on the first day of = the week=20 (as defined by the *firstDayOfWeek* property, or Monday if omitted), to = midnight 7 days later (exclusive). * daily: every second from midnight at the start of the day (inclusiv= e) to midnight at the end of the day (exclusive). * hourly: every second from the beginning of the hour (inclusive) to = the beginning of the next hour (exclusive). * minutely: every second from the beginning of the minute (inclusive)= to the beginning of the next minute (exclusive). * secondly: the second itself, only. 2. Each date-time candidate is compared against all of the *byX* proper= ties of=20 the rule except *bySetPosition*. If any property in the rule does not ma= tch the date-time, it is eliminated. Each *byX* property is an array; th= e date-time matches the property if it matches any of the values in the = array. The properties have the following semantics: * byMonth: the date-time is in the given month. * byMonthDay: the date-time is on the given day of the month. Negativ= e=20 numbers mean the nth last day of the month. * byDay: the date-time is on the given day of the week. If the day is= =20 prefixed by a number, it is the nth occurrence of that day of the week w= ithin the month (if frequency is monthly) or year (if frequency is yearl= y). Negative numbers means nth last occurrence within that period. * byYearDay: the date-time is on the nth day of year. Negative number= s mean the nth last day of the year. * byWeekNo: the date-time is in the nth week of the year. Negative nu= mbers=20 mean the nth last week of the year. This corresponds to weeks according = to=20 week numbering as defined in ISO.8601.2004, with a week defined as a sev= en=20 day period, starting on the *firstDayOfWeek* or Monday if omitted. Week number one of the calendar year is the first week that contains at=20= least four days in that calendar year. * byHour: the date-time has the given hour value. * byMinute: the date-time has the given minute value. * bySecond: the date-time has the given second value. 3. If a *bySetPosition* property is included, this is now applied to th= e=20 ordered list of remaining dates (this property specifies the indexes of = date-times to keep; all others should be eliminated. Negative numbers ar= e indexes from the end of the list, with -1 being the list item). 4. Any date-times *before* the start date of the event are eliminated (= see=20 below for why this might be needed). 5. If further dates are required (we have not reached the *until* date,= or *count* limit) skip the next (interval - 1) sets of candidates, then= continue from=20 step 1. When determining the set of occurrence dates for an event, the following= extra rules must be applied: 1. The *start* date-time is always the first occurrence in the expansio= n (and=20 is counted if the recurrence is limited by a "count" property), even if = it=20 would normally not match the rule. 2. The first set of candidates to consider is that which would *contain= * the=20 start. This means the first set may include candidates before the start;= =20 such candidates are eliminated from the results in step (4). 3. The following properties MUST be implicitly added to the rule under = the=20 given conditions: If frequency > "secondly" and no bySecond property: * Add a *bySecond* property with the sole value being the seconds val= ue of=20 the start date-time. If frequency > "minutely" and no byMinute property: * Add a *byMinute* property with the sole value being the minutes val= ue of=20 the start date-time. If frequency > "hourly" and no byHour property: * Add a *byHour* property with the sole value being the hours value o= f=20 the start date-time. If frequency is "weekly" and no byDay property: * Add a *byDay* property with the sole value being the day-of-the-wee= k of the start date-time. If frequency is "monthly" and no byDay property and no byMonthDay proper= ty: * Add a *byMonthDay* property with the sole value being the day-of-th= e-month of the start date-time. If frequency is "yearly" and no byDay, byYearDay or byWeekNo properties:= * if there is no byMonthDate property:=20 * Add a *byMonthDay* property with the sole value being the day-of-th= e-month of the start date-time. * if there is no byMonth property:=20 * Add a *byMonth* property with the sole value being the month of the= start date-time. ------ Neil. --11978b484d50499084c84bffd247b668-- From nobody Tue May 15 20:07:47 2018 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 C624F127599 for ; Tue, 15 May 2018 20:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.203 X-Spam-Level: X-Spam-Status: No, score=-0.203 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Uub4XSccZbrn for ; Tue, 15 May 2018 20:07:43 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 53332127136 for ; Tue, 15 May 2018 20:07:43 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id h9-v6so3323486lfi.0 for ; Tue, 15 May 2018 20:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=yCvZBq/nRBrSZn9nvgN01QPqGqhXUl+7hM8Q0Q906C8=; b=UTOYO5BkMkvcjXq+xtkZVc23nXgf6d9I2a+f9kXHCgAjGvoLkD3r0CO1B+JWSVKFSs Jw0hsmk9Z87djmWcmv4kb9xya8T/wC38Y6+kZazFLZOTo+cZutpLkGURNkmTzBiyEj42 2TyoxFd5TomsVp961F0eCHt0UeEiMnGgqHuCQCWehjMU4VSBjmLRHXHEHybLyQCQ3NmR vmIIf+4hmCd9lh2l5V3Xb/nyyP+KLIVr99GezmlS4JgOMkgAfIfi8neX7cwFv2CORPj+ 0vbNVzlLifuEt9WmqHTK3fwrwY3iXzAy82ZBN+zh7mIZXZXjNH/nBF7Abf0+ACg+Mqsa PHdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=yCvZBq/nRBrSZn9nvgN01QPqGqhXUl+7hM8Q0Q906C8=; b=cpiTL58+31RyQimxtFVWRc7o00lLKmHbBa8EKwpFXWk1PaUhhVfApWgTVceAe21+Ye 6B80PTl5MenHli6u+Sz9ESY/D7II9CuFv+r1SfhP3gqkEwqO6CpCSVMFJH1tYnqJJRso u7AUmdGvRmTVQ0aYbEVUW72R6WmAXLIDkeJ9Gdg3Gh4XKT9n8fVvVH0OeGlHCzBQHZgP fylgvnkp5TxZwqQaQOhxyG1d6jlJcSlrN+plw3tq3sZaUB4+7mGyddSolkMIPQvfsseK nKysYhRTZpopESrVmnrDoVQzDqniemmt+qswZRnaIJx/HVJH9jJRT695TCY5gdBgVMrG zwWw== X-Gm-Message-State: ALKqPwdX1EdtjsNMN0Y6Omb2YLfhcf0B21paK9YayQbOXliZIyZlBuO4 M32HBzDa0x2T0npmPhVBAhs3ifih9fwycA+iX0luKg== X-Google-Smtp-Source: AB8JxZr54US1qmD4lVktKVu6kt1mQ66EzDo7nlsshGujsyQnIArWtSfP9SAhu19NErmHPFcNUe3vll3luaet+lKVFa4= X-Received: by 2002:a19:910c:: with SMTP id t12-v6mr4506273lfd.29.1526440061197; Tue, 15 May 2018 20:07:41 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.158.88 with HTTP; Tue, 15 May 2018 20:07:40 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Tue, 15 May 2018 23:07:40 -0400 X-Google-Sender-Auth: 3qrl_p3kj9I4cL1rFcCi5gLR1xU Message-ID: To: calsify@ietf.org Content-Type: multipart/alternative; boundary="0000000000009e6f65056c4a05a7" Archived-At: Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 03:07:46 -0000 --0000000000009e6f65056c4a05a7 Content-Type: text/plain; charset="UTF-8" Hi, Please find some comments. These comments are indicative. Yours, Daniel Abstract: The header indicates that RFC 5545,and RFC 5546 are updated. This must be also stated in the Abstract and in the introduction. 1. Introduction """ Current practice is to embed this information as links in the description or to add x-properties. """ It is not clear to me how to use x-properties. Is it a notation ? In addition, I am also wondering if this does not designate the LABEL property. If that is correct, maybe that could be explicitly stated to better understand section 5. The conventions needs to be updated according to RFC 8174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Typed References """ perhaps for indexing or the presentation of additional related information for the user. """ Thought English is not my natural language, there might be a nit there. perhaps for indexing or presentating the additional related information to the user. -- """ Using STRUCTURED-LOCATION, information about a number of interesting locations can be communicated, for example, parking, restaurants and the venue. Servers and clients can retrieve the objects when storing the event and use them to index by geographic location. """ It is not clear from the text that the location information mentioned above (e.g. address, region, country, postal code) that motivated the STRUCTURED-LOCATION are part STRUCTURED-LOCATION. Thus I would also mention them 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. Servers and clients can retrieve the objects when storing the event and use them to index by geographic location. --- 3.1.2. Itineraries """ The contact information can provide detailed information about the booking agent, the airlines and car hire companies and the hotel. """ Looks to me that there is an additional "and". 5. New Property Parameters """ This specification makes use of the LABEL property parameter which is defined in [RFC7986] """ My understanding is that the parameters described in this section apply to the LABEL property. It seems to me that this is the first time the LABEL properties and associated parameters are mentioned in the document. In other words, I have hard time finding where this section is introduced in the previous sections such as the introduction. If I am correct, maybe that could be clarified in the introduction. It seems to me that the document is structured with a kind of bottom - up approach. parameters < properties < components. Thus I am wondering if there are any reasons for not having the Calendar Components at the very end instead of at the beginning. I am also wondering if that would not be more easy to read the document with Participant Types and Resource Types listed within their respective Properties. On Tue, May 15, 2018 at 1:12 PM, Daniel Migault wrote: > Hi, > > draft-ietf-calext-eventpub-extensions [1] is already on WGLC. We would > like to sufficient reviews to move the document to the IESG. If you have > not yet commented the document, please provide your feedbacks by May 29 so > we can move the document forward. > > Yours, > Calext co-chairs. > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-calext- > eventpub-extensions/ > --0000000000009e6f65056c4a05a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Please find some co= mments. These comments are indicative.

Yours,
=
Daniel

Abstract:
The header i= ndicates that RFC 5545,and RFC 5546 are updated. This must be also stated i= n the Abstract and in the introduction.


<= /div>
1.=C2=A0 Introduction

"""
Current practi= ce is to embed this information as links in the
=C2=A0=C2=A0 description= or to add x-properties.
"""

It is not clear to me= how to use x-properties. Is it a notation ? In addition, I am also wonderi= ng if this does not designate the LABEL property. If that is correct, maybe= that could be explicitly stated to better understand section 5.

The conventions needs to be updated according to RFC 8174

=C2=A0=C2= =A0 The key words "MUST", "MUST NOT", "REQUIRED&qu= ot;, "SHALL", "SHALL NOT",
=C2=A0=C2=A0 "SHOULD= ", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMEN= DED", "MAY", and
=C2=A0=C2=A0 "OPTIONAL" in thi= s document are to be interpreted as described in
=C2=A0=C2=A0 [RFC2119].=

3.=C2=A0 Typed References

"""
=C2=A0=C2=A0= perhaps
=C2=A0=C2=A0 for indexing or the presentation of additional rel= ated information
=C2=A0=C2=A0 for the user.
"""
Thought English is not my natural language, there might be a nit there.
=C2=A0=C2=A0 perhaps
=C2=A0=C2=A0 for indexing or presentating the= additional related information
=C2=A0=C2=A0 to the user.
--

<= br>"""
Using STRUCTURED-LOCATION, information about a num= ber of interesting
=C2=A0=C2=A0 locations can be communicated, for examp= le, parking, restaurants and
=C2=A0=C2=A0 the venue.=C2=A0 Servers and c= lients can retrieve the objects when storing
=C2=A0=C2=A0 the event and = use them to index by geographic location.
"""

It i= s not clear from the text that the location information mentioned above (e.= g. address, region, country, postal code) that motivated the STRUCTURED-LOC= ATION are part STRUCTURED-LOCATION. Thus I would also mention them

=
Using STRUCTURED-LOCATION, information about a number of interesting=C2=A0=C2=A0 locations can be communicated, for example, address, region, = country, postal code as well as other informations such as the parking, res= taurants and
=C2=A0=C2=A0 the venue.=C2=A0 Servers and clients can retri= eve the objects when storing
=C2=A0=C2=A0 the event and use them to inde= x by geographic location.

---

3.1.2.=C2=A0 Itineraries

"""
The contact information can
=C2=A0=C2=A0 prov= ide detailed information about the booking agent, the airlines
=C2=A0=C2= =A0 and car hire companies and the hotel.
"""

Look= s to me that there is an additional "and".



5.=C2= =A0 New Property Parameters

"""
=C2=A0=C2=A0 This = specification makes use of the LABEL property parameter which is
=C2=A0= =C2=A0 defined in [RFC7986]
"""

My understanding i= s that the parameters described in this section apply to the LABEL property= . It seems to me that this is the first time the LABEL properties and assoc= iated parameters are mentioned in the document. In other words, I have hard= time finding where this section is introduced=C2=A0 in the previous sectio= ns such as the introduction. If I am correct, maybe that could be clarified= in the introduction.

It seems to me that the document is structure= d with a kind of bottom - up approach. parameters < properties < comp= onents. Thus I am wondering if there are any reasons for not having the Cal= endar Components at the very end instead of at the beginning.

I am a= lso wondering if that would not be more easy to read the document with Part= icipant Types and Resource Types listed within their respective Properties.=




On Tue, May 15, 2018 at 1:12 PM, Daniel Migault <dan= iel.migault@ericsson.com> wrote:
Hi,

draft-ietf-ca= lext-eventpub-extensions [1] is already on WGLC. We would like to suff= icient reviews to move the document to the IESG. If you have not yet commen= ted the document, please provide your feedbacks by May 29 so we can move th= e document forward.

Yours,
Cal= ext co-chairs.




--0000000000009e6f65056c4a05a7-- From nobody Tue May 15 20:27:01 2018 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 28C53120726 for ; Tue, 15 May 2018 20:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.296 X-Spam-Level: * X-Spam-Status: No, score=1.296 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=1.996, RCVD_IN_DNSWL_LOW=-0.7, 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 mVgIGQl9_c6r for ; Tue, 15 May 2018 20:26:58 -0700 (PDT) Received: from forward3-smtp.messagingengine.com (forward3-smtp.messagingengine.com [66.111.4.237]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2348E120724 for ; Tue, 15 May 2018 20:26:58 -0700 (PDT) Received: from mailredirect.nyi.internal (imap22.nyi.internal [10.202.2.72]) by mailforward.nyi.internal (Postfix) with ESMTP id 366631AE9 for ; Tue, 15 May 2018 23:26:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mailredirect.nyi.internal (Postfix) with ESMTP id 2E278CA269 for ; Tue, 15 May 2018 23:26:57 -0400 (EDT) Message-Id: <0c02d353-0a47-44fa-a336-90ff132dfe33@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-600-gec03c65-next x-jmap-identity-id: 64588216 In-Reply-To: <478ec7b1-298d-06da-42ba-fa06c6fb396e@dmfs.org> References: <478ec7b1-298d-06da-42ba-fa06c6fb396e@dmfs.org> <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> Date: Tue, 15 May 2018 23:26:56 -0400 From: Neil Jenkins To: calsify@ietf.org Content-Type: multipart/alternative; boundary=1a595e10e0954c2097bf03d96df9af7e Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 03:26:59 -0000 --1a595e10e0954c2097bf03d96df9af7e Content-Type: multipart/related; boundary=ab6fe9142e8e49288343b1761c668141 --ab6fe9142e8e49288343b1761c668141 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Wed, 16= May 2018, at 7:12 AM, Marten Gajda wrote:
How about using false to identify exdates?

I don't mind this, but I wonder if it's likely = to be a real headache if implementing in strongly typed languages? Also,= is mapping to `true` forbidden or the same as mapping to `{}` (i.e. it'= s an RDATE with no further changes)?

The=E2= =80=A6 impurity of it annoys me a bit. But I have to say it's a reasonab= ly pragmatic solution, and I'm happy to go with it if there's no strong = objections.

Neil.
--ab6fe9142e8e49288343b1761c668141-- --1a595e10e0954c2097bf03d96df9af7e Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, 16 May 2018, at 7:12 AM, Marten Gajda wrote: > How about using false to identify exdates? I don't mind this, but I wonder if it's likely to be a real headache if= implementing in strongly typed languages? Also, is mapping to `true` fo= rbidden or the same as mapping to `{}` (i.e. it's an RDATE with no furth= er changes)? The=E2=80=A6 impurity of it annoys me a bit. But I have to say it's a re= asonably pragmatic solution, and I'm happy to go with it if there's no s= trong objections. Neil. --1a595e10e0954c2097bf03d96df9af7e-- From nobody Tue May 15 21:05:37 2018 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 55088127136 for ; Tue, 15 May 2018 21:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 28WpWMqnIc-t for ; Tue, 15 May 2018 21:05:33 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 6BC67120724 for ; Tue, 15 May 2018 21:05:33 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id t129-v6so2063817qke.11 for ; Tue, 15 May 2018 21:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=L3EfVlS6dnkRgUIulJazt8MRYx9tipqJRxvpycWryoA=; b=pk927uQ8joQLRSNeFaRASt+5gs9j6TKivVVjw0Sa8s8/XBXzVN1KME3LxiIFmq4gvq 7C8Dbo1e+F/7xBP5pkwPUN4logQ9cbRoQm6DxRgwVbw6KhsbC+KkxwNWv95jxSHxnt50 5+JoIHGHk/IqIFeOVMh0PIA9bNUXUIh2h4CnWiertZBDXr81EPG1ogpb/ZWChRmE1Hng 8RsBM1oXBa7aaSt7xNrICjsF/OriVO3kV9mlMlcxRR/1bVck3CaupIo4Ec64ZLX/rZNI QoYDotq0Y4smBR0yW/sXFxFqdID1D9SC/YBHpOLMw9Zg9/7H7/dKThaxHLpjdvsaDGz0 VJDQ== 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=L3EfVlS6dnkRgUIulJazt8MRYx9tipqJRxvpycWryoA=; b=lD/uw0jqwogoVrLwgKqU9vknpFla1BLb9fMK/mc9mmJxSLVWuovfzWRVYpX4YjTC0K 3VthJbXXLd3XBcOIPTK+oZTdmPPik7xHfI5/MJyvzBh6sDLKRQcRtTDe7WBefubYtlBX z+RQaUEpFRndUa98CwD0o+O7hgEDSwyOh5+xiisKbcyz/A9Yzf7hUCDROF/ZUmnamAEI Mz8aQiXnaEXAJW1qsZURQAjWo8uJnK5oTXTuJ4fMn2hTHb+w7JZoldKakdaZ5Tmr3Bcg LJx4VrMlBcBMymAL9X6ZhMalxpSZmzDkrXtPd8ErhvQDk0NNM2vDT3CLoXyBh1gyz8SJ 2s3g== X-Gm-Message-State: ALKqPwfVsEyaj0V2uNqqwlN6qizn4yswB3fTNtPsJZkgiv0HISmzJbNg zyjMYLNt6MEgZGOAdiCY4v9JKw== X-Google-Smtp-Source: AB8JxZqwXablgl0bLuMrOg4tqV+qBYKTuAHfny4Qg8/2dt2RxRW4RJZY1SCNTn0pQgqP7V9aBQT/8Q== X-Received: by 2002:ae9:f40c:: with SMTP id y12-v6mr8651464qkl.311.1526443532296; Tue, 15 May 2018 21:05:32 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id i8-v6sm1210023qtb.11.2018.05.15.21.05.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 May 2018 21:05:31 -0700 (PDT) To: calsify@ietf.org References: From: Michael Douglass Message-ID: <1fc0f576-a71c-5364-3d0d-f0b77c295c70@gmail.com> Date: Wed, 16 May 2018 00:05:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5205778BD1047EA53419E8C9" Content-Language: en-US Archived-At: Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 04:05:35 -0000 This is a multi-part message in MIME format. --------------5205778BD1047EA53419E8C9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 5/15/18 23:07, Daniel Migault wrote: > It seems to me that the document is structured with a kind of bottom - > up approach. parameters < properties < components. Thus I am wondering > if there are any reasons for not having the Calendar Components at the > very end instead of at the beginning. > > I am also wondering if that would not be more easy to read the > document with Participant Types and Resource Types listed within their > respective Properties. That's possible. I was following the structure of 5545 which arranges things that way. > > > > > On Tue, May 15, 2018 at 1:12 PM, Daniel Migault > > wrote: > > Hi, > > draft-ietf-calext-eventpub-extensions [1] is already on WGLC. We > would like to sufficient reviews to move the document to the IESG. > If you have not yet commented the document, please provide your > feedbacks by May 29 so we can move the document forward. > > Yours, > Calext co-chairs. > > > > [1] > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ > > > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------5205778BD1047EA53419E8C9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 5/15/18 23:07, Daniel Migault wrote:

It seems to me that the document is structured with a kind of bottom - up approach. parameters < properties < components. Thus I am wondering if there are any reasons for not having the Calendar Components at the very end instead of at the beginning.

I am also wondering if that would not be more easy to read the document with Participant Types and Resource Types listed within their respective Properties.
That's possible. I was following the structure of 5545 which arranges things that way.




On Tue, May 15, 2018 at 1:12 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi,

draft-ietf-calext-eventpub-extensions [1] is already on WGLC. We would like to sufficient reviews to move the document to the IESG. If you have not yet commented the document, please provide your feedbacks by May 29 so we can move the document forward.

Yours,
Calext co-chairs.






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

--------------5205778BD1047EA53419E8C9-- From nobody Tue May 15 22:29:45 2018 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 5FD27124234; Tue, 15 May 2018 22:29:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152644858333.31055.16283812224833824418@ietfa.amsl.com> Date: Tue, 15 May 2018 22:29:43 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-07.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 05:29:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : Event Publishing Extensions to iCalendar Author : Michael Douglass Filename : draft-ietf-calext-eventpub-extensions-07.txt Pages : 32 Date : 2018-05-15 Abstract: This specification updates [RFC5545] and [RFC5546] by introducing a number of new iCalendar properties and components which are of particular use for event publishers and in social networking. This specification also defines a new STRUCTURED-DATA property for iCalendar [RFC5545] to allow for data that is directly pertinent to an event or task to be included with the calendar data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-07 https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 15 22:34:29 2018 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 84CBB12EA9D for ; Tue, 15 May 2018 22:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aRx7ZAvLyesx for ; Tue, 15 May 2018 22:34:17 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 C83C612EA55 for ; Tue, 15 May 2018 22:34:16 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id l132-v6so2197600qke.3 for ; Tue, 15 May 2018 22:34:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=BWnF2a0ktYUlyCSwKqLcjvFCGhsIeIjwfJVnosbbWoE=; b=YCOkn2hPJyzHSzuj5nJ0V720ioN62vtEzyw93Y9e34t0k5dMt86hiSVWP80l6HvFzG mDsTWamLj1ZKuJ2+cpFxjPLiTaRlwBHI3SVj9M+X4414qw0Q4RK4+AL1Ie/xmdumsLHr y88Wgfmq46wUWCSboAv9s7zuC88HiWeiWXVrC6MucJIg4FPG8PXoO+VM8cUxDioFcKyB LueOOpjtv2rRPlv7q5NYc+Q/moloCuOPsAzeWMWB+jQOCrh1bqCKtK8PIhF3u1amO6N1 SNyYFk7gkbE0SisD+/fYyxqQj9t0X3oGmDOAV8a0sMEWhFhpNJxPbxo1N0Uwc8A1Ej/k aj1g== 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=BWnF2a0ktYUlyCSwKqLcjvFCGhsIeIjwfJVnosbbWoE=; b=jPQY9dPZi+wk6+w6qP/kVM+rkPoSqU8cGh28GBvQqbKN9ZT8pnCaqxGuhblAhWdVNH pTbmP+ICGk52joTPh9ir11QQG2FXsSTTRSRisD8xpivX0zSuJNWGSh+ivyJd0gGkOn+p d2BwveP15MJRcWKM8LnbhzlIb6n/FVioR9SSprsMiMXvInwWJGptm4KOVcUB9Er9W1s/ Liesti/P62qluQEczWEIURFrAuAPf0hQpkqBqafhb6DJ3xcjtMglU7XOj5ckkq7AniGb G14kDdLavz5Dd+76q23H3iuV96Q4jj7RK5xBQ4rpTC7IVU2mUdos2sFQrYSNQ4J0YNNa 0huQ== X-Gm-Message-State: ALKqPwdFApWu9erkhlHotwrvG5b3hkXVZAvrkFueoSgn0LM+c2GMpD01 uipd5ixy+688xmxNea2zt4HzuA== X-Google-Smtp-Source: AB8JxZp2l2KC8+B9NsJgdCcLijh8SwL4lck1FKbdVCv91L7LqCGhRaB+zt7lBwoF+CKmfQ0kPvpidQ== X-Received: by 2002:a37:c34f:: with SMTP id a76-v6mr14899238qkj.269.1526448855619; Tue, 15 May 2018 22:34:15 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id u47-v6sm1481657qtc.27.2018.05.15.22.34.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 May 2018 22:34:15 -0700 (PDT) To: calsify@ietf.org References: From: Michael Douglass Message-ID: <708d48bc-e213-1386-ff7b-23a476000774@gmail.com> Date: Wed, 16 May 2018 01:33:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A0C0719582A39AF9C4E12EDC" Content-Language: en-US Archived-At: Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions-06 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 05:34:28 -0000 This is a multi-part message in MIME format. --------------A0C0719582A39AF9C4E12EDC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thank you for the comments - I've submitted a new draft to address these and just realised I didn't address any of Robert's issues. I'll deal with those in day or so. On 5/15/18 23:07, Daniel Migault wrote: > Hi, > > Please find some comments. These comments are indicative. > > Yours, > Daniel > > Abstract: > The header indicates that RFC 5545,and RFC 5546 are updated. This must > be also stated in the Abstract and in the introduction. Some text added > > > 1.  Introduction > > """ > Current practice is to embed this information as links in the >    description or to add x-properties. > """ > > It is not clear to me how to use x-properties. Is it a notation ? In > addition, I am also wondering if this does not designate the LABEL > property. If that is correct, maybe that could be explicitly stated to > better understand section 5. I've changed the text to refer to non-standard properties and provided a reference to the section in 5545. LABEL is a parameter used to provide a human-readable label for properties - something like the alt attribute in html - so no - that is a different usage > > > The conventions needs to be updated according to RFC 8174 > >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >    "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and >    "OPTIONAL" in this document are to be interpreted as described in >    [RFC2119]. Done > > 3.  Typed References > > """ >    perhaps >    for indexing or the presentation of additional related information >    for the user. > """ > > Thought English is not my natural language, there might be a nit there. > >    perhaps >    for indexing or presentating the additional related information >    to the user. > -- Changed to: perhaps for indexing or the         presenting of additional related information for the user. > > > """ > Using STRUCTURED-LOCATION, information about a number of interesting >    locations can be communicated, for example, parking, restaurants and >    the venue.  Servers and clients can retrieve the objects when storing >    the event and use them to index by geographic location. > """ > > It is not clear from the text that the location information mentioned > above (e.g. address, region, country, postal code) that motivated the > STRUCTURED-LOCATION are part STRUCTURED-LOCATION. Thus I would also > mention them > > > 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.  Servers and clients can retrieve the objects when storing >    the event and use them to index by geographic location. > Done > --- > > 3.1.2.  Itineraries > > > """ > The contact information can >    provide detailed information about the booking agent, the airlines >    and car hire companies and the hotel. > """ > > Looks to me that there is an additional "and". Removed > > > > 5.  New Property Parameters > > """ >    This specification makes use of the LABEL property parameter which is >    defined in [RFC7986] > """ > > My understanding is that the parameters described in this section > apply to the LABEL property.. It seems to me that this is the first > time the LABEL properties and associated parameters are mentioned in > the document. In other words, I have hard time finding where this > section is introduced  in the previous sections such as the > introduction. If I am correct, maybe that could be clarified in the > introduction. LABEL is a parameter - it turns up in the ABNF for a number of the properties defined here. The phrase "property parameter" was pulled out of that spec - from 5545 as well. "LABEL parameter" is a little clearer I think. I'll try that. > > It seems to me that the document is structured with a kind of bottom - > up approach. parameters < properties < components. Thus I am wondering > if there are any reasons for not having the Calendar Components at the > very end instead of at the beginning. > I am also wondering if that would not be more easy to read the > document with Participant Types and Resource Types listed within their > respective Properties. > I see what you mean now. Makes sense. > > > > On Tue, May 15, 2018 at 1:12 PM, Daniel Migault > > wrote: > > Hi, > > draft-ietf-calext-eventpub-extensions [1] is already on WGLC. We > would like to sufficient reviews to move the document to the IESG. > If you have not yet commented the document, please provide your > feedbacks by May 29 so we can move the document forward. > > Yours, > Calext co-chairs. > > > > [1] > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ > > > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------A0C0719582A39AF9C4E12EDC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thank you for the comments - I've submitted a new draft to address these and just realised I didn't address any of Robert's issues.

I'll deal with those in day or so.


On 5/15/18 23:07, Daniel Migault wrote:
Hi,

Please find some comments. These comments are indicative.

Yours,
Daniel

Abstract:
The header indicates that RFC 5545,and RFC 5546 are updated. This must be also stated in the Abstract and in the introduction.
Some text added


1.  Introduction

"""
Current practice is to embed this information as links in the
   description or to add x-properties.
"""

It is not clear to me how to use x-properties. Is it a notation ? In addition, I am also wondering if this does not designate the LABEL property. If that is correct, maybe that could be explicitly stated to better understand section 5.
I've changed the text to refer to non-standard properties and provided a reference to the section in 5545.

LABEL is a parameter used to provide a human-readable label for properties - something like the alt attribute in html - so no - that is a different usage


The conventions needs to be updated according to RFC 8174

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].
Done

3.  Typed References

"""
   perhaps
   for indexing or the presentation of additional related information
   for the user.
"""

Thought English is not my natural language, there might be a nit there.

   perhaps
   for indexing or presentating the additional related information
   to the user.
--
Changed to:

perhaps for indexing or the
        presenting of additional related information for the user.


"""
Using STRUCTURED-LOCATION, information about a number of interesting
   locations can be communicated, for example, parking, restaurants and
   the venue.  Servers and clients can retrieve the objects when storing
   the event and use them to index by geographic location.
"""

It is not clear from the text that the location information mentioned above (e.g. address, region, country, postal code) that motivated the STRUCTURED-LOCATION are part STRUCTURED-LOCATION. Thus I would also mention them


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.  Servers and clients can retrieve the objects when storing
   the event and use them to index by geographic location.

Done
---

3.1.2.  Itineraries


"""
The contact information can
   provide detailed information about the booking agent, the airlines
   and car hire companies and the hotel.
"""

Looks to me that there is an additional "and".
Removed



5.  New Property Parameters

"""
   This specification makes use of the LABEL property parameter which is
   defined in [RFC7986]
"""

My understanding is that the parameters described in this section apply to the LABEL property.. It seems to me that this is the first time the LABEL properties and associated parameters are mentioned in the document. In other words, I have hard time finding where this section is introduced  in the previous sections such as the introduction. If I am correct, maybe that could be clarified in the introduction.
LABEL is a parameter - it turns up in the ABNF for a number of the properties defined here. The phrase "property parameter" was pulled out of that spec - from 5545 as well. "LABEL parameter" is a little clearer I think. I'll try that.

It seems to me that the document is structured with a kind of bottom - up approach. parameters < properties < components. Thus I am wondering if there are any reasons for not having the Calendar Components at the very end instead of at the beginning.
I am also wondering if that would not be more easy to read the document with Participant Types and Resource Types listed within their respective Properties.

I see what you mean now. Makes sense.



On Tue, May 15, 2018 at 1:12 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi,

draft-ietf-calext-eventpub-extensions [1] is already on WGLC. We would like to sufficient reviews to move the document to the IESG. If you have not yet commented the document, please provide your feedbacks by May 29 so we can move the document forward.

Yours,
Calext co-chairs.






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

--------------A0C0719582A39AF9C4E12EDC-- From nobody Wed May 16 00:57:08 2018 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 D7F16129C70 for ; Wed, 16 May 2018 00:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 Qcg1gmgbzuqe for ; Wed, 16 May 2018 00:57:06 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227E2129C51 for ; Wed, 16 May 2018 00:57:06 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9CB32224CF for ; Wed, 16 May 2018 03:57:02 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute1.internal (MEProxy); Wed, 16 May 2018 03:57:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=1Q14EA tudz+uudHmIe7QHzkSv0lWCKxZXcOQKXNw95E=; b=T1Vb+949UTAchkXLGPCZM6 WgjMktr8U/0SLOb787G3qIdARpRCLRSNerR7RjuN1Z5QXuyXQ+L/Sf1qLssTCXgQ eFqpF/yJpdeFJ03xwgCmeB0vOI10NpK796jCPcnq8LlN1TahcX6sUHYXFZcd4K9z oj5jufyCIJ0jOHcpcEq4uPzjjGWETVKR2jZ5hZFbyBczNitXc6/8O5A4+sjbdy63 rSpph2MknLufubLotqoB8cdrr63L6jpO8hC0O/XUmU2hL6nYRMnRwnld53Rp8Poa DNjVSOsZ8GzpsixM9ey1TrFHQKjA1/70fg+aP6GC3BXwqfYEMsu1TaQXN2FCQLgg == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 42A2C4298; Wed, 16 May 2018 03:57:02 -0400 (EDT) Message-Id: <1526457422.1612996.1373808904.0510211F@webmail.messagingengine.com> From: Robert Stepanek To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152645742216129961" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 Date: Wed, 16 May 2018 09:57:02 +0200 In-Reply-To: <0c02d353-0a47-44fa-a336-90ff132dfe33@sloti22d1t06> References: <478ec7b1-298d-06da-42ba-fa06c6fb396e@dmfs.org> <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> <0c02d353-0a47-44fa-a336-90ff132dfe33@sloti22d1t06> Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 07:57:08 -0000 This is a multi-part message in MIME format. --_----------=_152645742216129961 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, May 16, 2018, at 05:26, Neil Jenkins wrote: > On Wed, 16 May 2018, at 7:12 AM, Marten Gajda wrote: >> How about using false to identify exdates? > > I don't mind this, but I wonder if it's likely to be a real headache > if implementing in strongly typed languages? I share this concern. In addition, during the last JMAP session at IETF we had people asking for OpenAPI3 or JSON schema definitions. In my understanding, a variant- type property would require to use less common features of these definition languages, and hence make the resulting schema for JSCalendar more complicated and code generation brittle. I don't think that the shortcomings of particular technologies or tools should guide our design. But JSCalendar claims to be "simple to process", and the benefits of using `false` in this particular case don't seem to me to warrant its potential risks. Of all the proposals, I vouch for `method:cancel`, as it neither extends iTIP vocabulary, nor requires special handling of the payloads. Implementations can apply the same patch mechanism to all entries in recurrenceOverrides and if the resulting patched object instance has a `method:cancel` can just ignore it. --_----------=_152645742216129961 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, May 16, 2018, at 05:26, Neil Jenkins wrote:
On Wed, 16 May 2018, at 7:12 AM, Marten Gajda wrote:
How about using false to identify exdates?

I don't mind this, but I wonder if it's likely to be a real headache if implementing in strongly typed languages?

I share this concern.

In addition, during the last JMAP session at IETF we had people asking for OpenAPI3 or JSON schema definitions. In my understanding, a variant-type property would require to use less common features of these definition languages, and hence make the resulting schema for JSCalendar more complicated and code generation brittle.

I don't think that the shortcomings of particular technologies or tools should guide our design. But JSCalendar claims to be "simple to process", and the benefits of using `false` in this particular case don't seem to me to warrant its potential risks.

Of all the proposals, I vouch for `method:cancel`, as it neither extends iTIP vocabulary, nor requires special handling of the payloads. Implementations can apply the same patch mechanism to all entries in recurrenceOverrides and if the resulting patched object instance has a `method:cancel` can just ignore it.
--_----------=_152645742216129961-- From nobody Wed May 16 03:56:06 2018 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 6A6FF12D7F8 for ; Wed, 16 May 2018 03:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org 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 uuXjfG8wTwJK for ; Wed, 16 May 2018 03:56:01 -0700 (PDT) Received: from mailrelay3-1.pub.mailoutpod1-cph3.one.com (mailrelay3-1.pub.mailoutpod1-cph3.one.com [46.30.210.184]) (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 927CB12D969 for ; Wed, 16 May 2018 03:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=ct/yVvVfbqQsjQlt6vu7wPGVDcxpaLTFTSPZCn8K7VQ=; b=t06GNeYBpuO703B3YzhQIf5uoYB40Usi+U2AogDvlLk/H8K5PsWtIWdPo4qv2nffpgOqhdHVMB8jk KGDwk57vKtjAcAPeYGf05Smiedx/02gTesx2xO7XEj1hjdXc8pl6sFP69F9/yNSyiC2qTY8qQqNRLW 5C0xNLoW7OpwXxo0= X-HalOne-Cookie: ae61247381b7621e8bf72d000143046cb2d9b1ad X-HalOne-ID: b6d73bfb-58f7-11e8-bf2d-d0431ea8bb03 Received: from smtp.dmfs.org (unknown [91.47.32.197]) by mailrelay3.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id b6d73bfb-58f7-11e8-bf2d-d0431ea8bb03; Wed, 16 May 2018 10:55:58 +0000 (UTC) Received: from boss.localdomain (unknown [155.133.208.74]) by smtp.dmfs.org (Postfix) with ESMTPSA id C8967290 for ; Wed, 16 May 2018 12:55:57 +0200 (CEST) To: calsify@ietf.org References: <478ec7b1-298d-06da-42ba-fa06c6fb396e@dmfs.org> <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> <0c02d353-0a47-44fa-a336-90ff132dfe33@sloti22d1t06> <1526457422.1612996.1373808904.0510211F@webmail.messagingengine.com> From: Marten Gajda Message-ID: Date: Wed, 16 May 2018 12:55:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1526457422.1612996.1373808904.0510211F@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------B5224E373EBE96A6CBD1BEAF" Content-Language: en-US Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2018 10:56:04 -0000 This is a multi-part message in MIME format. --------------B5224E373EBE96A6CBD1BEAF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I'm not keen on this either. I'm usually working with a strongly-typed language and variant-type members can be a real pain. Anyway, `method:cancel` has completely different semantics and many clients still show canceled instances, just with the title crossed out. That's not a good option either. So here is another option: * add a new dedicated property to identify exdates, like so? ``` "recurrenceOverrides": {    "2018-05-16T12:50:00": { "excluded": true } } ``` I like "excluded" because it doesn't imply the instance ever existed (which "method:deleted" does, sort of). Not that it matters much though. Marten Am 16.05.2018 um 09:57 schrieb Robert Stepanek: > On Wed, May 16, 2018, at 05:26, Neil Jenkins wrote: >> On Wed, 16 May 2018, at 7:12 AM, Marten Gajda wrote: >>> How about using false to identify exdates? >> >> I don't mind this, but I wonder if it's likely to be a real headache >> if implementing in strongly typed languages? > > I share this concern. > > In addition, during the last JMAP session at IETF we had people asking > for OpenAPI3 or JSON schema definitions. In my understanding, a > variant-type property would require to use less common features of > these definition languages, and hence make the resulting schema for > JSCalendar more complicated and code generation brittle. > > I don't think that the shortcomings of particular technologies or > tools should guide our design. But JSCalendar claims to be "simple to > process", and the benefits of using `false` in this particular case > don't seem to me to warrant its potential risks. > > Of all the proposals, I vouch for `method:cancel`, as it neither > extends iTIP vocabulary, nor requires special handling of the > payloads. Implementations can apply the same patch mechanism to all > entries in recurrenceOverrides and if the resulting patched object > instance has a `method:cancel` can just ignore it. > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------B5224E373EBE96A6CBD1BEAF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I'm not keen on this either. I'm usually working with a strongly-typed language and variant-type members can be a real pain.

Anyway, `method:cancel` has completely different semantics and many clients still show canceled instances, just with the title crossed out. That's not a good option either.

So here is another option:

* add a new dedicated property to identify exdates, like so?
```
"recurrenceOverrides": {
   "2018-05-16T12:50:00": { "excluded": true }
}
```

I like "excluded" because it doesn't imply the instance ever existed (which "method:deleted" does, sort of). Not that it matters much though.

Marten

Am 16.05.2018 um 09:57 schrieb Robert Stepanek:
On Wed, May 16, 2018, at 05:26, Neil Jenkins wrote:
On Wed, 16 May 2018, at 7:12 AM, Marten Gajda wrote:
How about using false to identify exdates?

I don't mind this, but I wonder if it's likely to be a real headache if implementing in strongly typed languages?

I share this concern.

In addition, during the last JMAP session at IETF we had people asking for OpenAPI3 or JSON schema definitions. In my understanding, a variant-type property would require to use less common features of these definition languages, and hence make the resulting schema for JSCalendar more complicated and code generation brittle.

I don't think that the shortcomings of particular technologies or tools should guide our design. But JSCalendar claims to be "simple to process", and the benefits of using `false` in this particular case don't seem to me to warrant its potential risks.

Of all the proposals, I vouch for `method:cancel`, as it neither extends iTIP vocabulary, nor requires special handling of the payloads. Implementations can apply the same patch mechanism to all entries in recurrenceOverrides and if the resulting patched object instance has a `method:cancel` can just ignore it.


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


-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
--------------B5224E373EBE96A6CBD1BEAF-- From nobody Thu May 17 03:52:56 2018 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 4CAE512D77B for ; Thu, 17 May 2018 03:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, 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 TH_tT87Oj8KP for ; Thu, 17 May 2018 03:52:53 -0700 (PDT) Received: from forward3-smtp.messagingengine.com (forward3-smtp.messagingengine.com [66.111.4.237]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0176512D77A for ; Thu, 17 May 2018 03:52:52 -0700 (PDT) Received: from mailredirect.nyi.internal (imap22.nyi.internal [10.202.2.72]) by mailforward.nyi.internal (Postfix) with ESMTP id F02D31A15 for ; Thu, 17 May 2018 06:52:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mailredirect.nyi.internal (Postfix) with ESMTP id E7924CA2B7 for ; Thu, 17 May 2018 06:52:51 -0400 (EDT) Message-Id: <15d726fb-e02c-4252-86b0-aec652840271@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-606-gd567d7d-next x-jmap-identity-id: 64588216 In-Reply-To: References: <478ec7b1-298d-06da-42ba-fa06c6fb396e@dmfs.org> <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> <0c02d353-0a47-44fa-a336-90ff132dfe33@sloti22d1t06> <1526457422.1612996.1373808904.0510211F@webmail.messagingengine.com> Date: Thu, 17 May 2018 06:52:51 -0400 From: Neil Jenkins To: calsify@ietf.org Content-Type: multipart/alternative; boundary=4f220083ec8741c69dd699343acbe0f5 Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2018 10:52:55 -0000 --4f220083ec8741c69dd699343acbe0f5 Content-Type: multipart/related; boundary=c556279cb7674bea851dc72954fcceab --c556279cb7674bea851dc72954fcceab Content-Type: text/html
On Wed, 16 May 2018, at 8:56 PM, Marten Gajda wrote:
So here is another option:
"recurrenceOverrides": {
   "2018-05-16T12:50:00": { "excluded": true }
}

I could certainly go with this. I think we've agreed:
  • We want to keep it all part of recurrenceOverrides.
  • We don't want to map to a different JSON type.
  • Therefore we need to map to an object with a single key/value property that signifies this date should be omitted from the recurrence set.
Whether that property is `method: 'cancel'` or `excluded: true` doesn't bother me too much. I can see how using a new property avoids potential confusion that this is about scheduling in some way, so this seems reasonable.

Neil.
--c556279cb7674bea851dc72954fcceab-- --4f220083ec8741c69dd699343acbe0f5 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, 16 May 2018, at 8:56 PM, Marten Gajda wrote: > So here is another option:=20 > "recurrenceOverrides": { > =C2=A0=C2=A0 "2018-05-16T12:50:00": { "excluded": true } > } =20 I could certainly go with this. I think we've agreed: * We want to keep it all part of recurrenceOverrides. * We don't want to map to a different JSON type. * Therefore we need to map to an object with a single key/value propert= y that signifies this date should be omitted from the recurrence set. Whether that property is `method: 'cancel'` or `excluded: true` doesn't = bother me too much. I can see how using a new property avoids potential = confusion that this is about scheduling in some way, so this seems reaso= nable. Neil. --4f220083ec8741c69dd699343acbe0f5-- From nobody Thu May 17 17:00:17 2018 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 7D8B4124235 for ; Thu, 17 May 2018 17:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=tvsBGvzY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PhYblA2X 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 Bm670cxnTS_5 for ; Thu, 17 May 2018 17:00:13 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0DD120454 for ; Thu, 17 May 2018 17:00:13 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D28FA22390 for ; Thu, 17 May 2018 20:00:12 -0400 (EDT) Received: from web2 ([10.202.2.212]) by compute6.internal (MEProxy); Thu, 17 May 2018 20:00:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=L63h/wD0a0/NYK1Kx ZC4qNgTLYKr1UHG7jWYHcknT2w=; b=tvsBGvzYosCVLVsmFhaoQQKvYhfhTgJzy 6miLkp9h1q3NONz0sbSFw9k2OeQbq58VT7+jgl3CjeeFuMNlDHeCV5Kk5Rj+nnsB kO/3chnNvpNLvXI1Aq4dpTxYO5j1JeLAvfnIw6LJyR3SCtjS6Qw8fuNJbGIArYgo 2aKHhXG5MSZfyHZtdaFwPoTRgtX/Bujvo9Oz7DbG+qiPXHLJQYokVbJ0zhNtplHK ra75g13AASUhXaQQ8btACZTCvcV7ZKaURYJoXl+b64mueLDbqeXkwU9d9JI/rKid BP+1UyQwE47ogNYXwh2KTt/seCDsa1JJ5dHo8HM2tLi9zQNIPazug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=L63h/w D0a0/NYK1KxZC4qNgTLYKr1UHG7jWYHcknT2w=; b=PhYblA2XvcWmlo9+aIl2k9 +kFVWPPFUPbDHV94vD9Jnz6eLRnAWQKRL2ZPxbJGvtK17SvbCfMJPARrTcQwlWTR OQ1ECY6Bd8xK+8VgSgULEqLzex6g4mlDCDr+Y+b7aNg1DkYDPcqrx/jOGeXN+pk9 aaZhoymM0xzqLBdhIkJFQWoe2QInSEeOfQkEqU3zcXxc8GU3XiB+EEADIOPXxrwC vh8EwW79tOnrAB24LAKnAYcPh1XpBH15Q09puk+zHhulHTRKwX6OMKn3JuI2t8u7 6GWsGwZs3tGi00Yw4IQvhX/LAydZR8sUb0kpX/IaP6pLNBB2XbW8581T9bz3vEAw == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 91F82621DC; Thu, 17 May 2018 20:00:12 -0400 (EDT) Message-Id: <1526601612.3299349.1376196656.497F74F5@webmail.messagingengine.com> From: Bron Gondwana To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152660161232993490" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29fe4c42 Date: Fri, 18 May 2018 10:00:12 +1000 In-Reply-To: <15d726fb-e02c-4252-86b0-aec652840271@sloti22d1t06> References: <478ec7b1-298d-06da-42ba-fa06c6fb396e@dmfs.org> <1525875824.2195603.1366173968.5A8E249C@webmail.messagingengine.com> <0c02d353-0a47-44fa-a336-90ff132dfe33@sloti22d1t06> <1526457422.1612996.1373808904.0510211F@webmail.messagingengine.com> <15d726fb-e02c-4252-86b0-aec652840271@sloti22d1t06> Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-03 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2018 00:00:16 -0000 This is a multi-part message in MIME format. --_----------=_152660161232993490 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Thu, May 17, 2018, at 20:52, Neil Jenkins wrote: > Whether that property is `method: 'cancel'` or `excluded: true` > doesn't bother me too much. I can see how using a new property avoids > potential confusion that this is about scheduling in some way, so this > seems reasonable. I agree. My proposal of "method:cancel" was being too smart. "excluded:true" is both more obvious to the casual observer, and less overloading of meaning. The thing which frustrates me the most when implementing is when the same term is used for two different and slightly incompatible meanings (like IMAP's "UNSEEN" in status vs "UNSEEN" in select response). In summary - I support excluded: true Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_152660161232993490 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Thu, May 17, 2018, at 20:52, Neil Jenkins wrote:
Whether that property is `method: 'cancel'` or `excluded: true` doesn't bother me too much. I can see how using a new property avoids potential confusion that this is about scheduling in some way, so this seems reasonable.

I agree.  My proposal of "method:cancel" was being too smart.  "excluded:true" is both more obvious to the casual observer, and less overloading of meaning.  The thing which frustrates me the most when implementing is when the same term is used for two different and slightly incompatible meanings (like IMAP's "UNSEEN" in status vs "UNSEEN" in select response).

In summary - I support excluded: true

Bron.


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


--_----------=_152660161232993490-- From nobody Tue May 22 04:12:44 2018 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 516A9126D45 for ; Tue, 22 May 2018 04:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 8eLh2-GL4utL for ; Tue, 22 May 2018 04:12:41 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0FC3126CD8 for ; Tue, 22 May 2018 04:12:41 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DD9C4217DC for ; Tue, 22 May 2018 07:12:40 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute1.internal (MEProxy); Tue, 22 May 2018 07:12:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=OR39jp/i1sFnWtoUvjDIueERoLLQA XJMhBa5k4RgkJI=; b=itfVeUvdaSIjPU9XgNtgeWIMxp1zNsGxwlPWIeIWQX8E8 2xlHMWbHK+CdL2Y50bYBvuw9vid7Y/3/46V69EvIyGXun6Ry2xaGQXKUKpLjy3CN rqgWKYIHV4PrfID0rZQGAySdVVxuNCv7xrYqxsfh9ihjwC4qYVEWoj5IGsNFZyDS vvy+s6v6onYDZbnyhp81o+avQ85SsGubgQJHexZXHD+D2qYwEHoOPf/g3f06QZFI wpQrhCWaeKI7KcvbRF9YGTpQjq8xPnhE/mXw5XIH7z8Gcv3UR7NTSqBEkk6C8mH1 qUFq5sGZ4JeF7Hz/yAr7OqHo1mqGh8HUQMlPGGgnA== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9BBB040F6; Tue, 22 May 2018 07:12:40 -0400 (EDT) Message-Id: <1526987560.642209.1380540328.34EDDFAB@webmail.messagingengine.com> From: Robert Stepanek To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15269875606422090" X-Mailer: MessagingEngine.com Webmail Interface - ajax-a224ff37 Date: Tue, 22 May 2018 13:12:40 +0200 Archived-At: Subject: [calsify] Requesting feedback on recurring JSTask/VTODO X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 11:12:44 -0000 This is a multi-part message in MIME format. --_----------=_15269875606422090 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Following up our recent discussions around evaluation of recurrence rules, I am in the process of updating the JSCalendar draft. One of the areas that hasn't received attention, yet, are the specifics of JSTask and their recurrence rules. I would very much appreciate more feedback on this from people with more practical experience in task- oriented workflows. Specifically: *Task due vs start* The current JSCalendar RFC draft defines a JSTask to recur by its start property, if defined. This is in line with the iCalendar RRULE definition. As an addition, JSCalendar defines the recurrenceRule to apply to the due date, if no start is specified. Is this a reasonable suggestion? What is more important for tasks, the start or the due date, e.g. should due take precedence over start in RRULE evaluation? Or should it be possible to define which property to recur by? *Tasks without due and start* The iCalendar spec defines a VTODO without a start or due date to "specify a to-do that will be associated with each successive calendar date, until it is completed." During discussion of JSTask a year ago in Seattle, we had envisioned tasks without start or due date to exist without any specific anchor to a time-line. I am not sure if that's also what is meant in the iCalendar spec. Does anyone know better? Also: it looks reasonable to explicitly forbid recurrence rules for JSTasks without due or start time. Are there any objections to that? Cheers, Robert --_----------=_15269875606422090 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Following up our recent discussions around evaluation of recurrence rules, I am in the process of updating the JSCalendar draft.

One of the areas that hasn't received attention, yet, are the specifics of JSTask and their recurrence rules. I would very much appreciate more feedback on this from people with more practical experience in task-oriented workflows. Specifically:

Task due vs start
The current JSCalendar RFC draft defines a JSTask to recur by its start property, if defined. This is in line with the iCalendar RRULE definition.

As an addition, JSCalendar defines the recurrenceRule to apply to the due date, if no start is specified. Is this a reasonable suggestion? What is more important for tasks, the start or the due date, e.g. should due take precedence over start in RRULE evaluation? Or should it be possible to define which property to recur by?

Tasks without due and start
The iCalendar spec defines a VTODO without a start or due date to "specify a to-do that will be associated with each successive calendar date, until it is completed."

During discussion of JSTask a year ago in Seattle, we had envisioned tasks without start or due date to exist without any specific anchor to a time-line. I am not sure if that's also what is meant in the iCalendar spec. Does anyone know better? Also: it looks reasonable to explicitly forbid recurrence rules for JSTasks without due or start time. Are there any objections to that?

Cheers,
Robert

--_----------=_15269875606422090-- From nobody Tue May 22 09:23:28 2018 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 344B71275F4 for ; Tue, 22 May 2018 09:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 m3q-zIVgAAOQ for ; Tue, 22 May 2018 09:23:25 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 61FF4127275 for ; Tue, 22 May 2018 09:23:25 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id g13-v6so24170935qth.8 for ; Tue, 22 May 2018 09:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=c5azGy0ZGgtbRaiPAuzy6V2Oqvklo58LUQwmVZD5qSA=; b=bOism1+kybP/OGdkVZILL2DlfYw/H1s14XEE5GMeYIcAih5JRN5fTXAOy/3Oabc27P qwmBbEQNCCnIOwNE2qqUg08WahrsZHw4YuFZ9dRSoL9jX9CHTa8RAM0rgATKXnIDurRR RdKu29aZ23uRkRhBI81Akofaaf8TJIVhjL7ZiUHnv4LA19T/fuMxVBN26xC0QVA9YYqc tuz+zMOS1DcgOifhVK2Yb4BEydOv+d1gbLKlm/iEAIL4OrY4yvMbg3pWNiGjR+1C4gu0 BGUTK9taZ5cvbw9UaNZqiriysa26FVvRLbKAz/IH1qWDdz0japhWbSQHi+cUQ9F4QlPg bgyw== 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=c5azGy0ZGgtbRaiPAuzy6V2Oqvklo58LUQwmVZD5qSA=; b=Rxh5AkvyUbgb1VkjNR5t1Hmmmdo0bO+Lm8NY1EQ2nt3/+/rwKYcpXW5/rGPGiGVp+E o5nBBTL4RpB+UL/NNQ8tTuLuFFSvI5mAh/WVaQ/RrktwiGW5uwnHJJGZ2kKD7jJkx4mG DTOeYOgyuiDFzVnQ26Vypv3/4XmI90Evqayb4RB9BU0MZDSGvRyWUGxiI9f9cPyXB6/c AWU8ySD/P488TQzYI9pO7XnovUKCimRwN/t/wlmVuLJwYRPWHIyIGUgO5VgjbNTEcLBW /2tIb3Aq9fxbuT+MpWdG/X/QDsMpquIzCX11cFqQ/Dw9YQhDPI+vSp1z9mOJyIqtbyKp YQMA== X-Gm-Message-State: ALKqPwe+aq18e2Jh+4KWmhFDsw9JK76ycmqBrQkh/4iT8LKTMSJ3rAmW WGOY42nHiHgpXlBiBSUTj3ihPg== X-Google-Smtp-Source: AB8JxZongmFYmT5IfMBSqYAZ/TOBl+eC8B+Km6vB9iwwoaOmb50C/NXpWAk7Yjj7OHSM/20hXe0uuQ== X-Received: by 2002:a0c:96cd:: with SMTP id b13-v6mr22315112qvd.196.1527006204141; Tue, 22 May 2018 09:23:24 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id u24-v6sm13118412qku.18.2018.05.22.09.23.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 May 2018 09:23:23 -0700 (PDT) To: calsify@ietf.org References: <1526987560.642209.1380540328.34EDDFAB@webmail.messagingengine.com> From: Michael Douglass Message-ID: <8cd76945-a050-becb-3e9f-0800bd1c30ba@gmail.com> Date: Tue, 22 May 2018 12:23:23 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1526987560.642209.1380540328.34EDDFAB@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------CE0F5DA75684CE811AAF94FF" Content-Language: en-US Archived-At: Subject: Re: [calsify] Requesting feedback on recurring JSTask/VTODO X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 16:23:27 -0000 This is a multi-part message in MIME format. --------------CE0F5DA75684CE811AAF94FF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 5/22/18 07:12, Robert Stepanek wrote: > Following up our recent discussions around evaluation of recurrence > rules, I am in the process of updating the JSCalendar draft. > > One of the areas that hasn't received attention, yet, are the > specifics of JSTask and their recurrence rules. I would very much > appreciate more feedback on this from people with more practical > experience in task-oriented workflows. Specifically: > > *Task due vs start* > The current JSCalendar RFC draft defines a JSTask to recur by its > start property, if defined. This is in line with the iCalendar RRULE > definition. > > As an addition, JSCalendar defines the recurrenceRule to apply to the > due date, if no start is specified. Is this a reasonable suggestion? > What is more important for tasks, the start or the due date, e.g. > should due take precedence over start in RRULE evaluation? Or should > it be possible to define which property to recur by? *Tasks without due and start* > The iCalendar spec defines a VTODO without a start or due date to > "specify a to-do that will be associated with each successive calendar > date, until it is completed." > > During discussion of JSTask a year ago in Seattle, we had envisioned > tasks without start or due date to exist without any specific anchor > to a time-line. I am not sure if that's also what is meant in the > iCalendar spec. Does anyone know better? I believe that's correct - a task without any start or due floats along as time progresses. I think I imlemented them as always being the current date which may not be totally correct > Also: it looks reasonable to explicitly forbid recurrence rules for > JSTasks without due or start time. Are there any objections to that? I think it's fairly simple and the rules as defined mostly work. We don't need to worry about precedence. Any generated instance must have the same time difference between start and end. It's up to the consumer to decide whether the start (assignment) is more or less important than the due date. I think the rules are: if there's a start use that. otherwise if there's a due use that otherwise no recurrence is possible or allowed. > > > Cheers, > Robert > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------CE0F5DA75684CE811AAF94FF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 5/22/18 07:12, Robert Stepanek wrote:
Following up our recent discussions around evaluation of recurrence rules, I am in the process of updating the JSCalendar draft.

One of the areas that hasn't received attention, yet, are the specifics of JSTask and their recurrence rules. I would very much appreciate more feedback on this from people with more practical experience in task-oriented workflows. Specifically:

Task due vs start
The current JSCalendar RFC draft defines a JSTask to recur by its start property, if defined. This is in line with the iCalendar RRULE definition.

As an addition, JSCalendar defines the recurrenceRule to apply to the due date, if no start is specified. Is this a reasonable suggestion? What is more important for tasks, the start or the due date, e.g. should due take precedence over start in RRULE evaluation? Or should it be possible to define which property to recur by?
Tasks without due and start
The iCalendar spec defines a VTODO without a start or due date to "specify a to-do that will be associated with each successive calendar date, until it is completed."

During discussion of JSTask a year ago in Seattle, we had envisioned tasks without start or due date to exist without any specific anchor to a time-line. I am not sure if that's also what is meant in the iCalendar spec. Does anyone know better?
I believe that's correct - a task without any start or due floats along as time progresses. I think I imlemented them as always being the current date which may not be totally correct
Also: it looks reasonable to explicitly forbid recurrence rules for JSTasks without due or start time. Are there any objections to that?
I think it's fairly simple and the rules as defined mostly work. We don't need to worry about precedence. Any generated instance must have the same time difference between start and end. It's up to the consumer to decide whether the start (assignment) is more or less important than the due date.

I think the rules are:
if there's a start use that.
otherwise if there's a due use that
otherwise no recurrence is possible or allowed.





Cheers,
Robert



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

--------------CE0F5DA75684CE811AAF94FF-- From nobody Wed May 23 05:30:34 2018 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 0C48312DB6C for ; Wed, 23 May 2018 05:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apthorpia-com.20150623.gappssmtp.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 883_KXNpxWmC for ; Wed, 23 May 2018 05:30:01 -0700 (PDT) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (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 00C1212E03E for ; Wed, 23 May 2018 05:30:00 -0700 (PDT) Received: by mail-pl0-x231.google.com with SMTP id u6-v6so12944006pls.9 for ; Wed, 23 May 2018 05:30:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apthorpia-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hWh+M52ochs3BdCloDb7IM/80qlZ+OXBKJmepqfJjDE=; b=y7Csk12eu3g+UTNLpvZabtolBp459EsG7vxG71ZM5AhVqZbf+9ViNnmtMQNdL3Oq1u 1SBJ3dl7otMxRRsUTQVJ3UcEsdwwgYC2oVMG86Y0AbWV+2imfWTBqz5BD919mk3YQaYX UbL13aEwjGig7ZL2xIBsfc1tjE57DfEAtyIv/PA/HYN3hwOGMsvHOqvcTGI2xVjrPVQP 9ZY4Mmn3i56s0dFHl/Go9cU5zVt8cpYy/ONE76BRwUZg+XpH7O4eHIVfkuDNKLgj2HLP BTM4+fy+yYJvHaLTvjELf2gT5r8OLM9KKHTi3EolMiUVK05UvixofCK1g4CL21qO2h52 EhDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hWh+M52ochs3BdCloDb7IM/80qlZ+OXBKJmepqfJjDE=; b=sHWh0MxjLZVPbjJXxSXp3hyY93KRJHR3pgmunLJqMuWXLDptc53R18ADxjWc3fejrf hn8iS9WwGtucUvNvQhByLW1aHRiHE6SMasJlSyYw2XYg6GJixDv7rXVVDVGB+x8ZgamD t3pssuHs1lmCKiwnqdxVBD+LNQGbArhKc5rxB+PSB4joalnmiexmxQDGHbJnPnc3v6nD YNLoXEZqOR+scFIv5NJKvSOcSuEE49ZsjsRF8S+xm5a6KmWJuESx08fdtvK7IawmT8LF 3abw9CF3xC+D3yaNnATN1Vkg3mDXeQLxAd3uD+fWreLaemxS6Dvpq5N/bhA06LY+4msQ sc4g== X-Gm-Message-State: ALKqPwfEqiuwi25/HesnWbLKghkm6koGFza5XWWwirfVNpjYV0QQPjQw Hy9VSFM9CZYRxcyEzMheaLY5DxyKjxE= X-Google-Smtp-Source: AB8JxZp4EH7/qzFe29uG7TMPQ4t213w9O/855lHLqbQ4refrjZOrKZYu8EpRcm2oG3XZJOTM2vn/kQ== X-Received: by 2002:a17:902:7c03:: with SMTP id x3-v6mr2679339pll.237.1527078600229; Wed, 23 May 2018 05:30:00 -0700 (PDT) Received: from [192.168.2.245] ([138.75.30.234]) by smtp.gmail.com with ESMTPSA id j3-v6sm28510126pgs.76.2018.05.23.05.29.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 May 2018 05:29:58 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-DC39BACB-5A9C-4C19-8F61-EA30DB5B4442 Mime-Version: 1.0 (1.0) From: Adrian Apthorp X-Mailer: iPad Mail (15E302) In-Reply-To: <8cd76945-a050-becb-3e9f-0800bd1c30ba@gmail.com> Date: Wed, 23 May 2018 20:29:57 +0800 Cc: calsify@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <1526987560.642209.1380540328.34EDDFAB@webmail.messagingengine.com> <8cd76945-a050-becb-3e9f-0800bd1c30ba@gmail.com> To: Michael Douglass Archived-At: Subject: Re: [calsify] Requesting feedback on recurring JSTask/VTODO X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 12:30:15 -0000 --Apple-Mail-DC39BACB-5A9C-4C19-8F61-EA30DB5B4442 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 23 May 2018, at 12:23 AM, Michael Douglass wr= ote: >=20 >> On 5/22/18 07:12, Robert Stepanek wrote: >> Following up our recent discussions around evaluation of recurrence rules= , I am in the process of updating the JSCalendar draft. >>=20 >> One of the areas that hasn't received attention, yet, are the specifics o= f JSTask and their recurrence rules. I would very much appreciate more feedb= ack on this from people with more practical experience in task-oriented work= flows. Specifically: There was some discussion on this in TCTASK. You may find some details if yo= u have access to the group archives. However, generally we opted to keep thi= s simple, for the very reason that if we weren=E2=80=99t careful we=E2=80=99= d end up defining a workflow language and there=E2=80=99s enough of those ar= ound. This is particularly true if you try and define recurring related task= s with no time anchor. >>=20 >> Task due vs start >> The current JSCalendar RFC draft defines a JSTask to recur by its start p= roperty, if defined. This is in line with the iCalendar RRULE definition. >>=20 >> As an addition, JSCalendar defines the recurrenceRule to apply to the due= date, if no start is specified. Is this a reasonable suggestion? What is mo= re important for tasks, the start or the due date, e.g. should due take prec= edence over start in RRULE evaluation? Or should it be possible to define wh= ich property to recur by? > Tasks without due and start >>=20 >> The iCalendar spec defines a VTODO without a start or due date to "specif= y a to-do that will be associated with each successive calendar date, until i= t is completed."=20 >>=20 >> During discussion of JSTask a year ago in Seattle, we had envisioned task= s without start or due date to exist without any specific anchor to a time-l= ine. I am not sure if that's also what is meant in the iCalendar spec. Does a= nyone know better? > I believe that's correct - a task without any start or due floats along as= time progresses. I think I imlemented them as always being the current date= which may not be totally correct Yep. It just sits on a task list. >> Also: it looks reasonable to explicitly forbid recurrence rules for JSTas= ks without due or start time. Are there any objections to that? > I think it's fairly simple and the rules as defined mostly work. We don't n= eed to worry about precedence. Any generated instance must have the same tim= e difference between start and end. It's up to the consumer to decide whethe= r the start (assignment) is more or less important than the due date. >=20 > I think the rules are: > if there's a start use that. > otherwise if there's a due use that > otherwise no recurrence is possible or allowed. This sounds right to me. >=20 >=20 >=20 >>=20 >>=20 >> Cheers, >> Robert >>=20 >>=20 >>=20 >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >=20 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --Apple-Mail-DC39BACB-5A9C-4C19-8F61-EA30DB5B4442 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 23 May 2018, at 12:23 A= M, Michael Douglass <mikeadoug= lass@gmail.com> wrote:

On 5/22/18 07:12, Robert Stepanek wrote:
=20
Following up our recent discussions around evaluation of recurrence rules, I am in the process of updating the JSCalendar draft.

One of the areas that hasn't received attention, yet, are the specifics of JSTask and their recurrence rules. I would very much appreciate more feedback on this from people with more practical experience in task-oriented workflows. Specifically:

There was some discu= ssion on this in TCTASK. You may find some details if you have access to the= group archives. However, generally we opted to keep this simple, for the ve= ry reason that if we weren=E2=80=99t careful we=E2=80=99d end up defining a w= orkflow language and there=E2=80=99s enough of those around. This is particu= larly true if you try and define recurring related tasks with no time anchor= .

=

Task due vs start
The current JSCalendar RFC draft defines a JSTask to recur by its start property, if defined. This is in line with the iCalendar RRULE definition.

As an addition, JSCalendar defines the recurrenceRule to apply to the due date, if no start is specified. Is this a reasonable suggestion? What is more important for tasks, the start or the due date, e.g. should due take precedence over start in RRULE evaluation? Or should it be possible to define which property to recur by?
Tasks without due and start
The iCalendar spec defines a VTODO without a start or due date to "specify a to-do that will be associated with each successive calendar date, until it is completed."

During discussion of JSTask a year ago in Seattle, we had envisioned tasks without start or due date to exist without any specific anchor to a time-line. I am not sure if that's also what is meant in the iCalendar spec. Does anyone know better?
I believe that's correct - a task without any start or due floats along as time progresses. I think I imlemented them as always being the current date which may not be totally correct
=

Yep. It just sits on a task list.

Also: it looks reasonable to explicitly forbid recurrence rules for JSTasks without due or start time. Are there any objections to that?
I think it's fairly simple and the rules as defined mostly work. We don't need to worry about precedence. Any generated instance must have the same time difference between start and end. It's up to the consumer to decide whether the start (assignment) is more or less important than the due date.

I think the rules are:
if there's a start use that.
otherwise if there's a due use that
otherwise no recurrence is possible or allowed.

This sounds right to me.






Cheers,
Robert



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

=20
____________________= ___________________________
calsify mailing list
<= span>calsify@ietf.org
https://www.ietf= .org/mailman/listinfo/calsify
= = --Apple-Mail-DC39BACB-5A9C-4C19-8F61-EA30DB5B4442-- From nobody Fri May 25 01:25:01 2018 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 545CC12DA07; Fri, 25 May 2018 01:24:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152723668625.12989.13281187321461088241@ietfa.amsl.com> Date: Fri, 25 May 2018 01:24:46 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-04.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 08:24:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : JSCalendar: A JSON representation of calendar data Authors : Neil Jenkins Robert Stepanek Filename : draft-ietf-calext-jscalendar-04.txt Pages : 56 Date : 2018-05-25 Abstract: This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative to the widely deployed iCalendar data format and to be unambiguous, extendable and simple to process. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-04 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 25 01:26:27 2018 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 2EDA812EA95 for ; Fri, 25 May 2018 01:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 qH1-Rbbt8l1P for ; Fri, 25 May 2018 01:26:14 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E71A12E054 for ; Fri, 25 May 2018 01:26:14 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B03F422B86 for ; Fri, 25 May 2018 04:26:13 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute1.internal (MEProxy); Fri, 25 May 2018 04:26:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=5m7tBKP90RSrnEwFLiUxQlvcawpBr xtUAz88FfmWXtA=; b=UW6hcpjq38QNUprYfEt1nFAC+V5TG3VUgC4W7C9LbPiWm 2VHbU7QmKPMpfqhNdEcMgoigF/MQADzfCVFY4U/ymgs4CY61W3qeMqKYIMWtI2tU 11/izypMNyqHqJVxEAXWLKn0lKMnG9oUcUvbZGrZzgNdndSNlhQ6ytr+kqQBELZX BLJ039HBKWbm/jtU5cJbYToETD1OSLka6M1JmHBG4nb+x9UndzU81vIYXVLaC6PO cQZNHU/6j+yfi3MFMEWyrQrqzplKRmXsmtlZtI0u6ByufBEwlQCQ+Z6YFK7K3hpE mikkiTvG1fZZo674vnI4uCTIlYK6/3WI0TUqLhBaw== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 5CEE84109; Fri, 25 May 2018 04:26:13 -0400 (EDT) Message-Id: <1527236773.2751997.1384639856.43EC19AA@webmail.messagingengine.com> From: Robert Stepanek To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152723677327519971" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29e6b281 Date: Fri, 25 May 2018 10:26:13 +0200 Archived-At: Subject: [calsify] Updated JSCalendar draft calext-04 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 08:26:26 -0000 This is a multi-part message in MIME format. --_----------=_152723677327519971 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi all, thanks for all your input on version 3 of the JSCalendar RFC draft. I have just uploaded version 4[1] which incorporates your feedback. Main changes: * *recurrenceRule and recurrenceOverrides*: the definition of recurrence rules and overrides has been refined. It now also includes the evaluation instructions as outlined by Neil. * *localizations*: following our conference calls and email discussion, the specification again includes the localizations property. However, it does not define how to maintain validity of localized content, nor does it define how to map them between iCalendar and JSCalendar. * *replyTo*: the HTTP path template for the replyTo `web` property must use HTTPS. For the upcoming CalConnect conference in Tokyo in one week, I plan the current version to be the basis for discussion. Depending on your feedback on the list, we might send out a new version before the IETF 102 draft submission deadline on July 2. Cheers, Robert Links: 1. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-04 --_----------=_152723677327519971 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi all,

thanks for all your input on version 3 of the JSCalendar RFC draft. I have just uploaded version 4 which incorporates your feedback.

Main changes:
  • recurrenceRule and recurrenceOverrides: the definition of recurrence rules and overrides has been refined. It now also includes the evaluation instructions as outlined by Neil.
  • localizations: following our conference calls and email discussion, the specification again includes the localizations property. However, it does not define how to maintain validity of localized content, nor does it define how to map them between iCalendar and JSCalendar.
  • replyTo: the HTTP path template for the replyTo `web` property must use HTTPS.

For the upcoming CalConnect conference in Tokyo in one week, I plan the current version to be the basis for discussion. Depending on your feedback on the list, we might send out a new version before the IETF 102 draft submission deadline on July 2.

Cheers,
Robert
--_----------=_152723677327519971-- From nobody Fri May 25 03:43:14 2018 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 B210F124D68 for ; Fri, 25 May 2018 03:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=IMfM77G1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=I08cMCZ+ 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 hpUmoCKa7Td9 for ; Fri, 25 May 2018 03:43:11 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885D6124BAC for ; Fri, 25 May 2018 03:43:11 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id DD08C22BD5 for ; Fri, 25 May 2018 06:43:10 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Fri, 25 May 2018 06:43:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=O2QTQjEB9+Acv/Xc0C5Jl60fXHULnF++zTqxF9BYa WM=; b=IMfM77G1BWr65vuJOYTDNDUceykfC6gZ7TCVAGGqCxGyf1WeuiBnQRFZc JXtwpKm3rhpEgBOAlo3kffqzV9h89LawetTYxgRyr37QEWAwjLtoleUqIyzCuhNZ APcKOhY/5OK7sJmVlCklHKJSbvED0uZcNx91DUyH0O7JenBmaB7SBU8ch+Ov7HC0 YtKx/FpxEfvg8XHfDlKMdAr1oG5AEFcoVjyrkauxC0k9hoGEmyCcjUrGJubIPeeP Nqpqk6C8kECcLIG7AJbGyW8FtUXrsteW8c6k5KHBISEIzaRarQRgzQbW6Y9nLdKz st0N633qn5TXTAZ6Uu+68cHX06gaQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=O2QTQjEB9+Acv/Xc0C5Jl60fXHULnF++zTqxF9BYa WM=; b=I08cMCZ+WWNUcnwiQ6z9EKqsfeqYpEaty+ISBQgBUwIZt5cM4DeFZbme2 fKiAUjft0WFAIo2khfb4aAxr+WlDjVsalPgRzgjP6NA+U+RMmtt588D6Ajzz1BJO vCiLIsfdM587J0D5K5ALX0BDIu40ZlWWtnyoY7PMQIuMi5xidCxVxIA48DZrrgb5 otVIgjKQ/iwremE3F9kR1OOGjP062EyiKLUqxIKGjkOZmAD7Qs5Hn2LwIktVV3ln SIZtC+cm4epPLU76RGhNjSitXLTnVybVXl9eMbk62HO9ZO32skfoIRlaCRF1EXTI KDletpYYUxAnFHZesXC5MUkRpjqOg== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9C531CA2AD; Fri, 25 May 2018 06:43:10 -0400 (EDT) Message-Id: <1fb3e930-cce3-4e55-9040-da6fea5fd3f6@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-624-g558ee02-next x-jmap-identity-id: 64588216 In-Reply-To: <1527236773.2751997.1384639856.43EC19AA@webmail.messagingengine.com> References: <1527236773.2751997.1384639856.43EC19AA@webmail.messagingengine.com> Date: Fri, 25 May 2018 06:43:10 -0400 From: Neil Jenkins To: calsify@ietf.org Content-Type: multipart/alternative; boundary=6c82abba34044457bf6a29c61c9087b1 Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-04 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 10:43:13 -0000 --6c82abba34044457bf6a29c61c9087b1 Content-Type: multipart/related; boundary=5713f1b8d3134a2ca6f86a413f1ba586 --5713f1b8d3134a2ca6f86a413f1ba586 Content-Type: text/html
The recurrenceOverrides type is now wrong. It should just be LocalDate[PatchObject]|null

Neil.
--5713f1b8d3134a2ca6f86a413f1ba586-- --6c82abba34044457bf6a29c61c9087b1 Content-Type: text/plain The recurrenceOverrides type is now wrong. It should just be LocalDate[PatchObject]|null Neil. --6c82abba34044457bf6a29c61c9087b1-- From nobody Fri May 25 03:44:46 2018 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 942CD124D68 for ; Fri, 25 May 2018 03:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zonevs.eu header.b=ui/mnK8L; dkim=pass (2048-bit key) header.d=srs2.zonevs.eu header.b=xyB4BYWD; dkim=pass (2048-bit key) header.d=dot.ee header.b=WrUStpxv 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 m9NnuKtzr_fe for ; Fri, 25 May 2018 03:44:41 -0700 (PDT) Received: from srs2.zonevs.eu (srs2.zonevs.eu [217.146.68.192]) (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 B0EFB124BAC for ; Fri, 25 May 2018 03:44:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=LIvvjH3NisfZ0NL4M1cR81pr0tkf6+OE5wxPTz9emtw=; h=from:subject:date:message-id:to:mime-version:content-type; b=ui/mnK8LhhPu43vz6pIyOfXcXxfSSGJCejiv86XfmgWxu4jDWtXL7QNBGipn/98S9D3Pj+UUk 9AX/ANVWHoI8j2HIkWNJ+qCbCfSG3IqZNfbj+X1GW/i+FRAsf8zWDOixzaaYx7B4smFt/va1Lvp eeNQDNdDs4LWToKtz4vRbDf7pFsEEjNGkul2A5gaTuilidi3d6n0v3TvrLR9If1X2nKnqgKEnS0 VNFfhQZnqAmgW77AtYzCAAYZcbQmDoTBaJERt85yek2bPa4ERnKUMAPVsrGEh5BihtjcpDyv7fN +XmeDVXtywFI+kWIH8O/n8TyITciosgskgr4NtJnsa/w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs2.zonevs.eu; q=dns/txt; s=oct2016; bh=LIvvjH3NisfZ0NL4M1cR81pr0tkf6+OE5wxPTz9emtw=; h=from:subject:date:message-id:to:mime-version:content-type; b=xyB4BYWD3BVQDbnb7GPrzWWlgnrSB2pS2GMRgGwks52ZIg91e42dy/ykiMxkHmQByA4v3tHK1 tSCpPXPxUqu4QWCxTMaol4EvRfypCHjbejaWpivJ+1q3MXQ820Lc5TrXSIuVxRgbJlNFjMU2xNT J7Hwgjo3ojkqZYAyPf11ibOynDPvgU30f+tNRhaWtrnxRrHxgCHk3B97tm3A0Xn/ueG9pr3ya1x mLu9xP3XLfUPEUgQlnFL5WFibvd+tkLzuFMsfr44x270xNK2A2PTPTx/PjkFy6vhPhejdYH+r8A A4hptkM+9oFYykJqCGY1Va9xLlVfHdzrPcFa8tdKqsLg== Received: from smtp.zone.eu ([217.146.66.121] smtp.zone.eu) by srs2.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 16396e671da0006747.001 for ; Fri, 25 May 2018 10:44:34 +0000 X-Zone-Loop: 7df3ef48f0b1e9fe9fc5d67e590e17c9bca8be7478ab Received: from localhost (43-221-50-195.dyn.estpak.ee [195.50.221.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: d3623m47440@@) by smtp.zone.eu (Postfix) with ESMTPSA id 6DE9A18F9C12 for ; Fri, 25 May 2018 13:44:34 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1527245074; bh=abWKOnfkOW4mOMxtZLyckKU/Aqy/6EPBmbhSFcR5tyw=; h=To:From:Subject:Date; b=WrUStpxvrlW5D870gn78iiBIk4ARfTNJBWB2+ZwfUL0LcTTdTNpFW7KA1ztDC8/x/ 6f0tp1CGmNDSAVA9lWCp1olOAK3uNG3FCJhguVw/AQGSgz1e5N964Tdy+W4KPTkCVu VihC6Vau6VtA/I8enKuJ3MF0AUTpw8WeVDe7MDJgnWyYI7tL2TqQOqwRTf51k57mkZ /RTEXZKCknRpetZMJ4Ff2C+oLZ6en2Lh9YhGIDqpqZ0xQ9R3K+lO5W0Nfa1yngII47 9tkvIKtrbJyaZfH3YM1u9U4nqiaml5EBt57f0vnKNKWTqInCLL5xUeRu/btebqJ8I5 N+CLmQC1jeOnQ== To: calsify@ietf.org From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: <4e5fbfb3-3b6d-954c-9fb7-1fea100c400d@dot.ee> Date: Fri, 25 May 2018 10:44:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8E5421FD56CA6EA00E724C54" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-2.799173, required=15, tests=[HFILTER_HOSTNAME_5=3, BAYES_HAM=-3, ARC_NA=0, TO_DN_NONE=0, MID_RHS_MATCH_FROM=0, R_DKIM_ALLOW=-0.2, RCVD_VIA_SMTP_AUTH=0, RCVD_TLS_ALL=0, NEURAL_HAM=0, MIME_GOOD=-0.1, PREVIOUSLY_DELIVERED=0, DKIM_TRACE=0, FROM_EQ_ENVFROM=0, RCPT_COUNT_ONE=0, ASN=0, IP_SCORE=-2.599173, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: [calsify] ReplyTo with HTTP (for development) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 10:44:45 -0000 This is a multi-part message in MIME format. --------------8E5421FD56CA6EA00E724C54 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hey, I'd like to challenge the HTTPS-only requirement of ReplyTo and possibly other future properties in favor of a better development experience. On 05/25/2018 08:26 AM, Robert Stepanek wrote: > *replyTo*: the HTTP path template for the replyTo `web` property must > use HTTPS. Neil Jenkins: >> >> *Section 4.4.4. replyTo* >> >> Method “web”: It’s 2018, can we ditch support for plain, insecure >> “http”, and only support the secure version? A JSCalendar object with >> an insecure replyTo address is invalid and MUST be rejected. >> > > Seems reasonable to me, although in practice I wonder how many > implementations will actually reject the whole object because of an > http: /replyTo/ property. I'm all for strongly suggesting HTTPS for public Internet use, but during development I must say HTTPS is a pain in the ass. I, like a lot of other people, develop and test locally using either .local (if devices support zero conf) or a private domain in the likes of .dev or .test set up in the router. With HTTPS, one would have to migrate to a public [paid] domain; start managing and distributing certificates among team members; give up using .local in networks one doesn't control and with devices you can't change /etc/hosts on; etc. I'd argue HTTPS-only suggested through "SHOULD" combined with shaming of people using HTTP in the public net suffices. People occasionally do weird things that make HTTPS redundant (proxying HTTP directly to the web server over SSH). Let them. I don't think it's wise to corner oneself in a spec like this. Andri --------------8E5421FD56CA6EA00E724C54 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hey,

I'd like to challenge the HTTPS-only requirement of ReplyTo and possibly other future properties in favor of a better development experience.

On 05/25/2018 08:26 AM, Robert Stepanek wrote:
replyTo: the HTTP path template for the replyTo `web` property must use HTTPS.

Neil Jenkins:

Section 4.4.4. replyTo

Method “web”: It’s 2018, can we ditch support for plain, insecure “http”, and only support the secure version? A JSCalendar object with an insecure replyTo address is invalid and MUST be rejected.


Seems reasonable to me, although in practice I wonder how many implementations will actually reject the whole object because of an http: replyTo property.

I'm all for strongly suggesting HTTPS for public Internet use, but during development I must say HTTPS is a pain in the ass. I, like a lot of other people, develop and test locally using either .local (if devices support zero conf) or a private domain in the likes of .dev or .test set up in the router. With HTTPS, one would have to migrate to a public [paid] domain; start managing and distributing certificates among team members; give up using .local in networks one doesn't control and with devices you can't change /etc/hosts on; etc.

I'd argue HTTPS-only suggested through "SHOULD" combined with shaming of people using HTTP in the public net suffices. People occasionally do weird things that make HTTPS redundant (proxying HTTP directly to the web server over SSH). Let them. I don't think it's wise to corner oneself in a spec like this.

Andri
 --------------8E5421FD56CA6EA00E724C54-- From nobody Fri May 25 03:45:21 2018 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 67A86124BAC for ; Fri, 25 May 2018 03:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 qE6i7_X7P1tR for ; Fri, 25 May 2018 03:45:19 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B284124D68 for ; Fri, 25 May 2018 03:45:19 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 47DC1222E5 for ; Fri, 25 May 2018 06:45:18 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute1.internal (MEProxy); Fri, 25 May 2018 06:45:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=L++3Ol wd682OB1OuD65JQFuANz2jrQetkJ7UDmiFrkI=; b=d21AGrma0Je16XOjs7owmB ETX9qYRArP6rGvivqs2UclDMzN8HRbj2UyllF+YcWyWDNdYGkA93v3MmlC8rBiYc 47wTjNw4Fcl+HlIpb/KQiWHS7FxFWWDJe+5unaTgI2qbL8hFuoj++gQOqglqJFUs Q+OL5U1GR8tH3Ajxdfrf2Qhe+NMrwbrP4PDO72r1yTD6gv2A2yoFUVeRnCA18Gm8 LenxWweiWoISMJHT32k2WopJK3BP3mPdywW3gPfQojzKMGoZRhR/3/B8qAXRg5Z7 9qjB/gwfxNhnAN/OCAO2gGWVovhreKUYlX0CtxYanSnQHp2o82JwuDSvFLNMYjOw == X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1E70B410C; Fri, 25 May 2018 06:45:18 -0400 (EDT) Message-Id: <1527245118.2801484.1384882720.104D8893@webmail.messagingengine.com> From: Robert Stepanek To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_152724511828014840" X-Mailer: MessagingEngine.com Webmail Interface - ajax-29e6b281 References: <1527236773.2751997.1384639856.43EC19AA@webmail.messagingengine.com> <1fb3e930-cce3-4e55-9040-da6fea5fd3f6@sloti22d1t06> In-Reply-To: <1fb3e930-cce3-4e55-9040-da6fea5fd3f6@sloti22d1t06> Date: Fri, 25 May 2018 12:45:18 +0200 Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-04 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 10:45:20 -0000 This is a multi-part message in MIME format. --_----------=_152724511828014840 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, May 25, 2018, at 12:43, Neil Jenkins wrote: > The recurrenceOverrides type is now wrong. It should just be > LocalDate[PatchObject]|null Meh, I knew I had overseen something. I'll fix it in the next version. Thanks, Robert --_----------=_152724511828014840 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, May 25, 2018, at 12:43, Neil Jenkins wrote:
The recurrenceOverrides type is now wrong. It should just be LocalDate[PatchObject]|null

Meh, I knew I had overseen something. I'll fix it in the next version.

Thanks,
Robert

--_----------=_152724511828014840-- From nobody Fri May 25 04:00:09 2018 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 9EF6A124D68 for ; Fri, 25 May 2018 04:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=zonevs.eu header.b=dnsQw4nR; dkim=pass (2048-bit key) header.d=srs2.zonevs.eu header.b=jfspWbS8; dkim=pass (2048-bit key) header.d=dot.ee header.b=N3bEKU3q 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 aLvs0ZIAIsYL for ; Fri, 25 May 2018 04:00:04 -0700 (PDT) Received: from mta-68-250.tll01.zoneas.eu (srs2.zonevs.eu [217.146.68.192]) (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 618D8124BAC for ; Fri, 25 May 2018 04:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=p6voDuzXO4C/a4J0KXI+VD78A0Lffo6GBUzrlA1Z4eI=; h=from:subject:date:message-id:to:mime-version:content-type; b=dnsQw4nRV63r6DaIVbrt/Cn4DAeXrPQZ9BRjFfc0l3HrcPxP1kVxWELHcbIGdAFDjxhnPeELZ zV8m5ZJ4H9FUGFOULD4SiFAKr/rNDlFE5cIMQnc50s3H8eHRjRvZ34LLcdMwVVihu+f9i8kUIb/ LrxCFs3ePOI2PB4ZT3ycxLy5963r/0sX1jopYdLFn5RNNVnQ6DEpGWF9QzQjTUJ5jk18NNcBwOM xNrudK5CG++2Ykko4Tss17OWjGJ8FsFLQu86zqwlEh/YJZv6ck9iUhWtOSkWsSmbXIMJabt7zAV P2yhdj3QBGkOhnbpj8XAT7clGbCgtCWB1U3QOD1DjqoA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs2.zonevs.eu; q=dns/txt; s=oct2016; bh=p6voDuzXO4C/a4J0KXI+VD78A0Lffo6GBUzrlA1Z4eI=; h=from:subject:date:message-id:to:mime-version:content-type; b=jfspWbS86LZPQep50Q756Uj/PNdQmn/Y8oRp7jZe9UKJE1KpuizXUayrRYNL9yNlIv1fsVzVJ V1Ua6/SA7ExJYd6en8Srah2Joe6a93xECAAaO/3HuXA2881WLCRIHrhHuoNamHfoRTKm05ZRY7C KzN9/FFf9IMNlc+GqAmqYlD9jv5nGQjVVU+pcjTjDE3im8J5/avfuuWMphL3rYwgeznvcQ4Zex5 2UeE7S+Kpw1puaYxaVaqqb5QYYUhcCK2kbMpz+AKEDtUGQwUTLJ+8GGkzT+Pz4ilWEoSAv/LSYT Bs4dwi5QU8s+mO3YqSU0zjY3J8oVnPJyyrypjnbxsz/A== Received: from smtp.zone.eu ([217.146.66.121] smtp.zone.eu) by mta-68-250.tll01.zoneas.eu (ZoneMTA Forwarder) with ESMTP id 16396f48c99000027a.001 for ; Fri, 25 May 2018 10:59:59 +0000 X-Zone-Loop: de09dcc3d3d04f23fbcedbb5f78ac3ecf79d3b5d515c Received: from localhost (43-221-50-195.dyn.estpak.ee [195.50.221.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: d3623m47440@@) by smtp.zone.eu (Postfix) with ESMTPSA id 0C69A128B5DB for ; Fri, 25 May 2018 13:59:59 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1527245999; bh=6gVpJx7mxOJC1/PjNrOtSfkOBtt0RM7QdUjhsuPvOhU=; h=To:From:Subject:Date; b=N3bEKU3qjYbpWhU7/83M3ufKpYe6KptXurUouPDFTuGIewPUTbMLNUMEcAcLCz2Gw 3wEZXhpcWzyKUIuW2T8DNqOp5xq8LitEkpLM2c0KZQ7oFP0zc94DZnlmnsNSKFnS/Q sArp8T7Nk3hL6z9473CO+M+4SeQrO8L9UsIFKR3Q0Zy1MbZ0Uagme6o8I7flOfIXp3 8srtmEouvT5W5mY1u+b/1W0AbEigO5hlU5M5V9M1eCSgSASAnPjyOojjakpkllBrOB gPvi+qGBDLC5x7hBz9s/gYUypi67HqS+s+01Fdx+F/NP5VnnH+Hq174sVZ+SDoGuXi IYn7xcXSwoQrA== To: calsify@ietf.org From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: Date: Fri, 25 May 2018 10:59:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------FE5DEF91748B098654B541FE" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-2.817519, required=15, tests=[HFILTER_HOSTNAME_5=3, BAYES_HAM=-2.999693, ARC_NA=0, TO_DN_NONE=0, MID_RHS_MATCH_FROM=0, R_DKIM_ALLOW=-0.2, RCVD_VIA_SMTP_AUTH=0, RCVD_TLS_ALL=0, NEURAL_HAM=0, MIME_GOOD=-0.1, PREVIOUSLY_DELIVERED=0, DKIM_TRACE=0, FROM_EQ_ENVFROM=0, RCPT_COUNT_ONE=0, ASN=0, IP_SCORE=-2.617826, FROM_HAS_DN=0, SUBJECT_ENDS_EXCLAIM=0, ONCE_RECEIVED=0.1, RCVD_COUNT_ONE=0] Archived-At: Subject: [calsify] JSTask and estimatedDuration --- well done! X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 11:00:08 -0000 This is a multi-part message in MIME format. --------------FE5DEF91748B098654B541FE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Just wanted to thank whoever brought estimatedDuration over VTODO's duration to the table! Ever since I learned VTODO's definition of DURATION (DTSTART+DURATION being merely an alternative to DTSTART+DUE), I wanted to suggest JSTask not take that path. I'm happy to see the task's start, due and duration properties are all independent. Bothering to mention estimatedDuration SHOULD be less than due minus start is a tad peculiar though --- scheduling enough time for oneself is a human concern, after all. It'd be like the spec suggesting "completed" be set to a time before the due time for the person to not be reprimanded for going over their deadline. :) Andri --------------FE5DEF91748B098654B541FE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Just wanted to thank whoever brought estimatedDuration over VTODO's duration to the table! Ever since I learned VTODO's definition of DURATION (DTSTART+DURATION being merely an alternative to DTSTART+DUE), I wanted to suggest JSTask not take that path. I'm happy to see the task's start, due and duration properties are all independent.

Bothering to mention estimatedDuration SHOULD be less than due minus start is a tad peculiar though --- scheduling enough time for oneself is a human concern, after all. It'd be like the spec suggesting "completed" be set to a time before the due time for the person to not be reprimanded for going over their deadline. :)

Andri
 --------------FE5DEF91748B098654B541FE-- From nobody Fri May 25 04:23:07 2018 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 55485126C26 for ; Fri, 25 May 2018 04:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org 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 6onvKIdo_qdm for ; Fri, 25 May 2018 04:23:02 -0700 (PDT) Received: from mailrelay3-1.pub.mailoutpod1-cph3.one.com (mailrelay3-1.pub.mailoutpod1-cph3.one.com [46.30.210.184]) (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 9478F1204DA for ; Fri, 25 May 2018 04:23:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=KKmqc5WzdVQ0sq0K0x/Igel5TAPkqq2OAoVz/ArGRh8=; b=y/svnumMFZGejYSDcNz2CS1ywSzZWa/hObLgvpFoK16jBxVBdLCCkue466ULQPYHOsPcyk8kBdFqv clh2ZjtKXzyI6cDAWNqHd/475h7svh2AUq5z4PFAFyIL9iUuZUjOfsnE9kGtymvFNs1x59SpUHEDfY QCufFt1579wASIUM= X-HalOne-Cookie: 2c3b2aa1ad6855dbc16e106a77550c7db7d82b7c X-HalOne-ID: fa0de164-600d-11e8-80a6-d0431ea8bb03 Received: from smtp.dmfs.org (unknown [91.47.32.197]) by mailrelay3.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id fa0de164-600d-11e8-80a6-d0431ea8bb03; Fri, 25 May 2018 11:22:58 +0000 (UTC) Received: from boss.localdomain (boss [192.168.2.105]) by smtp.dmfs.org (Postfix) with ESMTPSA id BFB621F5 for ; Fri, 25 May 2018 13:22:57 +0200 (CEST) To: calsify@ietf.org References: From: Marten Gajda Message-ID: <528c3677-426e-6718-3e24-ceab61833fdb@dmfs.org> Date: Fri, 25 May 2018 13:22:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8572CC668C423E1D831B6D05" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSTask and estimatedDuration --- well done! X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 11:23:05 -0000 This is a multi-part message in MIME format. --------------8572CC668C423E1D831B6D05 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Andri, estimatedDuration originally has been added in another extension to VTODO: https://tools.ietf.org/html/draft-apthorp-ical-tasks-01#section-6.1 So you'll be able to use it in VTODO as well. However, at present it looks as if the JSTask spec will be ratified before the VTODO Extensions. Cheers, Marten Am 25.05.2018 um 12:59 schrieb Andri Möll: > Just wanted to thank whoever brought estimatedDuration over VTODO's > duration to the table! Ever since I learned VTODO's definition of > DURATION (DTSTART+DURATION being merely an alternative to > DTSTART+DUE), I wanted to suggest JSTask not take that path. I'm happy > to see the task's start, due and duration properties are all independent. > > Bothering to mention estimatedDuration SHOULD be less than due minus > start is a tad peculiar though --- scheduling enough time for oneself > is a human concern, after all. It'd be like the spec suggesting > "completed" be set to a time before the due time for the person to not > be reprimanded for going over their deadline. :) > > Andri > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------8572CC668C423E1D831B6D05 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Andri,

estimatedDuration originally has been added in another extension to VTODO: https://tools.ietf.org/html/draft-apthorp-ical-tasks-01#section-6.1

So you'll be able to use it in VTODO as well. However, at present it looks as if the JSTask spec will be ratified before the VTODO Extensions.

Cheers,

Marten



Am 25.05.2018 um 12:59 schrieb Andri Möll:
Just wanted to thank whoever brought estimatedDuration over VTODO's duration to the table! Ever since I learned VTODO's definition of DURATION (DTSTART+DURATION being merely an alternative to DTSTART+DUE), I wanted to suggest JSTask not take that path. I'm happy to see the task's start, due and duration properties are all independent.

Bothering to mention estimatedDuration SHOULD be less than due minus start is a tad peculiar though --- scheduling enough time for oneself is a human concern, after all. It'd be like the spec suggesting "completed" be set to a time before the due time for the person to not be reprimanded for going over their deadline. :)

Andri
 

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


-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: marten@dmfs.org

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
--------------8572CC668C423E1D831B6D05-- From nobody Sun May 27 14:47:01 2018 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 2426B12ECC3 for ; Sun, 27 May 2018 14:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 JkbLOkeenDtH for ; Sun, 27 May 2018 14:46:57 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 62EB712E8C2 for ; Sun, 27 May 2018 14:46:57 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id c198-v6so7902416qkg.12 for ; Sun, 27 May 2018 14:46:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=kacpMRL92YG6pnCiobvOAem3DE+YHnsxIh1et4/kgo8=; b=s100Z6HGDjXxr6K5dhwiS568rWASXOTyekUjktJNGk/YKqtRLXXEIopg5VJsZaNARN CDP5Lt2ttuloY64DDHBT56YQBBWSHuz67xIeepxg2GFRxgNjUPkdMkgUPrViggtYz26+ 1CO5O8eeX6b3///gUtfQKqjjiRI7iGkOP5wRZN7ahhkiahBNqJgE96hYr3KzOo3xncJB Q5ehV/xwp8IePfoGtb4HkgXASSQ6t0+7PBiBDKWUA3EdLOtlF8TOV9wI5I+qBLC2wlZ4 NS36RA00r17VcyySSOizVrZ2H7J1QluA6W5JFbLv2vcEKunv5m7FzEoowVI6iIQCupP0 lCSw== 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=kacpMRL92YG6pnCiobvOAem3DE+YHnsxIh1et4/kgo8=; b=nI77EXadlgv7iK1qwQyzLd5jsQVhByrHbqQOPxmWDYPNm1nG1rTLb7ikjo3i9EWpbt 0bTTeR34/r9dxwqWXeJXjlLrEcq4I6nlCwBNl22NeqncsveIq43DmHevQi/Nb9HAP1u3 TFn+3CsfGQnfzLT7smvUQ2OuUU7cRHp1n7CMBW1OIBs/embo2eFAiJ0KyifgFT/ruVrS VoeaL4rqHeFxF0/7Y4IyF7swK3+NbXoHaq1bhssoFwPCXMR3sZ/4cPHuBlKQU0SUmqr4 qYDDbvyrAcd6/5S4n+BdtfFjjcid2zn3nv7JWZJ8Ub4E4l6MbhFAp2q/Y1XVqWXo9xEt yhDQ== X-Gm-Message-State: ALKqPwfiH5aNKxrVGJwWuVjRtiy+nW2sIdFP+zwwYMvAImiT8Ejwzfzw Jk+Hfh7TjNZB3BWLVAx4vzSHqg== X-Google-Smtp-Source: ADUXVKIwyyxsfBXMXUS4Jf7v8pRdLYTnU2LZ4yagZKFsizKD+o/YBy0dyc4r9Bl3aVNloCAZXhahQw== X-Received: by 2002:a37:9a16:: with SMTP id c22-v6mr9245510qke.344.1527457616358; Sun, 27 May 2018 14:46:56 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id r186-v6sm20276650qkb.44.2018.05.27.14.46.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 May 2018 14:46:55 -0700 (PDT) To: calsify@ietf.org References: <1527236773.2751997.1384639856.43EC19AA@webmail.messagingengine.com> From: Michael Douglass Message-ID: <7ed02e59-680e-af72-d9fd-cf854cfe14e1@gmail.com> Date: Sun, 27 May 2018 17:46:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <1527236773.2751997.1384639856.43EC19AA@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------29B81CAA70D2551ECB18C5BB" Content-Language: en-US Archived-At: Subject: Re: [calsify] Updated JSCalendar draft calext-04 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 21:47:00 -0000 This is a multi-part message in MIME format. --------------29B81CAA70D2551ECB18C5BB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I'm glad to see localizations feature replaced and i was supposed to provide the arguments in favor of doing so in advance - so I'll provide it anyway. The lack of any multi-language support in the icalendar model is a significant issue. In many regions it is a legal requirement that some organizations - usually public/governmental - provide content in a number of languages - e.g. english and french or spanish and basque. This is usually not a problem for communications within an enterprise where a single language is often mandated. It IS a problem in event publication. This is not something that can be resolved by services doing language negotiation. An event may pass through a number of service - e.g. event aggregators - before being delivered to its final destination. At the end point of course - a service could choose to deliver the content in a single language. However we need a standard way of passing through the localized data. Of course there are problems in workflow and how to ensure the different languages content is in synch. This is not our problem. We define the data model - it's up to applications to implement workflow and publication mechanism in whatever way is appropriate to them. There have been many years of discussion on how to define a good data model and we finally seemed to have come to some agreement that a new LOCALIZATIONS component would be the best approach. I strongly support such a feature being part of the base JSCalendar specification. iCalendar from its inception was strongly biased towards creating meetings in corporate enterprises. In fact in the early years of calconnect people continuously referred to them not as "events" but as "meetings". Event publication and social calendaring have grown in importance over the years and it is incumbent on us as standards developers to support the needs of these communities or they will continue to use non or de-facto standards. On 5/25/18 04:26, Robert Stepanek wrote: > Hi all, > > thanks for all your input on version 3 of the JSCalendar RFC draft. I > have just uploaded version 4 > which > incorporates your feedback. > > Main changes: > > * *recurrenceRule and recurrenceOverrides*: the definition of > recurrence rules and overrides has been refined. It now also > includes the evaluation instructions as outlined by Neil. > * *localizations*: following our conference calls and email > discussion, the specification again includes the localizations > property. However, it does not define how to maintain validity of > localized content, nor does it define how to map them between > iCalendar and JSCalendar. > * *replyTo*: the HTTP path template for the replyTo `web` property > must use HTTPS. > > > For the upcoming CalConnect conference in Tokyo in one week, I plan > the current version to be the basis for discussion. Depending on your > feedback on the list, we might send out a new version before the IETF > 102 draft submission deadline on July 2. > > Cheers, > Robert > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------29B81CAA70D2551ECB18C5BB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I'm glad to see localizations feature replaced and i was supposed to provide the arguments in favor of doing so in advance - so I'll provide it anyway.

The lack of any multi-language support in the icalendar model is a significant issue. In many regions it is a legal requirement that some organizations - usually public/governmental - provide content in a number of languages - e.g. english and french or spanish and basque.

This is usually not a problem for communications within an enterprise where a single language is often mandated. It IS a problem in event publication.

This is not something that can be resolved by services doing language negotiation. An event may pass through a number of service - e.g. event aggregators - before being delivered to its final destination. At the end point of course - a service could choose to deliver the content in a single language. However we need a standard way of passing through the localized data.

Of course there are problems in workflow and how to ensure the different languages content is in synch. This is not our problem. We define the data model - it's up to applications to implement workflow and publication mechanism in whatever way is appropriate to them.

There have been many years of discussion on how to define a good data model and we finally seemed to have come to some agreement that a new LOCALIZATIONS component would be the best approach. 

I strongly support such a feature being part of the base JSCalendar specification. iCalendar from its inception was strongly biased towards creating meetings in corporate enterprises. In fact in the early years of calconnect people continuously referred to them not as "events" but as "meetings".

Event publication and social calendaring have grown in importance over the years and it is incumbent on us as standards developers to support the needs of these communities or they will continue to use non or de-facto standards.


On 5/25/18 04:26, Robert Stepanek wrote:
Hi all,

thanks for all your input on version 3 of the JSCalendar RFC draft. I have just uploaded version 4 which incorporates your feedback.

Main changes:
  • recurrenceRule and recurrenceOverrides: the definition of recurrence rules and overrides has been refined. It now also includes the evaluation instructions as outlined by Neil.
  • localizations: following our conference calls and email discussion, the specification again includes the localizations property. However, it does not define how to maintain validity of localized content, nor does it define how to map them between iCalendar and JSCalendar.
  • replyTo: the HTTP path template for the replyTo `web` property must use HTTPS.

For the upcoming CalConnect conference in Tokyo in one week, I plan the current version to be the basis for discussion. Depending on your feedback on the list, we might send out a new version before the IETF 102 draft submission deadline on July 2.

Cheers,
Robert


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

--------------29B81CAA70D2551ECB18C5BB-- From nobody Sun May 27 21:47:21 2018 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 5860612D7F1 for ; Sun, 27 May 2018 21:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=ro1CcEj7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CKYqoPdM 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 Z5AxIUCGvcVx for ; Sun, 27 May 2018 21:47:17 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9D791273E2 for ; Sun, 27 May 2018 21:47:16 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3511C21A47 for ; Mon, 28 May 2018 00:47:16 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Mon, 28 May 2018 00:47:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=rhjaZ8PzU+RIEPcJOh6vNDPJWA82cchoRfzSSk9va aw=; b=ro1CcEj7mqDeZNysBC1rMY5tzqkPVTlO+nWE/nLr+IPGCVLysrFeWeaLy 9m0rWXe3z+Y/3rRIiSlMbn1qVi6kaA83tX76v19L3sBKYkW34VVRfgg9RWY3pCNU CUr0izyVyEowjFZVoK0I6e50LX9vJ884VhiSGFtGfkYe3OvryPL/GYq24H3dhrxc 3g6I+blF/EWKsI3EH1coNdtdySH42n7YRjZfYqbbtoGtiFjWqR631YD+ART8U5Gy JmOrv13ggoZc44BWgS8yYryJRjvazqo3Wat8FpJzEvhqcddkoXRYjlQ6yuNJmF23 W9hWFJN2kKDLJlrMLsoMtxQ1Ext0Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=rhjaZ8PzU+RIEPcJOh6vNDPJWA82cchoRfzSSk9va aw=; b=CKYqoPdMU2BNP4rReSqnKvgAGBmvOFeNGgMTT759HQPrlGD9JbJ2UAsf8 O7VDe0mEAp1lFhiC9jwcrOXcDXTSNGFuzLxvLHgFSGIKuYYmTe/4oRXK/SgewAuS XO4zEKiYmD2pA/kmcf+xRH2doOWIwBFcdfP+dwNKS4J3fpFSxF2D3dShzb4K3o2+ 21Sseb3g7HwcmAoTJnnC5fCyZfSsL+Gdi9ieIPyq4Q2AZt8YK6bhg/ZWuKVpecCf Iwizjo9NhD4equhf26rWuetNqEDJTHyhGjIOE+8yuYDhkyQinC+NFbfYo6PFzVkX 56icOrjCNAtVRTUQHXkX4YL28H+WQ== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AFCC0CA2B7; Mon, 28 May 2018 00:47:15 -0400 (EDT) Message-Id: <00372112-6ab0-4076-a421-6f30f7fe94df@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.3-624-g558ee02-next x-jmap-identity-id: 64588216 In-Reply-To: <4e5fbfb3-3b6d-954c-9fb7-1fea100c400d@dot.ee> References: <4e5fbfb3-3b6d-954c-9fb7-1fea100c400d@dot.ee> Date: Mon, 28 May 2018 00:47:15 -0400 From: Neil Jenkins To: calsify@ietf.org Content-Type: multipart/alternative; boundary=55d9c2b53a7b4ad194dbadf183b1ede3 Archived-At: Subject: Re: [calsify] ReplyTo with HTTP (for development) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 04:47:19 -0000 --55d9c2b53a7b4ad194dbadf183b1ede3 Content-Type: multipart/related; boundary=c753cd563dd446e196f9c0af2ed6ca70 --c753cd563dd446e196f9c0af2ed6ca70 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Fri, 25 May = 2018, at 8:44 PM, Andri M=C3=B6ll wrote:
I'm all for strongly suggesting HTTPS for public Internet use, but during development I must say HTTPS is a pain in the ass. I, like a lot of other people, develop and test locally using either .local (if devices support zero conf) or a private domain= in the likes of .dev or .test set up in the router.

Following the standard is re= quired if you wish to interoperate. For when you are operating entirely = within a closed system (develop + test) you can of course ignore any req= uirements you like.

Having said that, I'm p= ersonally ambivalent to whether it's a MUST or a SHOULD, or a "make sure= you really think about this". My view is any decent service is only goi= ng to use HTTPS anyway, any shoddy service probably won't read the RFC, = and anyone doing some internal thing with its own encryption layer will = probably ignore it if they want to anyway. Shrug.
<= br>
Neil.
--c753cd563dd446e196f9c0af2ed6ca70-- --55d9c2b53a7b4ad194dbadf183b1ede3 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, 25 May 2018, at 8:44 PM, Andri M=C3=B6ll wrote: > I'm all for strongly suggesting HTTPS for public Internet use, but during development I must say HTTPS is a pain in the ass. I, like a lot of other people, develop and test locally using either .local (if devices support zero conf) or a private domain= in the likes of .dev or .test set up in the router. Following the standard is required if you wish to interoperate. For when= you are operating entirely within a closed system (develop + test) you = can of course ignore any requirements you like. Having said that, I'm personally ambivalent to whether it's a MUST or a = SHOULD, or a "make sure you really think about this". My view is any dec= ent service is only going to use HTTPS anyway, any shoddy service probab= ly won't read the RFC, and anyone doing some internal thing with its own= encryption layer will probably ignore it if they want to anyway. *Shrug= *. Neil. --55d9c2b53a7b4ad194dbadf183b1ede3--