From nobody Sat Sep 1 00:55:11 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 3C505130EAC for ; Sat, 1 Sep 2018 00:55:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 p7oQNGgONqto for ; Sat, 1 Sep 2018 00:55:06 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 4349412426A for ; Sat, 1 Sep 2018 00:55:06 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id a4-v6so6439590plm.13 for ; Sat, 01 Sep 2018 00:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apthorpia-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=Cd1ZBEoOupL1H9odZW4fg+BYCw59iUWtBVkNhcHQQ+I=; b=MMmMSN1v68rKPk64DVxjeRhTkfIgqKu6oqFebWXaS7Ir8CgMQTKwaoyOsX/p+vHokm 9gfUKVjBUazBvUy7HqmSHy8F2S7fG0mMQ2bdttD3Z8wKSOrDaqM7tq3L1OcHTe4c0h1y 1JztdEghS1cQ3NZFaUrqnkzoBuYpgAzusih1TGEjWlILDCCpb4ZM57QEi00/2tQrwtHW E/OiSfmj2OsnSm/2/7SSRZULGr9FXaL62JfB1OOA6lX/yMMQv3kWEJHoQ2X1i2BaJjj2 hKgB/EMC3hfJ5kfVJGXHlGbkYsUEYTuFq9HPufTa3xNhxPvTrr/6pSCyg0xUjdVZkX0b LZwQ== 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=Cd1ZBEoOupL1H9odZW4fg+BYCw59iUWtBVkNhcHQQ+I=; b=G/NkPhLwj+tz9C/ktBFOYQC65PnmxvlLFvT6x82es+OAMOHi7qrlYlgKOthlkjem63 K/lZCIH6byRPMc3K5t2h9+JM4I1dcNHivoGGS9zWu3eW6Di8c6qKz7r35TgANBf/z5ci Vbylxz9SNcm510CcQu14fQ8gYuXjc6OL7T822Jhw7z7oIzrwpp2PDJqnb24o8/hmzsAg r4NEXyHQO++5V/Mhey83nMr9Zl9zTcR28UW1M3cDbpuEv/pWsVMCcyEKQCcf/MRnQ9+a QlHO7h0rqYxztu4IwiQKdFqgxHkdP9petarZVPD70fiwc4Gqx2wtQlEsqFm89EkgWldG a3Bw== X-Gm-Message-State: APzg51BDw34NpFh4WXp0a59UCi1lxjhHO64NL+LwGs+yNTXcclGWjWYA qdZYoBqmHPQdETN7Ge5GXI4cT5IdYGk= X-Google-Smtp-Source: ANB0VdZ+0nRRSgY65p/oLRrPeZbxJb96gON5Vsw6jO+IZLtGAQ00VPSmuOv1S82kIDbpEJmIvXYPTA== X-Received: by 2002:a17:902:2ac3:: with SMTP id j61-v6mr19023085plb.172.1535788505298; Sat, 01 Sep 2018 00:55:05 -0700 (PDT) Received: from [192.168.2.109] ([175.156.157.4]) by smtp.gmail.com with ESMTPSA id n24-v6sm21647541pfi.161.2018.09.01.00.55.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Sep 2018 00:55:04 -0700 (PDT) To: Robert Stepanek , calsify@ietf.org References: <1535620158.162328.1491072080.2C47352D@webmail.messagingengine.com> <5eb08950-5d3a-ba80-7fdd-653f48ce5792@gmail.com> <1535637876.374476.1491356408.2B9BD317@webmail.messagingengine.com> From: Adrian Apthorp Message-ID: <76c114d4-708f-7cc0-7a47-fb8206556317@apthorpia.com> Date: Sat, 1 Sep 2018 15:55:01 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1535637876.374476.1491356408.2B9BD317@webmail.messagingengine.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [calsify] JSCalendar: what to do with JSTask? X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2018 07:55:09 -0000 I tend to agree with Mike. The core of tasks is covered in JsTask. In some ways specifying in json has helped to overcome some of the iCalendar format limitations on hierarchical data structures. i.e. it does away with the need for the GROUP parameter. From what I can see everything not included in JsCalendar, as of https://tools.ietf.org/html/draft-ietf-calext-jscalendar-06 but discussed in either https://tools.ietf.org/html/draft-apthorp-ical-tasks-01 or https://tools.ietf.org/html/draft-ietf-calext-ical-relations-04 would be an extension. i.e. - status reasons - sub-states - refid - gap - new reltypes I'm just wondering whether the link construct can somehow be used to achieve what refid is for? The most recent change with statusUpdatedAt mitigates a potential future annoyance. From a quick cross-check I think many existing proprietary task APIs (google, ASANA, etc) could be quite happily mapped to JsTask. Cheers Adrian On 30/08/18 22:04, Robert Stepanek wrote: > On Thu, Aug 30, 2018, at 15:48, Michael Douglass wrote: > >> I'm currently in the process of developing an app which relies heavily >> on tasks and the ease of translating from tasks to derived events and >> which uses json for messaging. I think this is a vital part of the spec >> and should remain. > I'm happy to hear that the proposed JSTask object is already useful in implementations. My concern is: is it ripe for standardization? It looks to me as if the discussion on a "better VTODO" is split on two draft documents, and it'd be sub-optimal if the two specifications come to different conclusions. I'm not involved in the discussions around VTODO, probably my concerns are unnecessary. > > Cheers, > Robert > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Sat Sep 1 04:11: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 69DC012F1A2 for ; Sat, 1 Sep 2018 04:11:46 -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, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xJaQaRcdrnJ4 for ; Sat, 1 Sep 2018 04:11:44 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 9482612008A for ; Sat, 1 Sep 2018 04:11:44 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id ba4-v6so6584469plb.11 for ; Sat, 01 Sep 2018 04:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apthorpia-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=GKVwJ6NMh5N5BgNztjHqvLPUUqWKKuad+W1UN9iausk=; b=zaHR8MSHGoEpl2nOrfLrQ7mLSc81uphRk0RGVXVVbhvhrvA7nPjW1O2djdWpUqM0iD b4yeHFuMncIOKOhkMQsY7GE2nr0YqokO6Vb0wZOxp6GkF1GE5YWB2L1eNXFoOMHF/TSr dvrf5BXS7tMyPeky8t1LMABTK0h8y+gOlFLgkwvSqXLfodRVSfBOQ7+SxNDcB7m03M7H z/leUqlH/pxEmSImUzwdttS99nP+09erflVCmq6CNtfhHRORwNKSr6YFOTRdeKenKEsZ h5Eh5Az2xdb0nOmrRvADUQuTW3WWPFoEBDz/EtBhtwwpGspL/CESjK9IfEiX/f+pjD0L Nhlw== 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=GKVwJ6NMh5N5BgNztjHqvLPUUqWKKuad+W1UN9iausk=; b=AR8QDP+H9tak+NA/jHJvo5+EPUwKh8dcLZ0adBbVEGcO0KVM+o6m/sWkYGm3evcCg+ IIunRbb1XCqiNNKk/Swzwg1V8irPOyKSSxmU9sJq/Mx5zUdY1sHoOyJZ/0KQQw/oJjjm KzMwkuSaHtbAYqj6kA4TWX4cUfF1WV8zLaNPOcj+tWJcT8+8I8qKpFH92WQE48lb7vMf dO0+zox4K84T1eoNswO7fdHvtyy3jBExJDkpUvQqA36bQPArm1Xr5rMjf24tjeIucB5o nmCYdGiyZ2jRuty2Nc4k6n7svWaWRb3PWE9xQePuTZK3dNH47qp+NcFs1n74jIlTsKGh xchg== X-Gm-Message-State: APzg51AfImmo18jkagRjelkXPfxKJTRfx10ZaMe8oxmlFpfTMOqPA3j6 FXzVfHy3b6lSFOrfwVM2RP7kOvN0avQ= X-Google-Smtp-Source: ANB0VdYsdEqZ5NYDLIl4Vanbqpa2peOzXabIYjPGp37/HCaFNVQktxaWP7blX8NWeZHaqUVGStJwTg== X-Received: by 2002:a17:902:ba86:: with SMTP id k6-v6mr19411591pls.84.1535800303696; Sat, 01 Sep 2018 04:11:43 -0700 (PDT) Received: from [192.168.2.109] ([175.156.157.4]) by smtp.gmail.com with ESMTPSA id o20-v6sm40093491pfj.35.2018.09.01.04.11.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Sep 2018 04:11:43 -0700 (PDT) To: calsify@ietf.org References: <153561991025.3128.17199133283283558597@ietfa.amsl.com> From: Adrian Apthorp Message-ID: <6716354d-1ff8-5567-8dda-f31f85c8fdc7@apthorpia.com> Date: Sat, 1 Sep 2018 19:11:40 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <153561991025.3128.17199133283283558597@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-06.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2018 11:11:46 -0000 Just going through one more time and I found a couple of things which would further improve the document. 1) Section 5.2.7 progress. The description of each of the status values sounds a bit strange       *  "completed": The participant completed their progress.       *  "in-process": The participant processes this task.       *  "failed": The participant failed to complete their progress. Shouldn't these be more like?       *  "completed": The participant completed their task.       *  "in-process": The participant has started this task.       *  "failed": The participant failed to complete their task. 2) Looking at example 7.6, it would be great if this could be extended to give more complete examples of location, especially how to represent the airport names Frankfurt / Narita with their IATA codes FRA / NRT. Clearly quite a common use case. On 30/08/18 17:05, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Calendaring Extensions WG of the IETF. > > Title : JSCalendar: A JSON representation of calendar data > Authors : Neil Jenkins > Robert Stepanek > Filename : draft-ietf-calext-jscalendar-06.txt > Pages : 53 > Date : 2018-08-30 > > 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-06 > https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-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 From nobody Tue Sep 4 06:49: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 E0186130EDB; Tue, 4 Sep 2018 06:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVl7ZAdLq1wr; Tue, 4 Sep 2018 06:49:15 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC81130EDE; Tue, 4 Sep 2018 06:49:15 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C5AC9B80FAC; Tue, 4 Sep 2018 06:49:15 -0700 (PDT) To: julian@lavanauts.org, Alexey.Melnikov@isode.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: aamelnikov@fastmail.fm, iesg@ietf.org, calsify@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180904134915.C5AC9B80FAC@rfc-editor.org> Date: Tue, 4 Sep 2018 06:49:15 -0700 (PDT) Archived-At: Subject: [calsify] [Errata Verified] RFC6047 (5447) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Sep 2018 13:49:18 -0000 The following errata report has been verified for RFC6047, "iCalendar Message-Based Interoperability Protocol (iMIP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5447 -------------------------------------- Status: Verified Type: Technical Reported by: Julian Cowley Date Reported: 2018-07-31 Verified by: Alexey Melnikov (IESG) Section: GLOBAL Original Text ------------- ATTENDEE;RSVP=YES:mailto:foo2@example.com Corrected Text -------------- ATTENDEE;RSVP=TRUE:mailto:foo2@example.com Notes ----- In the examples that include the ATTENDEE property, there is a minor issue. According to RFC 5545, Section 3.2.17, the RSVP parameter value should be "TRUE" or "FALSE", not "YES" or "NO". -------------------------------------- RFC6047 (draft-ietf-calsify-rfc2447bis-11) -------------------------------------- Title : iCalendar Message-Based Interoperability Protocol (iMIP) Publication Date : December 2010 Author(s) : A. Melnikov, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed Sep 5 06:53:41 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 06A6412F1A2 for ; Wed, 5 Sep 2018 06:53:40 -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 g9jU355aelr5 for ; Wed, 5 Sep 2018 06:53:38 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DA41126CC7 for ; Wed, 5 Sep 2018 06:53:38 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.west.internal (Postfix) with ESMTP id 7936E496 for ; Wed, 5 Sep 2018 09:53:37 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 05 Sep 2018 09:53:37 -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=fm3; bh=NsZ3Vw fDxEJj9BHucHwjaIZ4wMhsPqI3b7Y3l2jW2w4=; b=dU8FbdanrFuNA12YXZURxU VdOTXmNOBJUB7FmNIvyIjU13rpqFk8/cUi/zv7QFdda654/pXgaqegz79j/MPmEU 5WuOhrh86I35GBfysgiHl0Y9jBojWSP1rxy/1wh1Oexj6QvQsq82eZGRxW3pRL/B F8ypuPFrJI2UnKO8G7d9KNwevcJByGZjzRnPCs6aIqxR8VbSWxpTdtu+vfLQBO9x t6bsQBJ6xdtaSg0K4ReDzR2097CMJg5smuFVj/clAY9hrak6PwwCX+asarzx5kn8 kqFKhqTMQaHV2W2P3EEvOnscUZnLgeJNqbjYuS/vBXXXtQcl5mZvi8KYOqXwY53Q == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 48175E253F; Wed, 5 Sep 2018 09:53:36 -0400 (EDT) Message-Id: <1536155616.1980207.1497601368.26E0A3E9@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-133d65b2 In-Reply-To: <6716354d-1ff8-5567-8dda-f31f85c8fdc7@apthorpia.com> References: <153561991025.3128.17199133283283558597@ietfa.amsl.com> <6716354d-1ff8-5567-8dda-f31f85c8fdc7@apthorpia.com> Date: Wed, 05 Sep 2018 15:53:36 +0200 Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-06.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 13:53:40 -0000 Hi Adrian, On Sat, Sep 1, 2018, at 13:11, Adrian Apthorp wrote: > > Just going through one more time and I found a couple of things which > would further improve the document Thanks! I have rephrased the Participant status descriptions and updated the 7.6 example with airport codes. Any decent map application should now show the start and end airports using the location names (see https://github.com/CalConnect/PUBLIC_DRAFTS/commit/73de023af949dadb11d94b6be7687e500ed2f213). I'll wait with a RFC version update until end of this week in case further feedback comes up. Cheers, Robert From nobody Wed Sep 5 12:32:04 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 1147C130DC6 for ; Wed, 5 Sep 2018 12:32:02 -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=dP+P6WaX; dkim=pass (2048-bit key) header.d=srs1.zonevs.eu header.b=JOk63eVv; dkim=pass (2048-bit key) header.d=dot.ee header.b=Ulavp7q9 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 DenmpwZP_3vU for ; Wed, 5 Sep 2018 12:31:58 -0700 (PDT) Received: from srs1.zonevs.eu (srs1.zonevs.eu [217.146.68.191]) (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 5835E1274D0 for ; Wed, 5 Sep 2018 12:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=0x7K0+fCTsMxu9Jt9rTuB9BhCdcKdcLPj8+OJvVdmCc=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=dP+P6WaXbnVMg+VswtpdDaTGfKcSacNOwgZkUjsnlm6afKzCWk/tKUcjKki/NaZqjkWba12k2 Bc0igeK5QFbalTSorrsjqSNSjuRhP/CUifDHzHMRyYtVM7/Iow3mGbPaOD11lxcOgoMGWssy9uo CfYpkVgrnP0CuLXEfhRK6ft3aK1SxGoCb09k+oLi3COSU3pd/Mhl3mU51xzKjnxyv1BQ6D02jw4 i+NDaf+48gYO27uUPc43SBjw+ief1sELeN0glNp9spsfiZ/Iu/MEJ0Arm/HmD70ZbqDycjHqe2D n6kXvfe0SwUXeqIHGADppuOnkzGCEia+OOcKOnX9dyKw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs1.zonevs.eu; q=dns/txt; s=oct2016; bh=0x7K0+fCTsMxu9Jt9rTuB9BhCdcKdcLPj8+OJvVdmCc=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=JOk63eVvCBoJTV5Do00rOgmzu6IrxzCQC23mIag9vP9ieWqGQ5tCDodnDHMz7sHZLX1sIW6+e MF4HAP0SY9Vi09RBapYH5r+B4i2FcWGjv5fLoZK6j7bk2BHfg97AMDXuBRKCLCYDZ5rapav9f1T iiicH8rmWvfQob65xZ+A0NBWW80dPajz6boLeVHZyH8FYoag9aSLal6kpceTBOcobxUN2l0gxyO ftWnecD5QAuSwLL2kEWTnTRs9Ro+CWlKjdsVY6wJS7N7/2fernhdoPyF/0n0MokaVaWX7ksjRqG +YKHS4E8R0yUVLmULETOzot54q/yLc1qV6DVfNamBu6g== Received: from smtp.zone.ee ([217.146.66.124] smtp.zone.ee) by srs1.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 165ab383252000a745.001 for ; Wed, 05 Sep 2018 19:31:51 +0000 X-Zone-Loop: 36992e10514e8519f7e807e6f604da91e3c964933aba 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.ee (Postfix) with ESMTPSA id 1B541128B5C3 for ; Wed, 5 Sep 2018 22:31:50 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1536175911; bh=5E9h1E+k5ChYMqBWX8mWl1Q+XXgUL8CtQnwHlblsTus=; h=Subject:To:References:From:Date:In-Reply-To; b=Ulavp7q9UBbOnHMUydXDVxbj9whD/0AOXZ2i0ECVcmFEaha4FZ/v71ieJLATX/xHy 0eA73mZyQe+9jtBVlj41Bs8HFQwRvz9ZjqoVwCYc8RFQIhdnSeikoH2oNXtqAIC+kN PrfxNMMq5Ay/pdOoPIqOwLSnEig9XVeS3hOrOPuSZd2a0KsSmeMBpnspihMjknUb6r PTYwGDz3WPseZcJyva+PkY0hL4G+jg2sl62z3nHdB7yXBeZDxojhy6IH2rCoQavJtr 7O8SGMHabMt2ZHEjkUmCylKTr4YWMp53YosM52HRwb9+I1NjrOsRXV67Wyua5D/jiw 0x0ie2EsBeE1A== To: calsify@ietf.org References: <729E8F77-EFA6-47B0-851F-5E0D892C6C1E@ribose.com> <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> <84d5a7bd-abec-495e-bebd-154871c80413@sloti22d1t06> From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: Date: Wed, 5 Sep 2018 19:31:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <84d5a7bd-abec-495e-bebd-154871c80413@sloti22d1t06> Content-Type: multipart/alternative; boundary="------------4274C14EBDC2655E95089D06" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-0.200824, required=15, tests=[HFILTER_HOSTNAME_5=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=-3.000824, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 19:32:03 -0000 This is a multi-part message in MIME format. --------------4274C14EBDC2655E95089D06 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit > I'll wait with a RFC version update until end of this week in case further feedback comes up. > > Cheers, > Robert In light of things finalizing, I'd like to re-raise the nominal duration issue. As I may not be able to convince everyone of their value and accept their exclusion from the spec, I strongly recommend they NOT be allowed to be specified for events with times. That is, P1D should only be allowed for events with dates. Both for consistency and for future proofing. The first thing I learned when getting into calendaring, and something every course and book teaches you, is that days are not consistently 24 hours, months not 30 days and years not 365 days. It's _the_factoid  every time-enlightened person tells the uninitiated. Going against that in a calendaring spec is backwards and error prone. It's especially error prone because the difference between nominal and accurate durations is encoded not only into brains, but into libraries. Take JodaTime for Java, NodaTime for C# or Moment.js for JavaScript as examples. All are fine to reach out for when implementing basic time arithmetic, and all handle nominal durations as you'd expect --- moving the wall clock time forward a day, NOT by adding 24 hours. I know the spec _really_ refers to ISO 8601 as inspiration for the duration format, but that's irrelevant. If it quacks like ISO 8601, it's ISO 8601. No-one wants to, nor should they, reimplement duration arithmetic just because of this quirk. I know I sure won't. As we're not going to standardize nominal durations for events with times, they should be forbidden. On 7/5/18 12:47 AM, Neil Jenkins wrote: > On Thu, 5 Jul 2018, at 10:16 AM, Ronald Tse wrote: >> I’d like to remind ourselves that the "exact duration" of any time >> scale unit (except for the second) already depends on the start. The >> leap second modifies the exact duration of the last minute, the last >> hour, the last day of the year, etc. > > I don't believe any current (at least common) calendar implementations > implement leap seconds. While I appreciate your pedantry here, for the > purposes of JSCalendar I expect most implementations to treat minutes, > hours, days, weeks as fixed multiples of seconds. > >> The simple way of dealing with P1D, P1M, P1Y is to find the >> corresponding nominal duration. P1D will lead to the same time in a >> day after, whether it is a normal day or a leap day. P1M will lead to >> the same day in the next month. P1Y will lead to the same month day >> in the next year regardless if it is a leap year. > > As has been pointed out, this is not, in fact, simple, e.g. 31 July, > 29 Feb. I'm sure future ISO 8601 revisions can come up with ever more > complicated rules for how to handle this, but I come back to the point > that the added complexity here outweighs the meagre benefits in > functionality. > > Neil. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------4274C14EBDC2655E95089D06 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 

I'll wait with a RFC version update until end of this week in case further feedback comes up.

Cheers,
Robert

In light of things finalizing, I'd like to re-raise the nominal duration issue. As I may not be able to convince everyone of their value and accept their exclusion from the spec, I strongly recommend they NOT be allowed to be specified for events with times. That is, P1D should only be allowed for events with dates. Both for consistency and for future proofing.

The first thing I learned when getting into calendaring, and something every course and book teaches you, is that days are not consistently 24 hours, months not 30 days and years not 365 days. It's _the_factoid  every time-enlightened person tells the uninitiated. Going against that in a calendaring spec is backwards and error prone.

It's especially error prone because the difference between nominal and accurate durations is encoded not only into brains, but into libraries. Take JodaTime for Java, NodaTime for C# or Moment.js for JavaScript as examples. All are fine to reach out for when implementing basic time arithmetic, and all handle nominal durations as you'd expect --- moving the wall clock time forward a day, NOT by adding 24 hours. I know the spec _really_ refers to ISO 8601 as inspiration for the duration format, but that's irrelevant. If it quacks like ISO 8601, it's ISO 8601. No-one wants to, nor should they, reimplement duration arithmetic just because of this quirk. I know I sure won't.

As we're not going to standardize nominal durations for events with times, they should be forbidden.


On 7/5/18 12:47 AM, Neil Jenkins wrote:
On Thu, 5 Jul 2018, at 10:16 AM, Ronald Tse wrote:
I’d like to remind ourselves that the "exact duration" of any time scale unit (except for the second) already depends on the start. The leap second modifies the exact duration of the last minute, the last hour, the last day of the year, etc.

I don't believe any current (at least common) calendar implementations implement leap seconds. While I appreciate your pedantry here, for the purposes of JSCalendar I expect most implementations to treat minutes, hours, days, weeks as fixed multiples of seconds.

The simple way of dealing with P1D, P1M, P1Y is to find the corresponding nominal duration. P1D will lead to the same time in a day after, whether it is a normal day or a leap day. P1M will lead to the same day in the next month. P1Y will lead to the same month day in the next year regardless if it is a leap year.

As has been pointed out, this is not, in fact, simple, e.g. 31 July, 29 Feb. I'm sure future ISO 8601 revisions can come up with ever more complicated rules for how to handle this, but I come back to the point that the added complexity here outweighs the meagre benefits in functionality.

Neil.

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------4274C14EBDC2655E95089D06-- From nobody Wed Sep 5 13:14: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 DBEE6130E26 for ; Wed, 5 Sep 2018 13:14:12 -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=IJt9dbTL; dkim=pass (2048-bit key) header.d=srs7.zonevs.eu header.b=Dat2XPYR; dkim=pass (2048-bit key) header.d=dot.ee header.b=bj3xtQds 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 wN15QHLQV0Dq for ; Wed, 5 Sep 2018 13:14:10 -0700 (PDT) Received: from srs7.zonevs.eu (srs7.zonevs.eu [217.146.68.197]) (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 7D9AD130DD6 for ; Wed, 5 Sep 2018 13:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=vh/qV0aoCXUQXgcNnQ+T9Sjcd/jnMjUvaGKxz5G+7yE=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=IJt9dbTLWG+xqeJ5nMIqHjv/zKUNRSnLNZJ1cOqFoAQLuhGj9QYAvkbmLuI5IkXpCCVlyti+A l2LizSWCqKp3w9q82IfNc8dJ5xx0Ju6MY/NwmbmqGYbdm9TlLl4ZhHo4kajJHJ0HQPMni02Nj4x 1IEALF54YMy5AZY3dTJof0iYrBtYxu4B3N76/PureEXTM49HEAXgPJbOKlzCv6sIYN4a1GPJtsQ usH5wlAmHXCWV3pwFsjbvYzX+BpejbRY70tQx9rnFNzBWTyU7f9ssjjaRdKJSFED/OTA2hKbWuv lDi9u8vSwPnCxzfLp2GzVPHwziqI9+ghWxTuNXbJDaVg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs7.zonevs.eu; q=dns/txt; s=oct2016; bh=vh/qV0aoCXUQXgcNnQ+T9Sjcd/jnMjUvaGKxz5G+7yE=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=Dat2XPYRQvdiyKOcmofFdqN/F3mWp6hPpPnUaBLWTmUxXGtYfTXkS3YZJ9jNWWnAMxxNB8XLn h3hWNtAf8vFukES4rIMyfeUa4tbQ6ZlyeBmzbG377IiLgwSaVfWHoFi4ZT3tAp2e58u/MNAuJfS 8xH18oPz2kCB21nrRVehjECJsdGzOvzAAZ8B1rUKhnVol/3WziYGh95L+1C1ev4w396Zbk4YHWz fhMabZCDX9fvdtdeM+k7y8jwfkztuO7KoCB9eyScS78JWt1AsqyTYNaI1TCb23E2CD9yOEm5usZ NYIf5pBHa87hEvKYMr7E5QLopU8a4q6Rc+inJgaskQnw== Received: from smtp.zone.ee ([217.146.66.124] smtp.zone.ee) by srs7.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 165ab5ed5bb000a745.001 for ; Wed, 05 Sep 2018 20:14:03 +0000 X-Zone-Loop: 8e5f093045c0e7fb54250ea9380b92b9d7bbcf6ac8de 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.ee (Postfix) with ESMTPSA id 7042A128B5C1 for ; Wed, 5 Sep 2018 23:14:03 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1536178443; bh=VDyuynCIR/oPFuCh6fz37uqpyN0oijB+yl4DknbNzwo=; h=Subject:To:References:From:Date:In-Reply-To; b=bj3xtQds+jPYmWyjlkBQYN4GAh3jllvZpBmQ/d8k4WivQolbrH4SavTLUbid5NIKL SngHx8fo5zQ9bEwdrWm2iVXaN9TUzvgnsgbBHhuiVhpP3wwouJhympopKmlSEtn9aj /Ay7ahjeGfpev4E7HF5Qd0rUBhAbpB4jjCoVj1NGG+w+VMLxEdArooh8w6QrCX/abR kcekAS3F9scXxxr/gKD4ThuarR0712QspNjI/5MTBQAlOBcOS+SG7Od/WPxba/R0h8 6b/zVaBGNdDFz9CVFN3wvZEw2jtut82xN+RLyMomgWECnqmM8JXO71jjm7jSBqJk8G Sf5c/w+jGj7SA== To: calsify@ietf.org References: <4e5fbfb3-3b6d-954c-9fb7-1fea100c400d@dot.ee> <00372112-6ab0-4076-a421-6f30f7fe94df@sloti22d1t06> From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: Date: Wed, 5 Sep 2018 20:14:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <00372112-6ab0-4076-a421-6f30f7fe94df@sloti22d1t06> Content-Type: multipart/alternative; boundary="------------27826732ED2B7CCB4731B691" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-0.18691, required=15, tests=[HFILTER_HOSTNAME_5=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.98691, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: Re: [calsify] ReplyTo with HTTP (for development) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Sep 2018 20:14:13 -0000 This is a multi-part message in MIME format. --------------27826732ED2B7CCB4731B691 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit This isn't about a shoddy service. This is about debugging 3rd party client software. I've spent hours debugging and working around iOS's (and other platforms') CalDAV quirks and managed to so by directing the apps to a development machine. Yet if CalDAV had demanded HTTPS to the server, I would've been hosed. You can't get a legit certificate for a local IP address nor do I have a Mac to install custom root certificates to an iPhone, for example. If that's even a thing anymore. Some client software have their own bundled roots. There it would've impossible to productively debug HTTPS-only services. This is a weird thing for me to advocate, as I'm usually the first to jam encryption down people's throats, but my latest experience with implementing CalDAV has left me with quite a cynical view. While people _have_ to follow standards, they don't. They make mistakes. And that's where obstacles to debugging annoy me. ReplyTo issue itself is perhaps easy to work-around, but it's the principle that matters. I propose everywhere where there's a callback URL involved, the spec equally accept HTTP, but perhaps recommend a displaying a warning if used. Just like email and calendar apps do today. Demanding HTTPS from client software is just frustrating for us, server developers. On 5/28/18 4:47 AM, Neil Jenkins wrote: > On Fri, 25 May 2018, at 8:44 PM, Andri Möll 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 > decent service is only going 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/. > > Neil. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------27826732ED2B7CCB4731B691 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

This isn't about a shoddy service. This is about debugging 3rd party client software.

I've spent hours debugging and working around iOS's (and other platforms') CalDAV quirks and managed to so by directing the apps to a development machine. Yet if CalDAV had demanded HTTPS to the server, I would've been hosed. You can't get a legit certificate for a local IP address nor do I have a Mac to install custom root certificates to an iPhone, for example. If that's even a thing anymore. Some client software have their own bundled roots. There it would've impossible to productively debug HTTPS-only services.

This is a weird thing for me to advocate, as I'm usually the first to jam encryption down people's throats, but my latest experience with implementing CalDAV has left me with quite a cynical view. While people _have_ to follow standards, they don't. They make mistakes. And that's where obstacles to debugging annoy me. ReplyTo issue itself is perhaps easy to work-around, but it's the principle that matters.

I propose everywhere where there's a callback URL involved, the spec equally accept HTTP, but perhaps recommend a displaying a warning if used. Just like email and calendar apps do today. Demanding HTTPS from client software is just frustrating for us, server developers.


On 5/28/18 4:47 AM, Neil Jenkins wrote:
On Fri, 25 May 2018, at 8:44 PM, Andri Möll 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 decent service is only going 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.

Neil.

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------27826732ED2B7CCB4731B691-- From nobody Wed Sep 5 23:41:49 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 CDE69130DE5 for ; Wed, 5 Sep 2018 23:41:45 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.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 NLm9l6qXTveT for ; Wed, 5 Sep 2018 23:41:44 -0700 (PDT) Received: from mr85p00im-hyfv06021301.me.com (mr85p00im-hyfv06021301.me.com [17.58.23.188]) (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 168E8130DC6 for ; Wed, 5 Sep 2018 23:41:44 -0700 (PDT) Received: from process-dkim-sign-daemon.mr85p00im-hyfv06021301.me.com by mr85p00im-hyfv06021301.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) id <0PEM00L00FOH2R00@mr85p00im-hyfv06021301.me.com> for calsify@ietf.org; Thu, 06 Sep 2018 06:41:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1536216103; bh=RsvQGGKy3xoWwGHnF6Mg8yKXaU4WfNKfDLvrL4UFLY4=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=gg0EuNaemYWHS2LG/PLS/FV6yT1Oytn5i3DFpoR7w6tIstYkbaK8YGv9o6R2v1r0A VQuSyOPAUzzoNQdWHMvONSO8cFUowaAcruu3+LWJ/qzE42F0a7CwmmprFi7w4J+Bsp 06Exg1zyKnEozL2fH5Os5EQcfqORDmmyxdCEa/cEbGtKjX8bI37KyhqKQXICm51Sb2 3Q/QAv2Z1U5MrEbYj0o5nZct/6rrNWS/LYumIqoNWldjJoHv94bv9HYlJdyzwvMA9D 6hhcq9KFVHrrjwN5cupIVUp8vaR184PD3ZIF74O0kt69uBLKufJOwjCuWiMe64uhOA /YfQABcH5lTSg== Received: from icloud.com ([127.0.0.1]) by mr85p00im-hyfv06021301.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPSA id <0PEM00HUSFXIYC00@mr85p00im-hyfv06021301.me.com>; Thu, 06 Sep 2018 06:41:43 +0000 (GMT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1809060071 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-09-06_03:,, signatures=0 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Andrew Laurence In-reply-to: Date: Wed, 05 Sep 2018 23:41:40 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <729E8F77-EFA6-47B0-851F-5E0D892C6C1E@ribose.com> <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> <84d5a7bd-abec-495e-bebd-154871c80413@sloti22d1t06> To: calsify@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 06:41:46 -0000 > On Sep 5, 2018, at 12:31 PM, Andri M=C3=B6ll wrote: >=20 > In light of things finalizing, I'd like to re-raise the nominal = duration issue. As I may not be able to convince everyone of their value = and accept their exclusion from the spec, I strongly recommend they NOT = be allowed to be specified for events with times. That is, P1D should = only be allowed for events with dates. Both for consistency and for = future proofing. Could the period duration constrained to not exceed the logical bounds = of the prior unit? e.g. P1M6W is invalid because no Gregorian month has = six weeks. > The first thing I learned when getting into calendaring, and something = every course and book teaches you, is that days are not consistently 24 = hours, months not 30 days and years not 365 days. It's _the_factoid = every time-enlightened person tells the uninitiated. Going against that = in a calendaring spec is backwards and error prone. I love using this for that conversation: http://yourcalendricalfallacyis.com -Andrew From nobody Thu Sep 6 01:18: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 29ED0130E02 for ; Thu, 6 Sep 2018 01:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Pe4mPcemd5G8 for ; Thu, 6 Sep 2018 01:18:16 -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 507B7130DFA for ; Thu, 6 Sep 2018 01:18:16 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2278E21B84 for ; Thu, 6 Sep 2018 04:18:14 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute1.internal (MEProxy); Thu, 06 Sep 2018 04:18:14 -0400 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=fm3; bh=qiFilOlLNyW1BhqHpEceM2AJqTyAufsXm3N8QjLjT 8g=; b=qT17WCGXYDTLn2FNiBsWtZmTrcDcX59ejnBpaMaiiqoa2o5scNTCvv1d0 4qWX7dt8HWT3axnDy8OPPSwXAfKkCKPuC9COCn4t5F4pHuP6lfBLIoWRbtQsLml4 sYrrQTL4J9xWm4eD8/gSAss1hrqX/C7au+gXuhWUN2+YOpSe0n9Ba3of+v7zcbfM VEL6DRbsa5xnZCDLpji18dJdJigafu6yajlCLvT9fqgWNtS3fEHRQDze5NblrLMf s/CU6RROpvsW97bHBlTBNYvTSPDAQjsR14g2rvSQWyfl6fRkLSJ5fG2wAGe/amHH GHudVyDdryi3H8dud1iwjSvI/WFLw== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 963BAE629; Thu, 6 Sep 2018 04:18:13 -0400 (EDT) Message-Id: <369ad526-0012-4189-ac4d-df2945e786a4@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-440-g28598e9-fmnext-20180906v2 x-jmap-identity-id: 66430872 In-Reply-To: References: <4e5fbfb3-3b6d-954c-9fb7-1fea100c400d@dot.ee> <00372112-6ab0-4076-a421-6f30f7fe94df@sloti22d1t06> Date: Thu, 06 Sep 2018 04:18:13 -0400 From: Robert Stepanek To: calsify@ietf.org Content-Type: multipart/alternative; boundary=aa4f149dbd3842e4990cca5abc87ddd0 Archived-At: Subject: Re: [calsify] ReplyTo with HTTP (for development) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 08:18:18 -0000 --aa4f149dbd3842e4990cca5abc87ddd0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 5, 2018, at 22:14, Andri M=C3=B6ll wrote:=20 > This isn't about a shoddy service. This is about debugging 3rd party c= lient software.=20 > [...]=20 > I propose everywhere where there's a callback URL involved, the spec e= qually accept HTTP, but perhaps recommend a displaying a warning if used= . Just like email and calendar apps do today. Demanding HTTPS from clien= t software is just frustrating for us, server developers.=20 =20 I've been reading IETF's best practice recommendations (https://tools.ie= tf.org/html/rfc3365) but the only thing I get out of that is "it depends= ". =20 =20 Personally, I'm leaning towards not restricting the URI scheme at all. T= he reason we have to label the "mailto:" URI with "imip" is only because= a "mailto:" URI in itself doesn't allow client implementations to ident= ify what payload to use in that email. I'd be equally fine to just use "= imip" and "other" as keys in the "relatedTo" property, where the "other"= URI can be an URI template using whatever scheme implementations will f= ind useful.=20 =20 Would that be an improvement for clients?=20 =20 Cheers,=20 Robert=20 =20 =20 > On 5/28/18 4:47 AM, Neil Jenkins wrote:=20 >> On Fri, 25 May 2018, at 8:44 PM, Andri M=C3=B6ll wrote:=20 >>> I'm all for strongly suggesting HTTPS for public Internet use, but d= uring development I must say HTTPS is a pain in the ass. I, like a lot o= f 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 se= t up in the router.=20 >> =20 >> Following the standard is required if you wish to interoperate. For w= hen you are operating entirely within a closed system (develop + test) y= ou can of course ignore any requirements you like.=20 >> =20 >> 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 = decent service is only going to use HTTPS anyway, any shoddy service pro= bably 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. *Sh= rug*.=20 >> =20 >> Neil.=20 >> =20 >> _______________________________________________ calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >>=20 > _______________________________________________=20 > calsify mailing list=20 > calsify@ietf.org=20 > https://www.ietf.org/mailman/listinfo/calsify=20 > =20 =20 --aa4f149dbd3842e4990cca5abc87ddd0 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Wed, Se= p 5, 2018, at 22:14, Andri M=C3=B6ll wrote:

This isn't about a shoddy service. This is about debugging 3rd party client software.

=

[...]

= = I propose everywhere where there's a callback URL involved, the spec equally accept HTTP, but perhaps recommend a displaying a= warning if used. Just like email and calendar apps do today. Demanding HTTPS from client software is just frustrating for us, server developers.

=
I've been reading IETF's best practice recommendations (<= a href=3D"https://tools.ietf.org/html/rfc3365">https://tools.ietf.org/ht= ml/rfc3365) but the only thing I get out of that is "it depends".

Personally, I'm leaning towards not restrict= ing the URI scheme at all. The reason we have to label the "mailto:" URI= with "imip" is only because a "mailto:" URI in itself doesn't allow cli= ent implementations to identify what payload to use in that email. I'd b= e equally fine to just use "imip" and "other" as keys in the "relatedTo"= property, where the "other" URI can be an URI template using whatever s= cheme implementations will find useful.

Wou= ld that be an improvement for clients?

Chee= rs,
Robert


On 5/28/18 4:47 AM, Neil Jenkins wrote:
On Fri, 25 May 2018, at 8:44 PM, Andri M=C3=B6ll wrote:
I'm all for strong= ly 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 decent service is only going 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.
Neil.

______________________________________________=
_
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
=

--aa4f149dbd3842e4990cca5abc87ddd0-- From nobody Thu Sep 6 03:41: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 8E257130E5A for ; Thu, 6 Sep 2018 03:41:56 -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, 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=zonevs.eu header.b=NNG2ZjWT; dkim=pass (2048-bit key) header.d=srs2.zonevs.eu header.b=pFmXwYCC; dkim=pass (2048-bit key) header.d=dot.ee header.b=O7Z/ZuCv 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 inMIc3-b6GZg for ; Thu, 6 Sep 2018 03:41:53 -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 97D00130DEF for ; Thu, 6 Sep 2018 03:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=/z5Z5aR31z47ls+nGuwQ6lAcUhSNBInPn/ARckhOKto=; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references; b=NNG2ZjWTOFYJZq32dKv/w7GVGSLgQsmCzLBnnjv1bL153c9mjGlhPkJ4xLaK3+TyoisJgd3ae lFtj2ObIcSg58DUu7vxEHf4XsnYJm7Dq6U0xSDH8CDZyBUv9hkJ+RSYA1oxM9Eb/bKQGA85Xtnj wjGtdb/m3Rk93ZzLjG3trPKRdEUOMwG+6ei99NzkhOj4IKpaeQO0t2FqH4UtuU5qQcEQbfvU+5t Zjv73XAxuGJDWtIGYM0IWcCGCOHLt29lfs3cvHaJA+T3eWF26/gpfn3sEEEnNXUGAN9ckns5qxK JXXBec3uRoEd603g1vN7fMxC8oHw4n1c8KpJSiPw3enQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs2.zonevs.eu; q=dns/txt; s=oct2016; bh=/z5Z5aR31z47ls+nGuwQ6lAcUhSNBInPn/ARckhOKto=; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references; b=pFmXwYCCkNzjMruczlUpsJL9n8YbG+c3xxp9ocbbuByI0T7iNIgoweADENiXDWUqlg+bcwjEL YTiiFmPf1c+Phjj8J5zIKESD6+CgtAPrvAYdERnYN7Oj/tMhPZ4vHyWnwX3EbRtl35TTSzlkXM8 4FzW8VlZYpdPl7+9R8KroYCjjmU1UIAgVWSdY3dabKYvjfa+zUkCLfG9L44o3NJwi8P1z6TVa7a 9Y7AgckFH3M4bL/mIx/t7LSSC4mJw+Jhf1AedyTxwN6C4Cuy0N4IWiETeZycHaeOgBii8UjB6yR eijuhrmn1erLuIqLmiYvgmY4b97I0IhqCN7ppG6ZpUnw== Received: from smtp.zone.ee ([217.146.66.124] smtp.zone.ee) by srs2.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 165ae793ad10000e33.001 for ; Thu, 06 Sep 2018 10:41:45 +0000 X-Zone-Loop: 7050308571b9e8ed595434a3e9786cdda094cfd73588 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.ee (Postfix) with ESMTPSA id C4C92128B5C1; Thu, 6 Sep 2018 13:41:44 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1536230504; bh=qYyv1o49lW4nSCjMj3SEmam2jdcZ2etbRzRpnYoO7X4=; h=Subject:To:References:From:Date:In-Reply-To; b=O7Z/ZuCvnjeJZton92088+WBAOJCWSYU3w4GK9YPDJtnigKirFa4xQbKh/tdGD5du /F6mKaCM3oWUp9GEG3a2Heb3HovKPSWaZSct0zPzVRGT+t7jPDBgq+H8h9Vs4lXQ1Z iJTnOIv/LKhG8EPC+ihbWDuzUBcdUeYKS2+mzUAVk8WzQv4Qs5H5+GDizGcdZi2O+K ialIB94t9WkPHBEjpWWww4L7JFwKNhXK4GppRIhHoNMiFF4z51hjP1z/ufh6NTOimd UvuVASsOaQWdidRb2VkV6SS7QeF2D0N6W8FWfO/+QyFKUFDM6mYDbCQFEUdkjIJziy LU2qneCtsRKnw== To: Andrew Laurence , calsify@ietf.org References: <729E8F77-EFA6-47B0-851F-5E0D892C6C1E@ribose.com> <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> <84d5a7bd-abec-495e-bebd-154871c80413@sloti22d1t06> From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: Date: Thu, 6 Sep 2018 10:41:43 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-3.198721, required=15, tests=[HFILTER_HOSTNAME_5=3, BAYES_HAM=-3, ARC_NA=0, MID_RHS_MATCH_FROM=0, R_DKIM_ALLOW=-0.2, RCVD_VIA_SMTP_AUTH=0, IP_SCORE=-2.998721, RCVD_TLS_ALL=0, NEURAL_HAM=0, MIME_GOOD=-0.1, DKIM_TRACE=0, FROM_EQ_ENVFROM=0, RCPT_COUNT_TWO=0, ASN=0, TO_DN_SOME=0, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 10:41:57 -0000 On 9/6/18 6:41 AM, Andrew Laurence wrote: >> On Sep 5, 2018, at 12:31 PM, Andri Möll wrote: >> >> In light of things finalizing, I'd like to re-raise the nominal duration issue. As I may not be able to convince everyone of their value and accept their exclusion from the spec, I strongly recommend they NOT be allowed to be specified for events with times. That is, P1D should only be allowed for events with dates. Both for consistency and for future proofing. > Could the period duration constrained to not exceed the logical bounds of the prior unit? e.g. P1M6W is invalid because no Gregorian month has six weeks. For the record, how and whether to limit nominal durations is independent of permitting them in the first place. My proposal was to forbid them for events with times right now as the P1D == PT24H equivalence the spec supposedly assumes is just silly. As for limiting nominal durations, I don't agree. While ISO 8601 doesn't allow weeks to be specified along with anything else, even if it did, weeks decompose to days and days are one of the atoms, along with seconds and months. P1M6W would be as permissible as P1M42D. From nobody Thu Sep 6 03:45:41 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 F3EE3130E0F for ; Thu, 6 Sep 2018 03:45:39 -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 ZXwMee4lPcpB for ; Thu, 6 Sep 2018 03:45:38 -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 A7DF4128CF2 for ; Thu, 6 Sep 2018 03:45:38 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B3C0720C9A for ; Thu, 6 Sep 2018 06:45:37 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute1.internal (MEProxy); Thu, 06 Sep 2018 06:45:37 -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:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=u5dWayAPx9hC6pvXR G3SC+DT1sjGDhRYArmEIX9eCXw=; b=pcnlpYDFfqnCnmbjVtofhKT3zINM4LKed o+lq4uULsb2QnYFCSDk1aV0GPtRsl0hnvrepdCx+8t6V7YbE/7e5zN4Z4lFJFi/F KoO1y5hcPy/abhM6jUyw1mv9Nn6FeI97sN+j/mCU3CHFx3zLvOQm/bF3N7E9Wnqo teurYKY47bwBobGzVMcqdca18SDMu41jWQH9mLJOUBhJf4bbDDmK2pEiDyYx+e3B hlN8dIDVFuonbV0ydYzBtMPpjaeQkcAiuUTB6LWI+Q39EgOQyzPxsoJvgQqYnjp8 lbDniZ++tbvRX5scW/SRKUEW6giAVzilpJlgjMEuI1krqetgkJhEg== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4C3E8E629; Thu, 6 Sep 2018 06:45:37 -0400 (EDT) Message-Id: <7ff71d72-eede-4c19-b141-3ba999c5ec07@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-440-g28598e9-fmnext-20180906v2 x-jmap-identity-id: 66430872 In-Reply-To: References: <729E8F77-EFA6-47B0-851F-5E0D892C6C1E@ribose.com> <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> <84d5a7bd-abec-495e-bebd-154871c80413@sloti22d1t06> Date: Thu, 06 Sep 2018 06:45:36 -0400 From: Robert Stepanek To: calsify@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 10:45:40 -0000 On Thu, Sep 6, 2018, at 12:42, Andri M=C3=B6ll wrote: > My proposal was to=20 > forbid them for events with times right now as the P1D =3D=3D PT24H=20= > equivalence the spec supposedly assumes is just silly. I'm not sure which spec you mean? The JSCalendar spec doesn't assume equ= ivalence of P1D and PT24H. Cheers, Robert From nobody Thu Sep 6 04:03:45 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 9C08C128CF2 for ; Thu, 6 Sep 2018 04:03:43 -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 (2048-bit key) header.d=zonevs.eu header.b=c7dkv1Vm; dkim=pass (2048-bit key) header.d=srs7.zonevs.eu header.b=ElNjvNPx; dkim=pass (2048-bit key) header.d=dot.ee header.b=V1s8uQb9 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 3zQR4_QgUPoH for ; Thu, 6 Sep 2018 04:03:41 -0700 (PDT) Received: from srs7.zonevs.eu (srs7.zonevs.eu [217.146.68.197]) (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 71D641200D6 for ; Thu, 6 Sep 2018 04:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=Fh4wsqQccw5cEswAsAqJUE1JQ6ZbqFBd99WtQNMBBCE=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=c7dkv1Vmk0hsI3Z07ihgX5AdEgluY5A/n1uoEthW9JDXO1JruhJ3wrY1xyAlV+CiFGIruloOr 4jTfHpxaxT5UR0sdxaTdnOHBmMfM+MYQ92Ru7WA9OENvoGyDA+je2sciMD75ztSpNgZv+e3ZTd9 9g7ejEeHnNYj3Sz1chSiRH5uig8dQWGbkVh62xpJcjfOERWZkU3eMPQ9VsfK8GyZybEANDiqmKN Xr681ey3RxkicETuvdZtZrboPdx9IQ0kM3YTDaP+Dtp30Wmphs4nTopdLYQnbl/pPS/UpkLyRgW sQF2z0S92iYhv3oE1TWA1NNV3pGzSC+VmvgSu0UiXeRg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs7.zonevs.eu; q=dns/txt; s=oct2016; bh=Fh4wsqQccw5cEswAsAqJUE1JQ6ZbqFBd99WtQNMBBCE=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=ElNjvNPxDvTNu0E3FnkJQUuUTTf0tiE3LCLv+0aAKR92BloeFZ0d5Fe0tObh0tgZzRCM/BlGH 9+pb3VQIFQaT+QFKB6WungUApu/puBKFha/ip3F0T7Kfdaio0tBUZNL2hNRfQoCQGgPB+SlvaET I6OqkG1Vqv4qzKgRDwXJlZ2R6rDPJ7cCEbRuKCw65RUrvKh+SS+zsr8f8tEHwop3mcKdPObXQDk UerAjL08k8RsAp0/t0X8cMx7klmOyXLTWNcomQLI7udrUHz4obg/1gpg5a5O2aul1PX8ppvRJ+i TV5YQ2HVTZQN6X5BymrWQ8KURtGwEy71wTyL58oZzfjg== Received: from smtp.zone.ee ([217.146.66.124] smtp.zone.ee) by srs7.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 165ae8d33c50010e33.001 for ; Thu, 06 Sep 2018 11:03:34 +0000 X-Zone-Loop: d6813e9e8eaeab6ab0ce4ac325e6e619574330ec94e1 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.ee (Postfix) with ESMTPSA id BA215128B5C7 for ; Thu, 6 Sep 2018 14:03:33 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1536231813; bh=oP7a1le24FQGiAgirJztB/BHbCJuo2fehIE/Ar1QA0Q=; h=Subject:To:References:From:Date:In-Reply-To; b=V1s8uQb91RCkI/0Qk5sxWFRCbqGzA75eloZEQJhYHUAldQ1LlgmuJwIG0zOAJi3/4 mIQXml3BAlujU0CszLqhs+EmJolo8wJUovNo7z68PUKBlCEv1iHsDqJfXA7ZenL2ly +FemX+A/fQSzl3ndv0vkWF7cvguIfw7I9V8hx9nYq4pclcZNbJ/4z7ekqPOVekIBx2 wuvC3ZTwq6THjgvjpFzXYq1P5PsMkdkvvm6E/kNmHlsvHTVhNDnmOEwsodeNyKv4gz D7mAqAehtNCKLpQXInVTXwLOvnFjsncgC/hcYV9cvhLEAvoO8p9xG2Ui1+OdD6gxzc 8XUlwKqqKqSvQ== To: calsify@ietf.org References: <729E8F77-EFA6-47B0-851F-5E0D892C6C1E@ribose.com> <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> <84d5a7bd-abec-495e-bebd-154871c80413@sloti22d1t06> <7ff71d72-eede-4c19-b141-3ba999c5ec07@sloti22d1t06> From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: <829e4105-f579-75f7-fb4b-05b08534f5f5@dot.ee> Date: Thu, 6 Sep 2018 11:03:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <7ff71d72-eede-4c19-b141-3ba999c5ec07@sloti22d1t06> Content-Type: multipart/alternative; boundary="------------B7F5E67829F26A83E079B750" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-3.209808, 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=-3.009808, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 11:03:44 -0000 This is a multi-part message in MIME format. --------------B7F5E67829F26A83E079B750 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/6/18 10:45 AM, Robert Stepanek wrote: > On Thu, Sep 6, 2018, at 12:42, Andri Möll wrote: >> My proposal was to >> forbid them for events with times right now as the P1D == PT24H >> equivalence the spec supposedly assumes is just silly. > I'm not sure which spec you mean? The JSCalendar spec doesn't assume equivalence of P1D and PT24H. I was going off of Neil's conclusion and the convert-to-UTC aspect: On 7/4/18 11:10 PM, Neil Jenkins wrote: > No, see the actual spec > : > > * > > > 5.1.3 > . > duration > > * > Type: "Duration", e.g. "P2DT3H" (optional, default: "P0D") The zero or > positive duration of the event in absolute time (i.e. in UTC time; > ignoring DST shifts). > > Therefore, P1D is exactly equivalent to PT24H in the context of the > event duration. I'd be surprised if anyone pays attention to the UTC-conversion idiosyncrasy. It's natural, in the context of calendaring, to do arithmetic on date-times [objects] with time zones (for events with times), as you want the end time to be in the same time zone, after all. And it'll work just fine because +PT3H is the same in any time zone. +P1D however will diverge. It's an error prone idiosyncrasy I'm arguing should be dropped --- no P1Ds for events with times. --------------B7F5E67829F26A83E079B750 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/6/18 10:45 AM, Robert Stepanek wrote:
On Thu, Sep 6, 2018, at 12:42, Andri Möll wrote:

 My proposal was to 
forbid them for events with times right now as the P1D == PT24H 
equivalence the spec supposedly assumes is just silly.

I'm not sure which spec you mean? The JSCalendar spec doesn't assume equivalence of P1D and PT24H.

I was going off of Neil's conclusion and the convert-to-UTC aspect:

On 7/4/18 11:10 PM, Neil Jenkins wrote:

No, see the actual spec:

5.1.3.  duration


   Type: "Duration", e.g.  "P2DT3H" (optional, default: "P0D")

   The zero or positive duration of the event in absolute time (i.e. in
   UTC time; ignoring DST shifts).

Therefore, P1D is exactly equivalent to PT24H in the context of the event duration.
I'd be surprised if anyone pays attention to the UTC-conversion idiosyncrasy. It's natural, in the context of calendaring, to do arithmetic on date-times [objects] with time zones (for events with times), as you want the end time to be in the same time zone, after all. And it'll work just fine because +PT3H is the same in any time zone. +P1D however will diverge. It's an error prone idiosyncrasy I'm arguing should be dropped --- no P1Ds for events with times.

--------------B7F5E67829F26A83E079B750-- From nobody Thu Sep 6 05:02:10 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 3C899130E91 for ; Thu, 6 Sep 2018 05:02:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 hCAjIGO83ppa for ; Thu, 6 Sep 2018 05:01:58 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 63C9E130DFC for ; Thu, 6 Sep 2018 05:01:58 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id i190-v6so5127843pgc.6 for ; Thu, 06 Sep 2018 05:01:58 -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=XIezOGcH9XvvgqIMLR88RczX5+g3HsMsLDUVl0zjNTw=; b=HJ6EeTZAsFDXxID/HLoXCKh7R0jUMtQfAAnJsxjLVy+S0GaulHlOPz1g3W0WLHsga2 jRmr6Sxn5WtT3E5RAMRi5fEaU1TNoDa3PALhWRWGzM7pAcvgeWHSjoyROjqHiFxiVYEP /6kZGcohIFSWOVE8A+/VVwjC6OTUVRVs3qBiWBZ5E4CtotCwpNtEeVJr1hPZjA/q59WS dUAyrgE3woOroOl0zvu/uA96lCNWE9DEJwecV1ww02sMyU/8dZRglg0wrFx3X7x+K+tw t5NgB7abeR2RP99hwDLDQAZWrWXqPHqAaKvMLLcwB5x4S+REGsOmNEBAejmDBONvS85e O/UA== 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=XIezOGcH9XvvgqIMLR88RczX5+g3HsMsLDUVl0zjNTw=; b=lhjZ26AN1uAjn3dZiTfH7Hm2eJwfFDtf8eWCHt1IwLikFA0bQd1RS4U5WkU4yzQphn 11iFWHiJwObDQwcgk/TE8aKRU93r8KdbbRIOXfvKDghEbt7fHJzIqWHalOnMHZCZz3BI CenI9yPWjTpQ9qHGbaaW4mTcV+97XdEvwC6KWwA+9Y7LGvrEbpyQAWUHbCP9PNxawEwS M7czE/jiQsItXI65GKyIE1SsdO6ts1Ke6bSrrxqsa3GLw5lZDKGZm/8L80jQX6Ag9imj itb+4Dn+VDf3mGdjwq0SjIf0Feqyoth8h73MhTG/Nvp2A9SQzPm54KtXAVDXwbhtRx0S wuvA== X-Gm-Message-State: APzg51BouDvP6idf2zakMH4Q4i+mb/uvt9VFFROFli1+M4j8bDSDoFGd NiB7jpkb/Ot/Q/uk5QiUphRstiHO0gY= X-Google-Smtp-Source: ANB0Vda9j4Wm98YbblL9s+RG4LSKqtki1tx+ehJ6gKlevtXGKSsyzKESYH0Bp6AjZ8Nd7uFsU0AV6Q== X-Received: by 2002:a63:9244:: with SMTP id s4-v6mr2314486pgn.141.1536235317589; Thu, 06 Sep 2018 05:01:57 -0700 (PDT) Received: from [192.168.2.245] ([175.156.157.4]) by smtp.gmail.com with ESMTPSA id w72-v6sm10454322pfa.26.2018.09.06.05.01.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Sep 2018 05:01:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Adrian Apthorp X-Mailer: iPad Mail (15G77) In-Reply-To: <1536155616.1980207.1497601368.26E0A3E9@webmail.messagingengine.com> Date: Thu, 6 Sep 2018 20:01:54 +0800 Cc: calsify@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7DE87AC1-6021-45F6-B897-2ABE694128A6@apthorpia.com> References: <153561991025.3128.17199133283283558597@ietfa.amsl.com> <6716354d-1ff8-5567-8dda-f31f85c8fdc7@apthorpia.com> <1536155616.1980207.1497601368.26E0A3E9@webmail.messagingengine.com> To: Robert Stepanek Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-06.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 12:02:08 -0000 Thanks. Is there no mechanism to use a separate attribute for the airport co= de rather than embed it in the name? =46rom a machine processing perspective= this is obviously preferable. Could linkIds be used for this? > On 5 Sep 2018, at 9:53 PM, Robert Stepanek wrote: >=20 > Hi Adrian, >=20 >> On Sat, Sep 1, 2018, at 13:11, Adrian Apthorp wrote: >>=20 >> Just going through one more time and I found a couple of things which=20 >> would further improve the document >=20 > Thanks! I have rephrased the Participant status descriptions and updated t= he 7.6 example with airport codes. Any decent map application should now sho= w the start and end airports using the location names (see https://github.co= m/CalConnect/PUBLIC_DRAFTS/commit/73de023af949dadb11d94b6be7687e500ed2f213).= >=20 > I'll wait with a RFC version update until end of this week in case further= feedback comes up. >=20 > Cheers, > Robert >=20 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Thu Sep 6 05:42:50 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 C285E130E42 for ; Thu, 6 Sep 2018 05:42:47 -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, 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=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 59pAzml5tFWU for ; Thu, 6 Sep 2018 05:42:46 -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 1FEDD130E14 for ; Thu, 6 Sep 2018 05:42:46 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7680521BA9; Thu, 6 Sep 2018 08:42:44 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute1.internal (MEProxy); Thu, 06 Sep 2018 08:42:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=DjCui/j7aKZ0ALv8dO76eY44fqenGPxHTfoZyxz2X GY=; b=GcKoANKz7lIPEGO/hQwJVfMPz7RIC92ldk6EHhpT4aJU9fH5lA/J7+R1U /xbG4Ap0e2us24nJXnIXxdyZzXsNb9rVdop2JrMQ8hOS47/1WPydk0FXp0GQ4IMd X19cuGgM85Wl3xepGSH7PojV/eQx/4pIyyW/b6UJxukEpLIVlvm4e7D9Hj9URK7u Lqajh7tMrDfC+Cih+GepYqMH/2VsVJ4JC/rWULXeEb0InGC5mQ703Cj63eANubBZ SmH2HINbiUf3O76pfzbwDsluALalo/yE8Ze7NAA8LIpAgiF+Ah+YGSAejkrUxSFT fDfhnhFEloyNt/8rmgwQEEKL8jweQ== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CF87CE629; Thu, 6 Sep 2018 08:42:43 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.5-440-g28598e9-fmnext-20180906v2 x-jmap-identity-id: 66430872 In-Reply-To: <7DE87AC1-6021-45F6-B897-2ABE694128A6@apthorpia.com> References: <153561991025.3128.17199133283283558597@ietfa.amsl.com> <6716354d-1ff8-5567-8dda-f31f85c8fdc7@apthorpia.com> <1536155616.1980207.1497601368.26E0A3E9@webmail.messagingengine.com> <7DE87AC1-6021-45F6-B897-2ABE694128A6@apthorpia.com> Date: Thu, 06 Sep 2018 08:42:43 -0400 From: Robert Stepanek To: Adrian Apthorp Cc: calsify@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-06.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 12:42:48 -0000 On Thu, Sep 6, 2018, at 14:02, Adrian Apthorp wrote: > Thanks. Is there no mechanism to use a separate attribute for the > airport code rather than embed it in the name? Not in this spec, no. In my opinion, this is a use case for vendor extensions (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-06#section-3.3). E.g. a property named "iata.org/locationId" could hold the airport code. > From a machine > processing perspective this is obviously preferable. Absolutely! It's just, I don't think this should go in the core spec. > Could linkIds be used for this? In this case, I think the custom property would be more appropriate. From nobody Thu Sep 6 13:39:02 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 31583130F36 for ; Thu, 6 Sep 2018 13:39:01 -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 ED22L7hJikTW for ; Thu, 6 Sep 2018 13:38:58 -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 5C50C130EBC for ; Thu, 6 Sep 2018 13:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=w7XOWoizKSr/9rrdvHOpwGVE290cJkG4B6u8Roolxeo=; b=pIsfYK+39vLut10YjsfC/cq4KdwTBzq+F6oRlosRXJg213gh8ZcQneWRQ3pb5/5Ug5jmnpUIcJE0S eh5OD+c3woBdBIr3nt/XJGwEKsjx2r2X7BKrp1gedUC/Pw0iVO5IcVVj8fKNIMQJohZiFQPCIjyGNA XI08BNXqcPcJP3XY= X-HalOne-Cookie: 9959cc8d3b4bf48b1576b8d4b78a48182d61ace5 X-HalOne-ID: dead9f87-b214-11e8-af47-d0431ea8bb03 Received: from smtp.dmfs.org (unknown [84.129.200.204]) by mailrelay3.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id dead9f87-b214-11e8-af47-d0431ea8bb03; Thu, 06 Sep 2018 20:38:54 +0000 (UTC) Received: from boss.localdomain (p548B12C4.dip0.t-ipconnect.de [84.139.18.196]) by smtp.dmfs.org (Postfix) with ESMTPSA id CF8385C8 for ; Thu, 6 Sep 2018 22:38:53 +0200 (CEST) To: calsify@ietf.org References: <4e5fbfb3-3b6d-954c-9fb7-1fea100c400d@dot.ee> <00372112-6ab0-4076-a421-6f30f7fe94df@sloti22d1t06> From: Marten Gajda Message-ID: Date: Thu, 6 Sep 2018 22:38:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0621805421CAD5BE8BD44882" Content-Language: en-US Archived-At: Subject: Re: [calsify] ReplyTo with HTTP (for development) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 20:39:01 -0000 This is a multi-part message in MIME format. --------------0621805421CAD5BE8BD44882 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Andri, just to be sure we're on the same page, this "ReplyTo an HTTPS address" thing is not some kind of CalDAV extension or some kind of new protocol. The CUA is not supposed to send some document to this address or anything like that. The sole purpose of an HTTPS ReplyTo address is to open it in a browser. The URL should contain parameters which identify the event and the attendee (if the user doesn't have an account on the server) and the server would return an HTML page which prompts the user about the event and his attendance status, giving him the options to accept or decline the invite. So this is really just a lightweight RSVP mechanism that doesn't build upon ITIP. I'd guess in 99+% of all cases this HTTPS URL is opened in a browser or some kind of WebView. It's not something a CUA developer would have to care about and server developers can just test their implementation with available browser implementations. Does that make sense? Cheers, Marten Am 05.09.2018 um 22:14 schrieb Andri Möll: > > This isn't about a shoddy service. This is about debugging 3rd party > client software. > > I've spent hours debugging and working around iOS's (and other > platforms') CalDAV quirks and managed to so by directing the apps to a > development machine. Yet if CalDAV had demanded HTTPS to the server, I > would've been hosed. You can't get a legit certificate for a local IP > address nor do I have a Mac to install custom root certificates to an > iPhone, for example. If that's even a thing anymore. Some client > software have their own bundled roots. There it would've impossible to > productively debug HTTPS-only services. > > This is a weird thing for me to advocate, as I'm usually the first to > jam encryption down people's throats, but my latest experience with > implementing CalDAV has left me with quite a cynical view. While > people _have_ to follow standards, they don't. They make mistakes. And > that's where obstacles to debugging annoy me. ReplyTo issue itself is > perhaps easy to work-around, but it's the principle that matters. > > I propose everywhere where there's a callback URL involved, the spec > equally accept HTTP, but perhaps recommend a displaying a warning if > used. Just like email and calendar apps do today. Demanding HTTPS from > client software is just frustrating for us, server developers. > > > On 5/28/18 4:47 AM, Neil Jenkins wrote: >> On Fri, 25 May 2018, at 8:44 PM, Andri Möll 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 decent service is only going 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/. >> >> Neil. >> >> _______________________________________________ >> 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 -- 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 --------------0621805421CAD5BE8BD44882 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Andri,

just to be sure we're on the same page, this "ReplyTo an HTTPS address" thing is not some kind of CalDAV extension or some kind of new protocol. The CUA is not supposed to send some document to this address or anything like that.

The sole purpose of an HTTPS ReplyTo address is to open it in a browser. The URL should contain parameters which identify the event and the attendee (if the user doesn't have an account on the server) and the server would return an HTML page which prompts the user about the event and his attendance status, giving him the options to accept or decline the invite.

So this is really just a lightweight RSVP mechanism that doesn't build upon ITIP.

I'd guess in 99+% of all cases this HTTPS URL is opened in a browser or some kind of WebView. It's not something a CUA developer would have to care about and server developers can just test their implementation with available browser implementations.

Does that make sense?

Cheers,

Marten

Am 05.09.2018 um 22:14 schrieb Andri Möll:

This isn't about a shoddy service. This is about debugging 3rd party client software.

I've spent hours debugging and working around iOS's (and other platforms') CalDAV quirks and managed to so by directing the apps to a development machine. Yet if CalDAV had demanded HTTPS to the server, I would've been hosed. You can't get a legit certificate for a local IP address nor do I have a Mac to install custom root certificates to an iPhone, for example. If that's even a thing anymore. Some client software have their own bundled roots. There it would've impossible to productively debug HTTPS-only services.

This is a weird thing for me to advocate, as I'm usually the first to jam encryption down people's throats, but my latest experience with implementing CalDAV has left me with quite a cynical view. While people _have_ to follow standards, they don't. They make mistakes. And that's where obstacles to debugging annoy me. ReplyTo issue itself is perhaps easy to work-around, but it's the principle that matters.

I propose everywhere where there's a callback URL involved, the spec equally accept HTTP, but perhaps recommend a displaying a warning if used. Just like email and calendar apps do today. Demanding HTTPS from client software is just frustrating for us, server developers.


On 5/28/18 4:47 AM, Neil Jenkins wrote:
On Fri, 25 May 2018, at 8:44 PM, Andri Möll 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 decent service is only going 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.

Neil.

_______________________________________________
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


-- 
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
--------------0621805421CAD5BE8BD44882-- From nobody Thu Sep 6 14:47:11 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 C6EB4130E94 for ; Thu, 6 Sep 2018 14:47:08 -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, 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 MdlhrURcLoiB for ; Thu, 6 Sep 2018 14:47:06 -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 492A11292AD for ; Thu, 6 Sep 2018 14:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:to:subject:from; bh=AkRRjtXM+hAkZTJFG0imwpOnlXHoe7crGyBYgzomA6g=; b=M9HjLG75h8A7NHNINVOYoA7/3iN7ZSiy45zR0XCzp9TQ3S1f0DsynZpAP4WTSVHPJ1pwnvYnANeot ngLJYoER7pKEUz9nN70RQXKa9Ea4LXBv35sS28mB1FMxCSfv1fCAiu43FmQhs4n0Vsrod7i5WLsdbC t3H+iop5fei0bBFE= X-HalOne-Cookie: bf2a3c6197f6ad997e8faaabc27b9025ee3d628a X-HalOne-ID: 628925e6-b21e-11e8-af47-d0431ea8bb03 Received: from smtp.dmfs.org (unknown [84.129.200.204]) by mailrelay3.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 628925e6-b21e-11e8-af47-d0431ea8bb03; Thu, 06 Sep 2018 21:47:00 +0000 (UTC) Received: from boss.localdomain (p548B12C4.dip0.t-ipconnect.de [84.139.18.196]) by smtp.dmfs.org (Postfix) with ESMTPSA id 878FB654 for ; Thu, 6 Sep 2018 23:46:59 +0200 (CEST) To: calsify@ietf.org References: <153561991025.3128.17199133283283558597@ietfa.amsl.com> <6716354d-1ff8-5567-8dda-f31f85c8fdc7@apthorpia.com> <1536155616.1980207.1497601368.26E0A3E9@webmail.messagingengine.com> <7DE87AC1-6021-45F6-B897-2ABE694128A6@apthorpia.com> From: Marten Gajda Message-ID: <83b92bf5-8764-06f0-e137-2daff8c7cf62@dmfs.org> Date: Thu, 6 Sep 2018 23:46:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <7DE87AC1-6021-45F6-B897-2ABE694128A6@apthorpia.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-06.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 21:47:09 -0000 Am 06.09.2018 um 14:01 schrieb Adrian Apthorp: > Thanks. Is there no mechanism to use a separate attribute for the airport code rather than embed it in the name? From a machine processing perspective this is obviously preferable. Could linkIds be used for this? I think the consent was to put such structured information into a linked resource like a schema.org document, e.g. https://schema.org/Flight This could be embedded with a data: URI of course. Cheers, Marten > >> On 5 Sep 2018, at 9:53 PM, Robert Stepanek wrote: >> >> Hi Adrian, >> >>> On Sat, Sep 1, 2018, at 13:11, Adrian Apthorp wrote: >>> >>> Just going through one more time and I found a couple of things which >>> would further improve the document >> Thanks! I have rephrased the Participant status descriptions and updated the 7.6 example with airport codes. Any decent map application should now show the start and end airports using the location names (see https://github.com/CalConnect/PUBLIC_DRAFTS/commit/73de023af949dadb11d94b6be7687e500ed2f213). >> >> I'll wait with a RFC version update until end of this week in case further feedback comes up. >> >> Cheers, >> Robert >> >> _______________________________________________ >> 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 -- 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 From nobody Thu Sep 6 15:00: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 BB8C3130F29 for ; Thu, 6 Sep 2018 15:00:25 -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 (2048-bit key) header.d=zonevs.eu header.b=nTCXOBdc; dkim=pass (2048-bit key) header.d=srs2.zonevs.eu header.b=nKf/MT0H; dkim=pass (2048-bit key) header.d=dot.ee header.b=EMjn6A0s 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 E_2lgMc5qgv3 for ; Thu, 6 Sep 2018 15:00:17 -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 9D26C130DC7 for ; Thu, 6 Sep 2018 15:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=vKNcOQUYiyCg8/qIHUgnOUZteHLArHCVZJHFT/k892g=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=nTCXOBdco4xZYsOCOXDDiHp86Ayq3sLCsD4LrNzJsqOUw5OQBt7+yCkDPJL6eSd9ZdOfGc7fA H58EwTZH/saoPZKW39As9Xri+1QPvVke0321GzetVkwd1vKXyHtFxFRxt7GrqkhKoujaWmSWzsM bjlnf6abP5Qd3P7v3l75RqCkGC2MBPC9HxvZuBYsM+iElDDcLCVUgXoL56Mqvj0Y4W1NrpOhWyh AOZiqk8MVRDmqvFuzdYpBeizhg7sjV3ljKSDnzOmM0MOe6/m6S2guLsuUIOMG67yUdxZ1YD5TBK 52ahcXHeMFaejAwrvAEZgryxXjoFWs3yeoYtASCYFjaA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs2.zonevs.eu; q=dns/txt; s=oct2016; bh=vKNcOQUYiyCg8/qIHUgnOUZteHLArHCVZJHFT/k892g=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=nKf/MT0HPLEYuj1VAGsA2uTyNN7awVFwy9NpvG0Or6QDnHxImxfsJalx5863an727RJ4Z/ieA LDBZt+Miwg8BSAQOiH7apr4xd6b088DNPq/20tSSXKrpvPVJQPhOAT6wh7dhebg+UEr4Nnqbx+R tGJe373ipmOiDtkkGiUR5+CzgRip9DVpHpWLdSRusJ8HTJnDjJ4GN9cv1MXF8CEOyxfPnbDJ/91 3Zg7uBy5kaxbo++0h+VFFW+yDLYn1Yej4j3aMT+byd0Kw76rB51oMaAnfJUkrdlMM0GSgwcoScv PsQEpD9Jd6dFdC2yNc2YdfrBgonDFnvPQMeuR+6S+y8A== Received: from smtp.zone.ee ([217.146.66.124] smtp.zone.ee) by srs2.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 165b0e662760000e33.001 for ; Thu, 06 Sep 2018 22:00:13 +0000 X-Zone-Loop: 9a8f3821d6b24ac1e4e7023dc7ccf06e2416adfe66f0 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.ee (Postfix) with ESMTPSA id F1572128B5C1 for ; Fri, 7 Sep 2018 01:00:12 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1536271213; bh=9g9sLJc0GhwZm6zfvQ7DwRiTslQ7ZfpTqoMW3hLDjj4=; h=Subject:To:References:From:Date:In-Reply-To; b=EMjn6A0sMbj2E2J+RPtrQ48UizI+2rfvLq2M7ipwm8EMZOo9bXNv5YPaGGejJaScf f3tGdd2ynxl9ZLcpX+IDrupNv+O2yQQlYaGoLGdsEC8H1cKZDSoI8y70p9jWuVOd1o IXzS0VsnLkorJdKU0HMSyIINpeFmWRxcXt3ERGVqhzHpT+BA4DSv9keXEcE1l/cvRd Df8XblhifEzP4B7quh4hkpGzRNnuGeQ9uLAz9c6wG2aDDOov3mIVYNSM/RBCah4Hr7 rKvl/R7vr5a6V/P7VO65rIaMbB+WOPHZA2jamz5v42QF1ByDIOaVRsXq5S7KT9egbK IE9+dU1SEQIUA== To: calsify@ietf.org References: <4e5fbfb3-3b6d-954c-9fb7-1fea100c400d@dot.ee> <00372112-6ab0-4076-a421-6f30f7fe94df@sloti22d1t06> From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: Date: Thu, 6 Sep 2018 22:00:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BFD826971757C2FAB10288EB" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-2.924368, required=15, tests=[HFILTER_HOSTNAME_5=3, BAYES_HAM=-2.779775, 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.944594, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: Re: [calsify] ReplyTo with HTTP (for development) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2018 22:00:26 -0000 This is a multi-part message in MIME format. --------------BFD826971757C2FAB10288EB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Ah, thanks. I was indeed under the impression this is for automated responses. In that case Robert's proposal of not restricting URI schemes makes more sense. On 9/6/18 8:18 AM, Robert Stepanek wrote: > Personally, I'm leaning towards not restricting the URI scheme at all. > The reason we have to label the "mailto:" URI with "imip" is only > because a "mailto:" URI in itself doesn't allow client implementations > to identify what payload to use in that email. I'd be equally fine to > just use "imip" and "other" as keys in the "relatedTo" property, where > the "other" URI can be an URI template using whatever scheme > implementations will find useful. I do have to ask, why key-value pairs? To be able to later differentiate between using the same protocol for two different purposes --- one that requires a human to interact and the other for automated responses? If so, web URLs wouldn't need to be special-cased either and could live in the hypothetical "other" property. CUAs would pass them to the operating system to open just like they'd pass unknown URIs. Having "web" separately wouldn't contribute anything as an app would have to handle web URLs in "other" anyways. On 9/6/18 8:38 PM, Marten Gajda wrote: > > Hi Andri, > > just to be sure we're on the same page, this "ReplyTo an HTTPS > address" thing is not some kind of CalDAV extension or some kind of > new protocol. The CUA is not supposed to send some document to this > address or anything like that. > > The sole purpose of an HTTPS ReplyTo address is to open it in a > browser. The URL should contain parameters which identify the event > and the attendee (if the user doesn't have an account on the server) > and the server would return an HTML page which prompts the user about > the event and his attendance status, giving him the options to accept > or decline the invite. > > So this is really just a lightweight RSVP mechanism that doesn't build > upon ITIP. > > I'd guess in 99+% of all cases this HTTPS URL is opened in a browser > or some kind of WebView. It's not something a CUA developer would have > to care about and server developers can just test their implementation > with available browser implementations. > > Does that make sense? > > Cheers, > > Marten > > Am 05.09.2018 um 22:14 schrieb Andri Möll: >> >> This isn't about a shoddy service. This is about debugging 3rd party >> client software. >> >> I've spent hours debugging and working around iOS's (and other >> platforms') CalDAV quirks and managed to so by directing the apps to >> a development machine. Yet if CalDAV had demanded HTTPS to the >> server, I would've been hosed. You can't get a legit certificate for >> a local IP address nor do I have a Mac to install custom root >> certificates to an iPhone, for example. If that's even a thing >> anymore. Some client software have their own bundled roots. There it >> would've impossible to productively debug HTTPS-only services. >> >> This is a weird thing for me to advocate, as I'm usually the first to >> jam encryption down people's throats, but my latest experience with >> implementing CalDAV has left me with quite a cynical view. While >> people _have_ to follow standards, they don't. They make mistakes. >> And that's where obstacles to debugging annoy me. ReplyTo issue >> itself is perhaps easy to work-around, but it's the principle that >> matters. >> >> I propose everywhere where there's a callback URL involved, the spec >> equally accept HTTP, but perhaps recommend a displaying a warning if >> used. Just like email and calendar apps do today. Demanding HTTPS >> from client software is just frustrating for us, server developers. >> >> >> On 5/28/18 4:47 AM, Neil Jenkins wrote: >>> On Fri, 25 May 2018, at 8:44 PM, Andri Möll 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 decent service is only going 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/. >>> >>> Neil. >>> >>> _______________________________________________ >>> 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 > > -- > 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 > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------BFD826971757C2FAB10288EB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Ah, thanks. I was indeed under the impression this is for automated responses. In that case Robert's proposal of not restricting URI schemes makes more sense.

On 9/6/18 8:18 AM, Robert Stepanek wrote:
Personally, I'm leaning towards not restricting the URI scheme at all. The reason we have to label the "mailto:" URI with "imip" is only because a "mailto:" URI in itself doesn't allow client implementations to identify what payload to use in that email. I'd be equally fine to just use "imip" and "other" as keys in the "relatedTo" property, where the "other" URI can be an URI template using whatever scheme implementations will find useful.

I do have to ask, why key-value pairs? To be able to later differentiate between using the same protocol for two different purposes --- one that requires a human to interact and the other for automated responses?

If so, web URLs wouldn't need to be special-cased either and could live in the hypothetical "other" property. CUAs would pass them to the operating system to open just like they'd pass unknown URIs. Having "web" separately wouldn't contribute anything as an app would have to handle web URLs in "other" anyways.


On 9/6/18 8:38 PM, Marten Gajda wrote:

Hi Andri,

just to be sure we're on the same page, this "ReplyTo an HTTPS address" thing is not some kind of CalDAV extension or some kind of new protocol. The CUA is not supposed to send some document to this address or anything like that.

The sole purpose of an HTTPS ReplyTo address is to open it in a browser. The URL should contain parameters which identify the event and the attendee (if the user doesn't have an account on the server) and the server would return an HTML page which prompts the user about the event and his attendance status, giving him the options to accept or decline the invite.

So this is really just a lightweight RSVP mechanism that doesn't build upon ITIP.

I'd guess in 99+% of all cases this HTTPS URL is opened in a browser or some kind of WebView. It's not something a CUA developer would have to care about and server developers can just test their implementation with available browser implementations.

Does that make sense?

Cheers,

Marten

Am 05.09.2018 um 22:14 schrieb Andri Möll:

This isn't about a shoddy service. This is about debugging 3rd party client software.

I've spent hours debugging and working around iOS's (and other platforms') CalDAV quirks and managed to so by directing the apps to a development machine. Yet if CalDAV had demanded HTTPS to the server, I would've been hosed. You can't get a legit certificate for a local IP address nor do I have a Mac to install custom root certificates to an iPhone, for example. If that's even a thing anymore. Some client software have their own bundled roots. There it would've impossible to productively debug HTTPS-only services.

This is a weird thing for me to advocate, as I'm usually the first to jam encryption down people's throats, but my latest experience with implementing CalDAV has left me with quite a cynical view. While people _have_ to follow standards, they don't. They make mistakes. And that's where obstacles to debugging annoy me. ReplyTo issue itself is perhaps easy to work-around, but it's the principle that matters.

I propose everywhere where there's a callback URL involved, the spec equally accept HTTP, but perhaps recommend a displaying a warning if used. Just like email and calendar apps do today. Demanding HTTPS from client software is just frustrating for us, server developers.


On 5/28/18 4:47 AM, Neil Jenkins wrote:
On Fri, 25 May 2018, at 8:44 PM, Andri Möll 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 decent service is only going 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.

Neil.

_______________________________________________
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


-- 
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

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------BFD826971757C2FAB10288EB-- From nobody Fri Sep 7 00:11: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 B527A129C6A for ; Fri, 7 Sep 2018 00:11:55 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 ag9yVuFxur9O for ; Fri, 7 Sep 2018 00:11:54 -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 7A9381286D9 for ; Fri, 7 Sep 2018 00:11:54 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C365C21144 for ; Fri, 7 Sep 2018 03:11:53 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute1.internal (MEProxy); Fri, 07 Sep 2018 03:11:53 -0400 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=fm3; bh=6CI7AOVjH8Cs9YToO4M1pA/sgPTvk3fAi+CvZJnde Dw=; b=hI+RPNPQk/oUnlYUgUs9YVAaLi7scJ1NxX6hrO1EhLqmnUTVthyzhIHvM RWjdowhRYUR9i4JF6/bVHAFCHfwdd2qfotv3abWuyZYTjdyaJihYfZY/KFprKI3F ndXFXBDQst4uvcBeFG/QsOaN4pj11O7Eq7Cnur5/853srCAUhNNDU8FBug18DjiP hMpGr9yl8QPUf+V+vVlOBjSdPXj5ih/1Z2DeqRmKvDvUTL3ERAUOVV6+wwvGVWht Q2UvVm7oWEg8GNdjxIytmLMbfwoab+NVSJe+DKG6CS1JKd69WRjg2ENGr3STE41b eLCZpTTRpuFjsY9oshjcrAGW+6HMw== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 342EFE689; Fri, 7 Sep 2018 03:11:53 -0400 (EDT) Message-Id: User-Agent: Cyrus-JMAP/3.1.5-453-g95e844c-fmstable-20180907v1 x-jmap-identity-id: 66430872 In-Reply-To: References: <4e5fbfb3-3b6d-954c-9fb7-1fea100c400d@dot.ee> <00372112-6ab0-4076-a421-6f30f7fe94df@sloti22d1t06> Date: Fri, 07 Sep 2018 03:11:52 -0400 From: Robert Stepanek To: calsify@ietf.org Content-Type: multipart/alternative; boundary=260d2a5fbf444265bf23f1dcdd1a28da Archived-At: Subject: Re: [calsify] ReplyTo with HTTP (for development) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 07:11:56 -0000 --260d2a5fbf444265bf23f1dcdd1a28da Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 7, 2018, at 00:00, Andri M=C3=B6ll wrote:=20 > On 9/6/18 8:18 AM, Robert Stepanek wrote:=20 >> Personally, I'm leaning towards not restricting the URI scheme at all= [...]=20 > I do have to ask, why key-value pairs? To be able to later differentia= te between using the same protocol for two different purposes --- one th= at requires a human to interact and the other for automated responses?=20= =20 Yes. AFAIK there's also efforts to implement iTIP over HTTP, so that wou= ld also be a case where the URI scheme alone isn't enough to differentia= te interactive vs automated scheduling responses.=20 =20 > If so, web URLs wouldn't need to be special-cased either and could liv= e in the hypothetical "other" property. CUAs would pass them to the oper= ating system to open just like they'd pass unknown URIs. Having "web" se= parately wouldn't contribute anything as an app would have to handle web= URLs in "other" anyways.=20 =20 That was my idea, but it seems like I didn't communicate it correctly :)= =20 =20 Cheers,=20 Robert=20 --260d2a5fbf444265bf23f1dcdd1a28da Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Fri, Se= p 7, 2018, at 00:00, Andri M=C3=B6ll wrote:

On 9/6/18 8:18 AM, Robert Stepanek wrote:

Personally, I'm leaning towards not restricting the URI scheme at all [...]

I do have to ask, why key-value pairs? To be able to la= ter differentiate between using the same protocol for two different purposes --- one that requires a human to interact and the other for automated responses?


Y= es. AFAIK there's also efforts to implement iTIP over HTTP, so that woul= d also be a case where the URI scheme alone isn't enough to differentiat= e interactive vs automated scheduling responses.

If so, web URLs wou= ldn't need to be special-cased either and could live in the hypothetical "other" property. CUAs would pass them to the operating system to open just like they'd pass unknown= URIs. Having "web" separately wouldn't contribute anything as an app would have to handle web URLs in "other" anyways.


That was my idea, but it seems like I didn't= communicate it correctly :)

Cheers,
Robert
--260d2a5fbf444265bf23f1dcdd1a28da-- From nobody Fri Sep 7 07:58: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 E8918128D0C for ; Fri, 7 Sep 2018 07:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 jOf_q4H2E9VL for ; Fri, 7 Sep 2018 07:58:36 -0700 (PDT) Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (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 46515130DD4 for ; Fri, 7 Sep 2018 07:58:35 -0700 (PDT) Received: by mail-pg1-x544.google.com with SMTP id s15-v6so7133309pgv.8 for ; Fri, 07 Sep 2018 07:58:35 -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=P/roaFz6Yab3IbVx6ElGazO1kDa7vAMgGv0mMYqsUkE=; b=OyHSTi8/jELMBjdzzMI2ycrtoru5HL5PiPbf5mRmJa94uep8GiwS6ULfJTiCt4w1DW EtBi4iPWvL28uPAJnqmWeKPJxIm5NGr6sR7tjHjmRi7tnP4hGmLRwXPN2SmrI1oZzLHd mly/DwGc4E358ldVQbWMh+N9UkJ80teSrQi2siPe6K7IWCCY/OVk1ljxBgtyghgOm+E5 qNo19xslL+nJPB29J237RXwspv3Xtwm3ADm0jPARXgiCVXi2U7qcIvzbrOf6i3IgnX+2 0WW4vmEr8pyP+Eoxzm9fK7pY3OoH0EMRR9L+uzuqmuPodM/Cl9aCalSZKUYcbI7DXm6D EEuA== 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=P/roaFz6Yab3IbVx6ElGazO1kDa7vAMgGv0mMYqsUkE=; b=eN7OgVFWzaaz+TA66d1iTcD7/K2sEtG+rimRgw2pyoVAHGRqQVE8rlGDPIU1BqhUub 5j/GYfS+ZbchNaEdVP408Ikl9M9DvXZR8KRfzW9Eg8b09wN9fIyVfaoXE5oN+ex+xafE hCSPYPTHQC7jTUjGXuqEDJf6l58hSLonTo0blM9883vX/XERQQSiVH0RtDPBzeaohmUV YlPPJAUpdfR8oycWzXIlY9TEsiiuHIiCKW/jJShfIlXp3jBbqiVOm57U8Vt2hGqa22s1 LDwqjQ+uhizJlM2Yjsz0UMWOHP7Xq5vmjUCHvyspDFfF8BvifwT33a8PJ+5tBMppMx4f eJww== X-Gm-Message-State: APzg51AU8npNwNQGAL64Jkzt1BQ99EYIeb/PMq2jY1Az2EqI0s26Geuu Cfzyt0g18JAtUnG3alMYPgwbpav3Nhc= X-Google-Smtp-Source: ANB0VdZTP4g2zOKQsqAfSyxbOCsR5DcLWxOhTVqwiCyg0RlAHOokEIRQhvO8/yMU8/7jYwIu5doFYA== X-Received: by 2002:a62:9b46:: with SMTP id r67-v6mr8913564pfd.105.1536332314613; Fri, 07 Sep 2018 07:58:34 -0700 (PDT) Received: from [192.168.2.245] ([175.156.157.4]) by smtp.gmail.com with ESMTPSA id u83-v6sm25805290pfj.37.2018.09.07.07.58.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Sep 2018 07:58:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Adrian Apthorp X-Mailer: iPad Mail (15G77) In-Reply-To: Date: Fri, 7 Sep 2018 22:58:32 +0800 Cc: calsify@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7452D6DC-9E4F-4177-82F3-741FE195EB01@apthorpia.com> References: <153561991025.3128.17199133283283558597@ietfa.amsl.com> <6716354d-1ff8-5567-8dda-f31f85c8fdc7@apthorpia.com> <1536155616.1980207.1497601368.26E0A3E9@webmail.messagingengine.com> <7DE87AC1-6021-45F6-B897-2ABE694128A6@apthorpia.com> To: Robert Stepanek Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-jscalendar-06.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Sep 2018 14:58:38 -0000 Thanks. I wasn=E2=80=99t expecting this to be part of the core spec but know= that it could be done given this is likely to be a fairly common use case. I= thought it would be an example for LinkIds. But it seems there are differen= t opinions on the approach. A separate profile / spec for representing transportation details based on J= sCalendar would be useful. In which cas I think UN Locodes are worth a look.= > On 6 Sep 2018, at 8:42 PM, Robert Stepanek wrote: >=20 >> On Thu, Sep 6, 2018, at 14:02, Adrian Apthorp wrote: >>=20 >> Thanks. Is there no mechanism to use a separate attribute for the=20 >> airport code rather than embed it in the name? >=20 > Not in this spec, no. In my opinion, this is a use case for vendor extensi= ons (https://tools.ietf.org/html/draft-ietf-calext-jscalendar-06#section-3.3= ). E.g. a property named "iata.org/locationId" could hold the airport code. >=20 >> =46rom a machine=20 >> processing perspective this is obviously preferable. >=20 > Absolutely! It's just, I don't think this should go in the core spec. >=20 >> Could linkIds be used for this? >=20 > In this case, I think the custom property would be more appropriate. From nobody Tue Sep 11 06:04:49 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 4E65E12785F for ; Tue, 11 Sep 2018 06:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 6vVJXdCq7O1J for ; Tue, 11 Sep 2018 06:04:45 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19C41200D6 for ; Tue, 11 Sep 2018 06:04:45 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1A3EB371 for ; Tue, 11 Sep 2018 09:04:45 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute1.internal (MEProxy); Tue, 11 Sep 2018 09:04:45 -0400 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=fm3; bh=CgSmV0g+vQ3A5SIG4bruQq+SyyaEn9aZ/iedo/3fX q0=; b=ChhZlI3baKO+vngyhclT8YJRBWvPLvGwEVYy2xYVQC9VcSMlnWOFZGJAE I4WDTUcnQt6EXmE3xEekMyHhQm7El57y7JZbIkYt/ZUJArEFLcelZVxI2fQXTBIx UyccAQYjMKMU0IvqrKSEGNLPTtE4ubCmlUtg2WGSVShyuHjfyg99W53u4+Sw/593 TM+mm/sNX6mmiFJh7WF4dkwUpieRpC468tvJbXI8Eyfo4MKKDK82juDDfRk+5kbg A2OzOUe0x/IjNwGWyCYqj44k7rVFjRKoSRspPa18UZwn95PSH+zk2FesKYujPZXK 92/y3QdTskYWTbDd3ijwOiuMKak4A== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 19849E6A6; Tue, 11 Sep 2018 09:04:44 -0400 (EDT) Message-Id: <722fecff-9c1f-4cca-9b08-009dd244db8f@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-472-gf55f9be-fmstable-20180911v1 x-jmap-identity-id: 66430872 In-Reply-To: <829e4105-f579-75f7-fb4b-05b08534f5f5@dot.ee> References: <729E8F77-EFA6-47B0-851F-5E0D892C6C1E@ribose.com> <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> <84d5a7bd-abec-495e-bebd-154871c80413@sloti22d1t06> <7ff71d72-eede-4c19-b141-3ba999c5ec07@sloti22d1t06> <829e4105-f579-75f7-fb4b-05b08534f5f5@dot.ee> Date: Tue, 11 Sep 2018 09:04:40 -0400 From: Robert Stepanek To: calsify@ietf.org Content-Type: multipart/alternative; boundary=f12627a60d114fa4af370eb62a17f605 Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 13:04:47 -0000 --f12627a60d114fa4af370eb62a17f605 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, Sep 6, 2018, at 13:03, Andri M=C3=B6ll wrote:=20 > No, see the actual spec :=20 >> =20 >> 5.1.3 . duration >>=20 >>=20 Type: "Duration", e.g. "P2DT3H" (optional, default: "P0D") The zero or positive duration of the event in absolute time (i.e. in UTC time; ignoring DST shifts). >>=20 >> =20 >> Therefore, P1D is exactly equivalent to PT24H in the context of the e= vent duration.=20 > I'd be surprised if anyone pays attention to the UTC-conversion idiosy= ncrasy. It's natural, in the context of calendaring, to do arithmetic on= date-times [objects] with time zones (for events with times), as you wa= nt the end time to be in the same time zone, after all. And it'll work j= ust fine because +PT3H is the same in any time zone. +P1D however will d= iverge. It's an error prone idiosyncrasy I'm arguing should be dropped -= -- no P1Ds for events with times. =20 =20 Doesn't your proposal in fact require all events with isAllDay=3Dfalse t= o omit days and weeks from durations?=20 =20 Looking at the relevant sections of RFC 5545:=20 =20 https://tools.ietf.org/html/rfc5545#section-3.3.6=20 =20 The duration of a week or a day depends on its position in the calendar. In the case of discontinuities in the time scale, such as the change from standard time to daylight time and back, the computation of the exact duration requires the subtraction or addition of the change of duration of the discontinuity. =20 and later=20 =20 When computing an exact duration, the greatest order time components MUST be added first =20 it indeed looks to me as if there is a gap between JSCalendar and iCalen= dar durations (but I'm not sure I parsing the first requirement right).=20= =20 I'd favour to keep JSCalendar aligend with iCalendar for durations. In m= y understanding that is: allow days (and weeks) for non-zero event times= , but perform the addition in the event time-zone. For time gaps, P1D do= es not equal PT24H. Probably Neil has more insight how the JSCalendar du= ration spec came to its current definition?=20 =20 Cheers,=20 Robert=20 --f12627a60d114fa4af370eb62a17f605 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Thu, Sep 6, = 2018, at 13:03, Andri M=C3=B6ll wrote:
= No, see the actual spec:
5.1.3.  duration


   Type: "Duration", e.g.  "P2DT3H" (optional, default: "P0D")

   The zero or positive duration of the event in absolute time (i.e. in
   UTC time; ignoring DST shifts).

Therefore, P1D is exactly equivalent= to PT24H in the context of the event duration.
I'd be surprised = if anyone pays attention to the UTC-conversion idiosyncrasy. It's natural, in the context of calendaring, to do arithmetic on date-times [objects] with time zones (for events with times), as you want the end time to be in the same time zone,= after all. And it'll work just fine because +PT3H is the same in any time zone. +P1D however will diverge. It's an error prone idiosyncrasy I'm arguing should be dropped --- no P1Ds for events with times.

Doesn't you= r proposal in fact require all events with isAllDay=3Dfalse to omit days= and weeks from durations?

Looking at the r= elevant sections of RFC 5545:

    
      The duration of a week or a day depends o=
n its position in the
      calendar.  In the case of discontinuities in the time scale, such
      as the change from standard time to daylight time and back, the
      computation of the exact duration requires the subtraction or
      addition of the change of duration of the discontinuity.
=

and later
    &nbs= p;      
      =
When computing an exact duration, the greatest order time
      components MUST be added first

it ind= eed looks to me as if there is a gap between JSCalendar and iCalendar du= rations (but I'm not sure I parsing the first requirement right).

I'd favour to keep JSCalendar aligend with iCalen= dar for durations. In my understanding that is: allow days (and weeks) f= or non-zero event times, but perform the addition in the event time-zone= .  For time gaps, P1D does not equal PT24H. Probably Neil has more = insight how the JSCalendar duration spec came to its current definition?=

Cheers,
Robert
--f12627a60d114fa4af370eb62a17f605-- From nobody Tue Sep 11 07:00: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 EF276130DC6 for ; Tue, 11 Sep 2018 07:00:41 -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 (2048-bit key) header.d=zonevs.eu header.b=up9WA32F; dkim=pass (2048-bit key) header.d=srs7.zonevs.eu header.b=AjwSqDmb; dkim=pass (2048-bit key) header.d=dot.ee header.b=hnNCZ/ct 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 1JQd-PMscj90 for ; Tue, 11 Sep 2018 07:00:33 -0700 (PDT) Received: from srs7.zonevs.eu (srs7.zonevs.eu [217.146.68.197]) (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 BD8A5130E3B for ; Tue, 11 Sep 2018 07:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zonevs.eu; q=dns/txt; s=oct2016; bh=pCK692QxiZ74ph/kozZREob83lZ737iPzpFW+hnb8JM=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=up9WA32FRSKpGCDsBuyOCQJzJihj331KCJam25GPP6gT8BN5TX2HwwN3Dsk3oPQcJcGmzaNmU ZO6yH49l+Hl1jG/wXW3xiAaX/tdSacuDJYLKBL8+Gf4Ls1rnACk2RWc4dyWATKf9l5dLul/BlLX vHjnlqU8kwRdfeH84vvAScXVB0exTmSvNB2J82HgPWZZi2VYev9ko/9lTsxfFXzLzZ8dwJiI4aE kipJMEwd2RvvonYSTmDkkPoE99Yk+7kaQaxQJ4uTu6KGEB7krYS2j4sHaU5/FAujFsw9yTjH8+1 n9j5/N77THYCIvnzoj2qL+rTj3kvt9x4kKqjR18/Pj2A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=srs7.zonevs.eu; q=dns/txt; s=oct2016; bh=pCK692QxiZ74ph/kozZREob83lZ737iPzpFW+hnb8JM=; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to:references; b=AjwSqDmbUAPEVuvvc8UsmoLoxJ+uFQgnx9jhjn2oQFr+GrFRKoPYxusepF+HldoiJVfCLUsAV YeWM3Z04yXYZ9f1+6NsfCedul9+x6h01Vq1MAahwKETeXHxG47sutUvQSHqlPNJfbZLmbE266MR WEZd6QT2cCZMucj8KRksQjBIE92MP2+S1IKAfHJimgRIODoTiNBgWECzah7h0Ut2E1UvPwTnU+J EaWIg9y7gakcU4L62NsAOIPBxRqjdpA1PCZG4hOCCwFR88ZYu4ZBU9SfCkSvKl4ot+bOQvsogKS CYJYb6Z9Sz3IyQ4/40M6OMFhACJ16L4jZnSFTap0WpMw== Received: from smtp.zone.ee ([217.146.66.124] smtp.zone.ee) by srs7.zonevs.eu (ZoneMTA Forwarder) with ESMTP id 165c8eef6580011e91.001 for ; Tue, 11 Sep 2018 14:00:28 +0000 X-Zone-Loop: b0e9be4a590b9491de438762be5e1b36934db1194168 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.ee (Postfix) with ESMTPSA id 8E16F128B5E7 for ; Tue, 11 Sep 2018 17:00:26 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dot.ee; s=zone; t=1536674428; bh=QsSP66AI7VdtAwuKK5/mBwCqx+DtYii85zX7fZozaYs=; h=Subject:To:References:From:Date:In-Reply-To; b=hnNCZ/ct/ce8kS7fX3lpb2oRZStcIhmBuZiDvGHbT7mrNWL40cc0RKxDytkzSz9SL VtCdRpEyjTQshFV+jxxJNX/lMPWABVIqMs6dV827GzEISmkSewD51VxDTBLAEUeAhj hr10yvtruCSxIxmhIVLCzfZnT8a1adD0X+i8PJkVuW82qFH0UazjPRiMuwCN3jrPst r/9DNen6zNQWbZinWkUak9/VLe3cygHCQ+V93is86Itz3pxLZTYaihGwkOtEfyNVDp FN76y4dSU6DLxn5GbNlI+qrLif1n9W04MYcT/0+IZ4Lz+KV3rTlvJFQdESd4ZS2htx 8+osg5UfAvpsw== To: calsify@ietf.org References: <729E8F77-EFA6-47B0-851F-5E0D892C6C1E@ribose.com> <2025a4f7-6e92-ca56-f020-3e93c64038d3@dot.ee> <1530265140.358989.1424480712.163976AF@webmail.messagingengine.com> <6b9c3c64-40dc-ae2d-3b2f-366df1b34421@dmfs.org> <7c77d8bd-6f04-467d-87fc-3bf7988055bf@sloti22d1t06> <84d5a7bd-abec-495e-bebd-154871c80413@sloti22d1t06> <7ff71d72-eede-4c19-b141-3ba999c5ec07@sloti22d1t06> <829e4105-f579-75f7-fb4b-05b08534f5f5@dot.ee> <722fecff-9c1f-4cca-9b08-009dd244db8f@sloti22d1t06> From: =?UTF-8?Q?Andri_M=c3=b6ll?= Message-ID: <047333f6-9cb8-53eb-503f-621979f0a497@dot.ee> Date: Tue, 11 Sep 2018 14:00:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <722fecff-9c1f-4cca-9b08-009dd244db8f@sloti22d1t06> Content-Type: multipart/alternative; boundary="------------B1A142079138B83C1BF06D4C" Content-Language: en-US X-Zone-Spam-Resolution: no action X-Zone-Spam-Status: No, score=-0.084124, required=15, tests=[HFILTER_HOSTNAME_5=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.884124, FROM_HAS_DN=0, RCVD_COUNT_ONE=0, ONCE_RECEIVED=0.1] Archived-At: Subject: Re: [calsify] JSCalendar: duration normalization and weeks X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 14:00:42 -0000 This is a multi-part message in MIME format. --------------B1A142079138B83C1BF06D4C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit > Doesn't your proposal in fact require all events with isAllDay=false > to omit days and weeks from durations? It does. But I proposed it so only because I was under the impression the "proper" handling was not going to get in and I found the specified behavior --- P1D always being 24h (quoted below as 5.1.3) --- to be a poor choice. I'd be more than happy to see nominal durations for events with times (!isAllDay) be handled in the event's time zone --- like our interpretation of iCalendar seems to suggest. On 9/11/18 1:04 PM, Robert Stepanek wrote: > On Thu, Sep 6, 2018, at 13:03, Andri Möll wrote: >> No, see the actual spec >> : >>> >>> >>> 5.1.3 >>> . >>> duration >>> >>> Type: "Duration", e.g. "P2DT3H" (optional, default: "P0D") The zero >>> or positive duration of the event in absolute time (i.e. in UTC >>> time; ignoring DST shifts). >>> >>> Therefore, P1D is exactly equivalent to PT24H in the context of the >>> event duration. >> I'd be surprised if anyone pays attention to the UTC-conversion >> idiosyncrasy. It's natural, in the context of calendaring, to do >> arithmetic on date-times [objects] with time zones (for events with >> times), as you want the end time to be in the same time zone, after >> all. And it'll work just fine because +PT3H is the same in any time >> zone. +P1D however will diverge. It's an error prone idiosyncrasy I'm >> arguing should be dropped --- no P1Ds for events with times. > > Doesn't your proposal in fact require all events with isAllDay=false > to omit days and weeks from durations? > > Looking at the relevant sections of RFC 5545: > > https://tools.ietf.org/html/rfc5545#section-3.3.6 > > The duration of a week or a day depends on its position in the > calendar. In the case of discontinuities in the time scale, such > as the change from standard time to daylight time and back, the > computation of the exact duration requires the subtraction or > addition of the change of duration of the discontinuity. > > and later > > When computing an exact duration, the greatest order time > components MUST be added first > > it indeed looks to me as if there is a gap between JSCalendar and > iCalendar durations (but I'm not sure I parsing the first requirement > right). > > I'd favour to keep JSCalendar aligend with iCalendar for durations. In > my understanding that is: allow days (and weeks) for non-zero event > times, but perform the addition in the event time-zone..  For time > gaps, P1D does not equal PT24H. Probably Neil has more insight how the > JSCalendar duration spec came to its current definition? > > Cheers, > Robert > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------B1A142079138B83C1BF06D4C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Doesn't your proposal in fact require all events with isAllDay=false to omit days and weeks from durations?
It does. But I proposed it so only because I was under the impression the "proper" handling was not going to get in and I found the specified behavior --- P1D always being 24h (quoted below as 5.1.3) --- to be a poor choice. I'd be more than happy to see nominal durations for events with times (!isAllDay) be handled in the event's time zone --- like our interpretation of iCalendar seems to suggest.

On 9/11/18 1:04 PM, Robert Stepanek wrote:
On Thu, Sep 6, 2018, at 13:03, Andri Möll wrote:
No, see the actual spec:

5.1.3.  duration



   Type: "Duration", e.g.  "P2DT3H" (optional, default: "P0D")

   The zero or positive duration of the event in absolute time (i.e. in
   UTC time; ignoring DST shifts).

Therefore, P1D is exactly equivalent to PT24H in the context of the event duration.
I'd be surprised if anyone pays attention to the UTC-conversion idiosyncrasy. It's natural, in the context of calendaring, to do arithmetic on date-times [objects] with time zones (for events with times), as you want the end time to be in the same time zone, after all. And it'll work just fine because +PT3H is the same in any time zone. +P1D however will diverge. It's an error prone idiosyncrasy I'm arguing should be dropped --- no P1Ds for events with times.

Doesn't your proposal in fact require all events with isAllDay=false to omit days and weeks from durations?

Looking at the relevant sections of RFC 5545:

    
      The duration of a week or a day depends on its position in the
      calendar.  In the case of discontinuities in the time scale, such
      as the change from standard time to daylight time and back, the
      computation of the exact duration requires the subtraction or
      addition of the change of duration of the discontinuity.

and later
           
      When computing an exact duration, the greatest order time
      components MUST be added first

it indeed looks to me as if there is a gap between JSCalendar and iCalendar durations (but I'm not sure I parsing the first requirement right).

I'd favour to keep JSCalendar aligend with iCalendar for durations. In my understanding that is: allow days (and weeks) for non-zero event times, but perform the addition in the event time-zone..  For time gaps, P1D does not equal PT24H. Probably Neil has more insight how the JSCalendar duration spec came to its current definition?

Cheers,
Robert

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------B1A142079138B83C1BF06D4C-- From nobody Thu Sep 20 02:54:28 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 0C3B3128D0C; Thu, 20 Sep 2018 02:54:19 -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.84.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <153743725896.19760.5579205912151873883@ietfa.amsl.com> Date: Thu, 20 Sep 2018 02:54:19 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-07.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 09:54:19 -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-07.txt Pages : 53 Date : 2018-09-20 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-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 Thu Sep 20 02:55: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 D9459130DCD for ; Thu, 20 Sep 2018 02:55:36 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 JnFf0pcO40Qh for ; Thu, 20 Sep 2018 02:55:35 -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 556BF128D0C for ; Thu, 20 Sep 2018 02:55:35 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 5632021957 for ; Thu, 20 Sep 2018 05:55:33 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute1.internal (MEProxy); Thu, 20 Sep 2018 05:55:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=3B4esZ5ndmctOl jzU2iHMhoE+57E5pUqCjjlHIY4eVM=; b=gUR0GalXluiLYDHky1WcVw2qefrC51 wtRaZk3d1h5F6qG3GS/Zdcegac/OPXGPOAvcMMEOTIKlcwfHFIb4Id/9xx0lpOe1 IIbVZ4ZxAioYAcyxr/OxtgFGHQpkCAAKz1NtOgA/NJm1BSvrk9mjS/GBLWq8XGfJ FHau8mfRPq5TUzIlGqN6ouSYE6myjZerzkchLOgG7N7OBBjgrvuzQGu6TuMw4u/C BFQrYtE3Gz1uL1VXd2FK/hBgCIdT0iSNTpkACk118TqrdFvz12ALyZ3dig2dJCUZ zawaBKcMTQIPwpP/tx+6LdeGnagASykJiVaRiecdzZ8dI0TETj+Wo+Jw== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F3E79E83A; Thu, 20 Sep 2018 05:55:32 -0400 (EDT) Message-Id: <1ccadecc-bcae-46ac-98ac-d71787b2e4f5@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-514-g68b0d00-fmstable-20180920v2 x-jmap-identity-id: 66430872 Date: Thu, 20 Sep 2018 05:55:32 -0400 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=6ddb464538d24dce89d9f3c8134ddb26 Archived-At: Subject: [calsify] Updated JSCalendar draft version 07 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2018 09:55:37 -0000 --6ddb464538d24dce89d9f3c8134ddb26 Content-Type: text/plain All, I have just uploaded the latest iteration version 07 on the JSCalendar RFC draft for WG last call. It includes the following changes, including your feedback on the mailing list: *Main changes* * Replaced the `web` replyTo property with `other`. The iCalendar spec allows arbitrary CAL-ADDRESS values for attendees and organizer. While running our implementation of the latest JSCalendar spec draft on production data, we ran into such calendar objects. JSCalendar needs to be able to handle these non-mailto, non-HTTPs URIs. * The `email` property of the Participant object became optional (for the same reasons as the previous bullet point). The id of a Participant object in the `participants` property now must be a valid URI. * The `replyTo` URI Template replaced the `email` variable with a `participantId` variable. The allowed level for the URI template now is 2 (instead of previously 1) to support URI-encoding of the participant id. * All identifiers of calendar object subtypes except participants got redefined to use the same, simplified JSCalendar identifier scheme as outlined in section 3.2.5. *Minor changes* * Rephrased the `relatedTo` and JSTask participant `status` property definitions. * Added an example for an event with end time-zone and enriched location info. * Fixed broken iCalendar mapping table format. *Open points* * The current spec requires durations to be calculated in UTC. The iCalendar specification requires durations to be calculated in the calendar object time-zone. No consensus has been found on the mailing list, yet. I suggest to redefine durations to be calculated in the event time-zone. Cheers, Robert --6ddb464538d24dce89d9f3c8134ddb26 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
All, 
<= /div>
 
I have just uploaded the latest iteration= version 07 on the JSCalendar RFC draft for WG last call. 
<= /div>
 
It includes the following changes, includ= ing your feedback on the mailing list: 
 
Main changes 
  • Replaced the `web` re= plyTo property with `other`. The iCalendar spec allows arbitrary CAL-ADD= RESS values for attendees and organizer. While running our implementati= on of the latest JSCalendar spec draft on production data, we ran into s= uch calendar objects. JSCalendar needs to be able to handle these non-ma= ilto, non-HTTPs URIs.
  • The `email` property of the Participan= t object became optional (for the same reasons as the previous bullet po= int). The id of a Participant object in the `participants` property now = must be a valid URI.
  • The `replyTo` URI Template replaced the= `email` variable with a `participantId` variable. The allowed level for= the URI template now is 2 (instead of previously 1) to support URI-enco= ding of the participant id.
  • All identifiers of calendar obje= ct subtypes except participants got redefined to use the same, simplifie= d JSCalendar identifier scheme as outlined in section 3.2.5.
    •  
    Minor changes
    • Rephra= sed the `relatedTo` and JSTask participant `status` property definitions= . 
    • Added an example for an event with end time-zone and= enriched location info. 
    • Fixed broken iCalendar mappin= g table format. 
     
    Open poi= nts
    • The current spec requires durations to be calcu= lated in UTC. The iCalendar specification requires durations to be calcu= lated in the calendar object time-zone. No consensus has been found on t= he mailing list, yet. I suggest to redefine durations to be calculated i= n the event time-zone. 

    Cheers,&nb= sp;
    Robert 
     
    --6ddb464538d24dce89d9f3c8134ddb26-- From nobody Mon Sep 24 23:18: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 76ABD131127 for ; Mon, 24 Sep 2018 23:18:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.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 HXNLncY4fXLW for ; Mon, 24 Sep 2018 23:17:58 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (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 8B3F013107E for ; Mon, 24 Sep 2018 23:17:57 -0700 (PDT) Authentication-Results: mail.aegee.org/w8P6Hr1j016690; auth=pass (LOGIN) smtp.auth=didopalauzov@aegee.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1537856274; i=dkim+MSA-tls@aegee.org; r=y; bh=j0EDQjLxI6b4bYqX4Tmo86FAyD7tOQaI9WvnbK1auDw=; h=Subject:From:To:Date:In-Reply-To:References; b=IwAvDBsDbMgI6Y0avAB+YuQEVj6iRTviEZHQhUNeBz+XpNhqhkiyHIpD921hKFCKC V56uSFAYRAtPJxe6vnK2yYSo8DOKkSILpI6bAUJjLLCp5n3fSc0ydNDemz31iD3KD4 2iZYn4KK+T2/BA5yKRj8pRW1sr01Y2quStaHe8SYPKHm6LTW0HUfooMMDTffPLxw5Z GNzU9dprDbfZDc9dRpFcfuS/SliuUfnQhIXowQUL9JwrFSfTSHVNOfs7+twFvD+e3Y shjNCnN2yxwFNlalhgqCRiemp/Eg3PqhqzqUKfog02FFIXD5ocumhV4wNmDmtLmC9g y6xHiMZ4QvCCmc0oTX4D9HEXFLU/RI8YeXQlkmaxeVzZEFWyRkEGUlcKFiVTGi+/1n whzl884WlSSS418zbn9Jf1TCWDBiGxDLQKKI6Js+jAbs9hfiU2LJx79mmt4YU54//s naH7AKSETZ6w25Nh4zdnzezr6DPyDr2xVUNs3e9eMxAc6LGG+SNH6GLoGmYOMofeQv UOTcP6lDatkmKApvxgkskZ+ByU3gCoxtRr02P6fsBhZp99VDuQlMvW5aMs0qk2yVCY cmWKcga7RBPQVd6m+8nV2aUzCPbCOM5AeO88ePubmsQEel6dUEDX8MpTOIQ2ZPt41p AxFIYSRjvVB8W1hD8hnwnulk= Authentication-Results: mail.aegee.org/w8P6Hr1j016690; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id w8P6Hr1j016690 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 25 Sep 2018 06:17:54 GMT Message-ID: <745b6f839fd3019e940563c7b0f88296c195f53f.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: calsify@ietf.org Date: Tue, 25 Sep 2018 06:17:53 +0000 In-Reply-To: <153568537377.3324.16807132452273069111@ietfa.amsl.com> References: <153568537377.3324.16807132452273069111@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.31.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.1 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [calsify] CUTYPE: EVENT / Re: I-D Action: draft-ietf-calext-eventpub-extensions-09.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2018 06:18:01 -0000 Hello, just like a CalDAV server can host the calendars of many users and many rooms, that are discoverable with REPORT DAV:principal-property-search, the same server can host the calendars of many events. I propose adding a new CUTYPE: EVENT as part of draft-ietf-calext- eventpub-extensions. The use case is to be able to find the calendar-home-set of the event, that can consist of one or more collections, and not rely on searching of the calendar address “in non-standardized ways”. Greetings Дилян On Thu, 2018-08-30 at 20:16 -0700, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Calendaring Extensions WG of the IETF. > > Title : Event Publishing Extensions to iCalendar > Author : Michael Douglass > Filename : draft-ietf-calext-eventpub-extensions-09.txt > Pages : 32 > Date : 2018-08-30 > > Abstract: > This specification updates [RFC5545] 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-09 > https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-09 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-09 > > > 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 From nobody Wed Sep 26 02:10: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 D1427130E18 for ; Wed, 26 Sep 2018 02:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8ryQrM0bv6o for ; Wed, 26 Sep 2018 02:09:59 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C89D130DD0 for ; Wed, 26 Sep 2018 02:09:59 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 74B27B8108E; Wed, 26 Sep 2018 02:09:58 -0700 (PDT) To: bernard.desruisseaux@oracle.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, lear@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: murch@fastmail.com, calsify@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180926090958.74B27B8108E@rfc-editor.org> Date: Wed, 26 Sep 2018 02:09:58 -0700 (PDT) Archived-At: Subject: [calsify] [Technical Errata Reported] RFC5545 (5505) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 09:10:01 -0000 The following errata report has been submitted for RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5505 -------------------------------------- Type: Technical Reported by: Ken Murchison Section: 3.2.19 Original Text ------------- tzidparam = "TZID" "=" [tzidprefix] paramtext Corrected Text -------------- tzidparam = "TZID" "=" [tzidprefix] param-value Notes ----- TZID appears to be the only parameter defined 5545 whose value can not be a quoted string. This is problematic in that time zone IDs such as "GMT-03:00" are beginning to appear (note the embedded colon). RFC 6868 has no mechanism to quote a colon character, as it relies on such characters appearing within a quoted string. I see no technical reason why a TZID parameter can not be quoted, and existing implementations already accept quoted TZIDs. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5545 (draft-ietf-calsify-rfc2445bis-10) -------------------------------------- Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Publication Date : September 2009 Author(s) : B. Desruisseaux, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG From nobody Wed Sep 26 02: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 55400130E50 for ; Wed, 26 Sep 2018 02:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79gyMIDoLyDO for ; Wed, 26 Sep 2018 02:16:14 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04520130E48 for ; Wed, 26 Sep 2018 02:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3783; q=dns/txt; s=iport; t=1537953373; x=1539162973; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=BppEHzmn2HglKCZxM91J6QoLyZCGgirdh982BWfjQlE=; b=eOf+lF1+IzFgjNbfLyAHHKgLhc8zOdfxjw/KUd11vyVfofuehaYZXldd 78i2MCt80IHQwdT05Qg/3Q5EL43c1z4Kr92R99XW19Wyp+r8LgP+dOABK nPly3oE37M77ew4vEnGmTapaDd4cw0jDLN9PMP8Wj+uQMW+kk2xZ2HgaU Y=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BUAADsTatb/xbLJq1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGERG0SKIN0iHSNMAglmEkIAyOESQKEGDgUAQMBAQIBAQJ?= =?us-ascii?q?tHAyFOQEFI1YQCxgqAgJXBgEMBgIBAYMdAYIBD6JsgS6KDA+CbYgkggCBEic?= =?us-ascii?q?Mgl+BQYY+glcCiEgkhkuNUAmEAYFlikEGF4FGhFKCYYY7h3yNFYFZIYFVMxo?= =?us-ascii?q?IGxUagw0JghwMC4hahUA9MI1CAQE?= X-IronPort-AV: E=Sophos; i="5.54,305,1534809600"; d="asc'?scan'208"; a="6747390" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2018 09:16:10 +0000 Received: from [10.61.109.219] (dhcp-10-61-109-219.cisco.com [10.61.109.219]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id w8Q9G8dL008183; Wed, 26 Sep 2018 09:16:08 GMT To: RFC Errata System , bernard.desruisseaux@oracle.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com Cc: murch@fastmail.com, calsify@ietf.org References: <20180926090958.74B27B8108E@rfc-editor.org> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <983178de-f430-2115-0579-be861b198059@cisco.com> Date: Wed, 26 Sep 2018 11:16:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180926090958.74B27B8108E@rfc-editor.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tDUxVXMCfXTEYZXraGCDGkh4lbtAUxf8u" X-Outbound-SMTP-Client: 10.61.109.219, dhcp-10-61-109-219.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5505) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 09:16:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tDUxVXMCfXTEYZXraGCDGkh4lbtAUxf8u Content-Type: multipart/mixed; boundary="ajfPtzO4xhUJHHL3uGunRqOeBALa9Bl1w"; protected-headers="v1" From: Eliot Lear To: RFC Errata System , bernard.desruisseaux@oracle.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com Cc: murch@fastmail.com, calsify@ietf.org Message-ID: <983178de-f430-2115-0579-be861b198059@cisco.com> Subject: Re: [Technical Errata Reported] RFC5545 (5505) References: <20180926090958.74B27B8108E@rfc-editor.org> In-Reply-To: <20180926090958.74B27B8108E@rfc-editor.org> --ajfPtzO4xhUJHHL3uGunRqOeBALa9Bl1w Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US While I agree with Ken in principle, I'm a little nervous about the backward compatibility implications here, if parsers are now not expecting quoted text. On 26.09.18 11:09, RFC Errata System wrote: > The following errata report has been submitted for RFC5545, > "Internet Calendaring and Scheduling Core Object Specification (iCalend= ar)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5505 > > -------------------------------------- > Type: Technical > Reported by: Ken Murchison > > Section: 3.2.19 > > Original Text > ------------- > tzidparam =3D "TZID" "=3D" [tzidprefix] paramtext > > > Corrected Text > -------------- > tzidparam =3D "TZID" "=3D" [tzidprefix] param-value > > > Notes > ----- > TZID appears to be the only parameter defined 5545 whose value can not = be a quoted string. This is problematic in that time zone IDs such as "G= MT-03:00" are beginning to appear (note the embedded colon). RFC 6868 ha= s no mechanism to quote a colon character, as it relies on such character= s appearing within a quoted string. I see no technical reason why a TZID= parameter can not be quoted, and existing implementations already accept= quoted TZIDs. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 > > -------------------------------------- > RFC5545 (draft-ietf-calsify-rfc2445bis-10) > -------------------------------------- > Title : Internet Calendaring and Scheduling Core Object S= pecification (iCalendar) > Publication Date : September 2009 > Author(s) : B. Desruisseaux, Ed. > Category : PROPOSED STANDARD > Source : Calendaring and Scheduling Standards Simplificati= on > Area : Applications > Stream : IETF > Verifying Party : IESG > --ajfPtzO4xhUJHHL3uGunRqOeBALa9Bl1w-- --tDUxVXMCfXTEYZXraGCDGkh4lbtAUxf8u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlurTlkACgkQh7ZrRtnS ejO5PQgAjJz5XTITnlTZeOb3TXTMkBjlHux1fY2ImMAPDkdibwHnGpoLQfS3KXWs KVH3aH3DIpjWxrcLsx94M2rQpE9Fi9SCg4YQUvRdqQiP0h5YbI9fahmepEGTmgu4 rIPJ69p6jn+UTcZyKJ++a2ByI63DPjn8Nou+YNVVjx5cT5Nj6d93k3ylXeGHsX/p 9AVokLPXNz5/lFghVgoqw11adrplbt6ijTlT/4co15Z2W7K2awASXonB8R0JKMyO 6OV1fV76YgBaJr4SO5Um5EfMJQaO0qqC0NV891k+xF73RXEUdMmxOaBpSdf5R2Jo MC+xT+3pqC+cIdFzAk2PAqrFsYJfAA== =CIjr -----END PGP SIGNATURE----- --tDUxVXMCfXTEYZXraGCDGkh4lbtAUxf8u-- From nobody Wed Sep 26 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 65353130E81 for ; Wed, 26 Sep 2018 04:00:08 -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, 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 d5GinE9OSjOF for ; Wed, 26 Sep 2018 04:00:06 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (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 AD014130E7F for ; Wed, 26 Sep 2018 04:00:05 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id y13-v6so1818129wmi.1 for ; Wed, 26 Sep 2018 04:00:05 -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=kI4xFfLFaiQq/67upRkOVxF+WQa439Mt8r+P68m1iiY=; b=a/Ee+eW/I51L+0D4vknwwPvvlc4IY2slajUFC3rMMiJwKNG9iTP5XUiXay6mjqj/pS EuwgVaQzrrxu3RyfTesB2LJe4KoNqDZtX5s1jc7Ju9jqintNeU/bjh+MpGU76L3HNGFM ny/+k83K1LUxMvO8JC6XJtsfFQFWGRgO98LixkI0t0KgkljmMjlVd7wBW6bWH7oMKbV2 92QOYzxXpurJgNH3Fz6UiBK33+DBv3DPpCV+aacpNt8zCrhVyXrzPeQK3gD4JlklfBx0 sk6eOY+DlEeIexL0Xclw0ik20QPzEYBRH4RGLnMIrE5Blwvp/g4DH8wa8+U9gnC3uUvo lBxw== 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=kI4xFfLFaiQq/67upRkOVxF+WQa439Mt8r+P68m1iiY=; b=EAxVln8GdYmA83KyPA9FOjgNUZeC0oOFWA5s6dgFU4sh9hmstznJhAEXBfp7XzOsqV osCdfJBvoMFQvQTVCDUixGTYstP8OrNielf5EtNuA56hKGPOvwkigXjXozLRwlt24CPm 1c7Fr8RCFoGYzvbOQhv7mRtJjFw2Y5cLQwAaSQc+7UdGU0je8C35rGWOEoz0ANHiGTOb pLxgOJS2JHiwbKepym9eWZZF2tZA+criBVB9JW3iS4vVO1ltX8tQDynAVKBhm+CnCH2Y p3K3KBDr7TFV8wMP3P88Vj0vPZCBAPRzOC+FTF2zfWW4Jn3qDhIuddXn5oj2BbQbrnX/ hOLg== X-Gm-Message-State: ABuFfojGzIEhwYRlzorpxBtVevkUfFksy1EkGHTkzjNOGtX63qBCoFtR MK4j4b7pZwdFDyxLPESF1uEAxCQq X-Google-Smtp-Source: ACcGV60XhrzgX8EAEZvT6TZ2Hp7Z1NAMZx8+WRAQ15ltvFUcZoYr+JJrOBQv60uVNixjafRPNXFo4A== X-Received: by 2002:a1c:a683:: with SMTP id p125-v6mr3945822wme.14.1537959603670; Wed, 26 Sep 2018 04:00:03 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (et-0-97.gw-nat.bs.kae.de.oneandone.net. [212.227.19.105]) by smtp.googlemail.com with ESMTPSA id z13sm5102316wrw.19.2018.09.26.04.00.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Sep 2018 04:00:02 -0700 (PDT) To: calsify@ietf.org References: <20180926090958.74B27B8108E@rfc-editor.org> <983178de-f430-2115-0579-be861b198059@cisco.com> From: Michael Douglass Message-ID: Date: Wed, 26 Sep 2018 13:00:02 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <983178de-f430-2115-0579-be861b198059@cisco.com> Content-Type: multipart/alternative; boundary="------------9880B201BA87577C2C1C8C78" Content-Language: en-US Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5505) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 11:00:08 -0000 This is a multi-part message in MIME format. --------------9880B201BA87577C2C1C8C78 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 9/26/18 11:16, Eliot Lear wrote: > While I agree with Ken in principle, I'm a little nervous about the > backward compatibility implications here, if parsers are now not > expecting quoted text. My belief is that parsers are already expecting this. Certainly ical4j and libical already accept quoted values. In any case it's broken as it stands. Parameter escaping isn't an option as it assumes parameter value quoting is an option. > > > On 26.09.18 11:09, RFC Errata System wrote: >> The following errata report has been submitted for RFC5545, >> "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata/eid5505 >> >> -------------------------------------- >> Type: Technical >> Reported by: Ken Murchison >> >> Section: 3.2.19 >> >> Original Text >> ------------- >> tzidparam = "TZID" "=" [tzidprefix] paramtext >> >> >> Corrected Text >> -------------- >> tzidparam = "TZID" "=" [tzidprefix] param-value >> >> >> Notes >> ----- >> TZID appears to be the only parameter defined 5545 whose value can not be a quoted string. This is problematic in that time zone IDs such as "GMT-03:00" are beginning to appear (note the embedded colon). RFC 6868 has no mechanism to quote a colon character, as it relies on such characters appearing within a quoted string. I see no technical reason why a TZID parameter can not be quoted, and existing implementations already accept quoted TZIDs. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC5545 (draft-ietf-calsify-rfc2445bis-10) >> -------------------------------------- >> Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) >> Publication Date : September 2009 >> Author(s) : B. Desruisseaux, Ed. >> Category : PROPOSED STANDARD >> Source : Calendaring and Scheduling Standards Simplification >> Area : Applications >> Stream : IETF >> Verifying Party : IESG >> > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------9880B201BA87577C2C1C8C78 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



    On 9/26/18 11:16, Eliot Lear wrote:
    While I agree with Ken in principle, I'm a little nervous about the
backward compatibility implications here, if parsers are now not
expecting quoted text.
    My belief is that parsers are already expecting this. Certainly ical4j and libical already accept quoted values.

    In any case it's broken as it stands. Parameter escaping isn't an option as it assumes parameter value quoting is an option. 
    

On 26.09.18 11:09, RFC Errata System wrote:

    The following errata report has been submitted for RFC5545,
"Internet Calendaring and Scheduling Core Object Specification (iCalendar)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5505

--------------------------------------
Type: Technical
Reported by: Ken Murchison <murch@fastmail.com>

Section: 3.2.19

Original Text
-------------
       tzidparam  = "TZID" "=" [tzidprefix] paramtext


Corrected Text
--------------
       tzidparam  = "TZID" "=" [tzidprefix] param-value


Notes
-----
TZID appears to be the only parameter defined 5545 whose value can not be a quoted string.  This is problematic in that time zone IDs such as "GMT-03:00" are beginning to appear (note the embedded colon).  RFC 6868 has no mechanism to quote a colon character, as it relies on such characters appearing within a quoted string.  I see no technical reason why a TZID parameter can not be quoted, and existing implementations already accept quoted TZIDs.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5545 (draft-ietf-calsify-rfc2445bis-10)
--------------------------------------
Title               : Internet Calendaring and Scheduling Core Object Specification (iCalendar)
Publication Date    : September 2009
Author(s)           : B. Desruisseaux, Ed.
Category            : PROPOSED STANDARD
Source              : Calendaring and Scheduling Standards Simplification
Area                : Applications
Stream              : IETF
Verifying Party     : IESG


    



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

    --------------9880B201BA87577C2C1C8C78-- From nobody Wed Sep 26 04:01: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 B4D19130E84 for ; Wed, 26 Sep 2018 04:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqxyS0N1kz8O for ; Wed, 26 Sep 2018 04:01:13 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17131130E7F for ; Wed, 26 Sep 2018 04:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9613; q=dns/txt; s=iport; t=1537959673; x=1539169273; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=zG1rdTFZOywQqecCa4AiYI0Y+JxDCupFMwoOy8Fy4qs=; b=gEFmldasBXCNhrkA89lbI5rubpgSosWLi3+5W9Y+NHIV3OtMPlgLxxm/ PV9DUGDAOTZeYYvyEsF5yQuRhbJdA+2WtsMJ8vfvSqA5nUm6p/+sZSgzA 2FBc2559fE5H6gOmJwazP9FHAFLHS25odn65s+R9Lp5cNRHrfIkgiUfRK o=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbAACcZqtb/xbLJq0WAUIZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBAYREbRIog3SIdI0wLZEThzYIAxgBCoQDRgKEGzgUAQM?= =?us-ascii?q?BAQIBAQJtHAyFOQEBAQMBASFLGwsOCioCAicwBgEMBgIBAYMdAYIBD4VjnHy?= =?us-ascii?q?BLh+Jbg+CbYgkggCBEieCa4FBgVoBAYRiglcCiEgkhkuNUAmEAYFlikEGF4F?= =?us-ascii?q?GhFKCYYY7h3yNFYFZIYFVMxoIGxUaIYJsCYIcDAuIWoVAPTCNQgEB?= X-IronPort-AV: E=Sophos;i="5.54,306,1534809600"; d="asc'?scan'208,217";a="6749765" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2018 11:01:10 +0000 Received: from [10.61.109.219] (dhcp-10-61-109-219.cisco.com [10.61.109.219]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w8QB19hA022340; Wed, 26 Sep 2018 11:01:09 GMT To: Michael Douglass , calsify@ietf.org References: <20180926090958.74B27B8108E@rfc-editor.org> <983178de-f430-2115-0579-be861b198059@cisco.com> From: Eliot Lear Openpgp: preference=signencrypt Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ== Message-ID: <52b5ebfd-cf74-d765-3ea6-e5c30d071465@cisco.com> Date: Wed, 26 Sep 2018 13:01:16 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="REb7lCISU7Bohbl0npLst3XbieQbnlqWY" X-Outbound-SMTP-Client: 10.61.109.219, dhcp-10-61-109-219.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5505) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 11:01:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --REb7lCISU7Bohbl0npLst3XbieQbnlqWY Content-Type: multipart/mixed; boundary="rOhGQ9x81V6chspE9Gye8trBSPIHFdPTr"; protected-headers="v1" From: Eliot Lear To: Michael Douglass , calsify@ietf.org Message-ID: <52b5ebfd-cf74-d765-3ea6-e5c30d071465@cisco.com> Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5505) References: <20180926090958.74B27B8108E@rfc-editor.org> <983178de-f430-2115-0579-be861b198059@cisco.com> In-Reply-To: --rOhGQ9x81V6chspE9Gye8trBSPIHFdPTr Content-Type: multipart/alternative; boundary="------------5E468309A7DDCD6B70DF0480" Content-Language: en-US This is a multi-part message in MIME format. --------------5E468309A7DDCD6B70DF0480 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Would it make sense for folks at Calconnect to chime in on this? On 26.09.18 13:00, Michael Douglass wrote: > > > > On 9/26/18 11:16, Eliot Lear wrote: >> While I agree with Ken in principle, I'm a little nervous about the >> backward compatibility implications here, if parsers are now not >> expecting quoted text. > My belief is that parsers are already expecting this. Certainly ical4j > and libical already accept quoted values. > > In any case it's broken as it stands. Parameter escaping isn't an > option as it assumes parameter value quoting is an option. >> On 26.09.18 11:09, RFC Errata System wrote: >>> The following errata report has been submitted for RFC5545, >>> "Internet Calendaring and Scheduling Core Object Specification (iCale= ndar)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata/eid5505 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Ken Murchison >>> >>> Section: 3.2.19 >>> >>> Original Text >>> ------------- >>> tzidparam =3D "TZID" "=3D" [tzidprefix] paramtext >>> >>> >>> Corrected Text >>> -------------- >>> tzidparam =3D "TZID" "=3D" [tzidprefix] param-value >>> >>> >>> Notes >>> ----- >>> TZID appears to be the only parameter defined 5545 whose value can no= t be a quoted string. This is problematic in that time zone IDs such as = "GMT-03:00" are beginning to appear (note the embedded colon). RFC 6868 = has no mechanism to quote a colon character, as it relies on such charact= ers appearing within a quoted string. I see no technical reason why a TZ= ID parameter can not be quoted, and existing implementations already acce= pt quoted TZIDs. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party =20 >>> can log in to change the status and edit the report, if necessary.=20 >>> >>> -------------------------------------- >>> RFC5545 (draft-ietf-calsify-rfc2445bis-10) >>> -------------------------------------- >>> Title : Internet Calendaring and Scheduling Core Object= Specification (iCalendar) >>> Publication Date : September 2009 >>> Author(s) : B. Desruisseaux, Ed. >>> Category : PROPOSED STANDARD >>> Source : Calendaring and Scheduling Standards Simplifica= tion >>> Area : Applications >>> Stream : IETF >>> Verifying Party : IESG >>> >> >> >> _______________________________________________ >> 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 --------------5E468309A7DDCD6B70DF0480 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

    Would it make sense for folks at Calconnect to chime in on this?


    On 26.09.18 13:00, Michael Douglass wrote:



    On 9/26/18 11:16, Eliot Lear wrote:<= br> 
    While I agree with Ken in principle, I'm a little =
nervous about the
backward compatibility implications here, if parsers are now not
expecting quoted text.
    My belief is that parsers are already expecting this. Certainly ical4j and libical already accept quoted values.

    In any case it's broken as it stands. Parameter escaping isn't an option as it assumes parameter value quoting is an option. 
    On 26.09.18 11:09, RFC Errata System wrote:

    The following errata report has been submitted f=
or RFC5545,
"Internet Calendaring and Scheduling Core Object Specification (iCalendar=
)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid=
5505

--------------------------------------
Type: Technical
Reported by: Ken Murchison <murch@fastmail.com&g=
t;

Section: 3.2.19

Original Text
-------------
       tzidparam  =3D "TZID" "=3D" [tzidprefix] paramtext


Corrected Text
--------------
       tzidparam  =3D "TZID" "=3D" [tzidprefix] param-value


Notes
-----
TZID appears to be the only parameter defined 5545 whose value can not be=
 a quoted string.  This is problematic in that time zone IDs such as "GMT=
-03:00" are beginning to appear (note the embedded colon).  RFC 6868 has =
no mechanism to quote a colon character, as it relies on such characters =
appearing within a quoted string.  I see no technical reason why a TZID p=
arameter can not be quoted, and existing implementations already accept q=
uoted TZIDs.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party =20
can log in to change the status and edit the report, if necessary.=20

--------------------------------------
RFC5545 (draft-ietf-calsify-rfc2445bis-10)
--------------------------------------
Title               : Internet Calendaring and Scheduling Core Object Spe=
cification (iCalendar)
Publication Date    : September 2009
Author(s)           : B. Desruisseaux, Ed.
Category            : PROPOSED STANDARD
Source              : Calendaring and Scheduling Standards Simplification=

Area                : Applications
Stream              : IETF
Verifying Party     : IESG




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




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

    --------------5E468309A7DDCD6B70DF0480-- --rOhGQ9x81V6chspE9Gye8trBSPIHFdPTr-- --REb7lCISU7Bohbl0npLst3XbieQbnlqWY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlurZvwACgkQh7ZrRtnS ejODaAf9HkGtT932MJfUUd+/zlAUNYHB6I+Wzz7MjjK1XbSaHt14sEZt3chxwnBh OeFt+vnzDCqfIkjaRvToOR+eAZOSZSHhmwBt0QavoWCxwKWM4cTvMnp8r7a+X4Os Au9rYla2zfb44IhWhNueTV1eoADCBlB8Dab2/RFkahswhEbxB4edICoHPDHDgCbS fndFlDsbhZAO1UJDdEbrgeB1b6nIbn8IuuJdWPXXf7yf/YLpiLtkld6/Npe7lWAF vKFcpFYg9ROpyew6gl+aDvpYM76f6Syry7QTd6ou7cEPAm2eRJwZeECUjp4SXrO6 rdolzNvNuh/eZpwbxvp2eK6aqxhFLg== =SrPZ -----END PGP SIGNATURE----- --REb7lCISU7Bohbl0npLst3XbieQbnlqWY-- From nobody Wed Sep 26 04:34:50 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 A4A59130E84 for ; Wed, 26 Sep 2018 04:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=youcanbook-me.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 eo-eh-01Qmrp for ; Wed, 26 Sep 2018 04:34:46 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC47C12426A for ; Wed, 26 Sep 2018 04:34:45 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id c14-v6so1896578wmb.4 for ; Wed, 26 Sep 2018 04:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=youcanbook-me.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KzH54WKclmUHpOWCjPLZc0PDczYco6GYsniiEl9s8k8=; b=zfORGgrlr/xGdcBH6j0V57R/35NrMR2rriguIKbbIVIpmQP5Fyque/4mv5bkqnP32S 46G12s7rdqjBpDFaZHszmg77fs8PpHHONUrKmLTzvu+/TynAQ55BZ/xVfIobz40xvPcF NQc33vYBMc6by6xmf6OfbqOGU3jTSO1zQJQ324vakRVgYIcdtG8iPyCgGvvA2S3Mn0nK Ecltg5Mlp/jft+cIhsRW0YwL0oxhyDzuQApKryiMktAyT0p1p9rRAGQaqhUu94OrayMa lQyg+O3AkQDTIieGc/xttDfMmLDNI4KskGKFgJqnKSZjinYyUzeudml6wpI5nGJwIIxb jSiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KzH54WKclmUHpOWCjPLZc0PDczYco6GYsniiEl9s8k8=; b=O0pSTQA2wFcZy6tYnQalaeTa6L/FgcCro4sN+u+7yQQ35fyj1gEhHtxdzKND9vzh/y bkKtLEhCdOstTSZfYM2QXjQWl/0cVqMTcbWIHeqjPt6A7l8NbruCaSmPwFJ+atyXkm+/ S0ZS5asdyj4n7lmevfXyZrKoNmqC8r6lUvDV9KNxKTOZkfoKr2Sj0ilr+kqLQXr0QoP9 yKJqjIUfvlh01okNVwVxIDv/9fuHWGd0VBQoRK6ZzYLY/wDOBsaEq+PyuxAoJnQ7oKeC qIiBYQ5GUfdYW647FFD+GOuZwfIu6Scurgm+Ewh/uzjxfPqWMbPMEq4WClRGZhoAKMeZ GthA== X-Gm-Message-State: ABuFfoiI+ELDA0GY4agISBAo4IwpH3tlson7BPLa8QIc6cmCQoOde/tj Ss7kDtAhJOA5KKalf/ScfJvMWYAn6p+yfnORX+qeopGjRBa3 X-Google-Smtp-Source: ACcGV62GeqYc4/WWiCrGZwaz9pyqJLQJYhF1Gb1bmBVqRl20is+J868BWgjnwBPvqKcviy3O5yJtx/3jgb3kMZjKDFM= X-Received: by 2002:a1c:1802:: with SMTP id 2-v6mr4037303wmy.81.1537961683986; Wed, 26 Sep 2018 04:34:43 -0700 (PDT) MIME-Version: 1.0 References: <20180926090958.74B27B8108E@rfc-editor.org> <983178de-f430-2115-0579-be861b198059@cisco.com> <52b5ebfd-cf74-d765-3ea6-e5c30d071465@cisco.com> In-Reply-To: <52b5ebfd-cf74-d765-3ea6-e5c30d071465@cisco.com> From: Keith Harris Date: Wed, 26 Sep 2018 13:34:31 +0200 Message-ID: To: lear@cisco.com Cc: mikeadouglass@gmail.com, calsify@ietf.org Content-Type: multipart/alternative; boundary="000000000000da45390576c49bb5" Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5505) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 11:34:49 -0000 --000000000000da45390576c49bb5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Actually, this topic is one that came up as part of a conversation this morning at the CalConnect confernce here in Germany this week. I had been asking the group for help about how to solve a problem (parsing the line DTSTART;TZID=3DGMT-03:00:20180822T075501 from a partner organisation). We had a small group discussion and Ken and Mike were advising me to tell our partner to quote the timezone when they spotted the issue. Thanks, Keith Harris https://youcanbook.me On Wed, 26 Sep 2018 at 13:01, Eliot Lear wrote: > Would it make sense for folks at Calconnect to chime in on this? > > On 26.09.18 13:00, Michael Douglass wrote: > > > > On 9/26/18 11:16, Eliot Lear wrote: > > While I agree with Ken in principle, I'm a little nervous about the > backward compatibility implications here, if parsers are now not > expecting quoted text. > > My belief is that parsers are already expecting this. Certainly ical4j an= d > libical already accept quoted values. > > In any case it's broken as it stands. Parameter escaping isn't an option > as it assumes parameter value quoting is an option. > > > On 26.09.18 11:09, RFC Errata System wrote: > > The following errata report has been submitted for RFC5545, > "Internet Calendaring and Scheduling Core Object Specification (iCalendar= )". > > -------------------------------------- > You may review the report below and at:http://www.rfc-editor.org/errata/e= id5505 > > -------------------------------------- > Type: Technical > Reported by: Ken Murchison > > Section: 3.2.19 > > Original Text > ------------- > tzidparam =3D "TZID" "=3D" [tzidprefix] paramtext > > > Corrected Text > -------------- > tzidparam =3D "TZID" "=3D" [tzidprefix] param-value > > > Notes > ----- > TZID appears to be the only parameter defined 5545 whose value can not be= a quoted string. This is problematic in that time zone IDs such as "GMT-0= 3:00" are beginning to appear (note the embedded colon). RFC 6868 has no m= echanism to quote a colon character, as it relies on such characters appear= ing within a quoted string. I see no technical reason why a TZID parameter= can not be quoted, and existing implementations already accept quoted TZID= s. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5545 (draft-ietf-calsify-rfc2445bis-10) > -------------------------------------- > Title : Internet Calendaring and Scheduling Core Object Spe= cification (iCalendar) > Publication Date : September 2009 > Author(s) : B. Desruisseaux, Ed. > Category : PROPOSED STANDARD > Source : Calendaring and Scheduling Standards Simplification > Area : Applications > Stream : IETF > Verifying Party : IESG > > > > > _______________________________________________ > calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo= /calsify > > > > > _______________________________________________ > calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo= /calsify > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --000000000000da45390576c49bb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Actually, this topic is one that came up = as part of a conversation this morning at the CalConnect confernce here in = Germany this week.=C2=A0

    I= had been asking the group for help about how to solve a problem (parsing t= he line=C2=A0DTSTART;TZID=3DGMT-03:00:20180822T075501 from a partner organi= sation). We had a small group discussion and Ken and Mike were advising me = to tell our partner to quote the timezone when they spotted the issue.

    Thanks,
    =
    =

    On Wed, 26 = Sep 2018 at 13:01, Eliot Lear <lear@ci= sco.com> wrote:
    =20 =20 =20

    Would it make sense for folks at Calconnect to chime in on this?


    On 26.09.18 13:00, = Michael Douglass wrote:
    =20



    On 9/26/18 11:16,= Eliot Lear wrote:
    While I agree with Ken in principle, I'm a little nervous =
about the
backward compatibility implications here, if parsers are now not
expecting quoted text.
    My belief is that parsers are already expecting this. Certainly ical4j and libical already accept quoted values.

    In any case it's broken as it stands. Parameter escaping isn'= t an option as it assumes parameter value quoting is an option. 
    On 26.09.18 11:09, RFC Errata System wrote:

    The following errata report has been submitted for RFC5545,
"Internet Calendaring and Scheduling Core Object Specification (iCalen=
dar)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/=
errata/eid5505

--------------------------------------
Type: Technical
Reported by: Ken Murchison <murch@fast=
mail.com>

Section: 3.2.19

Original Text
-------------
       tzidparam  =3D "TZID" "=3D" [tzidprefix] paramte=
xt


Corrected Text
--------------
       tzidparam  =3D "TZID" "=3D" [tzidprefix] param-v=
alue


Notes
-----
TZID appears to be the only parameter defined 5545 whose value can not be a=
 quoted string.  This is problematic in that time zone IDs such as "GM=
T-03:00" are beginning to appear (note the embedded colon).  RFC 6868 =
has no mechanism to quote a colon character, as it relies on such character=
s appearing within a quoted string.  I see no technical reason why a TZID p=
arameter can not be quoted, and existing implementations already accept quo=
ted TZIDs.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple=
ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party =20
can log in to change the status and edit the report, if necessary.=20

--------------------------------------
RFC5545 (draft-ietf-calsify-rfc2445bis-10)
--------------------------------------
Title               : Internet Calendaring and Scheduling Core Object Speci=
fication (iCalendar)
Publication Date    : September 2009
Author(s)           : B. Desruisseaux, Ed.
Category            : PROPOSED STANDARD
Source              : Calendaring and Scheduling Standards Simplification
Area                : Applications
Stream              : IETF
Verifying Party     : IESG




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




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

    _______________________________________________
    calsify mailing list
    calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
    --000000000000da45390576c49bb5-- From nobody Wed Sep 26 07:27:41 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 88A10130EB2 for ; Wed, 26 Sep 2018 07:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8bcqyUUuPdf for ; Wed, 26 Sep 2018 07:27:39 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id EAA60124BE5 for ; Wed, 26 Sep 2018 07:27:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 64D8CA6BC3C3; Wed, 26 Sep 2018 10:27:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmcHq7gIJzXr; Wed, 26 Sep 2018 10:27:38 -0400 (EDT) Received: from [17.44.178.182] (unknown [17.44.178.182]) by daboo.name (Postfix) with ESMTPSA id 81B84A6BC3B3; Wed, 26 Sep 2018 10:27:37 -0400 (EDT) Date: Wed, 26 Sep 2018 10:27:33 -0400 From: Cyrus Daboo To: Michael Douglass , calsify@ietf.org Message-ID: <19EFCA1E91A6F59ABAE023F7@cyrus.local> In-Reply-To: References: <20180926090958.74B27B8108E@rfc-editor.org> <983178de-f430-2115-0579-be861b198059@cisco.com> X-Mailer: Mulberry/4.1.0b1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1553 Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5505) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 14:27:41 -0000 Hi Michael, --On September 26, 2018 at 1:00:02 PM +0200 Michael Douglass wrote: > My belief is that parsers are already expecting this. Certainly ical4j > and libical already accept quoted values. > > In any case it's broken as it stands. Parameter escaping isn't an option > as it assumes parameter value quoting is an option. I agree this should be fixed, but the proposed change in the erratum is wrong. This was the proposed new definition: tzidparam = "TZID" "=" [tzidprefix] param-value That does not work because it would allow the optional tzidprefix (which is a single "/" character) to appear before the first quote of any quoted string. I think you really need: tzidparam = "TZID" "=" ([tzidprefix] paramtext) / (DQUOTE [tzidprefix] *QSAFE-CHAR DQUOTE) That ensures the tzidprefix appears inside the quoted string, if that construct is used. That said, I don't think I have ever seen tzidprefix being used. It was meant to be used to indicate the the ID was from a globally defined registry - well we have that now (IANA tzdb) and we aren't using the prefix. I would suggest any future revision of 5545 should drop tzidprefix as a formal syntax element, and instead just mention that the tzid value may be prefixed. FYI I checked my 5545 code and all implementations parse and generate paramaters based on the generic definition of a parameter: param = param-name "=" param-value *("," param-value) So a quoted TZID would be fine. -- Cyrus Daboo From nobody Wed Sep 26 07:33: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 8BC7F130EB2 for ; Wed, 26 Sep 2018 07:33:20 -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=OzIRDgrq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=i0dKxcx5 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 fjKxunRCQ2bv for ; Wed, 26 Sep 2018 07:33:19 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8D9130EAB for ; Wed, 26 Sep 2018 07:33:19 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id ADFE6262 for ; Wed, 26 Sep 2018 10:33:16 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 26 Sep 2018 10:33:16 -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= fm1; bh=Wbt6axNXAjSVJ93q8GWYPpAyuwEIJGUA0Qz+ywPjkjs=; b=OzIRDgrq XjVdQNtWnNa5KI0Czgr0naSKsHCKDggLcKvJ7Yma/LoYECoL7qnczzP6SR+2w15A hzMs/2jUwhQ7MxAHtNV3x/smrmyLGzZmEYi8LWjgHFW2xuX86DfhiRaph7FzDWTe e05lqZXHJzMYvsO5a1I12h62YdtMrSyiuzwIffblx+yfzZlNmEXbm3Cg6yNUaQM8 ajBUaQFl66qOGi6KC+aC4AKnblnzDiheGhlV66/Jam7fD2/GXKEfyApK6P7/LDTl /FY2PxCzbUTTXCHnah4ZEQUzT0hcN3mqr8h+cJWffwaTxCKUojC/4/0I6iN/ssps le5PaoyHBPjEdQ== 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=fm3; bh=Wbt6axNXAjSVJ93q8GWYPpAyuwEIJ GUA0Qz+ywPjkjs=; b=i0dKxcx5qLeAwAa0pPXr6IySP09OnzJxTbOnS0sD8e4kq 8GJ2FNzFvJNObOoENyX/of9yHYMyqXibkaKohUl1Tm69rQ4xHV+EDQktJ1nRdNls YLVTePirqLqrWzieFD9VhhtsleMl7Q8dvb04CNADL59Z6Yo+g7/mY9GEbm1Zq59W 3At3LicEJVbkbwJN8wP9naWulLGP54WgtImWeGtEZNJSCSBbaaM8VSIRnPNYPziu R7iuJDqRi6IHCzobRPb8CmYdENMyyTVYMxvdr/aqmjwMjRnb9s9ZpQl8pLaYWaq9 QEBBTZB+aXVwZlmYSC9ewumVkZfBh/rdwNPha/KWw== X-ME-Proxy: X-ME-Sender: Received: from localhost.localdomain (et-0-97.gw-nat.bs.kae.de.oneandone.net [212.227.19.105]) by mail.messagingengine.com (Postfix) with ESMTPA id AA57F102D2 for ; Wed, 26 Sep 2018 10:33:15 -0400 (EDT) To: calsify@ietf.org References: <20180926090958.74B27B8108E@rfc-editor.org> <983178de-f430-2115-0579-be861b198059@cisco.com> <19EFCA1E91A6F59ABAE023F7@cyrus.local> From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Wed, 26 Sep 2018 10:33:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <19EFCA1E91A6F59ABAE023F7@cyrus.local> Content-Type: multipart/mixed; boundary="------------AEE29140DCE1D684AEC66FF0" Content-Language: en-US Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5505) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2018 14:33:20 -0000 This is a multi-part message in MIME format. --------------AEE29140DCE1D684AEC66FF0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/26/18 10:27 AM, Cyrus Daboo wrote: > Hi Michael, > > --On September 26, 2018 at 1:00:02 PM +0200 Michael Douglass > wrote: > >> My belief is that parsers are already expecting this. Certainly ical4j >> and libical already accept quoted values. >> >> In any case it's broken as it stands. Parameter escaping isn't an option >> as it assumes parameter value quoting is an option. > > I agree this should be fixed, but the proposed change in the erratum > is wrong. This was the proposed new definition: > >       tzidparam  = "TZID" "=" [tzidprefix] param-value > > That does not work because it would allow the optional tzidprefix > (which is a single "/" character) to appear before the first quote of > any quoted string. I think you really need: > > tzidparam  = "TZID" "=" ([tzidprefix] paramtext) / >                        (DQUOTE [tzidprefix] *QSAFE-CHAR DQUOTE) > > That ensures the tzidprefix appears inside the quoted string, if that > construct is used. Correct.  I was careless in not considering the prefix when I posted the errata.  Can the errata be augmented as suggested by Cyrus, or does it need to be rejected and a new errata submitted? -- Ken Murchison Cyrus Development Team FastMail US LLC --------------AEE29140DCE1D684AEC66FF0 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------AEE29140DCE1D684AEC66FF0-- From nobody Wed Sep 26 18:46: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 8449D130D7A for ; Wed, 26 Sep 2018 18:46:41 -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=JygqG/yx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lApZILDk 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 L4adc0k5Lefn for ; Wed, 26 Sep 2018 18:46:39 -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 B5536127AC2 for ; Wed, 26 Sep 2018 18:46:39 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id F0CB621F39 for ; Wed, 26 Sep 2018 21:46:38 -0400 (EDT) Received: from imap22 ([10.202.2.72]) by compute6.internal (MEProxy); Wed, 26 Sep 2018 21:46:38 -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=fm3; bh=5sh0DdGXV+ZPQM6/r+uZr99elB0OVBVEPaC99BTQ/ T4=; b=JygqG/yxho5/4WDmgGHyIaulsfK3AJbj1HFkkYAH3L+UHnfevlrZifZn/ zuIeeWbJG5yxNzt/Srw/IWwFK9kth3dztU3RxOvi2x8FPZa7BGstUMlIcEGxZ6ck VlaGH28FaPd8H8xcn+/9hUV7lk3nPK/l4cNrap79+i+avpWVPbt3lVqbf8tCsxXo la/xAYSI+LkKuNkZvkktaUqXYSRsTMlOgiHorSGcsggcR/gq1w9qyq7G2eSQV8dV QFyWyfO4FSNqhyxcp/E4lhl5jVgP/R/nN+9bgwY3y8fbsO+r4OkmKxX1qnggAs1F f4+12MowrzWf5LalsdSRbol3t32Dg== 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=fm3; bh=5sh0DdGXV+ZPQM6/r+uZr99elB0OVBVEPaC99BTQ/ T4=; b=lApZILDk0Nqff5O2KnHdTBhVPyeGWhBGWRV8CellAErYQYmPtfWCtT/TL 80XejmaOkEAqxP/7WZxsSkvDGAP/kg9w92Js7BIGnD6KRxcWZqWedZ7ddeHK5WAO Q8gL83AYtcX05+d0/R8XB3IaL89vHE2NtLQ1rBCnnLPDgKwuS/XpQuQDZCrSKDyc mnV/iZH50vgXsJIl5QGhTqh2GFQZeuQCaoms1DtfRcHjuqLGH6bn2u7hrB6YrCaC WYvZTrS1SwN2xP4+Ue/eIVAA3Li9qWQjHmSwthb0eNMqSVV0wPjfmSNoGr3E7Lt6 NG7IF0oEsufan6O2z14IwnSJHpnvA== X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 63A8EE311; Wed, 26 Sep 2018 21:46:38 -0400 (EDT) Message-Id: <9cadcdb8-af01-4350-91b3-80c77ae8674a@sloti22d1t06> User-Agent: Cyrus-JMAP/3.1.5-524-g68ca53c-fmnext-20180924v1 X-Me-Personality: 64588216 In-Reply-To: <1ccadecc-bcae-46ac-98ac-d71787b2e4f5@sloti22d1t06> References: <1ccadecc-bcae-46ac-98ac-d71787b2e4f5@sloti22d1t06> Date: Wed, 26 Sep 2018 21:46:37 -0400 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=c42c01ec1f3047df829663d8eb342ef7 Archived-At: Subject: Re: [calsify] Updated JSCalendar draft version 07 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 01:46:42 -0000 --c42c01ec1f3047df829663d8eb342ef7 Content-Type: text/plain On Thu, 20 Sep 2018, at 7:55 PM, Robert Stepanek wrote: > *Main changes* > * Replaced the `web` replyTo property with `other`. The iCalendar spec allows arbitrary CAL-ADDRESS values for attendees and organizer. While running our implementation of the latest JSCalendar spec draft on production data, we ran into such calendar objects. JSCalendar needs to be able to handle these non-mailto, non-HTTPs URIs. > * The `email` property of the Participant object became optional (for the same reasons as the previous bullet point). That's fine. > * The id of a Participant object in the `participants` property now must be a valid URI. I don't like this because it's different to how these kind of set-of-items properties (e.g. locations, alerts) work in two imporant ways: * It means the id has semantic value. * It means the id has different allowed character restrictions compared to these other objects. I suggest that instead we add a new `sendTo` property on the participant object, with a value in the same format as the `replyTo` JSEvent property. This has a number of advantages: * The ids for the participants can have the same restrictions as elsewhere and, like elsewhere do not have semantic meaning. * The email property (for contacting the person) can be defined separated from the imip-email (for sending updates to the event). In the future, you could create an event that sends an iMIP message to the user's email. The RSVP however could update the `sendTo` property to either give a different email, or even add a separate protocol option (like `replyTo` it can include multiple options, so the organiser can then choose whichever they support). This allows you to then potentially bypass email for future updates (which is nice because most systems avoid sending iMIP updates for attendee status changes to avoid flooding the user's inbox, but if the organiser knew it was directly updating the calendar they could send all the updates and keep everyone in sync). > * The `replyTo` URI Template replaced the `email` variable with a `participantId` variable. The allowed level for the URI template now is 2 (instead of previously 1) to support URI-encoding of the participant id. This can then be level 1 again (so only simpler substitution required) with the above change. > *Open points* > * The current spec requires durations to be calculated in UTC. The iCalendar specification requires durations to be calculated in the calendar object time-zone. No consensus has been found on the mailing list, yet. I suggest to redefine durations to be calculated in the event time-zone. Yes, I think this is probably the best way forward, if nothing else for iCalendar compatibility. It also gives more flexibility, in that a client can define an event as 24h duration to ignore DST shifts, or 1 day if they really want to include them. (All day events are always in floating time, so this makes no difference to them of course). Neil. --c42c01ec1f3047df829663d8eb342ef7 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
    On Thu, 20= Sep 2018, at 7:55 PM, Robert Stepanek wrote:
    Main changes 
  • Replaced the `web` replyTo property with `other`. The iCalendar sp= ec allows arbitrary CAL-ADDRESS values for attendees and organizer. Whi= le running our implementation of the latest JSCalendar spec draft on pro= duction data, we ran into such calendar objects. JSCalendar needs to be = able to handle these non-mailto, non-HTTPs URIs.
  • The `email`= property of the Participant object became optional (for the same reason= s as the previous bullet point).

That's fine.

  • The id of a Participant object in the `partici= pants` property now must be a valid URI.
=
I don't like this because it's different to how these kin= d of set-of-items properties (e.g. locations, alerts) work in two impora= nt ways:
  • It means the id has semantic value.
    • It means the id has different allowed character restrictions compared = to these other objects.

I suggest that = instead we add a new sendTo property on the participant object, wi= th a value in the same format as the replyTo JSEvent property. Thi= s has a number of advantages:
  • The ids for the participa= nts can have the same restrictions as elsewhere and, like elsewhere do n= ot have semantic meaning.
  • The email property (for contacting= the person) can be defined separated from the imip-email (for sending u= pdates to the event). In the future, you could create an event that send= s an iMIP message to the user's email. The RSVP however could update the= = sendTo property to either give a different email, or even add a s= eparate protocol option (like replyTo it can include multiple opti= ons, so the organiser can then choose whichever they support). This allo= ws you to then potentially bypass email for future updates (which is nic= e because most systems avoid sending iMIP updates for attendee status ch= anges to avoid flooding the user's inbox, but if the organiser knew it w= as directly updating the calendar they could send all the updates and ke= ep everyone in sync).

  • The `replyTo` URI Template replaced t= he `email` variable with a `participantId` variable. The allowed level f= or the URI template now is 2 (instead of previously 1) to support URI-en= coding of the participant id.

<= div>This can then be level 1 again (so only simpler substitution require= d) with the above change.
 
Open points
  • Th= e current spec requires durations to be calculated in UTC. The iCalendar= specification requires durations to be calculated in the calendar objec= t time-zone. No consensus has been found on the mailing list, yet. I sug= gest to redefine durations to be calculated in the event time-zone. = ;

Yes, I think this is pro= bably the best way forward, if nothing else for iCalendar compatibility.= It also gives more flexibility, in that a client can define an event as= 24h duration to ignore DST shifts, or 1 day if they really want to incl= ude them. (All day events are always in floating time, so this makes no = difference to them of course).

Neil.
--c42c01ec1f3047df829663d8eb342ef7-- From nobody Thu Sep 27 08:09:24 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 48CDA130E23 for ; Thu, 27 Sep 2018 08:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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, UNPARSEABLE_RELAY=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=oracle.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 7ZJ1Mw3TGeQy for ; Thu, 27 Sep 2018 08:09:21 -0700 (PDT) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 16E6F12008A for ; Thu, 27 Sep 2018 08:09:20 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w8RF9BKI028199; Thu, 27 Sep 2018 15:09:11 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2018-07-02; bh=fdzdj8MuDrU87W1MN4xfwsq90wAwAxpy72bMRrOUXR8=; b=hhVKt6UJAsLEWtNZiX8VnmveF/B1GYZjwfudMaF2+BG/vIVI0PnxQhCJCJ3EWf+agB/U Qi56HBECTPidyQXfGqnbII9pbW3PbBkenvAH3QQtRZNKst3VyoS930ELmReYMUz+dxIA 0wgG7HTnE0x5gfaChKXVJmydQLVVhAbUAb5YUkOREBEB4QfLRZDTohLQB/KfxTamX0o8 8j9B3xaVnm6jcSWk/aJj/CSfDd3dAsFR7MGcgf5yu8Be97IVMxo5eNK8nUGWJviTGn9J cZ9wdXngOi2568pz45UYR0rvGAHm+dnr6820TUe6RW7KOHynsrmif3JLfxblns2j5vR4 tA== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2mnd5ttt2b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Sep 2018 15:09:10 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w8RF94ue012141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Sep 2018 15:09:04 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w8RF94g3029393; Thu, 27 Sep 2018 15:09:04 GMT Received: from dhcp-10-156-45-121.ca.oracle.com (/10.156.45.121) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Sep 2018 08:09:04 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Bernard Desruisseaux In-Reply-To: <19EFCA1E91A6F59ABAE023F7@cyrus.local> Date: Thu, 27 Sep 2018 11:09:02 -0400 Cc: "Michael A. Douglass" , IETF Calsify Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180926090958.74B27B8108E@rfc-editor.org> <983178de-f430-2115-0579-be861b198059@cisco.com> <19EFCA1E91A6F59ABAE023F7@cyrus.local> To: Cyrus Daboo X-Mailer: Apple Mail (2.3124) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9028 signatures=668707 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809270144 Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5505) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 15:09:23 -0000 Hi Cyrus, Should TZID allow quoted values? One could easily answer: Why not! In = 2018, though I=E2=80=99m more tempted to ask: Why? As you rightly mentioned, we now have the IANA Time Zone Database. Why would someone want / need to specify TZID=3DGMT-03:00 instead of = TZID=3DEtc/GMT-3? Perhaps this iCalendar inconsistency is actually a good thing for = interoperability! Finally, for the record only, not that it matters, Mozilla.org did use = the tzprefix at some point. See: https://www.google.ca/search?q=3DTZID=3D/mozilla.org Cheers, Bernard > Le 26 sept. 2018 =C3=A0 10:27, Cyrus Daboo a =C3=A9cr= it : >=20 > Hi Michael, >=20 > --On September 26, 2018 at 1:00:02 PM +0200 Michael Douglass = wrote: >=20 >> My belief is that parsers are already expecting this. Certainly = ical4j >> and libical already accept quoted values. >>=20 >> In any case it's broken as it stands. Parameter escaping isn't an = option >> as it assumes parameter value quoting is an option. >=20 > I agree this should be fixed, but the proposed change in the erratum = is wrong. This was the proposed new definition: >=20 > tzidparam =3D "TZID" "=3D" [tzidprefix] param-value >=20 > That does not work because it would allow the optional tzidprefix = (which is a single "/" character) to appear before the first quote of = any quoted string. I think you really need: >=20 > tzidparam =3D "TZID" "=3D" ([tzidprefix] paramtext) / > (DQUOTE [tzidprefix] *QSAFE-CHAR DQUOTE) >=20 > That ensures the tzidprefix appears inside the quoted string, if that = construct is used. >=20 > That said, I don't think I have ever seen tzidprefix being used. It = was meant to be used to indicate the the ID was from a globally defined = registry - well we have that now (IANA tzdb) and we aren't using the = prefix. I would suggest any future revision of 5545 should drop = tzidprefix as a formal syntax element, and instead just mention that the = tzid value may be prefixed. >=20 > FYI I checked my 5545 code and all implementations parse and generate = paramaters based on the generic definition of a parameter: >=20 > param =3D param-name "=3D" param-value *("," param-value) >=20 > So a quoted TZID would be fine. >=20 > --=20 > Cyrus Daboo >=20 > _______________________________________________ > calsify mailing list > calsify@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_calsify&d=3DDwICAg&c=3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_= JnE&r=3D1KWjrk6WfltMq-xNvZw71GcUXlVStaOFvtc__OOO9f8&m=3DBvqZ3mUPlLxPK4dmzA= OgTYiPUSywS7v8KV8Ybm3XBbI&s=3D6mggIoTabdhZqrS4rxdSdbK9RHlUdSEx7oHg6CNppKE&= e=3D From nobody Thu Sep 27 09:50:52 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 DAD69130EB5 for ; Thu, 27 Sep 2018 09:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LF37m6apX3wJ for ; Thu, 27 Sep 2018 09:50:49 -0700 (PDT) Received: from smtp.ucolick.org (zilan.ucolick.org [128.114.23.234]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 794B2130E4B for ; Thu, 27 Sep 2018 09:50:49 -0700 (PDT) Received: from smtp.ucolick.org (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id B852329A8; Thu, 27 Sep 2018 09:29:24 -0700 (PDT) Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) by smtp.ucolick.org (Postfix) with ESMTP id 7D25C2742; Thu, 27 Sep 2018 09:29:24 -0700 (PDT) Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (Postfix) with ESMTP id 69A2D75B; Thu, 27 Sep 2018 09:29:24 -0700 (PDT) Received: (from sla@localhost) by geneva.ucolick.org (8.14.7/8.14.7/Submit) id w8RGTNPh012670; Thu, 27 Sep 2018 09:29:23 -0700 Date: Thu, 27 Sep 2018 09:29:23 -0700 From: Steve Allen To: Bernard Desruisseaux , IETF Calsify Message-ID: <20180927162923.GA12451@ucolick.org> References: <20180926090958.74B27B8108E@rfc-editor.org> <983178de-f430-2115-0579-be861b198059@cisco.com> <19EFCA1E91A6F59ABAE023F7@cyrus.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5505) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2018 16:50:51 -0000 On Thu 2018-09-27T11:09:02-0400 Bernard Desruisseaux hath writ: > As you rightly mentioned, we now have the IANA Time Zone Database. > > Why would someone want / need to specify TZID=GMT-03:00 instead of TZID=Etc/GMT-3? I would specify TZID=GMT-20:00 and TZID=GMT-23:00, and those are not found in IANA Time Zone database. For practical purposes, the first is the time zone in which the astronomical calendar for Lick Observatory has always been expressed. The astronomical day begins at noon local time. The lack of availability of those means that modern computing systems do not recognize the traditional day boundaries, so the calendars are presented with footnotes to be interpreted by humans. The second is the time zone in which the calendar for Keck Observatory is expressed. > Perhaps this iCalendar inconsistency is actually a good thing for interoperability! It is a bad thing for situations which are not common enough to be accommodated by the widely-used interfaces. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From nobody Fri Sep 28 04:16: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 9776B130E1D for ; Fri, 28 Sep 2018 04:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=youcanbook-me.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 XtwmOnfSevfA for ; Fri, 28 Sep 2018 04:16:53 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 BCAA2130E17 for ; Fri, 28 Sep 2018 04:16:52 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id z3-v6so5934462wrr.13 for ; Fri, 28 Sep 2018 04:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=youcanbook-me.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lryPPbedWQNAJ0HFAxVBG4NjlXIGMMgiAwJM+pFByCI=; b=CjZCr1v+jE1ZcYGwKyGE8EATOuv/j6QZ72r7UircBUDONsV1MoHEn5pzyeetdQZ5ri ia1mJURXb0IY02BcgCX/1hSs65sdQSPaG273fqaJbp2siFPWvR+sdjT4ZB/wmMY2HWG0 yaBlpPmK2pey8VGejQG0Z08jO4Th+m5p9K2C19N25jF68tCfiRJ7252k+o9NCCL7R6CA yo5Cx88si2Csm+ZwucYRRyhHkDq+l6M2vFuYroV6D6HaR+Y+Aym1KQ8lrUxKrA26qHrA v+H00nzWWMI1DcGP5TrFhHnyUOh+RK2IE/Cos2BwLjgsVsLmKX08Nyy3kE9G/lAFJDbQ A+xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lryPPbedWQNAJ0HFAxVBG4NjlXIGMMgiAwJM+pFByCI=; b=DGnG0QhlqUaaMEylwyTmmo6BQdnYCQEqvhvMy8XqJqmQh9IwGRfnOQcA1PnzntTshv jl8JoWwHhiEUE/9XSlDn0oizag22zmokIj0OgcRjQBH3eBgsHKc7iUvmOy9kWTocQAKx k8g68/dI8cXv81RwuTK7TGapgpLnVg+iFyp+aEdAQROAJ27wk5hLNjpN4wQmvBsxB1gs 3rWuMjZ9W14OCFaUb7xwXkiFvPdKkbU/MCVKWDVrX97pEAQ0syPvdvkQzGugw7qxzMB7 tF+fQ4xf1vSuRqvQvTNnixexUEPiWPhGT3l5UwZmYdDni4/DmKslfY6Q34sz4njtWVP+ 1anw== X-Gm-Message-State: ABuFfog5luFXS0uJBxsif6mLsu7e7QTgwN9D4vMweC7Hs0TfuNZqhdux PKtRMg1POL7PT3uXDlBpMyy3BnT/o3qayJMUhDdw X-Google-Smtp-Source: ACcGV62+9WANp3wfYFdHdSAXnOtpr7sXyo0fjFmERk5eXB9OAWlxRdt9t6lDjF/USStFngscLxR51CNnuMN7WCrA1Nw= X-Received: by 2002:adf:c845:: with SMTP id e5-v6mr12146157wrh.243.1538133410894; Fri, 28 Sep 2018 04:16:50 -0700 (PDT) MIME-Version: 1.0 References: <20180926090958.74B27B8108E@rfc-editor.org> <983178de-f430-2115-0579-be861b198059@cisco.com> <19EFCA1E91A6F59ABAE023F7@cyrus.local> <20180927162923.GA12451@ucolick.org> In-Reply-To: <20180927162923.GA12451@ucolick.org> From: Keith Harris Date: Fri, 28 Sep 2018 12:16:39 +0100 Message-ID: To: sla@ucolick.org Cc: bernard.desruisseaux@oracle.com, calsify@ietf.org Content-Type: multipart/alternative; boundary="00000000000092e69b0576ec9766" Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (5505) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2018 11:16:55 -0000 --00000000000092e69b0576ec9766 Content-Type: text/plain; charset="UTF-8" Perhaps TZID=GMT-03:30 is another example of a offset defined zone that can not neatly be done without a colon. (Though I agree that there could be a signal here regarding interoperability, but for me it would be to steer away offset zones and towards geographic names: TZID=America/St_Johns) On Thu, 27 Sep 2018 at 17:50, Steve Allen wrote: > On Thu 2018-09-27T11:09:02-0400 Bernard Desruisseaux hath writ: > > As you rightly mentioned, we now have the IANA Time Zone Database. > > > > Why would someone want / need to specify TZID=GMT-03:00 instead of > TZID=Etc/GMT-3? > > I would specify TZID=GMT-20:00 and TZID=GMT-23:00, and those are > not found in IANA Time Zone database. > > For practical purposes, the first is the time zone in which the > astronomical calendar for Lick Observatory has always been expressed. > The astronomical day begins at noon local time. The lack of > availability of those means that modern computing systems do not > recognize the traditional day boundaries, so the calendars are > presented with footnotes to be interpreted by humans. > > The second is the time zone in which the calendar for Keck Observatory > is expressed. > > > Perhaps this iCalendar inconsistency is actually a good thing for > interoperability! > > It is a bad thing for situations which are not common enough to be > accommodated by the widely-used interfaces. > > -- > Steve Allen WGS-84 (GPS) > UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat > +36.99855 > 1156 High Street Voice: +1 831 459 3046 Lng > -122.06015 > Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --00000000000092e69b0576ec9766 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Perhaps TZID=3DGMT-03:30 is another examp= le of a offset defined zone that can not neatly be done without a colon.
(Though I agree that there could be a signal here regardin= g interoperability, but for me it would be to steer away offset zones and t= owards geographic names: TZID=3DAmerica/St_Johns)

On Thu 2018-09-27T11:09:02-0400 Bernard Desruisseaux hath writ:<= br> > As you rightly mentioned, we now have the IANA Time Zone Database.
>
> Why would someone want / need to specify=C2=A0 =C2=A0TZID=3DGMT-03:00= =C2=A0 instead of=C2=A0 TZID=3DEtc/GMT-3?

I would specify TZID=3DGMT-20:00 and TZID=3DGMT-23:00, and those are
not found in IANA Time Zone database.

For practical purposes, the first is the time zone in which the
astronomical calendar for Lick Observatory has always been expressed.
The astronomical day begins at noon local time.=C2=A0 The lack of
availability of those means that modern computing systems do not
recognize the traditional day boundaries, so the calendars are
presented with footnotes to be interpreted by humans.

The second is the time zone in which the calendar for Keck Observatory
is expressed.

> Perhaps this iCalendar inconsistency is actually a good thing for inte= roperability!

It is a bad thing for situations which are not common enough to be
accommodated by the widely-used interfaces.

--
Steve Allen=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 <sla@ucolick= .org>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WGS-84 (GPS) UCO/Lick Observatory--ISB 260=C2=A0 Natural Sciences II, Room 165=C2=A0 Lat= =C2=A0 +36.99855
1156 High Street=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Voic= e: +1 831 459 3046=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lng -122.06015
Santa Cruz, CA 95064=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.= ucolick.org/~sla/=C2=A0 =C2=A0Hgt +250 m

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