From nobody Sun Feb 3 07:27:37 2019 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 73593130FAB for ; Sun, 3 Feb 2019 07:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=qfddxm3Y; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uEWCSA3S 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 4fTFfSapGi-X for ; Sun, 3 Feb 2019 07:27:26 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6384B130F97 for ; Sun, 3 Feb 2019 07:27:26 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5A8D321BCA for ; Sun, 3 Feb 2019 10:27:25 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 03 Feb 2019 10:27:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=L59wptWju4fGE4QoiTDkuxU/tIZB H4Wi4HWBuuwW61E=; b=qfddxm3YiyPTn/4QTl7HsR/XKS5egZaDFsAomYmKbctt SGWYIV2p3BaMxznaXnSY0tKiJWbMYSRIV0Sj7mCBNC39DcHNIuIfik6+68p2emem KI5cTG9W81v6VxIeWKJI+eOYlD2IGvDrTjAXYE9rFHKYw+pdy2Xu/epURPBsY5HC O3a+zUL2gMUE7boqAGLXcV907IKYlWHyZ726ChlFmubADGuuh+Oskv6axj6HAn+7 tKVFj36HN/ZkXTkjKQzWXohpDsS4lZKfYDbyaKtFuEFLCRp+R2NodjYgOr7yTvYr 1LhbLEodoRkr45NDB5r9kSK2Zu7EOe6kugoX/bR7Vw== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=L59wptWju4fGE4Qoi TDkuxU/tIZBH4Wi4HWBuuwW61E=; b=uEWCSA3SgEDFt3inIiXq+8Mq8EWQN2RLI 4jq6WpYCw6eKhmOHc7qZ66/5B2QyHplSw1nGkGQX52IVohs7jVaaPS4KXxvSOVb7 8o+YGWWIrm+eloJHooNVF+YjAfCMUFivwWxf9Juf+8AEsWSkRz6bkJ0uGalyg8Ww l+T/5E9yf34DaxevFKOxbw9nVTbscy5cYSHGUnwvw2Q2sUs7u+69159p+MffEOmZ DXcKRipuoBnul3WQrx4nJ8uH1/HCtdqodVL5pteJPG2FWUA9XevjB+9MKiMJ7mX9 mc5Na0LJrNLC+Cd0HfMcn1vB7xCN/FT4DY9XRKDxdT42SUOoqUFcQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkedvgdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucenucfjughrpefofgfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfd eurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdr tghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrh homhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfu ihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 12612203BD; Sun, 3 Feb 2019 10:27:25 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 56629417 Message-Id: <92b94be5-f3aa-4d41-aee1-77de3ea8bc9f@www.fastmail.com> In-Reply-To: <68d00c8a-13df-4c17-ada2-8af2d6777fcf@www.fastmail.com> References: <68d00c8a-13df-4c17-ada2-8af2d6777fcf@www.fastmail.com> Date: Sun, 03 Feb 2019 10:27:24 -0500 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=87409ebdee944db8995a66a00be80cc0 Archived-At: Subject: Re: [calsify] Shall we meet in Prague? (also: what shall we work on?) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2019 15:27:35 -0000 --87409ebdee944db8995a66a00be80cc0 Content-Type: text/plain Due to lack of interest... I haven't submitted a request YET! But... it doesn't need to be in until the end of the week, so there's still time. let me know :) Bron. On Tue, Jan 29, 2019, at 10:12, Bron Gondwana wrote: > Hi all, > > It's getting on time to submit meeting requests for the next face-to-face IETF meeting! > > We have two documents that are waiting for revised drafts: > > * eventpub-extensions-10 > * caldav-attachments-03 > > As well as the almost ready to go jscalendar: > > * jscalendar-11 > > I know there's also interest in bringing other items of work to this group. From memory things that I've seen mentioned include: > > * caldav-scheduling-controls (author: me, when I write it up!) - a new header "Scheduling-Enabled: F" to disable all scheduling when storing a resource to a server. Good for restoring from backup as well as a way to avoid sending updates more generally while cleaning up spam, rather than the current "Schedule-Reply: F" which is only for resources where you are not the organizer. > > * caldav-upgrade - a header returned by a server to tell a client that a .ics feed is also available via read-only caldav, allowing clients to use sync-collection for more efficient updates. > > * caldav-push - a method for delivering push updates when a calendar is changed, allowing clients to avoid polling. > > * caldav-server-side-subscriptions - a method for federating caldav calendars (potentially with local cached copy) such that the server acts as a client to another server, aggregating calendars from multiple servers into a single homeset. > > * calendar autodiscovery - I'm not sure if that's coming to this group, or if there's going to be an attempt at renewing the more general service autodiscovery discussion. My notes from last calconnect said it would go to DISPATCH, but I didn't make it to the Monday of Bangkok, so I missed out. > > > .... > > Does anybody have any other work that they want to bring to this group, or appetite to work on any of the above? I'd love to get this group flowing smoothly and improving calendaring for everybody! I'll be at CalConnect in Zurich next week, and I'll be asking everyone there to get involved over here as well. > > Submissions for sessions are due Feb 8th at the latest, so do let us know if you'll be present at Prague (or joining remotely) and have something to talk about! > > Cheers, > > Bron (on behalf of the calext chairs) > > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --87409ebdee944db8995a66a00be80cc0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Due to lack of interest... I haven't submitted a requ= est YET!  But... it doesn't need to be in until the end of the week= , so there's still time.  let me know :)

Bron.

On Tue, Jan 29, 2019, at 10:12, Bron Gondwana wrote:
=
Hi all,

=
It's getting on time to submit meeting= requests for the next face-to-face IETF meeting!

We have= two documents that are waiting for revised drafts:


As well as th= e almost ready to go jscalendar:


I know there's also interest in bringing other items of wo= rk to this group.  From memory things that I've seen mentioned incl= ude:

* caldav-scheduling-controls (author: me, when I wri= te it up!) - a new header "Scheduling-Enabled: F" to disable all schedul= ing when storing a resource to a server.  Good for restoring from b= ackup as well as a way to avoid sending updates more generally while cle= aning up spam, rather than the current "Schedule-Reply: F" which is only= for resources where you are not the organizer.

* caldav-= upgrade - a header returned by a server to tell a client that a .ics fee= d is also available via read-only caldav, allowing clients to use sync-c= ollection for more efficient updates.

* caldav-push - a m= ethod for delivering push updates when a calendar is changed, allowing c= lients to avoid polling.

=
* caldav-server-side-subscriptio= ns - a method for federating caldav calendars (potentially with local ca= ched copy) such that the server acts as a client to another server, aggr= egating calendars from multiple servers into a single homeset.
=

* calendar autodiscovery - I'm not sure if that's coming to this g= roup, or if there's going to be an attempt at renewing the more general = service autodiscovery discussion.  My notes from last calconnect sa= id it would go to DISPATCH, but I didn't make it to the Monday of Bangko= k, so I missed out.


....

Does anybody have any other work that they wa= nt to bring to this group, or appetite to work on any of the above? = ; I'd love to get this group flowing smoothly and improving calendaring = for everybody!  I'll be at CalConnect in Zurich next week, and I'll= be asking everyone there to get involved over here as well.

Submissions for sessions are due Feb 8th at the latest, so do let us= know if you'll be present at Prague (or joining remotely) and have some= thing to talk about!

Ch= eers,

Bron (on be= half of the calext chairs)


--
  Bron Gondwana, CE= O, FastMail Pty Ltd
&n= bsp; brong@fastmailteam.com


_= ______________________________________________
calsify mai= ling list
calsify@ietf.org
https://www.ietf.= org/mailman/listinfo/calsify


--
  Bron Gondwana= , CEO, FastMail Pty Ltd
  brong@f= astmailteam.com


--87409ebdee944db8995a66a00be80cc0-- From nobody Sun Feb 3 07:33:54 2019 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 68B5B12426A for ; Sun, 3 Feb 2019 07:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwMg49d1xSaE for ; Sun, 3 Feb 2019 07:33:50 -0800 (PST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 98E0512008F for ; Sun, 3 Feb 2019 07:33:49 -0800 (PST) Received: by mail-ed1-x52e.google.com with SMTP id h15so9243359edb.4 for ; Sun, 03 Feb 2019 07:33:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=OSbdkIP3IyzHfCoQS3KxIRh5/wnclso/T5mMgQ1qjNQ=; b=mbZxqf/tgd5REc1Y8F6xbkO2Uk2rr3QQYrGbMY/P3oK3rhxP/cN4v4ZIlgwRmOBUiK gFornJShr4VDnuAFaaBvg8xB5z2ZU9AOdCc4MzGMNEbnCJHREhBANeMCbYYo6anDzixN 4Wz4+Ha4LZ6jMkaX2XXmcYTXnQB5XQoAQk3JG9aqt6+wotEqgJlNri63oh+t7duLqPVY 9IUZd9A96AAZIV0jAOeUoa+7lu3XE/uRxaCwwXACFzMTNZSkNjqOkazn+Caet844ACN3 zpBVwbNC1dYiRz1h0F9KCttwftiIsVw8FxWr9OZlNUOVXtxyp5mq4EMvaEwMJoVNgIL2 fPjg== 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=OSbdkIP3IyzHfCoQS3KxIRh5/wnclso/T5mMgQ1qjNQ=; b=g8W03sPc/E5V9C4MFv4EdjNBIWKpYgAafW0RvbXiLuPpM+Mug+9iF9FTWo49EaJIjL WANuT1OCEpHcflpq+VQmmb0Cpbti33U2OsPqJEAkVFeUr5rDrhfMG7bSW1obBA48nR2y XDmmIVLoSf7Q3RON2ywGiBfATkB4nB7jX/FxfpRR998pA3Oq2vZE5wZyNljwZwCc14mO LvxBwlsTXcB+EN/rbvvvoZsSIrkVp8sHP8+/OCD35IgsHVcxFvy2QKbENOePPgeV+zNx a+j5fHY4lHZaoSgF5md6Vnkr8CIWG7wGj6rrp1vEQHOO+q4G4FPX44h9NTBbGkXPJdC6 mOoQ== X-Gm-Message-State: AJcUukdadN4FWjW7JnZ1iRKkArjkQdq5xM+650L1Z1RQ55VqIKt5CbFy cSlLlw1TZ4+WU7DyiF16NYspqL1S X-Google-Smtp-Source: ALg8bN7LHHxoLYc7lwZ2L1EvBzvdtW6QS2t/tYR/4zCxKQ/CSFwjg0mKL/NyldgPRKQes7oJe25GEA== X-Received: by 2002:a05:6402:1816:: with SMTP id g22mr48417742edy.191.1549208027720; Sun, 03 Feb 2019 07:33:47 -0800 (PST) Received: from surfer-172-29-11-153-hotspot.internet-for-guests.com ([46.140.192.12]) by smtp.googlemail.com with ESMTPSA id w31sm3625722edw.82.2019.02.03.07.33.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Feb 2019 07:33:47 -0800 (PST) To: calsify@ietf.org References: <68d00c8a-13df-4c17-ada2-8af2d6777fcf@www.fastmail.com> <92b94be5-f3aa-4d41-aee1-77de3ea8bc9f@www.fastmail.com> From: Michael Douglass Message-ID: <0a5f6b27-420c-10d7-bc71-16c86e27cdb4@gmail.com> Date: Sun, 3 Feb 2019 16:33:46 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <92b94be5-f3aa-4d41-aee1-77de3ea8bc9f@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------418A81C44D9E7EC1C44009C4" Content-Language: en-US Archived-At: Subject: Re: [calsify] Shall we meet in Prague? (also: what shall we work on?) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2019 15:33:52 -0000 This is a multi-part message in MIME format. --------------418A81C44D9E7EC1C44009C4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I wouldn't call it that: mostly pressing deadlines and an assumption we'll talk about it this week - also one of the topics may trigger a last minute addition to the eventpub extensions. When do you arrive? On 2/3/19 10:27, Bron Gondwana wrote: > Due to lack of interest... I haven't submitted a request YET!  But... > it doesn't need to be in until the end of the week, so there's still > time.  let me know :) > > Bron. > > On Tue, Jan 29, 2019, at 10:12, Bron Gondwana wrote: >> Hi all, >> >> It's getting on time to submit meeting requests for the next >> face-to-face IETF meeting! >> >> We have two documents that are waiting for revised drafts: >> >> * eventpub-extensions-10 >> >> * caldav-attachments-03 >> >> >> As well as the almost ready to go jscalendar: >> >> * jscalendar-11 >> >> >> I know there's also interest in bringing other items of work to this >> group.  From memory things that I've seen mentioned include: >> >> * caldav-scheduling-controls (author: me, when I write it up!) - a >> new header "Scheduling-Enabled: F" to disable all scheduling when >> storing a resource to a server.  Good for restoring from backup as >> well as a way to avoid sending updates more generally while cleaning >> up spam, rather than the current "Schedule-Reply: F" which is only >> for resources where you are not the organizer. >> >> * caldav-upgrade - a header returned by a server to tell a client >> that a .ics feed is also available via read-only caldav, allowing >> clients to use sync-collection for more efficient updates. >> >> * caldav-push - a method for delivering push updates when a calendar >> is changed, allowing clients to avoid polling. >> >> * caldav-server-side-subscriptions - a method for federating caldav >> calendars (potentially with local cached copy) such that the server >> acts as a client to another server, aggregating calendars from >> multiple servers into a single homeset. >> >> * calendar autodiscovery - I'm not sure if that's coming to this >> group, or if there's going to be an attempt at renewing the more >> general service autodiscovery discussion.  My notes from last >> calconnect said it would go to DISPATCH, but I didn't make it to the >> Monday of Bangkok, so I missed out. >> >> >> .... >> >> Does anybody have any other work that they want to bring to this >> group, or appetite to work on any of the above?  I'd love to get this >> group flowing smoothly and improving calendaring for everybody!  I'll >> be at CalConnect in Zurich next week, and I'll be asking everyone >> there to get involved over here as well. >> >> Submissions for sessions are due Feb 8th at the latest, so do let us >> know if you'll be present at Prague (or joining remotely) and have >> something to talk about! >> >> Cheers, >> >> Bron (on behalf of the calext chairs) >> >> >> -- >>   Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >> > > -- >   Bron Gondwana, CEO, FastMail Pty Ltd >   brong@fastmailteam.com > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------418A81C44D9E7EC1C44009C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I wouldn't call it that: mostly pressing deadlines and an assumption we'll talk about it this week - also one of the topics may trigger a last minute addition to the eventpub extensions.

When do you arrive?

On 2/3/19 10:27, Bron Gondwana wrote:
Due to lack of interest... I haven't submitted a request YET!  But... it doesn't need to be in until the end of the week, so there's still time.  let me know :)

Bron.

On Tue, Jan 29, 2019, at 10:12, Bron Gondwana wrote:
Hi all,

It's getting on time to submit meeting requests for the next face-to-face IETF meeting!

We have two documents that are waiting for revised drafts:


As well as the almost ready to go jscalendar:


I know there's also interest in bringing other items of work to this group.  From memory things that I've seen mentioned include:

* caldav-scheduling-controls (author: me, when I write it up!) - a new header "Scheduling-Enabled: F" to disable all scheduling when storing a resource to a server.  Good for restoring from backup as well as a way to avoid sending updates more generally while cleaning up spam, rather than the current "Schedule-Reply: F" which is only for resources where you are not the organizer.

* caldav-upgrade - a header returned by a server to tell a client that a .ics feed is also available via read-only caldav, allowing clients to use sync-collection for more efficient updates.

* caldav-push - a method for delivering push updates when a calendar is changed, allowing clients to avoid polling.

* caldav-server-side-subscriptions - a method for federating caldav calendars (potentially with local cached copy) such that the server acts as a client to another server, aggregating calendars from multiple servers into a single homeset.

* calendar autodiscovery - I'm not sure if that's coming to this group, or if there's going to be an attempt at renewing the more general service autodiscovery discussion.  My notes from last calconnect said it would go to DISPATCH, but I didn't make it to the Monday of Bangkok, so I missed out.


....

Does anybody have any other work that they want to bring to this group, or appetite to work on any of the above?  I'd love to get this group flowing smoothly and improving calendaring for everybody!  I'll be at CalConnect in Zurich next week, and I'll be asking everyone there to get involved over here as well.

Submissions for sessions are due Feb 8th at the latest, so do let us know if you'll be present at Prague (or joining remotely) and have something to talk about!

Cheers,

Bron (on behalf of the calext chairs)


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


_______________________________________________
calsify mailing list


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



_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------418A81C44D9E7EC1C44009C4-- From nobody Sun Feb 3 09:47:21 2019 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 7EDE2130F5F for ; Sun, 3 Feb 2019 09:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=ItmoiU4E; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=F8LR1ck9 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 XsAJbVhR0E5E for ; Sun, 3 Feb 2019 09:47:08 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3DC1286D9 for ; Sun, 3 Feb 2019 09:47:07 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D7CE420E0E for ; Sun, 3 Feb 2019 12:47:06 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 03 Feb 2019 12:47:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=rU8M/g7uMiFSAcvq/cv45BlPCFox mpXeBB7gWpUt8/A=; b=ItmoiU4E/b+gDrjWibEkxO8EjjRPmehi6N03qDFmi7Fu q28rY6Uphqk++ReslDZhbZGw+kXPSg3YFFiFteCqCQB1HlJdSsY3E7H2GkYbXzpc HePNsbxaPYtgnr3sQS1rWthXTdFDoiVEXlsmszVdfAcYu/aoonrVxQFDQ/jPRJPz 8kLZinA5zptZd1qeuW6VES50Lf3A+n6/oX2KunHiwIPZ5kEL320UESTOIlhODGA3 3xFFwXhfg5R9vAJienV6zVLv7wKKiv5YB2y4TqnTV76Ok0waPJx2ze7x5Bu05nph Oli62gvZ6W0lAGZT+sESGSLnpDsvh7epboSuYpmv+Q== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=rU8M/g7uMiFSAcvq/ cv45BlPCFoxmpXeBB7gWpUt8/A=; b=F8LR1ck9/tWyutQ/jEQWL3ZNtTlsrZk/o uE/s3dfC/MCae+/OmYDmI4fFT4AHoDBsMUMRUcWFpz8ejn/uZM6mFXqBCEi8zlqf RuZliCZ/6lxA5cFSO5ypUFtD43ga8TF286wkE2IFQVX5vGYlA1ycI9elYCZU/JZ5 WaQ/9xZe1uh2vXaCp3EvyVrEs0HZdGMSkiePfSkhb5643WZbYp+os4CKLND0NFPD EeTrBiBDUap1jKouLudlu/bbN8rbdOHiP7/fkPLGAgPQWtxgrCTr63yyIzMNrcKy Cle7rXIPxFQESjuVi1DUui/i1lEAHR1TDi/BuoWCa9SVKXs7aAtGg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkedvgddutdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepofgfkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpe dfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghm rdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfh hrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghr ufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 78B48203BD; Sun, 3 Feb 2019 12:47:06 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 56629417 Message-Id: <069aa616-fa30-4278-a0ab-5a52529386c0@beta.fastmail.com> In-Reply-To: <0a5f6b27-420c-10d7-bc71-16c86e27cdb4@gmail.com> References: <68d00c8a-13df-4c17-ada2-8af2d6777fcf@www.fastmail.com> <92b94be5-f3aa-4d41-aee1-77de3ea8bc9f@www.fastmail.com> <0a5f6b27-420c-10d7-bc71-16c86e27cdb4@gmail.com> Date: Sun, 03 Feb 2019 12:47:06 -0500 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=fed2f672645d4f06b53601472e2b4a60 Archived-At: Subject: Re: [calsify] Shall we meet in Prague? (also: what shall we work on?) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2019 17:47:19 -0000 --fed2f672645d4f06b53601472e2b4a60 Content-Type: text/plain Late tonight! Assuming my train makes it to the airport on time! I should be at the hotel about 10pm On Sun, Feb 3, 2019, at 16:34, Michael Douglass wrote: > I wouldn't call it that: mostly pressing deadlines and an assumption we'll talk about it this week - also one of the topics may trigger a last minute addition to the eventpub extensions. > When do you arrive? > On 2/3/19 10:27, Bron Gondwana wrote: >> Due to lack of interest... I haven't submitted a request YET! But... it doesn't need to be in until the end of the week, so there's still time. let me know :) >> >> Bron. >> >> On Tue, Jan 29, 2019, at 10:12, Bron Gondwana wrote: >>> Hi all, >>> >>> It's getting on time to submit meeting requests for the next face-to-face IETF meeting! >>> >>> We have two documents that are waiting for revised drafts: >>> >>> * eventpub-extensions-10 >>> * caldav-attachments-03 >>> >>> As well as the almost ready to go jscalendar: >>> >>> * jscalendar-11 >>> >>> I know there's also interest in bringing other items of work to this group. From memory things that I've seen mentioned include: >>> >>> * caldav-scheduling-controls (author: me, when I write it up!) - a new header "Scheduling-Enabled: F" to disable all scheduling when storing a resource to a server. Good for restoring from backup as well as a way to avoid sending updates more generally while cleaning up spam, rather than the current "Schedule-Reply: F" which is only for resources where you are not the organizer. >>> >>> * caldav-upgrade - a header returned by a server to tell a client that a .ics feed is also available via read-only caldav, allowing clients to use sync-collection for more efficient updates. >>> >>> * caldav-push - a method for delivering push updates when a calendar is changed, allowing clients to avoid polling. >>> >>> * caldav-server-side-subscriptions - a method for federating caldav calendars (potentially with local cached copy) such that the server acts as a client to another server, aggregating calendars from multiple servers into a single homeset. >>> >>> * calendar autodiscovery - I'm not sure if that's coming to this group, or if there's going to be an attempt at renewing the more general service autodiscovery discussion. My notes from last calconnect said it would go to DISPATCH, but I didn't make it to the Monday of Bangkok, so I missed out. >>> >>> >>> .... >>> >>> Does anybody have any other work that they want to bring to this group, or appetite to work on any of the above? I'd love to get this group flowing smoothly and improving calendaring for everybody! I'll be at CalConnect in Zurich next week, and I'll be asking everyone there to get involved over here as well. >>> >>> Submissions for sessions are due Feb 8th at the latest, so do let us know if you'll be present at Prague (or joining remotely) and have something to talk about! >>> >>> Cheers, >>> >>> Bron (on behalf of the calext chairs) >>> >>> >>> -- >>> Bron Gondwana, CEO, FastMail Pty Ltd >>> brong@fastmailteam.com >>> >>> >>> _______________________________________________ >>> calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify >>> >> >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >> >> >> >> _______________________________________________ calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >> > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --fed2f672645d4f06b53601472e2b4a60 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Late tonight! Assuming my train makes it to the airpo= rt on time! I should be at the hotel about 10pm

On Sun, Feb 3= , 2019, at 16:34, Michael Douglass wrote:

I wouldn't call it that: mostly pressing = deadlines and an assumption we'll talk about it this week - also one of the topics may trigger a last minute addition to the eventpub extensions.
=

When do you arrive?

On 2/3/19 10:27, Bron Gondwana wrote:
Due to lack of interest... I haven't submitted a request YET!  But... it doesn't need to= be in until the end of the week, so there's still time.  let m= e know :)

Bron.

On Tue, Jan 29, 2019= , at 10:12, Bron Gondwana wrote:
Hi all,=

It's getting on time to submit meeting requests for the next face-to-face IETF meeting!

We have two documents that are waiting for revised drafts:


As well as the almost rea= dy to go jscalendar:

=
=

I know there's also interest in bringing other items of work to this group.  From memory things that I've seen mentioned include:

* calda= v-scheduling-controls (author: me, when I write it up!) - a new header "Scheduling-Enabled: F" to disable all scheduling when storing= a resource to a server.  Good for restoring from backup a= s well as a way to avoid sending updates more generally while cleaning up spam, rather than the current "Schedule-Reply: F" which is only for resources where you are not the organizer.

* caldav-upgrade - a header returned by a server to tell a client that a .ics feed is also= available via read-only caldav, allowing clients to use sync-collection for more efficient updates.

* c= aldav-push - a method for delivering push updates when a calendar is changed, allowing clients to avoid polling.

* caldav-server-side-subscriptions - a method for federating caldav calendars (potentially with local cached copy) such that the server acts as a client to another server, aggregating calendars from multiple servers into a single homeset.

=
* calendar autodiscovery - I'm not sure if that's coming to this group, or if there's going to be an attempt at renewing the more general service autodiscovery discussion.  My notes from last calconnect = said it would go to DISPATCH, but I didn't make it to the Monday of= Bangkok, so I missed out.


....
Does anybody have any other wor= k that they want to bring to this group, or appetite to work on any of the above?  I'd love to get this group flowing smo= othly and improving calendaring for everybody!  I'll be at CalConnect in Zurich next week, and I'll be asking everyone there to get involved over here as well.

Submiss= ions for sessions are due Feb 8th at the latest, so do let us know if you'll be present at Prague (or joining remotely) and have something to talk about!

Cheers,=

Bron (on behalf = of the calext chairs)

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.co= m
=

_______= ________________________________________
calsify mailing l= ist


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailte= am.com

<= /div>


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

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

--fed2f672645d4f06b53601472e2b4a60-- From nobody Sun Feb 3 10:55:10 2019 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 02159130F8B for ; Sun, 3 Feb 2019 10:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 zpwVUWosh6D4 for ; Sun, 3 Feb 2019 10:54:58 -0800 (PST) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (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 203C4130F9C for ; Sun, 3 Feb 2019 10:54:58 -0800 (PST) Received: by mail-lf1-f42.google.com with SMTP id c16so8680594lfj.8 for ; Sun, 03 Feb 2019 10:54:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=11Xo3j5rG5zNvzTaZwc+W3TKWRhIcLwPqRXP9ZoTOmk=; b=ag/u+BrwEeEcxABAU4zKZ+uR9ORKuiIfjiBN5RhHZ95TmvGOdAOoY3LOlV+kk+/9fe d9ZIKwIsrbG5U1LHGqQfrflfuus0xfsss4o+5C05nut0hI26ohpGpz/JXDMFW/lWz5zo 9qNUnzN+6LRE0yNqTybtFdflfRRLYOagfG7+3m5tcSSIdv3jCYD+bSSTeVRNr8uFlhLL 9E/6/TrjgwCK1w7KZywI/liJqz0liPBiB6jrdt5qNmueTqJ5wtQu6io5YapvMazbR7lM xRJ53IZwLWcV/DSORKKzLRM87FIDmvC7RV/r910B4U+PgCEOLdUzs7EiPLhBu3UMRnSx 0PNQ== X-Gm-Message-State: AHQUAubB/xU0YXlWL8rT5vhAdFYQ9yO/TMQXQoVdq64iAOBJW4uwO347 6sKjgHhOOo9nRJGirPCVzQBbJfaG+JJsZSByQoV55Q== X-Google-Smtp-Source: AHgI3IYID1rZYTpN2vkaHnxj4F5yFmv4VK5IsWN+61za4YVZAmMgu2J8ga33n7Kg05D86qwKT7rx1HcCvQhKpoE2Mz4= X-Received: by 2002:a19:a411:: with SMTP id q17mr16950544lfc.160.1549220096048; Sun, 03 Feb 2019 10:54:56 -0800 (PST) MIME-Version: 1.0 References: <68d00c8a-13df-4c17-ada2-8af2d6777fcf@www.fastmail.com> <92b94be5-f3aa-4d41-aee1-77de3ea8bc9f@www.fastmail.com> <0a5f6b27-420c-10d7-bc71-16c86e27cdb4@gmail.com> <069aa616-fa30-4278-a0ab-5a52529386c0@beta.fastmail.com> In-Reply-To: <069aa616-fa30-4278-a0ab-5a52529386c0@beta.fastmail.com> From: Daniel Migault Date: Sun, 3 Feb 2019 13:54:44 -0500 Message-ID: To: Bron Gondwana Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary="00000000000081022b058101e90a" Archived-At: Subject: Re: [calsify] Shall we meet in Prague? (also: what shall we work on?) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2019 18:55:09 -0000 --00000000000081022b058101e90a Content-Type: text/plain; charset="UTF-8" If lots of these topics will be discussed at Calconnect, it sounds to me as an indication that an IETF session would be welcome. Having part of the discussions at the IETF would help moving proposals forward at the IETF as it would ease showing these proposals have reached consensus and have undergone a sufficient number of reviews. Yours, Daniel On Sun, Feb 3, 2019 at 12:47 PM Bron Gondwana wrote: > Late tonight! Assuming my train makes it to the airport on time! I should > be at the hotel about 10pm > > On Sun, Feb 3, 2019, at 16:34, Michael Douglass wrote: > > I wouldn't call it that: mostly pressing deadlines and an assumption we'll > talk about it this week - also one of the topics may trigger a last minute > addition to the eventpub extensions. > > When do you arrive? > On 2/3/19 10:27, Bron Gondwana wrote: > > Due to lack of interest... I haven't submitted a request YET! But... it > doesn't need to be in until the end of the week, so there's still time. > let me know :) > > Bron. > > On Tue, Jan 29, 2019, at 10:12, Bron Gondwana wrote: > > Hi all, > > It's getting on time to submit meeting requests for the next face-to-face > IETF meeting! > > We have two documents that are waiting for revised drafts: > > * eventpub-extensions-10 > > * caldav-attachments-03 > > > As well as the almost ready to go jscalendar: > > * jscalendar-11 > > > I know there's also interest in bringing other items of work to this > group. From memory things that I've seen mentioned include: > > * caldav-scheduling-controls (author: me, when I write it up!) - a new > header "Scheduling-Enabled: F" to disable all scheduling when storing a > resource to a server. Good for restoring from backup as well as a way to > avoid sending updates more generally while cleaning up spam, rather than > the current "Schedule-Reply: F" which is only for resources where you are > not the organizer. > > * caldav-upgrade - a header returned by a server to tell a client that a > .ics feed is also available via read-only caldav, allowing clients to use > sync-collection for more efficient updates. > > * caldav-push - a method for delivering push updates when a calendar is > changed, allowing clients to avoid polling. > > * caldav-server-side-subscriptions - a method for federating caldav > calendars (potentially with local cached copy) such that the server acts as > a client to another server, aggregating calendars from multiple servers > into a single homeset. > > * calendar autodiscovery - I'm not sure if that's coming to this group, or > if there's going to be an attempt at renewing the more general service > autodiscovery discussion. My notes from last calconnect said it would go > to DISPATCH, but I didn't make it to the Monday of Bangkok, so I missed out. > > > .... > > Does anybody have any other work that they want to bring to this group, or > appetite to work on any of the above? I'd love to get this group flowing > smoothly and improving calendaring for everybody! I'll be at CalConnect in > Zurich next week, and I'll be asking everyone there to get involved over > here as well. > > Submissions for sessions are due Feb 8th at the latest, so do let us know > if you'll be present at Prague (or joining remotely) and have something to > talk about! > > Cheers, > > Bron (on behalf of the calext chairs) > > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > > _______________________________________________ > calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --00000000000081022b058101e90a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If lots of these topics will be discussed at Calconne= ct, it sounds to me as an indication that an IETF session would be welcome.= Having part of the discussions at the IETF would help moving proposals for= ward at the IETF as it would ease showing these proposals have reached cons= ensus and have undergone a sufficient number of reviews.
Yours,
Daniel

On Sun, Feb 3, 2019 at 1= 2:47 PM Bron Gondwana <brong@f= astmailteam.com> wrote:
Late tonight! A= ssuming my train makes it to the airport on time! I should be at the hotel = about 10pm

On Sun, Feb 3, 2019, at 16:34, Michael Douglass wrote:
=

I wouldn't call it that: mostly pressing deadlines and an assumption we'll talk about it this week - also one of the topics may trigger a last minute addition to the eventpub extensions.

When do you arrive?

On 2/3/19 10:27, Bron Gondwana wrote:
Due to lack of= interest... I haven't submitted a request YET!=C2=A0 But... it doesn't ne= ed to be in until the end of the week, so there's still time.=C2=A0 let = me know :)

Bron.
<= br>
On Tue, Jan 29, 2019, at 10:12, Bron Gondwana wrote:
Hi all,

It's getting on time to submit meeting requests for the next face-to-face IETF meeting!

We have two documents that are waiting for revised drafts:

* caldav-attachments-03

As well as the = almost ready to go jscalendar:


I know there's also interest in bringing other items of work to this group.=C2=A0 From memory things that I've seen mentioned include:

* caldav-= scheduling-controls (author: me, when I write it up!) - a new header "Scheduling-Enabled: F" to disable all scheduling when = storing a resource to a server.=C2=A0 Good for restoring from backup as well as a way to avoid sending updates more generally while cleaning up spam, rather than the current "Schedule-Reply: F= " which is only for resources where you are not the organizer.
<= /div>

* caldav-upgrade - a header returned by a server to tell a client that a .ics feed is also available via read-only caldav, allowing clients to use sync-collection for more efficient updates.

* caldav-= push - a method for delivering push updates when a calendar is changed, allowing clients to avoid polling.

* caldav-server-side-subscriptions - a method for federating caldav calendars (potentially with local cached copy) such that the server acts as a client to another server, aggregating calendars from multiple servers into a single homeset.

* calendar autodiscovery - I'm not sure if that's coming to this group, or if there's go= ing to be an attempt at renewing the more general service autodiscovery discussion.=C2=A0 My notes from last calconnect sai= d it would go to DISPATCH, but I didn't make it to the Monday o= f Bangkok, so I missed out.


....

Does anybody have any other work that they want to bring to this group, or appetite to work on any of the above?=C2=A0 I'd love to get this group flowing sm= oothly and improving calendaring for everybody!=C2=A0 I'll be at CalConnect in Zurich next week, and I'll be asking everyone there to get involved over here as well.

Submissions fo= r sessions are due Feb 8th at the latest, so do let us know if you'll be present at Prague (or joining remotely) and have something to talk about!

Cheers,
<= br>
Bron (on behalf of the calext chairs)


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


_______________________________________________
calsify mail= ing list


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



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


--=
=C2=A0 Bron G= ondwana, CEO, FastMail Pty Ltd
=C2=A0 brong@fastmailteam.com

_______________________________= ________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--00000000000081022b058101e90a-- From nobody Sun Feb 3 10:56:16 2019 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 8F80F1277D2 for ; Sun, 3 Feb 2019 10:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=McD1sAlr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jGTwmAxp 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 AVK9iXW8Szll for ; Sun, 3 Feb 2019 10:56:12 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203FC126BED for ; Sun, 3 Feb 2019 10:56:12 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D75CC21F17; Sun, 3 Feb 2019 13:56:10 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sun, 03 Feb 2019 13:56:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=tw+NKkjmtqePYDj9vhDTqn9WA N23PMiVw1xlryYEXJg=; b=McD1sAlrqHIHKzJz1666s9W1LbGLnjlAb3Cv6aEpv YDCAhQUwJwlUup/6LSc0erqsIdXetPSe6aH5kxNCwdDrqMr6HTcS/ixptaqECNYg qYUgXC94d6IjGbs/IA8Pwdy+OPfX+faryxjjt584F4N6QKAJbgfHNiRyt6/vDd6R RgIdvxfNfEkKEw1MdMcEQcOeyfSnlHd1kcPtqR2+V6jxxE/QAmNWzog+fzMXB62I ZnXtmUnvJ4oZ0ib5s7at9ay05KO17klGArJswnJ4LvoUmZyDebMm6YKT5NBmlNGE +EzJcwzsA2AwBfyZvTpEHAhHONbDulp0/NMQJjFvG4l5w== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=tw+NKkjmtqePYDj9v hDTqn9WAN23PMiVw1xlryYEXJg=; b=jGTwmAxpPRnFBdv/yP1tfdQf0hwTegc9y Qc0YUD38u1WfH7/d37TWtdYdsIQaYL8DymkDQOFjbA3ITwPdgBzQ3Xv6IaBMyW91 IXz0ceJNx3ftiphucXAZi+uX8ZlnALfqIcYjc0FYGeLOg4/+Tku/N7AsKD/fdU/4 UXxPDoFpBLjiZwvJoYWcIYazDI1FxEZlCJdBTXcX++RHIT5xAWMzZuB1+mY7h8xt L8q5qKtFdTqmVj66oxtLStnA2Sbv+u5367sOYSeEzmrTLe9BuJtPn1QFKmpPCHfP 7EKDRkCU4VPBen8ytAsmlOY5oOMDVFVQRNMfKJfCmF2O/twbztJDA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrkedvgdduvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefofgfkjghfff fhvffutgesrgdtreerreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcu oegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivg htfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgr ihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 720C4203BD; Sun, 3 Feb 2019 13:56:10 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 56629417 Message-Id: <89bad68f-fe0f-47e7-8d57-034c9153a326@beta.fastmail.com> In-Reply-To: References: <68d00c8a-13df-4c17-ada2-8af2d6777fcf@www.fastmail.com> <92b94be5-f3aa-4d41-aee1-77de3ea8bc9f@www.fastmail.com> <0a5f6b27-420c-10d7-bc71-16c86e27cdb4@gmail.com> <069aa616-fa30-4278-a0ab-5a52529386c0@beta.fastmail.com> Date: Sun, 03 Feb 2019 13:56:10 -0500 From: "Bron Gondwana" To: "Daniel Migault" Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary=443e411c9bc2419bbcff395701a03bd4 Archived-At: Subject: Re: [calsify] Shall we meet in Prague? (also: what shall we work on?) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2019 18:56:15 -0000 --443e411c9bc2419bbcff395701a03bd4 Content-Type: text/plain Ok! I'll chat with Mike tomorrow and also see who can make it to Prague either in person or virtually. On Sun, Feb 3, 2019, at 19:55, Daniel Migault wrote: > If lots of these topics will be discussed at Calconnect, it sounds to me as an indication that an IETF session would be welcome. Having part of the discussions at the IETF would help moving proposals forward at the IETF as it would ease showing these proposals have reached consensus and have undergone a sufficient number of reviews. > > Yours, > Daniel > > On Sun, Feb 3, 2019 at 12:47 PM Bron Gondwana wrote: >> __ >> Late tonight! Assuming my train makes it to the airport on time! I should be at the hotel about 10pm >> >> On Sun, Feb 3, 2019, at 16:34, Michael Douglass wrote: >>> I wouldn't call it that: mostly pressing deadlines and an assumption we'll talk about it this week - also one of the topics may trigger a last minute addition to the eventpub extensions. >>> When do you arrive? >>> On 2/3/19 10:27, Bron Gondwana wrote: >>>> Due to lack of interest... I haven't submitted a request YET! But... it doesn't need to be in until the end of the week, so there's still time. let me know :) >>>> >>>> Bron. >>>> >>>> On Tue, Jan 29, 2019, at 10:12, Bron Gondwana wrote: >>>>> Hi all, >>>>> >>>>> It's getting on time to submit meeting requests for the next face-to-face IETF meeting! >>>>> >>>>> We have two documents that are waiting for revised drafts: >>>>> >>>>> * eventpub-extensions-10 >>>>> * caldav-attachments-03 >>>>> >>>>> As well as the almost ready to go jscalendar: >>>>> >>>>> * jscalendar-11 >>>>> >>>>> I know there's also interest in bringing other items of work to this group. From memory things that I've seen mentioned include: >>>>> >>>>> * caldav-scheduling-controls (author: me, when I write it up!) - a new header "Scheduling-Enabled: F" to disable all scheduling when storing a resource to a server. Good for restoring from backup as well as a way to avoid sending updates more generally while cleaning up spam, rather than the current "Schedule-Reply: F" which is only for resources where you are not the organizer. >>>>> >>>>> * caldav-upgrade - a header returned by a server to tell a client that a .ics feed is also available via read-only caldav, allowing clients to use sync-collection for more efficient updates. >>>>> >>>>> * caldav-push - a method for delivering push updates when a calendar is changed, allowing clients to avoid polling. >>>>> >>>>> * caldav-server-side-subscriptions - a method for federating caldav calendars (potentially with local cached copy) such that the server acts as a client to another server, aggregating calendars from multiple servers into a single homeset. >>>>> >>>>> * calendar autodiscovery - I'm not sure if that's coming to this group, or if there's going to be an attempt at renewing the more general service autodiscovery discussion. My notes from last calconnect said it would go to DISPATCH, but I didn't make it to the Monday of Bangkok, so I missed out. >>>>> >>>>> >>>>> .... >>>>> >>>>> Does anybody have any other work that they want to bring to this group, or appetite to work on any of the above? I'd love to get this group flowing smoothly and improving calendaring for everybody! I'll be at CalConnect in Zurich next week, and I'll be asking everyone there to get involved over here as well. >>>>> >>>>> Submissions for sessions are due Feb 8th at the latest, so do let us know if you'll be present at Prague (or joining remotely) and have something to talk about! >>>>> >>>>> Cheers, >>>>> >>>>> Bron (on behalf of the calext chairs) >>>>> >>>>> >>>>> -- >>>>> Bron Gondwana, CEO, FastMail Pty Ltd >>>>> brong@fastmailteam.com >>>>> >>>>> >>>>> _______________________________________________ >>>>> calsify mailing list >>>>> calsify@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/calsify >>>>> >>>> >>>> -- >>>> Bron Gondwana, CEO, FastMail Pty Ltd >>>> brong@fastmailteam.com >>>> >>>> >>>> >>>> _______________________________________________ calsify mailing list >>>> calsify@ietf.org >>>> https://www.ietf.org/mailman/listinfo/calsify >>>> >>> _______________________________________________ >>> calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify >>> >> >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --443e411c9bc2419bbcff395701a03bd4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Ok! I'll chat with Mike tomorrow and also see who can make= it to Prague either in person or virtually.

On Sun, Feb 3, 2= 019, at 19:55, Daniel Migault wrote:
If lots of these topics wil= l be discussed at Calconnect, it sounds to me as an indication that an I= ETF session would be welcome. Having part of the discussions at the IETF= would help moving proposals forward at the IETF as it would ease showin= g these proposals have reached consensus and have undergone a sufficient= number of reviews.

Yours,
= Daniel

On Sun, Feb 3, 2019 at 12:47 PM Bron Gondwana <brong@fastmailteam.com> wr= ote:

=
Late tonight! Assuming my t= rain makes it to the airport on time! I should be at the hotel about 10p= m

On Sun, Feb 3, 2019, at 16:34, Michael Douglass wrote:<= br>

I wouldn't call it that: mostly pressing= deadlines and an assumption we'll talk about it this week - also one of the topics may trigger a last minute addition to the eventpub extensions.
=

When do you arrive?

On 2/3/19 10:27, Bro= n Gondwana wrote:
Due to lack of interest... I haven't submitted a request YET!  But... it doesn't need to= be in until the end of the week, so there's still time.  let m= e know :)

Bron.

On Tue, Jan 29, 2019= , at 10:12, Bron Gondwana wrote:
Hi all,

It's getting = on time to submit meeting requests for the next face-to-face IETF meeting!

We have two documents that are waiting for revised drafts:


As well as the almost rea= dy to go jscalendar:

=
* jscalendar-11

I know there's also interest in bringing other items of work to this group.  From memory things that I've seen mentioned include:

* calda= v-scheduling-controls (author: me, when I write it up!) - a new header "Scheduling-Enabled: F" to disable all scheduling when storing= a resource to a server.  Good for restoring from backup a= s well as a way to avoid sending updates more generally while cleaning up spam, rather than the current "Schedule-Reply: F" which is only for resources where you are not the organizer.

* caldav-upgrade - a header returned by a server to tell a client that a .ics feed is also= available via read-only caldav, allowing clients to use sync-collection for more efficient updates.

* c= aldav-push - a method for delivering push updates when a calendar is changed, allowing clients to avoid polling.

* caldav-server-side-subscriptions - a method for federating caldav calendars (potentially with local cached copy) such that the server acts as a client to another server, aggregating calendars from multiple servers into a single homeset.

=
* calendar autodiscovery - I'm not sure if that's coming to this group, or if there's going to be an attempt at renewing the more general service autodiscovery discussion.  My notes from last calconnect = said it would go to DISPATCH, but I didn't make it to the Monday of= Bangkok, so I missed out.


....
Does anybody have any other wor= k that they want to bring to this group, or appetite to work on any of the above?  I'd love to get this group flowing smo= othly and improving calendaring for everybody!  I'll be at CalConnect in Zurich next week, and I'll be asking everyone there to get involved over here as well.

Submiss= ions for sessions are due Feb 8th at the latest, so do let us know if you'll be present at Prague (or joining remotely) and have something to talk about!

Cheers,=

Bron (on behalf = of the calext chairs)

--
 = brong@f= astmailteam.com


______________________= _________________________
calsify mailing list
calsify@iet= f.org


--
  Br= on Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.= com



_______________________________________________
calsify mailing list
calsify@ietf.o=
rg
https://www.ietf.org/mailman/listinfo/calsify
____________________________________________= ___
calsify mailing list


--
  Bron Gondwana, CEO, FastMail Pty Ltd
<= /div>
  brong@fastmailteam.com=

______= _________________________________________
calsify mailing list

--
  Bron Gondwana, CEO, = FastMail Pty Ltd
  brong@fastmail= team.com

--443e411c9bc2419bbcff395701a03bd4-- From nobody Mon Feb 4 09:10:21 2019 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 80497130EA0 for ; Mon, 4 Feb 2019 09:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 32A4XmRNOtpg for ; Mon, 4 Feb 2019 09:10:13 -0800 (PST) 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 A20C8130E86 for ; Mon, 4 Feb 2019 09:10:13 -0800 (PST) Received: from smtp.ucolick.org (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id 7626629D7; Mon, 4 Feb 2019 09:10:12 -0800 (PST) Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) by smtp.ucolick.org (Postfix) with ESMTP id 7255729BA; Mon, 4 Feb 2019 09:10:12 -0800 (PST) Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (Postfix) with ESMTP id 665E21FC; Mon, 4 Feb 2019 09:10:12 -0800 (PST) Received: (from sla@localhost) by geneva.ucolick.org (8.14.7/8.14.7/Submit) id x14HABQQ024149; Mon, 4 Feb 2019 09:10:11 -0800 Date: Mon, 4 Feb 2019 09:10:11 -0800 From: Steve Allen To: Bernard Desruisseaux Cc: Keith Harris , IETF Calsify Message-ID: <20190204171011.GG31448@ucolick.org> References: <20180926090958.74B27B8108E@rfc-editor.org> <983178de-f430-2115-0579-be861b198059@cisco.com> <19EFCA1E91A6F59ABAE023F7@cyrus.local> <20180927162923.GA12451@ucolick.org> <034024CF-6623-4255-AD2C-D9C9204A1AC2@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <034024CF-6623-4255-AD2C-D9C9204A1AC2@oracle.com> 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: Mon, 04 Feb 2019 17:10:20 -0000 On Mon 2018-10-01T12:57:14-0400 Bernard Desruisseaux hath writ: > Have you considered requesting the addition of these missing time zones to the IANA Time Zone database? > Etc/GMT-20 > Etc/GMT-23 > Etc/GMT-0330 (or whatever TZID IANA comes up with) I think the first two (Lick and Keck time) are akin to convenience stores in northeast Arizona which set their clocks differently than the surrounding regions. The ICU/CLDR code and naming scheme do not even include the counties in Indiana which have unique time zone history. A public database which must be squished into the memory of internet-of-things devices needs a limit on the number of named specialist cases. My objection is to interfaces which only tolerate the enumerated cases in some database and do not allow custom offsets. -- 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 https://www.ucolick.org/~sla/ Hgt +250 m From nobody Tue Feb 5 05:42:08 2019 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 7DDE31294D0; Tue, 5 Feb 2019 05:42:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: brong@fastmailteam.com, calsify@ietf.org, calext-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154937412647.32203.10917321712527175223.idtracker@ietfa.amsl.com> Date: Tue, 05 Feb 2019 05:42:06 -0800 Archived-At: Subject: [calsify] calext - New Meeting Session Request for IETF 104 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2019 13:42:06 -0000 A new meeting session request has just been submitted by Bron Gondwana, a Chair of the calext working group. --------------------------------------------------------- Working Group Name: Calendaring Extensions Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 6 Conflicts to Avoid: First Priority: jmap extra dispatch People who must be present: Alexey Melnikov Donald E. Eastlake 3rd Daniel Migault Bron Gondwana Resources Requested: Special Requests: We have some people would like to participate remotely from the USA, so please give us an afternoon slot. --------------------------------------------------------- From nobody Sun Feb 10 16:58:14 2019 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 DFAB9130E68 for ; Sun, 10 Feb 2019 16:58:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154984669291.14527.10484999556340635933.idtracker@ietfa.amsl.com> Date: Sun, 10 Feb 2019 16:58:12 -0800 From: IETF Secretariat Archived-At: Subject: [calsify] Milestones changed for calext WG X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 00:58:13 -0000 Changed milestone "Send attachment dratf to IESG", set due date to June 2019 from June 2018. Changed milestone "Send Event Publication draft to IESG", set due date to June 2019 from June 2018. Changed milestone "Send iCal relation draft to IESG", set due date to June 2019 from June 2018. Changed milestone "Send JSCalendar draft to IESG", set due date to June 2019 from September 2018. URL: https://datatracker.ietf.org/wg/calext/about/ From nobody Mon Feb 11 05:29:30 2019 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 A86F2130E8F for ; Mon, 11 Feb 2019 05:29:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154989176868.18726.18177187842342762413.idtracker@ietfa.amsl.com> Date: Mon, 11 Feb 2019 05:29:28 -0800 From: IETF Secretariat Archived-At: Subject: [calsify] Milestones changed for calext WG X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 13:29:29 -0000 Changed milestone "Update charter to reflect current and planned work", set state to active from review, accepting new milestone, set description to "Update charter/milestones to reflect current and planned work". URL: https://datatracker.ietf.org/wg/calext/about/ From nobody Wed Feb 13 07:55:20 2019 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 BC403126C7E for ; Wed, 13 Feb 2019 07:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=uaks2e7k; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=r1kBaxZX 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 zU3DnXc_nEYR for ; Wed, 13 Feb 2019 07:55:18 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 177DD1200ED for ; Wed, 13 Feb 2019 07:55:18 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D4EDE221D6 for ; Wed, 13 Feb 2019 10:55:16 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 13 Feb 2019 10:55:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm1; bh=tlstN+3Dws4QbVk8GGX2cyZ/0ovBXU0fEP03rqT +Cbs=; b=uaks2e7kLsqQ5K3nSkUaN6BFw/LFxWh3Kwj60t9NpEfx6A8Dmf6hyb1 +ZN+dU2pjUyI81xzKMLg93ujMZTnnOSW5e+KktIg1rZBxdETvo9UUGcJvRyUemjn 3CcYRdTcwpS4Oj3BhOO52F3K4PwdKvYjLu4sclzSCDBTkKz16dhd1oNSLPoaVWgv OB5UqIX04YUXIdlFcPsgSOm5umKKkCCVxYgGa9ixZHYMCFYriIC2ZpBOrAfYv1lJ y702X6j1uErVJZq5T5eY1InbKlKeIPbDgAUfWPAtgOMv/phkAiGFiekCD307ZShF MkchyOSe775Tl5pxL7SYAp6ri6gs5Uw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=tlstN+3Dws4QbVk8GGX2cyZ/0ovBXU0fEP03rqT+Cbs=; b=r1kBaxZX OFYFfPdV4q2yEjo5vXgZxiMuDfigU6Ss2ubDPelpvnlWRhhNVQgRoxrmsNqyJRDQ vSkTGUg6YepRdUy6sXEzglyC6UgFdN2g/t0Q7BClf8r0RiOtX1aGMsJ5NufHrRzX 8aHOxNED6O8NtJj6QAye6LQmMQheyDwmntFntfBzYMZ2nvNuxktzjvDsh2Rd77sJ FrzIKmFpE2ejsVp4StXw4aVVVdj9XHIk0TFsEWno+hMjrVpmMF+F9yuhZCSjb7iR QNNrvv1oHvxrWIqCjiHe7TLMYQ872IocX1TtRdfFRiFGcSyAsHudVqwxdQxYU6OA tUHv5pXGGelCKA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtfedgkeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepofgfkfffhffvufgtsegrtderreerreejnecuhfhrohhmpedfue hrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgt ohhmqeenucffohhmrghinhepihgtrghnnhdrohhrghdpfhgrshhtmhgrihhlrdhfmhenuc frrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4516620250; Wed, 13 Feb 2019 10:55:16 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 56629417 Message-Id: <06b6d3d8-d4d6-44da-9bc6-c565471ef09d@www.fastmail.com> Date: Wed, 13 Feb 2019 10:55:15 -0500 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=b92123efe4f04aed9bd15cf07a938867 Archived-At: Subject: [calsify] Notes from CalConnect in Zurich, Feb 2019 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 15:55:20 -0000 --b92123efe4f04aed9bd15cf07a938867 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi All, Sorry for the delay in summarising all this. I thought I should email he= re with a summary of the key CALEXT related things we discussed at CalCo= nnect last week. *TimeZones:* See also: https://mm.icann.org/pipermail/tz/2019-February/027503.html fo= r the discussion on the TZ list. We have RFC7808 and RFC8536 for standard representations of timezone dat= a, but there aren't public servers or a standard practice of vendors pro= viding fast updates, leading to the ongoing problem of late-stage politi= cal updates causing software and devices to be out of sync. * ISO is working on their own process for timezones per country and a n= on-country "community zones". * IANA have already taken over the Olsen zones and keep them updated (s= ee RFC6557) * Microsoft have their own separate database * IATA already have a database which is government provided and verifie= d and used by airlines The main issues with any faster update process are oversight and verific= ation - somebody could do things like attack the stock market by interfe= ring with timezone data updates. There are also issues with location -> zone mapping and timezone naming,= mostly political (eg: disputed territories). There's a proposal to give zones non-name IDs rather than names, and als= o accurate geo boundaries. Using that, people could choose between zones= which were verified to be used within or claimed to cover any particula= r area, and vendors could ship their own names or even localised names f= or any particular zone ID. Next steps: see if IANA is interested in running a tzdata server that ca= n be used for direct lookups (and how that would be funded), and talk to= the tz group about working with ISO. *JSCalendar:* * Robert will follow up on that! There were a few last minute clarifica= tions * I did a Perl implementation which I will publish shortly. *IETF and CalConnect:* I did a presentation about taking documents to IETF and why CalConnect s= hould continue to do that! There's a known cultural mismatch which I am = attempting to bridge! I have uploaded my slides here: http://talks.brong.fastmail.fm/calconnect-feb2019/calconnect-ieft.pdf I didn't take notes during my talk (obviously), but it was a good kickof= f for the discussion about our exisiting drafts, which I'll paste below:= * Managed Attachments - nearly complete * *Ken* will finish * VPOLL * Need to lock down poll * *Mike*! (Ken can help with) * VALARM Extensions * Draft written by Cyrus Daboo * Main one we want to keep is acknowledgement - Apple, Thunderbird su= pport * Probably *Ken*? (currently co-author) * Considering removing Apple=E2=80=99s =E2=80=9Cdefault alarms=E2=80=9D= hack. * Avoid server putting defaults back on! * Proximity alarm (Apple already using) * If close to supermarket, fire an alarm! * Specify if you want an alarm, and how important the event is for yo= u. * "Is it really important for me to get to this event?" * Spend time in TC-CALENDAR debating if we want to change behaviour? * SECOND DRAFT * ALARM AGENT =E2=86=92 client/server. * Related events =E2=86=92 * alarm tied to multiple events? * X-travel-time? Client side will decide when to notify, not server s= ide at all with Android * Proprietary API anyway. * Subscription Upgrade * Smart updates to an ICS feed * Conditional request with a prefer header. * Adds =E2=80=9CStatus DELETED=E2=80=9D. * OPTIONS =E2=86=92 can specify what=E2=80=99s available. * Is =E2=80=9CeTag=E2=80=9D being used? Need to use weak eTag. * Does it support pagination? NO! * A header that says =E2=80=9Cstill more changes=E2=80=9D. * A way to say =E2=80=9Cthere=E2=80=99s been a change=E2=80=9D =E2=86= =92 aka push. * Author: *Mike* - individual submission (rev 3) * Ask HTTPBIS to look at it. * CalDAV Sharing =E2=86=92 * what Apple has already implemented * is 3 drafts * DAV Notifications * DAV sharing * CALDAV sharing * Author: Evert wrote originally (*Ken* to take on authorship?) * MAY WANT TO STANDARDISE Per-USER write capability * Put into DAV namespace (also useful for Contacts/CardDAV and maybe = more?) * *Go via Dispatch*? * Per user notes on a vcard? * TODO: organizer, owner, etc in the caldav part. * VPATCH * Cyrus Daboo originated * Reduce client/server chatter. * Describes how to use it with RFC PATCH method. * ENHANCED CalDAV sync * VINSTANCE * Effort to reduce size of recurring events with a bunch of overrides= .=20 * Suggestion: Punt these three in favour of JSCalendar. * Informational draft =E2=86=92 or DEVGUIDE. List all the resources a= developer needs for a caldav client/server. * SCHEDULING CONTROLS * *Bron *wrote this * draft submitted to IETF already * will propose to calext that it gets adopted Documents that are in the queue and we think should go to the IETF: * scheduling * valarm * vpoll (there=E2=80=99s some iTIP stuff, but it=E2=80=99s our domain) * subscription upgrade - needs http input * caldav sharing - same My suggestion to the group was - submit ALL of these to calext and get i= nitial drafts published within the working group, then progress each of = them as there is interest and time to work on them. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --b92123efe4f04aed9bd15cf07a938867 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi All,
Sorry for the delay in summari= sing all this. I thought I should email here with a summary of the key C= ALEXT related things we discussed at CalConnect last week.

TimeZones:

See also: https://mm.icann.org/piperm= ail/tz/2019-February/027503.html for the discussion on the TZ list.<= br>

We have RFC7808 and RFC8536 for standard representations = of timezone data, but there aren't public servers or a standard practice= of vendors providing fast updates, leading to the ongoing problem of la= te-stage political updates causing software and devices to be out of syn= c.

  • ISO is working on their own process for timezones p= er country and a non-country "community zones".
  • IANA have already taken over the Olsen zones and keep t= hem updated (see RFC6557)
  • Micro= soft have their own separate database
  • IATA already have a database which is government provided and ver= ified and used by airlines

The main issues with any f= aster update process are oversight and verification - somebody could do = things like attack the stock market by interfering with timezone data up= dates.

There are also issues with location -> zone mapp= ing and timezone naming, mostly political (eg: disputed territories).

There's a proposal to give zones non-name IDs rather than n= ames, and also accurate geo boundaries.  Using that, people could c= hoose between zones which were verified to be used within or claimed to = cover any particular area, and vendors could ship their own names or eve= n localised names for any particular zone ID.

Next steps:= see if IANA is interested in running a tzdata server that can be used f= or direct lookups (and how that would be funded), and talk to the tz gro= up about working with ISO.
JSCalendar:

  • Robert will follow up on that!  There were a few last minute= clarifications
  • I did a Perl im= plementation which I will publish shortly.

IETF an= d CalConnect:

<= div style=3D"font-family:Arial;">I did a presentation about taking docum= ents to IETF and why CalConnect should continue to do that!  There'= s a known cultural mismatch which I am attempting to bridge!  I hav= e uploaded my slides here:

I d= idn't take notes during my talk (obviously), but it was a good kickoff f= or the discussion about our exisiting drafts, which I'll paste below:

  • Managed Attac= hments - nearly complete
    • Ken will finish
  • VPOLL=
    • Need to lock down poll
      =
    • Mike!  (Ken can help w= ith)
  • VALARM Extensions
    =
    • Draft written by Cyrus Daboo
    • Main one we want to keep is ackn= owledgement - Apple, Thunderbird support
    • Probably Ken?  (currently co-author)
    • Considering removing Apple=E2=80=99s =E2=80=9C= default alarms=E2=80=9D hack.
      • Avoid server putting defaults back on!
    • Proximity alarm (Apple already using)
      • If close to supermarket, fire an alarm!
    • Specify if you want an alarm, a= nd how important the event is for you.
    • "Is it really important for me to get to this event?"
      • Spend time in TC-CALENDAR debating if we = want to change behaviour?
    • SECON= D DRAFT
    • ALARM AGENT =E2=86=92 c= lient/server.
    • Related events =E2= =86=92
    • alarm tied to multiple e= vents?
    • X-travel-time?  Cli= ent side will decide when to notify, not server side at all with Android=
    • Proprietary API anyway.
  • Subscription Upgrade
  • Smart updates to an ICS feed
    • <= li style=3D"font-family:Arial;">Conditional request with a prefer header= .
  • Adds =E2=80=9CStatus DELETED=E2= =80=9D.
  • OPTIONS =E2=86=92 can s= pecify what=E2=80=99s available.
  • Is =E2=80=9CeTag=E2=80=9D being used?  Need to use weak eTag.
    =
  • Does it support pagination?  = NO!
    • A header that says =E2=80= =9Cstill more changes=E2=80=9D.
  • A way to say =E2=80=9Cthere=E2=80=99s been a change=E2=80=9D =E2=86= =92 aka push.
  • Author: Mike - individual submission (rev 3)
  • Ask HTTPBIS to look at it.
  • CalDAV Sharing =E2=86=92
    • what Apple has already implemented
    • is 3 drafts
    • DAV Notifica= tions
    • DAV sharing
    • CALDAV sharing
    • Author: Evert wrote originally  (Ken to take on = authorship?)
    • MAY WANT TO STANDA= RDISE Per-USER write capability
    • Put into DAV namespace (also useful for Contacts/CardDAV and maybe more= ?)
    • Go via Dispatch?
      <= /li>
    • Per user notes on a vcard?
      • =
    • TODO: organizer, owner, etc in the cald= av part.
  • VPATCH
  • Cyrus Daboo originated
  • Reduce client/server chatter.
  • Describes how to use it with RFC PATCH method.=
  • ENHANCED CalDAV sync
    • <= /ul>
  • VINSTANCE
    • Effort to reduce size of recurring events with a bun= ch of overrides.  
    • Suggest= ion: Punt these three in favour of JSCalendar.
    • Informational draft =E2=86=92 or DEVGUIDE.  List al= l the resources a developer needs for a caldav client/server.
    • SCHEDULING CONTROLS
      • Bron wrote this
      • draft submitted to IETF already
      • will propose to calext that it gets adopted
    =
    Documents that are in the = queue and we think should go to the IETF:
    • scheduling
    • valarm
    • vpoll (there=E2=80=99s some iTIP stuff, but it=E2=80=99s= our domain)
    • subscription upgrade - needs http input
    • caldav sharing - same

    My suggestion = to the group was - submit ALL of these to calext and get initial drafts = published within the working group, then progress each of them as there = is interest and time to work on them.



    --
      Bron Gondwana, C= EO, FastMail Pty Ltd
      brong@fast= mailteam.com


    --b92123efe4f04aed9bd15cf07a938867-- From nobody Wed Feb 13 10:37:41 2019 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 8999C128766 for ; Wed, 13 Feb 2019 10:37:39 -0800 (PST) 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 S86KD4DZFGiK for ; Wed, 13 Feb 2019 10:37:38 -0800 (PST) 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 16D66126F72 for ; Wed, 13 Feb 2019 10:37:38 -0800 (PST) Received: from smtp.ucolick.org (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id 0A68429E4 for ; Wed, 13 Feb 2019 10:37:37 -0800 (PST) Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) by smtp.ucolick.org (Postfix) with ESMTP id 0795B2827 for ; Wed, 13 Feb 2019 10:37:37 -0800 (PST) Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (Postfix) with ESMTP id 02A76192 for ; Wed, 13 Feb 2019 10:37:37 -0800 (PST) Received: (from sla@localhost) by geneva.ucolick.org (8.14.7/8.14.7/Submit) id x1DIbadr028950 for calsify@ietf.org; Wed, 13 Feb 2019 10:37:36 -0800 Date: Wed, 13 Feb 2019 10:37:36 -0800 From: Steve Allen To: calsify@ietf.org Message-ID: <20190213183736.GA28885@ucolick.org> References: <06b6d3d8-d4d6-44da-9bc6-c565471ef09d@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <06b6d3d8-d4d6-44da-9bc6-c565471ef09d@www.fastmail.com> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [calsify] Notes from CalConnect in Zurich, Feb 2019 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 18:37:39 -0000 On Wed 2019-02-13T10:55:15-0500 Bron Gondwana hath writ: > I thought I should email here with a summary of the key CALEXT > related things we discussed at CalConnect last week. > Next steps: see if IANA is interested in running a tzdata server > that can be used for direct lookups (and how that would be funded), > and talk to the tz group about working with ISO. Do you mean a tzdist server? Following along that, in the discussion I believe I heard folks ruminating that it might be about a half-day of hacking to create an application that could query data from a tzdist server and convert it into information for /usr/share/zoneinfo on a Linux system, and that could become a prototype for other similar systems that want to get new zone info without needing an operating system patch. Did I actually hear that, who was suggesting it, and does it seem likely that someone will write code like that? -- 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 https://www.ucolick.org/~sla/ Hgt +250 m From nobody Wed Feb 13 11:08:01 2019 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 E966B127287 for ; Wed, 13 Feb 2019 11:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaGDi-bLaYa2 for ; Wed, 13 Feb 2019 11:07:57 -0800 (PST) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 F399A1200D7 for ; Wed, 13 Feb 2019 11:07:56 -0800 (PST) Received: by mail-qt1-x842.google.com with SMTP id a48so3945486qtb.4 for ; Wed, 13 Feb 2019 11:07:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=eJ4JHB1N2OgU4Q3deTYrZlxtDC0mk+0CZjJ2meWD1gc=; b=HoeO9GIcqWYu2ax3dsHw7Y2N2ES42w8HM1XYbEyXlP4P3KkCuCUewBfUz6OqYKAWNf yr8h/WR0MwzqMY6MovZhmev7OVVxyL8+T1BXGHbzHpEP6lVIw5teP6uDZByjn2xk8V2U A1z+2CixAsELvrR0Rm8Ox62giTls4/bpKWQ19Ip1Lrm+QLKm9Z17C2h4qtvhWwf6b1FL QaZU+NfqoYYabIDSW2gy18N4w53tMewaYGFQsDmA5QMEDwVcPYRynDclRI4oeBhLOKuJ v0aR/Ay51RRagOvBIW/xY5stMO9r7J8y1+z20ruEmQU26bFoGTN6eysei+XiXkEe6AJz Lt+A== 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=eJ4JHB1N2OgU4Q3deTYrZlxtDC0mk+0CZjJ2meWD1gc=; b=pA//eBSHPSIJNFcg8JiAX1HpQE0yi08OZS+winee674Q5gy+9lVqykbra+L6xuP7WN BqXooDmZF7rnAahSumpzHcqZ8jMvBN/jCyFP0pVVU+ifyGGkCJb+vOM4Td2MGFxVZtdf 84oWpjwNlab7hzU+aAxFvIm7N4zeUlrPKHqyOYStV/JvehwsXSNQK1eyrVgPq+elaUlx PFR5nVaiT0VpnsO94S1MVvj45KlOx5NE8gciZMbVfakETscn3OEj30s1aIgLpZxYnVMe KFImRWnbttR3s2I3xo5c9uAgQgh+NmzuTZYeSeJL1k2+7uviAq4vjuF8BAZoD0v8aiqT 7vzw== X-Gm-Message-State: AHQUAuYslyLjv/PcGjC+X491+v+STca+6UbiY35xFsAh+Lnf+2zn7Gs5 ng7eD6rBNQTGf1TAg5Vho9tnwqID X-Google-Smtp-Source: AHgI3IajY9u4ZN6tQ8ka7FFNUGFnZLIpRCmuyna7iKBbP6Gk5YMk57fTWTXjZtARNve5RbmqmqPtMg== X-Received: by 2002:ac8:38cd:: with SMTP id g13mr1665671qtc.167.1550084875396; Wed, 13 Feb 2019 11:07:55 -0800 (PST) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id 12sm28972qka.83.2019.02.13.11.07.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Feb 2019 11:07:54 -0800 (PST) To: calsify@ietf.org References: <06b6d3d8-d4d6-44da-9bc6-c565471ef09d@www.fastmail.com> <20190213183736.GA28885@ucolick.org> From: Michael Douglass Message-ID: <7926125d-a712-35e3-0363-f9db2b07eb63@gmail.com> Date: Wed, 13 Feb 2019 14:07:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <20190213183736.GA28885@ucolick.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [calsify] Notes from CalConnect in Zurich, Feb 2019 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 19:08:00 -0000 I think we (Ken) were challenged to modify a linux distribution to use a tzdist server to get the tz info. And yes - I think it was felt a simple script using curl could do the job On 2/13/19 13:37, Steve Allen wrote: > On Wed 2019-02-13T10:55:15-0500 Bron Gondwana hath writ: >> I thought I should email here with a summary of the key CALEXT >> related things we discussed at CalConnect last week. >> Next steps: see if IANA is interested in running a tzdata server >> that can be used for direct lookups (and how that would be funded), >> and talk to the tz group about working with ISO. > Do you mean a tzdist server? > > Following along that, in the discussion I believe I heard folks > ruminating that it might be about a half-day of hacking to create an > application that could query data from a tzdist server and convert it > into information for /usr/share/zoneinfo on a Linux system, and that > could become a prototype for other similar systems that want to get > new zone info without needing an operating system patch. > > Did I actually hear that, who was suggesting it, and does it seem > likely that someone will write code like that? > > -- > 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 https://www.ucolick.org/~sla/ Hgt +250 m > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Thu Feb 14 08:02:12 2019 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 601331311AF for ; Thu, 14 Feb 2019 08:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=1eMNGjj8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3zfOmnUC 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 6M6jBMOWb34I for ; Thu, 14 Feb 2019 08:01:53 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF9B13119D for ; Thu, 14 Feb 2019 08:01:53 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id AF628221B7 for ; Thu, 14 Feb 2019 11:01:52 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 14 Feb 2019 11:01:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:date:subject; s=fm1; bh= hPPtGRwoCdGxEMVhwoOf2LERuNRnwTRCTorQxLeSMnU=; b=1eMNGjj8JrNsK3nI b4CIA2aQpyasIvC5t+ut3m+m0zUzZzMeUrcl4/IJ6ap5QT3gC4qZYwgT5gVRov8+ Nly+5EiVij1yfEZ3DDPNPdjT2/rptCLSWDgDJ6buApLaW7j4j839vJbLBG6Xx+yj vyQtBnKtbhtPs5dbXwUWhPNAw7YaSRXBr3n0mJ4oNjRyLLImDm2GaGTS7xoyFpSL jEMuG1v8XpbROMu88SxpsQKrUbuy7/yzZZcfXZwqZ9M0rIHRi5wST2zKwL+XrNe1 DqbH4SKccX/ASjuqOdAz22PhDIpN/X2hjesCIrXz9PbdHOwgPFcRaBIv3b76rPEt lSrL5Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=hPPtGR woCdGxEMVhwoOf2LERuNRnwTRCTorQxLeSMnU=; b=3zfOmnUCbui1al7Q+x/ZNu +RhQzBg3YzxfRayoougiL8O7Xvntxhen4oF1y1ROY+bmUrYVxHXhLb2tjIquSYEL PMbE8L35DZZikPwxkXpy1eXIVwagbLIe3FqRCGU7jaJqOLWThtR/5m3psz4uMrsP bioG+HWS1R0XzGCkpijGRrq+MJbmOZAudY5VQkBJUCUAGOM4bdP4GORnSUJYU0Eu mF8aQGPc0wHGW9qSjepc4MXPAysg9UJh6MF8hZO7eMeE/v91uX9STdqO62eL0tnu HBIGSCrX6/67KYpmnVDNORW/257DURLkdaSbHpmoqL0ckb17KK21jQj7EI4x3UgA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddthedgkeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlnecuuegrihhlohhuthemuceftddtnecu necujfgurhepkffhvfgggfgtofffufesrgejreerredtjeenucfhrhhomheptfhosggvrh htucfuthgvphgrnhgvkhcuoehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeen ucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrsh htohesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B5B26E22F9; Thu, 14 Feb 2019 11:01:51 -0500 (EST) Message-Id: <1550160111.3612386.1658010576.0F11D14D@webmail.messagingengine.com> From: Robert Stepanek To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_155016011136123860" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e97eb308 Date: Thu, 14 Feb 2019 17:01:51 +0100 Archived-At: Subject: [calsify] JSCalendar timezones 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, 14 Feb 2019 16:02:03 -0000 This is a multi-part message in MIME format. --_----------=_155016011136123860 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" At CalConnect XLIV last week, the need for a non-IANA time zone identifiers and custom time zone definitions was raised. We'd like to discuss options how to support them in JSCalendar. Currently, an event's timezone in JSCalendar is defined in the timeZone property, which is of string type. Its value must be a name in the IANA time zone database, or null for floating time (see the latest spec here[1]). We discussed, if to replace the string value with a URI. That way we could either use a IANA time zone database name in a to be defined URI scheme, or e.g. could embed custom VTIMEZONEs in a data URI.However, on second thought we'd rather prefer a different solution, because URIs in iCalendar parameters could cause breakage on ill- behaving clients. There also wouldn't be an obvious urn namespace or URI scheme to use for IANA names, AFAIK. Alternatively, we could keep the time zone identifier as string value, and use the same escape mechanism with a SOLIDUS character as specified in RFC 5545 (see section 3.8.3.1[2]). All time zone identifiers that do not start with SOLIDUS must be an IANA time zone. For custom timezones, we might want to consider defining a JSON representation of time zones, which could be defined in a timeZones property on the JSCalendar object, keyed by their time zone identifier. Do you have other suggestions on how to handle non-IANA timezones in JSCalendar? Cheers, Robert Links: 1. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11 2. https://tools.ietf.org/html/rfc5545#section-3.8.3.1 --_----------=_155016011136123860 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
    At CalConnect XLIV last week, the need for a non-IANA time zone identifiers and custom time zone definitions was raised. We'd like to discuss options how to support them in JSCalendar.

    Currently, an event's timezone in JSCalendar is defined in the timeZone property, which is of string type.  Its value must be a name in the IANA time zone database, or null for floating time (see the latest spec here).

    We discussed, if to replace the string value with a URI. That way we could either use a IANA time zone database name in a to be defined URI scheme, or e.g. could embed custom VTIMEZONEs in a data URI.
    However, on second thought we'd rather prefer a different solution, because URIs in iCalendar parameters could cause breakage on ill-behaving clients. There also wouldn't be an obvious urn namespace or URI scheme to use for IANA names, AFAIK.

    Alternatively, we could keep the time zone identifier as string value, and use the same escape mechanism with a SOLIDUS character as specified in RFC 5545  (see section 3.8.3.1). All time zone identifiers that do not start with SOLIDUS must be an IANA time zone. For custom timezones, we might want to consider defining a JSON representation of time zones, which could be defined in a timeZones property on the JSCalendar object, keyed by their time zone identifier.

    Do you have other suggestions on how to handle non-IANA timezones in JSCalendar?

    Cheers,
    Robert
    --_----------=_155016011136123860-- From nobody Thu Feb 14 08:02:20 2019 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 049DF131174 for ; Thu, 14 Feb 2019 08:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=ak/NxSO6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pSZPRkU5 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 1eHKxyHS8p8H for ; Thu, 14 Feb 2019 08:02:08 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B55221311B5 for ; Thu, 14 Feb 2019 08:02:08 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 19CAF21DC7 for ; Thu, 14 Feb 2019 11:02:07 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 14 Feb 2019 11:02:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date; s=fm1; bh= /xlaJ5BdR/OytRsaCOvcU3vHDchJFB8Z0EpIRlhIUKA=; b=ak/NxSO6umNb3q4u THkbVQxG77h7pv81R0Hdewm+nViyIScXGGxtxxZmAf2RLEKysDuBRnm3ppSa7nuN 9Pg+bk5G7rcShQlXk7YRkMQ21wntnJEVwt1lq2m+gWu2qWOR8k6hjMU9awBQB29T nsdm2rG/4UAZ02AhO17BXv8Pjd4m3KBt0LMdN9nAVLAczhfP3bMsQB8Sbrdc6jey mehiF7XV5pT1h3uSbhGmTC4YD06gPyUoCyOE2CXvh1IrkrTFRa1P/OsjWbo4NhLH andP4fFPfQSdAXJbCNOTs0xie1km46fOmfOb/NVNFaFL+jDZlhq3khN8m4IWGBed o+yB3g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=/xlaJ5 BdR/OytRsaCOvcU3vHDchJFB8Z0EpIRlhIUKA=; b=pSZPRkU5klggeN5nJy7Wy/ G7jVY6rlTnfvbEwCfWiW5N9osDIJh/RP3KeonFztDcMN6a3ujYS+HCddDruySfVL tXbIvI390FDxMZB5YDbi4QOKmejJTZwI+a/2h/+KKMsBX28hVpQ9BYDfuC2VMGx8 pcUHx5nfvw4/6xaLpWFvYPptBAZLxnZ8M04ITmMLzR7D/gaMp02P40qg+21FJkk0 3nZ0Cx6N83eS+CNzEkBB0e/wj5dPqbDriqrVY/V9b5m9S/1DQPZHrwtnTb1PgnWN 91gUharcHXs9Ld19Es6R3ZmM2oq88JB1Jouoq4ouvGZpBXexDZx5KegNTY0OvmBQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddthedgkeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlnecuuegrihhlohhuthemuceftddtnecu necujfgurhepkffhvfgggfgtoffuffesrgejreerredtjeenucfhrhhomheptfhosggvrh htucfuthgvphgrnhgvkhcuoehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeen ucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrsh htohesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id ACD25E22F9; Thu, 14 Feb 2019 11:02:06 -0500 (EST) Message-Id: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> From: Robert Stepanek To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_155016012636020723" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e97eb308 Date: Thu, 14 Feb 2019 17:02:06 +0100 Archived-At: Subject: [calsify] JSCalendar duration vs. end time 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, 14 Feb 2019 16:02:19 -0000 This is a multi-part message in MIME format. --_----------=_155016012636020723 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" During CalConnect XLIV in Zurich last week, discussion arose if the JSCalendar duration property is enough to define the time span of an event, or if an end time should be allowed as well (see the latest spec here[1]). Two arguments were raised in favor of adding an end time * It simplifies translation of VEVENTs with DTSTART/DTEND from iCalendar. * It allows to specify recurring events with a fixed end time even in case of time gaps (e.g. a recurring night club that has to close at a fixed time for legal reasons). Our main concerns with adding an end time are: * Having two representations to define an event time span adds complexity. This contradicts the stated goals of JSCalendar. * Translation of DTSTART/DTEND to duration for one-time events is in almost all cases trivial. It does not require to rewrite existing calendar data. * The "night club scenario" isn't covered by iCalendar either, as the same exact duration of a recurring even with DTEND must be applied to all members of the generated recurrence set (see RFC 5545, section 3.8.5.3). If anything, this scenario speaks for a new parameter on the RRULE. * Durations are guaranteed to be zero or positive, which makes it harder to produce invalid events. As it currently stands we therefore see no need for an end time property. Please let us know if you disagree. Thanks, Robert Links: 1. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11 --_----------=_155016012636020723 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
    During CalConnect XLIV in Zurich last week, discussion arose if the JSCalendar duration property is enough to define the time span of an event, or if an end time should be allowed as well (see the latest spec here).

    Two arguments were raised in favor of adding an end time
    • It simplifies translation of VEVENTs with DTSTART/DTEND from iCalendar.
    • It allows to specify recurring events with a fixed end time even in case of time gaps (e.g. a recurring night club that has to close at a fixed time for legal reasons).

    Our main concerns with adding an end time are:
    • Having two representations to define an event time span adds complexity. This contradicts the stated goals of JSCalendar.
    • Translation of DTSTART/DTEND to duration for one-time events is in almost all cases trivial. It does not require to rewrite existing calendar data.
    • The "night club scenario" isn't covered by iCalendar either, as the same exact duration of a recurring even with DTEND must be applied to all members of the generated recurrence set (see RFC 5545, section 3.8.5.3). If anything, this scenario speaks for a new parameter on the RRULE.
    • Durations are guaranteed to be zero or positive, which makes it harder to produce invalid events.

    As it currently stands we therefore see no need for an end time property. Please let us know if you disagree.

    Thanks,
    Robert







    --_----------=_155016012636020723-- From nobody Thu Feb 14 08:22:28 2019 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 DBBE513104A for ; Thu, 14 Feb 2019 08:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=E+sxEmCF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PgNsnBp5 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 R74Ici6E1LC2 for ; Thu, 14 Feb 2019 08:22:24 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD25131048 for ; Thu, 14 Feb 2019 08:22:23 -0800 (PST) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 4040F2210E for ; Thu, 14 Feb 2019 11:22:23 -0500 (EST) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 14 Feb 2019 11:22:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date; s=fm1; bh= ry5TmpbBL9m6PfcTdnnewBNHs+sa/TzxdZSjZVaIW5s=; b=E+sxEmCFYwz3Aoer 4rxhJR1ETCptOtXpsSabtmbU2fuCN+jmkn8RbUIz+DFWd2GSnxmHmUJvQiO0rv5C Hg/z8F7UuxbnecRxqnvscNO1TUrYkA6Iguz0SdOQetbrzgmtUXz+o2AzscUWXlH5 3xaVh+tgo+47Ho+tmTzvPtowbpuxgcJwfqWjvIq7XGqSeLustcIlbN2yqEI1g11r JtHU9WaLxyCl7KNCBXcxZNcMGeoVP30lMgsqs3sFm4l5o80HpuJwKSgHJiSGb9xT uLYp+p3w7jRgWXip8y9YvQKSJt+ByEOjW0xzceaARPD3BOCVAYCCn//RnNtsTpkO ouJE+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ry5Tmp bBL9m6PfcTdnnewBNHs+sa/TzxdZSjZVaIW5s=; b=PgNsnBp58vMmrW65qFhW79 So2gPxYLvVzPWBGl7B8mzfH+onlJYTHeZEcr1tnS7KllJBDv4lzyjvGiH+JCZYbT 3uGdrMMf5c/xntQyWs7E9tQXX4XWPovsKOXTQ/p1jIM7ejwKt0w/c2PfE8PZNYce A4tLFsKzBrH9WRS1iliNkoyGO9peJOq5LyuxECZxKGO4nm13cJKTiMrQ8iOl3ZwD uiJpOLuCI3b+7tThBSjNfdt43bgirOjz/ROdO7FO07s4d/G2TV9cCZ0f4HulQ2Yt Rrr2uNGpjbxmFP3tktqbleJp9GS0cXHajURnrdXQzGjJDIHL3ZZzRUuYVThnyQEA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddthedgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlnecuuegrihhlohhuthemuceftddtnecu necujfgurhepkffhvfgggfgtoffuffesrgejreerredtjeenucfhrhhomheptfhosggvrh htucfuthgvphgrnhgvkhcuoehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeen ucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehrsh htohesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 846D3E22F9; Thu, 14 Feb 2019 11:22:22 -0500 (EST) Message-Id: <1550161342.3633293.1658022312.2075C011@webmail.messagingengine.com> From: Robert Stepanek To: calsify@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_155016134236332930" X-Mailer: MessagingEngine.com Webmail Interface - ajax-e97eb308 Date: Thu, 14 Feb 2019 17:22:22 +0100 Archived-At: Subject: [calsify] JSCalendar recurrenceRule until vs. before 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, 14 Feb 2019 16:22:26 -0000 This is a multi-part message in MIME format. --_----------=_155016134236332930 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" We are considering to change the definition of a JSCalendar recurrence rule to simplify specifying time-bounded recurrence rules. We'd be happy about your feedback. Currently, a JSCalendar recurrenceRule[1] type is almost completely compatible with an iCalendar RRULE. The only difference is that the until property of a recurrenceRule is defined as a local time, whereas in iCalendar it must be a UTC time if DTSTART is a UTC time or a local time with time zone reference. We are evaluating if to use a "before" property in JSCalendar recurrences, instead of "until". This "before" property would time- bound the recurrence set exclusively, whereas the UNTIL definition in iCalendar is inclusive. The rationale is that an exclusive "before" would allow to use the same value as boundary, regardless if the event is an all-day event. In contrast, using the current inclusive "until" requires two different values, depending on if the event is all-day or not. For example, an all-day recurring event that ends on February 14, 2019 requires the until value to be "2019-02-14T00:00:00". However, if all- day is false, this would need to be "2019-02-14T23:59:59" to allow for all inclusive occurrences on that day. An exclusive "before" could in both cases be "2019-02-15T00:00:00". This would make semantics of JSCalendar recurrenceRules differ to iCalendar, and we are wary of the risks involved. Yet, it clearly would make things simpler. What's your take on this? Cheers, Robert Links: 1. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-11#section-4.3.1 --_----------=_155016134236332930 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
    We are considering to change the definition of a JSCalendar recurrence rule to simplify specifying time-bounded recurrence rules. We'd be happy about your feedback.

    Currently, a JSCalendar recurrenceRule type is almost completely compatible with an iCalendar RRULE. The only difference is that the until property of a recurrenceRule is defined as a local time, whereas in iCalendar it must be a UTC time if DTSTART is a UTC time or a local time with time zone reference.

    We are evaluating if to use a "before" property in JSCalendar recurrences, instead of "until". This "before" property would time-bound the recurrence set exclusively, whereas the UNTIL definition in iCalendar is inclusive. The rationale is that an exclusive "before" would allow to use the same value as boundary, regardless if the event is an all-day event. In contrast, using the current inclusive "until" requires two different values, depending on if the event is all-day or not.

    For example, an all-day recurring event that ends on February 14, 2019 requires the until value to be "2019-02-14T00:00:00". However, if all-day is false, this would need to be "2019-02-14T23:59:59" to allow for all inclusive occurrences on that day. An exclusive "before" could in both cases be "2019-02-15T00:00:00".

    This would make semantics of JSCalendar recurrenceRules differ to iCalendar, and we are wary of the risks involved. Yet, it clearly would make things simpler. What's your take on this?

    Cheers,
    Robert
    --_----------=_155016134236332930-- From nobody Thu Feb 14 09:06:13 2019 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 46106128CE4; Thu, 14 Feb 2019 09:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 EJQ_p6VIAkfi; Thu, 14 Feb 2019 09:06:10 -0800 (PST) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6365D128701; Thu, 14 Feb 2019 09:06:09 -0800 (PST) Received: by mail-lf1-f44.google.com with SMTP id n15so5092004lfe.5; Thu, 14 Feb 2019 09:06:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+e/Qtshs1lLgCICIctH1n8mVIZB6ImZzlJcx7pQ/Owo=; b=fRMYzbQT+vier4MTsVeP6CRYng81rI13mvUfV1/E7sriWY6k9pEmeaPPiNXLDqufD1 nhh7P3GQF2TCZZDhmUFQrF6R2CLdOoOXb4YW8GVY5Gk9vzNcWwZHvsW0gxeMC+balmvg dvaQblJqWd9gSYHPakwQAg0tmZaYMg9ZmFDrszUJOA2jaJzMmjWzwOrDcbHZyVJ1yPo8 1kDPjkL+1Q/yn3JA/+oMYEMwO6XojO/nG5CF5+pjIywvKMuSTyExu3xAPAdWY6TE+gyu CGVVPtunGNIjCe0s06LhxNqr7kDRUdQlSele5G7TS5PK8HcRpe1AEZ4rSdErHP9SDdLy GoqQ== X-Gm-Message-State: AHQUAuadzWCrauLq39VnF6mTtVcQCJQOXnsKHlqMwjGXI2Hg/0m8n6yy LcSENcjtCtFje0747Kv+b70KEou1nXgpW5zZZjCmxXI2 X-Google-Smtp-Source: AHgI3IarwoaeWNYC7uOc3C7Nb7KZmr1D00/SWY0s8Ca/JxCAn7MBLO9cE5HodU+Pg9oGMjrflUtSROidnl3wLkVAI9A= X-Received: by 2002:a19:260e:: with SMTP id m14mr3084791lfm.158.1550163967361; Thu, 14 Feb 2019 09:06:07 -0800 (PST) MIME-Version: 1.0 References: <06b6d3d8-d4d6-44da-9bc6-c565471ef09d@www.fastmail.com> In-Reply-To: <06b6d3d8-d4d6-44da-9bc6-c565471ef09d@www.fastmail.com> From: Daniel Migault Date: Thu, 14 Feb 2019 12:05:55 -0500 Message-ID: To: Bron Gondwana Cc: calsify@ietf.org, tzdist-bis@ietf.org, Time Zone Data Distribution Service Content-Type: multipart/alternative; boundary="0000000000009e47e40581ddac51" Archived-At: Subject: Re: [calsify] Notes from CalConnect in Zurich, Feb 2019 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, 14 Feb 2019 17:06:12 -0000 --0000000000009e47e40581ddac51 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ccing our tzdist collegues, The possibility of requesting IANA to host a public server has been raised at the time of RFC 7808 publication . I do not recall any issue raised by IANA at that time. I believe distributing tzdata is one service with probably less potential contentions than binding geographic boundaries to a time zone. In that sense it might be good to keep these services separate. Please feel free to share your thoughts on IANA serving the tzdata with tzdist, our our position toward other organizations as well as envisioned future steps. Yours, Daniel On Wed, Feb 13, 2019 at 10:55 AM Bron Gondwana wrote: > Hi All, > > Sorry for the delay in summarising all this. I thought I should email her= e > with a summary of the key CALEXT related things we discussed at CalConnec= t > last week. > > *TimeZones:* > > See also: https://mm.icann.org/pipermail/tz/2019-February/027503.html > for the > discussion on the TZ list. > > We have RFC7808 and RFC8536 for standard representations of timezone data= , > but there aren't public servers or a standard practice of vendors providi= ng > fast updates, leading to the ongoing problem of late-stage political > updates causing software and devices to be out of sync. > > > - ISO is working on their own process for timezones per country and a > non-country "community zones". > - IANA have already taken over the Olsen zones and keep them updated > (see RFC6557) > - Microsoft have their own separate database > - IATA already have a database which is government provided and > verified and used by airlines > > > The main issues with any faster update process are oversight and > verification - somebody could do things like attack the stock market by > interfering with timezone data updates. > > There are also issues with location -> zone mapping and timezone naming, > mostly political (eg: disputed territories). > > There's a proposal to give zones non-name IDs rather than names, and also > accurate geo boundaries. Using that, people could choose between zones > which were verified to be used within or claimed to cover any particular > area, and vendors could ship their own names or even localised names for > any particular zone ID. > > Next steps: see if IANA is interested in running a tzdata server that can > be used for direct lookups (and how that would be funded), and talk to th= e > tz group about working with ISO. > > *JSCalendar:* > > > - Robert will follow up on that! There were a few last minute > clarifications > - I did a Perl implementation which I will publish shortly. > > > *IETF and CalConnect:* > > I did a presentation about taking documents to IETF and why CalConnect > should continue to do that! There's a known cultural mismatch which I am > attempting to bridge! I have uploaded my slides here: > > http://talks.brong.fastmail.fm/calconnect-feb2019/calconnect-ieft.pdf > > I didn't take notes during my talk (obviously), but it was a good kickoff > for the discussion about our exisiting drafts, which I'll paste below: > > > - Managed Attachments - nearly complete > - *Ken* will finish > - VPOLL > - Need to lock down poll > - *Mike*! (Ken can help with) > - VALARM Extensions > - Draft written by Cyrus Daboo > - Main one we want to keep is acknowledgement - Apple, Thunderbird > support > - Probably *Ken*? (currently co-author) > - Considering removing Apple=E2=80=99s =E2=80=9Cdefault alarms=E2= =80=9D hack. > - Avoid server putting defaults back on! > - Proximity alarm (Apple already using) > - If close to supermarket, fire an alarm! > - Specify if you want an alarm, and how important the event is > for you. > - "Is it really important for me to get to this event?" > - Spend time in TC-CALENDAR debating if we want to change behaviour= ? > - SECOND DRAFT > - ALARM AGENT =E2=86=92 client/server. > - Related events =E2=86=92 > - alarm tied to multiple events? > - X-travel-time? Client side will decide when to notify, not > server side at all with Android > - Proprietary API anyway. > - Subscription Upgrade > - Smart updates to an ICS feed > - Conditional request with a prefer header.. > - Adds =E2=80=9CStatus DELETED=E2=80=9D. > - OPTIONS =E2=86=92 can specify what=E2=80=99s available. > - Is =E2=80=9CeTag=E2=80=9D being used? Need to use weak eTag. > - Does it support pagination? NO! > - A header that says =E2=80=9Cstill more changes=E2=80=9D. > - A way to say =E2=80=9Cthere=E2=80=99s been a change=E2=80=9D = =E2=86=92 aka push. > - Author: *Mike* - individual submission (rev 3) > - Ask HTTPBIS to look at it. > - CalDAV Sharing =E2=86=92 > - what Apple has already implemented > - is 3 drafts > - DAV Notifications > - DAV sharing > - CALDAV sharing > - Author: Evert wrote originally (*Ken* to take on authorship?) > - MAY WANT TO STANDARDISE Per-USER write capability > - Put into DAV namespace (also useful for Contacts/CardDAV and > maybe more?) > - *Go via Dispatch*? > - Per user notes on a vcard? > - TODO: organizer, owner, etc in the caldav part. > - VPATCH > - Cyrus Daboo originated > - Reduce client/server chatter. > - Describes how to use it with RFC PATCH method. > - ENHANCED CalDAV sync > - VINSTANCE > - Effort to reduce size of recurring events with a bunch of overrides. > > - Suggestion: Punt these three in favour of JSCalendar. > - Informational draft =E2=86=92 or DEVGUIDE. List all the resource= s a > developer needs for a caldav client/server. > - SCHEDULING CONTROLS > - *Bron *wrote this > - draft submitted to IETF already > - will propose to calext that it gets adopted > > > Documents that are in the queue and we think should go to the IETF: > > - scheduling > - valarm > - vpoll (there=E2=80=99s some iTIP stuff, but it=E2=80=99s our domain) > > > - subscription upgrade - needs http input > > > - caldav sharing - same > > > My suggestion to the group was - submit ALL of these to calext and get > initial drafts published within the working group, then progress each of > them as there is interest and time to work on them. > > > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --0000000000009e47e40581ddac51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    ccing our tzdist collegues,

    = The possibility of requesting IANA to host a public server has been raised = at the time of RFC 7808 publication . I do not recall any issue raised by = IANA at that time. I believe distributing tzdata is one service with probab= ly less potential contentions than binding geographic boundaries to a time = zone. In that sense it might be good to keep these services separate.
    <= /div>

    Please feel free to share your thoughts on IANA se= rving the tzdata with tzdist, our our position toward other organizations a= s well as envisioned future steps.

    Yours= ,
    Daniel

    =C2=A0

    On = Wed, Feb 13, 2019 at 10:55 AM Bron Gondwana <brong@fastmailteam.com> wrote:
    Hi All,

    Sorry for the delay in summarising all this. I tho= ught I should email here with a summary of the key CALEXT related things we= discussed at CalConnect last week.

    TimeZones:

    S= ee also: https://mm.icann.org/pipermail/tz/2019-February/02= 7503.html for the discussion on the TZ list.

    We have RFC7808 = and RFC8536 for standard representations of timezone data, but there aren&#= 39;t public servers or a standard practice of vendors providing fast update= s, leading to the ongoing problem of late-stage political updates causing s= oftware and devices to be out of sync.

    • ISO is working on their= own process for timezones per country and a non-country "community zo= nes".
    • IANA have already taken = over the Olsen zones and keep them updated (see RFC6557)
    • Microsoft have their own separate database
      • <= li style=3D"font-family:Arial">IATA already have a database which is govern= ment provided and verified and used by airlines

    The main issu= es with any faster update process are oversight and verification - somebody= could do things like attack the stock market by interfering with timezone = data updates.

    There are also issues with location -> zone mapp= ing and timezone naming, mostly political (eg: disputed territories).

    There's a proposal to give zones non-name IDs rather than names, a= nd also accurate geo boundaries.=C2=A0 Using that, people could choose betw= een zones which were verified to be used within or claimed to cover any par= ticular area, and vendors could ship their own names or even localised name= s for any particular zone ID.
    Next steps: see if IANA is interest= ed in running a tzdata server that can be used for direct lookups (and how = that would be funded), and talk to the tz group about working with ISO.
    =

    JSCalendar:

    • Robert will follow up on that!=C2=A0= There were a few last minute clarifications
    • I did a Perl implementation which I will publish shortly.

    IETF and CalConnect:

    I did a presentation about tak= ing documents to IETF and why CalConnect should continue to do that!=C2=A0 = There's a known cultural mismatch which I am attempting to bridge!=C2= =A0 I have uploaded my slides here:

    http= ://talks.brong.fastmail.fm/calconnect-feb2019/calconnect-ieft.pdf

    I didn't take notes during my talk (obviously), but it was a good = kickoff for the discussion about our exisiting drafts, which I'll paste= below:

    • Managed Attachments - nearly complete
      • Ken will finish
    • VPOLL
      • Need to l= ock down poll
      • Mike! =C2=A0(K= en can help with)
    • VALARM Exten= sions
      • Draft written by Cyrus Da= boo
      • Main one we want to keep is ack= nowledgement - Apple, Thunderbird support
      • Probably Ken? =C2=A0(currently co-author)
      • Considering removing Apple=E2=80=99s =E2=80=9Cdefaul= t alarms=E2=80=9D hack.
        • Avoid s= erver putting defaults back on!
      • Proximity alarm (Apple already using)
        • If close to supermarket, fire an alarm!
      • Specify if you want an alarm, and how important the even= t is for you.
      • "Is it really im= portant for me to get to this event?"
      • Spend time in TC-CALENDAR debating if we want to change behaviour?<= br>
      • SECOND DRAFT
      • ALARM AGENT =E2=86=92 client/server.
      • Related events =E2=86=92
      • alarm tied to multiple events?
      • X-travel-time?=C2=A0 Client side will decide when to notify, not serv= er side at all with Android
      • Proprie= tary API anyway.
    • Subscription = Upgrade
      • Smart updates to an ICS= feed
      • Conditional request with a pr= efer header..
      • Adds =E2=80=9CStatus = DELETED=E2=80=9D.
      • OPTIONS =E2=86=92= can specify what=E2=80=99s available.
      • Is =E2=80=9CeTag=E2=80=9D being used?=C2=A0 Need to use weak eTag.
        <= /li>
      • Does it support pagination?=C2=A0 NO!
        • A header that says =E2=80=9Cstil= l more changes=E2=80=9D.
      • A way= to say =E2=80=9Cthere=E2=80=99s been a change=E2=80=9D =E2=86=92 aka push.=
      • Author: Mike - individual s= ubmission (rev 3)
      • Ask HTTPBIS to lo= ok at it.
    • CalDAV Sharing =E2= =86=92
      • what Apple has already i= mplemented
      • is 3 drafts
      • DAV Notifications
      • DAV sharing
      • CALDAV shari= ng
      • Author: Evert wrote originally = =C2=A0(Ken to take on authorship?)
      • MAY WANT TO STANDARDISE Per-USER write capability
      • Put into DAV namespace (also useful for Contacts/Car= dDAV and maybe more?)
      • Go via Dis= patch?
      • Per user notes on a vcar= d?
      • TODO: organizer, owner, etc in t= he caldav part.
    • VPATCH
      • Cyrus Daboo originated
      • Reduce client/server chatter.
      • Describes how to use it with RFC PATCH method.
        • =
      • ENHANCED CalDAV sync
    • VINSTANCE
      • Effort to reduce size of recurring events with a bunch of overrides. =C2= =A0
      • Suggestion: Punt these three in= favour of JSCalendar.
      • Informationa= l draft =E2=86=92 or DEVGUIDE.=C2=A0 List all the resources a developer nee= ds for a caldav client/server.
    • SCHEDULING CONTROLS
      • Bron wrote this
      • draft submitted to IET= F already
      • will propose to calext th= at it gets adopted

    Documents that are in the queue and we think sho= uld go to the IETF:
    • scheduling
    • valarm<= br>
    • = vpoll (there=E2=80= =99s some iTIP stuff, but it=E2=80=99s our domain)
      <= /li>
      <= li>subscription upgrade - needs http input
    • caldav sharing -= same

    =
    My suggestion to the group was - submit AL= L of these to calext and get initial drafts published within the working gr= oup, then progress each of them as there is interest and time to work on th= em.



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


    ____________________________________= ___________
    calsify mailing list
    calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
    --0000000000009e47e40581ddac51-- From nobody Thu Feb 14 09:12:06 2019 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 A2A2B131088 for ; Thu, 14 Feb 2019 09:12:04 -0800 (PST) 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 1DvyRn3MLiU1 for ; Thu, 14 Feb 2019 09:12:01 -0800 (PST) Received: from mailrelay1-1.pub.mailoutpod1-cph3.one.com (mailrelay1-1.pub.mailoutpod1-cph3.one.com [46.30.210.182]) (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 82854131096 for ; Thu, 14 Feb 2019 09:12:00 -0800 (PST) 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=JuKMHsx3SSScCkCB3dRY0WwaGjk5ZtLcN2sE/Z4Jur8=; b=LQwu93SqAdqtq1Yrc1wbE7pXora0slu4MejszaVV5flHnazTJcUB+OkRKeuasFeTgOb2o0xlo+nrf sgtSmc61YTw3/oT0ySmeltf/CUqoGHBVHyYBN6yCdnyD5fFB2HzERJ/oQuhEWQUPyAsGua7RDEhDOq ZkbS7zfN9wANv9ww= X-HalOne-Cookie: 55e25d8710cb8eabba2d93ffd219ac21d6b9de21 X-HalOne-ID: a1f7310c-307b-11e9-94f2-d0431ea8a283 Received: from smtp.dmfs.org (unknown [62.224.76.2]) by mailrelay1.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id a1f7310c-307b-11e9-94f2-d0431ea8a283; Thu, 14 Feb 2019 17:11:57 +0000 (UTC) Received: from boss.localdomain (p2E50E0ED.dip0.t-ipconnect.de [46.80.224.237]) by smtp.dmfs.org (Postfix) with ESMTPSA id 91CD02F6 for ; Thu, 14 Feb 2019 18:11:56 +0100 (CET) To: calsify@ietf.org References: <1550161342.3633293.1658022312.2075C011@webmail.messagingengine.com> From: Marten Gajda Message-ID: <61f84257-4e52-5bea-d51d-29048cc2d90f@dmfs.org> Date: Thu, 14 Feb 2019 18:11:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <1550161342.3633293.1658022312.2075C011@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------92ECD82E9FB904BA4053AD28" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar recurrenceRule until vs. before 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, 14 Feb 2019 17:12:05 -0000 This is a multi-part message in MIME format. --------------92ECD82E9FB904BA4053AD28 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I've never understood why iCalendar specified until to be inclusive in the first place. However, I also don't see much of a problem either. If this is really a concern for some of us, there might be another solution to this approach: Just allow until to have a non-zero time component, even if all-day is true. This way "until=2019-02-14T23:59:59" could be used for all-day and non-all-day events. Conversion to iCalendar RRULE is trivial: just remove the time component Conversion from iCalendar is trivial too: just append "T23:59:59" to the until date. My implementation wouldn't really care. It does check whether until is all-day if the given start is all-day, but it only does so to enforce RFC 5545 compliance of the given rule. I could just as well remove that check and it would still yield the correct result. In any case such a change certainly wouldn't require more changes on the rrule implementation than adding a new "before" part. Cheers, Marten Am 14.02.19 um 17:22 schrieb Robert Stepanek: > We are considering to change the definition of a JSCalendar recurrence > rule to simplify specifying time-bounded recurrence rules. We'd be > happy about your feedback. > > Currently, a JSCalendar recurrenceRule >  type > is almost completely compatible with an iCalendar RRULE. The only > difference is that the until property of a recurrenceRule is defined > as a local time, whereas in iCalendar it must be a UTC time if DTSTART > is a UTC time or a local time with time zone reference. > > We are evaluating if to use a "before" property in JSCalendar > recurrences, instead of "until". This "before" property would > time-bound the recurrence set exclusively, whereas the UNTIL > definition in iCalendar is inclusive. The rationale is that an > exclusive "before" would allow to use the same value as boundary, > regardless if the event is an all-day event. In contrast, using the > current inclusive "until" requires two different values, depending on > if the event is all-day or not. > > For example, an all-day recurring event that ends on February 14, 2019 > requires the until value to be "2019-02-14T00:00:00". However, if > all-day is false, this would need to be "2019-02-14T23:59:59" to allow > for all inclusive occurrences on that day. An exclusive "before" could > in both cases be "2019-02-15T00:00:00". > > This would make semantics of JSCalendar recurrenceRules differ to > iCalendar, and we are wary of the risks involved. Yet, it clearly > would make things simpler. What's your take on this? > > Cheers, > Robert > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------92ECD82E9FB904BA4053AD28 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    I've never understood why iCalendar specified until to be inclusive in the first place. However, I also don't see much of a problem either.

    If this is really a concern for some of us, there might be another solution to this approach: Just allow until to have a non-zero time component, even if all-day is true. This way "until=2019-02-14T23:59:59" could be used for all-day and non-all-day events.

    Conversion to iCalendar RRULE is trivial: just remove the time component

    Conversion from iCalendar is trivial too: just append "T23:59:59" to the until date.

    My implementation wouldn't really care. It does check whether until is all-day if the given start is all-day, but it only does so to enforce RFC 5545 compliance of the given rule. I could just as well remove that check and it would still yield the correct result.

    In any case such a change certainly wouldn't require more changes on the rrule implementation than adding a new "before" part.

    Cheers,

    Marten


    Am 14.02.19 um 17:22 schrieb Robert Stepanek:
    We are considering to change the definition of a JSCalendar recurrence rule to simplify specifying time-bounded recurrence rules. We'd be happy about your feedback.

    Currently, a JSCalendar recurrenceRule type is almost completely compatible with an iCalendar RRULE. The only difference is that the until property of a recurrenceRule is defined as a local time, whereas in iCalendar it must be a UTC time if DTSTART is a UTC time or a local time with time zone reference.

    We are evaluating if to use a "before" property in JSCalendar recurrences, instead of "until". This "before" property would time-bound the recurrence set exclusively, whereas the UNTIL definition in iCalendar is inclusive. The rationale is that an exclusive "before" would allow to use the same value as boundary, regardless if the event is an all-day event. In contrast, using the current inclusive "until" requires two different values, depending on if the event is all-day or not.

    For example, an all-day recurring event that ends on February 14, 2019 requires the until value to be "2019-02-14T00:00:00". However, if all-day is false, this would need to be "2019-02-14T23:59:59" to allow for all inclusive occurrences on that day. An exclusive "before" could in both cases be "2019-02-15T00:00:00".

    This would make semantics of JSCalendar recurrenceRules differ to iCalendar, and we are wary of the risks involved. Yet, it clearly would make things simpler. What's your take on this?

    Cheers,
    Robert

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

    -- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

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

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
    --------------92ECD82E9FB904BA4053AD28-- From nobody Thu Feb 14 09:18:12 2019 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 E28EF12426A; Thu, 14 Feb 2019 09:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 iuZdYyFTWMSt; Thu, 14 Feb 2019 09:18:08 -0800 (PST) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (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 9BDD3131088; Thu, 14 Feb 2019 09:18:07 -0800 (PST) Received: by mail-lf1-f52.google.com with SMTP id j1so5102855lfb.10; Thu, 14 Feb 2019 09:18:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=SZmyrpR1vrZ7AW5zvPS9FA2CCK0Bncw3AvyQRQ3h1JY=; b=YPxyp8gMy4+GW3/UruJTqufhnpQf8IUlT+SqoAshKd+/4m2/FU3Nl+DqQZ28g+Lqyx h7nACed6xD0dUktHcUi3Bo4aDv0lyoUNcjVE+pQap5a+NFpC4Orzrk+jzpxOyxYw13UY HQGAeD2dvCzksxah463p4wVKEefdvSUxSK2y1P+h09Xb0LGpMSNzX4WTzJBlIZSWr0Gr aXax/w78hoBLsK5mzp2uE8Y7AdKmFdq276c1ODDaOpgAJHyNV7X/XYLJRFmystq6H4Dx yfsowqhYDoxBDQyOErWTX6EGeEobGyesy6fTgd2P2fCC0vaZ4Qy7cL2WLFPUfNveB0Jl uRjQ== X-Gm-Message-State: AHQUAubdycRrVBdpqxLlhX7/lUN4B6upXp8bWFP7ZGp0UNwystEPr6XQ 1i2UKq+JAx143R9WoUef+4LFTXY0IrFMhZkPd5I= X-Google-Smtp-Source: AHgI3IYjGDhAo3n9qFbvenT0jy7vNqtW0mBgUrFMqTO1XO8ypQuYBZ/MVtofOK7xNFhoFFNQt8C2iRUgzL2Jh37JpUw= X-Received: by 2002:a19:f619:: with SMTP id x25mr2978507lfe.57.1550164685591; Thu, 14 Feb 2019 09:18:05 -0800 (PST) MIME-Version: 1.0 References: <1550160111.3612386.1658010576.0F11D14D@webmail.messagingengine.com> In-Reply-To: <1550160111.3612386.1658010576.0F11D14D@webmail.messagingengine.com> From: Daniel Migault Date: Thu, 14 Feb 2019 12:17:53 -0500 Message-ID: To: Robert Stepanek , calsify@ietf.org, tzdist-bis@ietf.org Content-Type: multipart/alternative; boundary="0000000000006d99dd0581ddd7ed" Archived-At: Subject: Re: [calsify] JSCalendar timezones 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, 14 Feb 2019 17:18:11 -0000 --0000000000006d99dd0581ddd7ed Content-Type: text/plain; charset="UTF-8" Hi Robert, I am adding tzdist-bis in the discussion. Not being URN expert, I have the feeling that using a SOLIDUS would be used to define global identifiers versus non global and that URI might be more appropriated. I would as much as possible prevent global identifiers scheme be impacted by ill-clients. I believe inputs from people that have more expertise on urn would be welcome. Yours, Daniel On Thu, Feb 14, 2019 at 11:03 AM Robert Stepanek wrote: > At CalConnect XLIV last week, the need for a non-IANA time zone > identifiers and custom time zone definitions was raised. We'd like to > discuss options how to support them in JSCalendar. > > Currently, an event's timezone in JSCalendar is defined in the timeZone > property, which is of string type. Its value must be a name in the IANA > time zone database, or null for floating time (see the latest spec here > ). > > We discussed, if to replace the string value with a URI. That way we could > either use a IANA time zone database name in a to be defined URI scheme, or > e.g. could embed custom VTIMEZONEs in a data URI. > However, on second thought we'd rather prefer a different solution, > because URIs in iCalendar parameters could cause breakage on ill-behaving > clients. There also wouldn't be an obvious urn namespace or URI scheme to > use for IANA names, AFAIK. > > Alternatively, we could keep the time zone identifier as string value, and > use the same escape mechanism with a SOLIDUS character as specified in RFC > 5545 (see section 3.8.3.1 > ). All time zone > identifiers that do not start with SOLIDUS must be an IANA time zone. For > custom timezones, we might want to consider defining a JSON representation > of time zones, which could be defined in a timeZones property on the > JSCalendar object, keyed by their time zone identifier. > > Do you have other suggestions on how to handle non-IANA timezones in > JSCalendar? > > Cheers, > Robert > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --0000000000006d99dd0581ddd7ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Robert,

    I am adding = tzdist-bis in the discussion.

    Not being URN e= xpert, I have the feeling that using a SOLIDUS would be used to define glob= al identifiers versus non global and that URI might be more appropriated. I= would as much as possible prevent global identifiers scheme be impacted by= ill-clients.

    I believe inputs from people th= at have more expertise on urn would be welcome.

    Yours,
    Daniel

    On Thu, Feb 14, 2019 at 11:03 AM Ro= bert Stepanek <rsto@fastmailteam.com> wrote:
    At CalConnect XLIV last week, the need for a=C2=A0non-IANA time z= one identifiers and custom time zone definitions was raised. We'd like = to discuss options how to support them in JSCalendar.

    Currently, an event's timezone in JSCalendar is defined in the tim= eZone property, which is of string type.=C2=A0 Its value must be a name in = the IANA time zone database, or null for floating time (see the latest spec= here).

    We discussed, if to replace the string value with a URI. That way we c= ould either use a IANA time zone database name in a to be defined URI schem= e, or e.g. could embed custom VTIMEZONEs in a data URI.
    However, on second thought we'd rather prefer a different solution= , because URIs in iCalendar parameters could cause breakage on ill-behaving= clients. There also wouldn't be an obvious urn namespace or URI scheme= to use for IANA names, AFAIK.

    Alternatively, we could keep the time zone identifier as string value,= and use the same escape mechanism with a SOLIDUS character as specified in= RFC 5545=C2=A0 (see section 3.8.3.1). All time zone identifiers= that do not start with SOLIDUS must be an IANA time zone. For custom timez= ones, we might want to consider defining a JSON representation of time zone= s, which could be defined in a timeZones property on the JSCalendar object,= keyed by their time zone identifier.

    Do you have other suggestions on how to handle non-IANA timezones in J= SCalendar?

    Cheers,
    Robert
    _______________________________________________
    calsify mailing list
    calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
    --0000000000006d99dd0581ddd7ed-- From nobody Thu Feb 14 10:24:52 2019 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 D55871200ED for ; Thu, 14 Feb 2019 10:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 C1eVtZfazGBB for ; Thu, 14 Feb 2019 10:24:47 -0800 (PST) Received: from dd40210.kasserver.com (dd40210.kasserver.com [85.13.156.70]) (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 1D7E31288BD for ; Thu, 14 Feb 2019 10:24:46 -0800 (PST) Received: from nbnimm (178.165.129.3.wireless.dyn.drei.com [178.165.129.3]) by dd40210.kasserver.com (Postfix) with ESMTPSA id 98A6063A03F5 for ; Thu, 14 Feb 2019 19:24:43 +0100 (CET) From: "Alexander Nimmervoll" To: References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> In-Reply-To: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> Date: Thu, 14 Feb 2019 19:24:43 +0100 Message-ID: <022801d4c492$91037820$b30a6860$@caldavsynchronizer.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0229_01D4C49A.F2C7E020" X-Mailer: Microsoft Outlook 16.0 Content-Language: de-at Thread-Index: AQOLZthb+8PHggH5/l2b8JGbRR609aJyUz+A Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time 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, 14 Feb 2019 18:24:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0229_01D4C49A.F2C7E020 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I agree that having 2 different representations is confusing and should = be avoided. Similar problem with COUNT and UNTIL in RRULE. =20 But looking into it also from client UI perspective almost every client = allows you to choose start and end time and not start time and duration = for an event. Is there a reason you choose start time and duration vs start time and = end time? You also use start and due for JSTask and no duration there, = again confusing. There shouldn=E2=80=99t be different representations = for events and tasks. Using start and end time allows also an easier specification of = different start and end timezones and is less confusing for triggers = related to start or end. =20 During CalConnect we also mentioned the airline example where start and = end times are different from scheduled durations but that can=E2=80=99t = be modelled in iCalendar as well. =20 Cheers, Alex =20 Von: calsify Im Auftrag von Robert Stepanek Gesendet: Donnerstag, 14. Februar 2019 17:02 An: calsify@ietf.org Betreff: [calsify] JSCalendar duration vs. end time =20 During CalConnect XLIV in Zurich last week, discussion arose if the = JSCalendar duration property is enough to define the time span of an = event, or if an end time should be allowed as well (see the latest spec = here). =20 Two arguments were raised in favor of adding an end time * It simplifies translation of VEVENTs with DTSTART/DTEND from = iCalendar. * It allows to specify recurring events with a fixed end time even in = case of time gaps (e.g. a recurring night club that has to close at a = fixed time for legal reasons). =20 Our main concerns with adding an end time are: * Having two representations to define an event time span adds = complexity. This contradicts the stated goals of JSCalendar. * Translation of DTSTART/DTEND to duration for one-time events is in = almost all cases trivial. It does not require to rewrite existing = calendar data. * The "night club scenario" isn't covered by iCalendar either, as the = same exact duration of a recurring even with DTEND must be applied to = all members of the generated recurrence set (see RFC 5545, section = 3.8.5.3). If anything, this scenario speaks for a new parameter on the = RRULE. * Durations are guaranteed to be zero or positive, which makes it harder = to produce invalid events. =20 As it currently stands we therefore see no need for an end time = property. Please let us know if you disagree. =20 Thanks, Robert =20 =20 =20 =20 =20 =20 =20 ------=_NextPart_000_0229_01D4C49A.F2C7E020 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    I agree that having 2 = different representations is confusing and should be avoided. Similar = problem with COUNT and UNTIL in RRULE.

     

    But looking into it also from = client UI perspective almost every client allows you to choose start and = end time and not start time and duration for an = event.

    Is there a reason you choose start = time and duration vs start time and end time? You also use start and due = for JSTask and no duration there, again confusing. There = shouldn=E2=80=99t be different representations for events and = tasks.

    Using start and end time allows = also an easier specification of different start and end timezones and is = less confusing for triggers related to start or = end.

     

    During CalConnect we also mentioned = the airline example where start and end times are different from = scheduled durations but that can=E2=80=99t be modelled in iCalendar as = well.

     

    Cheers,

    Alex

     

    Von: calsify <calsify-bounces@ietf.org> Im Auftrag von = Robert Stepanek
    Gesendet: Donnerstag, 14.     Februar 2019 17:02
    An: = calsify@ietf.org
    Betreff: [calsify] JSCalendar duration vs. = end time

     

    During CalConnect XLIV in Zurich last week, discussion = arose if the JSCalendar duration property is enough to define the time = span of an event, or if an end time should be allowed as well (see the = latest spec here).

     

    Two arguments were raised in favor = of adding an end time

    • It simplifies translation of VEVENTs = with DTSTART/DTEND from iCalendar.
    • It allows to specify recurring events = with a fixed end time even in case of time gaps (e.g. a recurring night = club that has to close at a fixed time for legal = reasons).

     

    Our main concerns with adding an = end time are:

    • Having two representations to define an = event time span adds complexity. This contradicts the stated = goals of JSCalendar.
    • Translation of DTSTART/DTEND to duration = for one-time events is in almost all cases trivial. It does not = require to rewrite existing calendar data.
    • The "night club scenario" = isn't covered by iCalendar either, as the same exact duration of a = recurring even with DTEND must be applied to all members of the = generated recurrence set (see RFC 5545, section 3.8.5.3). If anything, = this scenario speaks for a new parameter on the = RRULE.
    • Durations are guaranteed to be zero or = positive, which makes it harder to produce invalid = events.

     

    As it currently stands we therefore = see no need for an end time property. Please let us know if you = disagree.

     

    Thanks,

    Robert

     

     

     

     

     

     

     

    ------=_NextPart_000_0229_01D4C49A.F2C7E020-- From nobody Thu Feb 14 12:25:27 2019 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 B15E3128D52; Thu, 14 Feb 2019 12:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=B6uPKi2B; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XFdG1PiZ 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 I1RkBuLmFhjm; Thu, 14 Feb 2019 12:25:16 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3BAE12867A; Thu, 14 Feb 2019 12:25:16 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 9C5482D12; Thu, 14 Feb 2019 15:25:15 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 14 Feb 2019 15:25:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm1; bh=0/zyGrqSFFNRjNGkKLD5BVYms 5INTBKoUdewol5x954=; b=B6uPKi2BD2vlKg0GSHYnL5cnwx1KUPkTukJHBu5d7 5HcvYeOGurfOLYWNruGhGcmLRW55GjmUUhIa3leAtdnWc8OkP3wY71eF4h1XXVbH 5IlT/q9QPVuWSnLSTuF0ZlcsPxC7Jrj5F68M+HtXqTdwcchQExOo1RxW5YksHOLH 0VMw1fIrnYinqrW4hyoHYySIAoxmigrz0fmTK5IBH8YYLxNeYGE+F9L341pUPMFb 1g7IREkqibUWv/flG0gXHjCCMHWlX2mvKG1t+hnDpgigJSnMJH1XBCPS/oao4M8i xpCBpFp7WvAvstv4QantnTfg7icP6N9DNlfVaZbxh3C/g== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=0/zyGrqSFFNRjNGkK LD5BVYms5INTBKoUdewol5x954=; b=XFdG1PiZ3TYQsktsa2TMzl4oa5k5Jkr0i vkiy6rn0HcbXyuiHAKUgpG+WVE2D24fHPqAu7ile2WSpLt9WV6REJROop8vWlWPe Ocn44O69OLv7afhibRs9ZGv/NpPiPVCLwrLHbW8WcBnH23Yfzs4JsSLsCEEOQv75 zm9N3tgSmXxYbuTfxVxB94eYsb/Ab2+ILbYUSm0eTjZtaRGzQzFZFM/lnRx6xe/Q +RyOOXYuFlSCJzu5h/8cbZ3Rl+S3/8OgEQQ7KBil9pRJdq966mpfVsdtilEchsXC zc3ngk8Ke//XKghB8Pk+ZbglCMCQM3qrqSWgze86/yY1d979Zu5kg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddthedgudefjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecu fedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepofgfkfgjfh ffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdf uceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepih gtrghnnhdrrdhorhhgpdhivghtfhdrohhrghdpihgtrghnnhdrohhrghdpfhgrshhtmhgr ihhlrdhfmhenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrih hlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3205920250; Thu, 14 Feb 2019 15:25:14 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 56629417 Message-Id: In-Reply-To: References: <06b6d3d8-d4d6-44da-9bc6-c565471ef09d@www.fastmail.com> Date: Thu, 14 Feb 2019 15:25:12 -0500 From: "Bron Gondwana" To: "Daniel Migault" Cc: calsify@ietf.org, tzdist-bis@ietf.org, "Time Zone Data Distribution Service" Content-Type: multipart/alternative; boundary=44b797d16a124d9dadfba6564c746568 Archived-At: Subject: Re: [calsify] Notes from CalConnect in Zurich, Feb 2019 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, 14 Feb 2019 20:25:20 -0000 --44b797d16a124d9dadfba6564c746568 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for doing this Daniel! I was preparing to write to tzdist as well= , but I ran out of time before spending 24 hours in small aeroplane seat= s. Back in Australia for now until the 21st of March when I fly to Pragu= e. I know a few people from tzdist were already on the call, so heard the d= iscussion about both tzdist and potential involvement of ISO to provide = a pathway for countries to officially provide their timezone data throug= h an organisation that has treaty obligations with their country standar= ds bodies. Cheers, Bron. On Fri, Feb 15, 2019, at 04:06, Daniel Migault wrote: > ccing our tzdist collegues, >=20 > The possibility of requesting IANA to host a public server has been ra= ised at the time of RFC 7808 publication . I do not recall any issue rai= sed by IANA at that time. I believe distributing tzdata is one service w= ith probably less potential contentions than binding geographic boundari= es to a time zone. In that sense it might be good to keep these services= separate.=20 >=20 > Please feel free to share your thoughts on IANA serving the tzdata wit= h tzdist, our our position toward other organizations as well as envisio= ned future steps.=20 >=20 > Yours,=20 > Daniel >=20 > =20 >=20 > On Wed, Feb 13, 2019 at 10:55 AM Bron Gondwana wrote: >> __ >> Hi All, >>=20 >> Sorry for the delay in summarising all this. I thought I should email= here with a summary of the key CALEXT related things we discussed at Ca= lConnect last week. >>=20 >> *TimeZones:* >>=20 >> See also: https://mm.icann.org/pipermail/tz/2019-February/027503.html= for the = discussion on the TZ list. >>=20 >> We have RFC7808 and RFC8536 for standard representations of timezone = data, but there aren't public servers or a standard practice of vendors = providing fast updates, leading to the ongoing problem of late-stage pol= itical updates causing software and devices to be out of sync. >>=20 >> * ISO is working on their own process for timezones per country and = a non-country "community zones". >> * IANA have already taken over the Olsen zones and keep them updated= (see RFC6557) >> * Microsoft have their own separate database >> * IATA already have a database which is government provided and veri= fied and used by airlines >>=20 >> The main issues with any faster update process are oversight and veri= fication - somebody could do things like attack the stock market by inte= rfering with timezone data updates. >>=20 >> There are also issues with location -> zone mapping and timezone nami= ng, mostly political (eg: disputed territories). >>=20 >> There's a proposal to give zones non-name IDs rather than names, and = also accurate geo boundaries. Using that, people could choose between zo= nes which were verified to be used within or claimed to cover any partic= ular area, and vendors could ship their own names or even localised name= s for any particular zone ID. >>=20 >> Next steps: see if IANA is interested in running a tzdata server that= can be used for direct lookups (and how that would be funded), and talk= to the tz group about working with ISO. >>=20 >> *JSCalendar:* >>=20 >> * Robert will follow up on that! There were a few last minute clarif= ications >> * I did a Perl implementation which I will publish shortly. >>=20 >> *IETF and CalConnect:* >>=20 >> I did a presentation about taking documents to IETF and why CalConnec= t should continue to do that! There's a known cultural mismatch which I = am attempting to bridge! I have uploaded my slides here: >>=20 >> http://talks.brong.fastmail.fm/calconnect-feb2019/calconnect-ieft.pdf= >>=20 >> I didn't take notes during my talk (obviously), but it was a good kic= koff for the discussion about our exisiting drafts, which I'll paste bel= ow: >>=20 >> * Managed Attachments - nearly complete >> * *Ken* will finish >> * VPOLL >> * Need to lock down poll >> * *Mike*! (Ken can help with) >> * VALARM Extensions >> * Draft written by Cyrus Daboo >> * Main one we want to keep is acknowledgement - Apple, Thunderbird= support >> * Probably *Ken*? (currently co-author) >> * Considering removing Apple=E2=80=99s =E2=80=9Cdefault alarms=E2=80= =9D hack. >> * Avoid server putting defaults back on! >> * Proximity alarm (Apple already using) >> * If close to supermarket, fire an alarm! >> * Specify if you want an alarm, and how important the event is for= you. >> * "Is it really important for me to get to this event?" >> * Spend time in TC-CALENDAR debating if we want to change behaviou= r? >> * SECOND DRAFT >> * ALARM AGENT =E2=86=92 client/server. >> * Related events =E2=86=92 >> * alarm tied to multiple events? >> * X-travel-time? Client side will decide when to notify, not serve= r side at all with Android >> * Proprietary API anyway. >> * Subscription Upgrade >> * Smart updates to an ICS feed >> * Conditional request with a prefer header.. >> * Adds =E2=80=9CStatus DELETED=E2=80=9D. >> * OPTIONS =E2=86=92 can specify what=E2=80=99s available. >> * Is =E2=80=9CeTag=E2=80=9D being used? Need to use weak eTag. >> * Does it support pagination? NO! >> * A header that says =E2=80=9Cstill more changes=E2=80=9D. >> * A way to say =E2=80=9Cthere=E2=80=99s been a change=E2=80=9D =E2= =86=92 aka push. >> * Author: *Mike* - individual submission (rev 3) >> * Ask HTTPBIS to look at it. >> * CalDAV Sharing =E2=86=92 >> * what Apple has already implemented >> * is 3 drafts >> * DAV Notifications >> * DAV sharing >> * CALDAV sharing >> * Author: Evert wrote originally (*Ken* to take on authorship?) >> * MAY WANT TO STANDARDISE Per-USER write capability >> * Put into DAV namespace (also useful for Contacts/CardDAV and may= be more?) >> * *Go via Dispatch*? >> * Per user notes on a vcard? >> * TODO: organizer, owner, etc in the caldav part. >> * VPATCH >> * Cyrus Daboo originated >> * Reduce client/server chatter. >> * Describes how to use it with RFC PATCH method. >> * ENHANCED CalDAV sync >> * VINSTANCE >> * Effort to reduce size of recurring events with a bunch of overri= des.=20 >> * Suggestion: Punt these three in favour of JSCalendar. >> * Informational draft =E2=86=92 or DEVGUIDE. List all the resource= s a developer needs for a caldav client/server. >> * SCHEDULING CONTROLS >> * *Bron *wrote this >> * draft submitted to IETF already >> * will propose to calext that it gets adopted >>=20 >> Documents that are in the queue and we think should go to the IETF: >> * scheduling >> * valarm >> * vpoll (there=E2=80=99s some iTIP stuff, but it=E2=80=99s our domai= n) >> * subscription upgrade - needs http input >> * caldav sharing - same >>=20 >> My suggestion to the group was - submit ALL of these to calext and ge= t initial drafts published within the working group, then progress each = of them as there is interest and time to work on them. >>=20 >>=20 >>=20 >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >>=20 >>=20 >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --44b797d16a124d9dadfba6564c746568 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Thanks for doing this Daniel! I was preparing to write to = tzdist as well, but I ran out of time before spending 24 hours in small = aeroplane seats. Back in Australia for now until the 21st of March when = I fly to Prague.

    I know a few people from tzdist were alr= eady on the call, so heard the discussion about both tzdist and potentia= l involvement of ISO to provide a pathway for countries to officially pr= ovide their timezone data through an organisation that has treaty obliga= tions with their country standards bodies.

    Cheers,
    <= div style=3D"font-family:Arial;">
    Bron.

    On Fri, Feb 15, 2019, at 04:06, Daniel Migault wrot= e:
    ccing our tzdist collegues,

    The = possibility of requesting IANA to host a public server has been raised a= t the time of RFC 7808 publication . I do not recall any issue raised b= y IANA at that time. I believe distributing tzdata is one service with p= robably less potential contentions than binding geographic boundaries to= a time zone. In that sense it might be good to keep these services sepa= rate.

    Please feel free to share your thoug= hts on IANA serving the tzdata with tzdist, our our position toward othe= r organizations as well as envisioned future steps.
    =
    Yours,
    Daniel

     

    On Wed, Feb 13, 2019 at 10:55 AM Bron Gondwana= <brong@fastmailteam.com> wrote:

    TimeZones:


    We have RFC7808 and RF= C8536 for standard representations of timezone data, but there aren't pu= blic servers or a standard practice of vendors providing fast updates, l= eading to the ongoing problem of late-stage political updates causing so= ftware and devices to be out of sync.

    • ISO is working o= n their own process for timezones per country and a non-country "communi= ty zones".
    • IANA have already ta= ken over the Olsen zones and keep them updated (see RFC6557)
      • Microsoft have their own separate database=
    • IATA already have a database w= hich is government provided and verified and used by airlines

      • The main issues with any faster update process are oversight an= d verification - somebody could do things like attack the stock market b= y interfering with timezone data updates.

      There are also = issues with location -> zone mapping and timezone naming, mostly poli= tical (eg: disputed territories).

      There's a proposal to g= ive zones non-name IDs rather than names, and also accurate geo boundari= es.  Using that, people could choose between zones which were verif= ied to be used within or claimed to cover any particular area, and vendo= rs could ship their own names or even localised names for any particular= zone ID.

      Next steps: see if IANA is interested in runnin= g a tzdata server that can be used for direct lookups (and how that woul= d be funded), and talk to the tz group about working with ISO.
      =

      JSCalendar:

      =
      • Robert will follow up on that= !  There were a few last minute clarifications
      • I did a Perl implementation which I will publish sh= ortly.

      IETF and CalConnect:

      I d= id a presentation about taking documents to IETF and why CalConnect shou= ld continue to do that!  There's a known cultural mismatch which I = am attempting to bridge!  I have uploaded my slides here:
      =


      <= div style=3D"font-family:Arial;">I didn't take notes during my talk (obv= iously), but it was a good kickoff for the discussion about our exisitin= g drafts, which I'll paste below:

    • Manage= d Attachments - nearly complete
      • Ken will finish
    • VPOLL
      • Need to lock down p= oll
      • Mike!  (Ken can= help with)
    • VALARM Extensi= ons
      • Draft written by Cyrus = Daboo
      • Main one we want to keep = is acknowledgement - Apple, Thunderbird support
      • Probably Ken?  (currently co-author)
      • Considering removing Apple=E2=80=99s = =E2=80=9Cdefault alarms=E2=80=9D hack.
        • Avoid server putting defaults back on!
      • Proximity alarm (Apple already using)
        • <= ul>
      • If close to supermarket, fire an ala= rm!
    • Specify if you want an= alarm, and how important the event is for you.
    • "Is it really important for me to get to this event?"
    • Spend time in TC-CALENDAR debati= ng if we want to change behaviour?
    • SECOND DRAFT
    • ALARM AGENT =E2= =86=92 client/server.
    • Related e= vents =E2=86=92
    • alarm tied to m= ultiple events?
    • X-travel-time?&= nbsp; Client side will decide when to notify, not server side at all wit= h Android
    • Proprietary API anywa= y.
  • Subscription Upgrade
    • Smart updates to an ICS feed<= br>
    • Conditional request with a pref= er header..
    • Adds =E2=80=9CStatu= s DELETED=E2=80=9D.
    • OPTIONS =E2= =86=92 can specify what=E2=80=99s available.
    • Is =E2=80=9CeTag=E2=80=9D being used?  Need to use we= ak eTag.
    • Does it support pagina= tion?  NO!
      • A header th= at says =E2=80=9Cstill more changes=E2=80=9D.
    • A way to say =E2=80=9Cthere=E2=80=99s been a change=E2= =80=9D =E2=86=92 aka push.
    • Auth= or: Mike - individual submission (rev 3)
    • Ask HTTPBIS to look at it.
  • CalDAV Sharing =E2=86=92
    • what Apple has already implemented
    • is 3 drafts
    • DAV Notifications
    • DAV sharing<= br>
    • CALDAV sharing
    • Author: Evert wrote originally  (Ken to take on authorship?)
    • MAY W= ANT TO STANDARDISE Per-USER write capability
    • Put into DAV namespace (also useful for Contacts/CardDAV a= nd maybe more?)
    • Go via Dispa= tch?
    • Per user notes on a vc= ard?
    • TODO: organizer, owner, et= c in the caldav part.
  • VPAT= CH
    • Cyrus Daboo originated
    • Reduce client/server chatter.
    • Describes how to use it with RFC = PATCH method.
    • ENHANCED CalDAV s= ync
  • VINSTANCE
      • =
    • Effort to reduce size of recurring even= ts with a bunch of overrides.  
    • Suggestion: Punt these three in favour of JSCalendar.
    • Informational draft =E2=86=92 or DEVGUIDE.&= nbsp; List all the resources a developer needs for a caldav client/serve= r.
  • SCHEDULING CONTROLS
    =
    • Bron wrote this
    • draft submitted to IETF already
    • will propose to calext that it gets a= dopted
    <= span class=3D"fastmail-quoted-gmail-m_7736785499390903782ace-line-pocket= -zws">
    Documents that= are in the queue and we think should go to the IETF:
    • sch= eduling
    • valarm
      • vpoll (there=E2=80=99s some iTIP= stuff, but it=E2=80=99s our domain)
    • subscription upgrade - needs http input
    • caldav sharing - same

    My sugges= tion to the group was - submit ALL of these to calext and get initial dr= afts published within the working group, then progress each of them as t= here is interest and time to work on them.



    --
      Bron Gondwana, CEO, FastMa= il Pty Ltd
      brong@f= astmailteam.com


    ___________________= ____________________________
    = calsify mailing list

    --
      Bron Gondwana, CEO, FastMail Pty = Ltd
      brong@fastmailteam.com
    <= /div>

    --44b797d16a124d9dadfba6564c746568-- From nobody Thu Feb 14 15:20:37 2019 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 1912C13126A for ; Thu, 14 Feb 2019 15:20:29 -0800 (PST) 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=zEzK0aQg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jo6v8hUU 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 xKzB_mUxZUDS for ; Thu, 14 Feb 2019 15:20:27 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3AE13123A for ; Thu, 14 Feb 2019 15:20:26 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 3B3C822326 for ; Thu, 14 Feb 2019 18:20:26 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 14 Feb 2019 18:20:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=WaRuCqm4oY5TbXm6saVv19b5vQGX JMUQMOiTjaKw/XQ=; b=zEzK0aQgd8X6XsCS+bZiJqMLDd9wXeBul0t0f2FIRqif GAbGEQnpudyZ8sYPuCuiRpshnO2bRbNMz4RCtow9OqkqbSZd6qE52FhFxOZUk6KF HkaNxeNQyKUceU4haSI0AVzNgKGqpTyiFqzSRx4TmfTLT3GhzO+yXyHl8nUJ/TQA B/drcAD3eqxabQDLYL20lPlMSnYZju0F2x6ZyWYzIvbNEGd7Devuww3T0Wgi/eaY lf5Cl47TeOut8THqk+WLOcRMucJ4luUpjxLfLe0oubOsQAT4vH+qKp0lOhVBPFr+ QgDAQwx1emXlDvNEGZ6SqmN3pgg97/RzPwa93fjr3w== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=WaRuCqm4oY5TbXm6s aVv19b5vQGXJMUQMOiTjaKw/XQ=; b=jo6v8hUUN0RJ7b1tmZkOvBdVDHIcpvboV 6t5Byt0OxzoVATeZmwIbsXnezvIX9ZdiHZ73heEVs5YcmDnb8lKP4M1ZpzLXHM8y 8gfdAYAMDdH2JX4b7O2oFHD5AzRfnKp+3kJpKmjRNg4qixeimABKpposOJsip5qM klfCFurUEUmnuy6zMsRBlmsoAVrw+tg9HQ1PAnAKkRX0UoXSoA/Hv4eFv01G0409 BbOgJGtl9VTornfUhWfMVmEYmwYAufKiIgW0lBXyjNcY76GBU0+ckOag4KG+oJrf 5SzFeyPZh+3ctuVRzWQF6ag5WDiSBYTDjOBDlsV60FOU9gfpLY5oQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtiedgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepofgfkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpe dfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdr tghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5567420250; Thu, 14 Feb 2019 18:20:25 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 64588216 Message-Id: In-Reply-To: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> Date: Thu, 14 Feb 2019 18:20:24 -0500 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=53036da0c1064414bf534248f6411811 Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time 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, 14 Feb 2019 23:20:35 -0000 --53036da0c1064414bf534248f6411811 Content-Type: text/plain On Fri, 15 Feb 2019, at 03:03, Robert Stepanek wrote: > Two arguments were raised in favor of adding an end time > * It simplifies translation of VEVENTs with DTSTART/DTEND from iCalendar. Every client/server will need to be able to translate between duration and end already, so this is unlikely to be a significant hurdle to anyone. > * It allows to specify recurring events with a fixed end time even in case of time gaps (e.g. a recurring night club that has to close at a fixed time for legal reasons). You kind-of mention this below, but I think it's important to note that *this argument is false*. You cannot do this with recurrences as they exist right now in iCalendar. On Fri, 15 Feb 2019, at 05:25, Alexander Nimmervoll wrote: > But looking into it also from client UI perspective almost every client allows you to choose start and end time and not start time and duration for an event. The UI is independent of the underlying data format; as mentioned above you need to be able to translate between the two anyway. > Is there a reason you choose start time and duration vs start time and end time? Yes. There are many reasons why I strongly believe duration is preferable to end: 1. Having two representations for the same thing requires more code complexity, as there are two code paths to deal with. 2. Recurrences always operate with duration regardless of whether it's actually specified as "end time", which is very confusing. With duration, it's very clean: you expand the start time according to the recurrence rule and then just inherit every other property (duration is just another property you inherit). 3. There is no extra expressivity adding "end time". You can always convert from end time to duration. The *one* exception is if the time zone data changed so that an offset transition now happened in the middle of the event AND in such a case you wanted the event to maintain its original end time rather than its original duration. I contend that: 1. This case is exceedingly rare, and not important enough to make the common case more complex. 2. No UI will ever be built to offer the user a choice for how to handle this situation, so it's even less important to handle. 3. A better way to handle it would be to add an extra property that could be used to indicate the duration should be done in "wall clock" time; this would then also work for recurrences, which there is no solution for in iCalendar. 4. Duration is guaranteed to be zero or positive, making it harder to create an invalid event and easier to check that an event object is valid. If you move the start of a series of events you don't need to make sure to keep the end in sync. 5. Should time zone definitions change, it is more likely the duration should remain fixed and the end should shift (e.g. for flights). > Using start and end time allows also an easier specification of different start and end timezones This is modelled differently in JSCalendar: there is a single time zone for the event, which is what it is scheduled in, but you can associate time zones with locations and mark that a location is where the event finishes, which is equivalent to the end time zone in iCalendar. This again is clearer, as it more closely matches the semantics of iCalendar (the "end" time zone is not used for scheduling/recurrences, it is only used for displaying in the UI after the necessary date arithmetic). And if time zone definitions change, again it's more likely the duration should stay constant rather than the end time (the example everyone uses for a different end time zone is flights: flying from Melbourne to LA is not going to get an hour shorter if California suddenly changes its daylight saving rules). Neil. --53036da0c1064414bf534248f6411811 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
    On Fri, 15= Feb 2019, at 03:03, Robert Stepanek wrote:
    Two arguments were raised in favor of= adding an end time
    • It simplifies translation of V= EVENTs with DTSTART/DTEND from iCalendar.

    Every client/server will need to be able to transl= ate between duration and end already, so this is unlikely to be a signif= icant hurdle to anyone.

    • It allows to specify recurring eve= nts with a fixed end time even in case of time gaps (e.g. a recurring ni= ght club that has to close at a fixed time for legal reasons).
      • <= /ul>

    You kind-of mention this belo= w, but I think it's important to note that this argument is false= . You cannot do this with recurrences as they exist right now in iCalend= ar. 

    On Fri, 15 Feb 2019, at 05:25, Al= exander Nimmervoll wrote:
    But lo= oking into it also from client UI perspective almost every client allows= you to choose start and end time and not start time and duration for an= event.

    The UI is independent = of the underlying data format; as mentioned above you need to be able to= translate between the two anyway.

    Is there a reason you choose start time and duration v= s start time and end time?

    Yes= . There are many reasons why I strongly believe duration is preferable t= o end:
    1. Having two representations for the same thing re= quires more code complexity, as there are two code paths to deal with.
    2. Recurrences always operate with duration regardless of whethe= r it's actually specified as "end time", which is very confusing. With d= uration, it's very clean: you expand the start time according to the rec= urrence rule and then just inherit every other property (duration is jus= t another property you inherit).
    3. There is no extra expressiv= ity adding "end time". You can always convert from end time to duration.= The one exception is if the time zone data changed so that = an offset transition now happened in the middle of the event AND in such= a case you wanted the event to maintain its original end time rather th= an its original duration. I contend that:
      1. This case is e= xceedingly rare, and not important enough to make the common case more c= omplex.
      2. No UI will ever be built to offer the user a choice = for how to handle this situation, so it's even less important to handle.=
      3. A better way to handle it would be to add an extra property= that could be used to indicate the duration should be done in "wall clo= ck" time; this would then also work for recurrences, which there is no s= olution for in iCalendar.
    4. Duration is guaranteed to be = zero or positive, making it harder to create an invalid event and easier= to check that an event object is valid. If you move the start of a seri= es of events you don't need to make sure to keep the end in sync.
    5. Should time zone definitions change, it is more likely the duratio= n should remain fixed and the end should shift (e.g. for flights).

    Using start a= nd end time allows also an easier specification of different start and e= nd timezones

    This i= s modelled differently in JSCalendar: there is a single time zone for th= e event, which is what it is scheduled in, but you can associate time zo= nes with locations and mark that a location is where the event finishes,= which is equivalent to the end time zone in iCalendar. This again is cl= earer, as it more closely matches the semantics of iCalendar (the "end" = time zone is not used for scheduling/recurrences, it is only used for di= splaying in the UI after the necessary date arithmetic). And if time zon= e definitions change, again it's more likely the duration should stay co= nstant rather than the end time (the example everyone uses for a differe= nt end time zone is flights: flying from Melbourne to LA is not going to= get an hour shorter if California suddenly changes its daylight saving = rules).

    Neil.
    --53036da0c1064414bf534248f6411811-- From nobody Thu Feb 14 15:35:18 2019 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 C1A201289FA for ; Thu, 14 Feb 2019 15:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 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, URIBL_BLOCKED=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=k4xtCeWZ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=8Ik53E/W 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 ksjYeq4c9hxw for ; Thu, 14 Feb 2019 15:35:14 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E959131096 for ; Thu, 14 Feb 2019 15:35:14 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 88E6E30FB for ; Thu, 14 Feb 2019 18:35:13 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 14 Feb 2019 18:35:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=7quoJh/PR+I544RsIi8PjvzjnWht mzd7gS9Kliu2OO4=; b=k4xtCeWZpovvzeOalMWwhKXqi3S1wsrIl83495U6uFsC M0+Xy+Bp6ae4guNSMIt7uUceLQ9odA8C8EpY84NLHyQtqGuNNhBan+5q/Vp1VqoM SXhOgIoCtOad4KhTh6OKLCsWwBxasvIGR/0E6K2KsejAszKeU/7yOyXpWkLyr373 aESFE3pLubI2vXaFjdoUWR3aZZqS7fYhc1aJmwng/pf9yr4vsR+DBU89H9K3Ldo2 pKQNheLdp96CmAgEuoTr3P2IDZLUe/K/IWzubg1fRhaXdEYJUO3CpUK2v2Kp1p9R SXUlEXi/fY6IoaPsLsT4d7NXCX5oGLzuoZEx73EH2Q== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=7quoJh/PR+I544RsI i8PjvzjnWhtmzd7gS9Kliu2OO4=; b=8Ik53E/WUJ8Re41rapPTRJtNR+ZeVXmxo OstcVAJRNRlaOnyT6N0PvkHFV0x72+dWic45KEoHuwOoLJmK5buYTt+eSMc27xEZ p796iMsw8rc7R/Aj+4VTBNGPtmFMQe+MppnQhiWjlF2PLNZm2BgLx521qfd+KrF+ wdYB4D9lSboafM0HfWQMIiJUNsRsGAHZA0ao/ldiq+fTjC33fDb3lStmo50j+dN1 mjwisOTeU0GVsZJQqWo+ejjMOw8+j2WEqlPhfC8TKfkZulj1nvnXij/421jotgAp QQS9GoIrGJvMpP7kc7Fsukn02rwKAATvx53Teuamf1Ok9dBPT31WQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtiedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepofgfkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpe dfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghm rdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrih hlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8D8C220250; Thu, 14 Feb 2019 18:35:12 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 56629417 Message-Id: In-Reply-To: <022801d4c492$91037820$b30a6860$@caldavsynchronizer.org> References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> <022801d4c492$91037820$b30a6860$@caldavsynchronizer.org> Date: Thu, 14 Feb 2019 18:35:11 -0500 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=29d010928c0b4a278eb48edebcab1530 Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time 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, 14 Feb 2019 23:35:17 -0000 --29d010928c0b4a278eb48edebcab1530 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 15, 2019, at 05:25, Alexander Nimmervoll wrote: > I agree that having 2 different representations is confusing and shoul= d be avoided. Similar problem with COUNT and UNTIL in RRULE. > =20 > But looking into it also from client UI perspective almost every clien= t allows you to choose start and end time and not start time and duratio= n for an event. There's no particular difficulty for any client to convert an end time t= o a duration for storage and back again, given that any client which can= parse arbitrary iCalendar already needs to know how to convert between = the two. Obviously client UI considerations are important. Just checking Google's= UI, it shows both a duration and an end time - and if you create someth= ing with an odd start time (like 5 minutes past the hour) it proposes en= d times based on the duration rather than by the end time: > Is there a reason you choose start time and duration vs start time and= end time? You also use start and due for JSTask and no duration there, = again confusing. There shouldn=E2=80=99t be different representations fo= r events and tasks. > Using start and end time allows also an easier specification of differ= ent start and end timezones and is less confusing for triggers related t= o start or end. Duration can't be negative, so you don't have "end before start" issues.= Duration is the unit used for recurrence calculations (as in: you need t= o calculate the duration of the first event using date math, then apply = that duration to the future occurrences to calculate their actual end ti= me). Particularly if you have different timezones for the start and end, dura= tion is easy to reason about! > =20 > During CalConnect we also mentioned the airline example where start an= d end times are different from scheduled durations but that can=E2=80=99= t be modelled in iCalendar as well. > =20 The way airline flights book the start and end slots and the duration be= tween is fuzzy within the flexibility of the flight speed is kind of a s= pecial case - but again the UI or even API for modifying an event and th= e underlying format don't need to be identical - and in even in the airl= ine case it would be easier to validate the event based on known constra= ints of airline speed and fuel capacity. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --29d010928c0b4a278eb48edebcab1530 Content-Type: multipart/related; boundary=88bd74d5948c45abab56160e9397149e --88bd74d5948c45abab56160e9397149e Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable


    On Fri, Feb 15, 2019, at 05:25, Alexa= nder Nimmervoll wrote:

    I agree that having = 2 different representations is confusing and should be avoided. Similar = problem with COUNT and UNTIL in RRULE.

     

    = But looking into it also from client UI perspective almost every client = allows you to choose start and end time and not start time and duration = for an event.


    There's no particul= ar difficulty for any client to convert an end time to a duration for st= orage and back again, given that any client which can parse arbitrary iC= alendar already needs to know how to convert between the two.
    <= div style=3D"font-family:Arial;">
    Obviously client UI considerations are important.  Just checki= ng Google's UI, it shows both a duration and an end time - and if you cr= eate something with an odd start time (like 5 minutes past the hour) it = proposes end times based on the duration rather than by the end time:




    Is there a reason you choose start time and durat= ion vs start time and end time? You also use start and due for JSTask an= d no duration there, again confusing. There shouldn=E2=80=99t be differe= nt representations for events and tasks.

    Using start and en= d time allows also an easier specification of different start and end ti= mezones and is less confusing for triggers related to start or end.


    Duration can't be negative, so you do= n't have "end before start" issues.

    Duration is the unit = used for recurrence calculations (as in: you need to calculate the durat= ion of the first event using date math, then apply that duration to the = future occurrences to calculate their actual end time).

    P= articularly if you have different timezones for the start and end, durat= ion is easy to reason about!
    =

     

    During CalConnect we a= lso mentioned the airline example where start and end times are differen= t from scheduled durations but that can=E2=80=99t be modelled in iCalend= ar as well.

     


    T= he way airline flights book the start and end slots and the duration bet= ween is fuzzy within the flexibility of the flight speed is kind of a sp= ecial case - but again the UI or even API for modifying an event and the= underlying format don't need to be identical - and in even in the airli= ne case it would be easier to validate the event based on known constrai= nts of airline speed and fuel capacity.

    Bron.

    --
      Bron Gond= wana, CEO, FastMail Pty Ltd
      bro= ng@fastmailteam.com


    --88bd74d5948c45abab56160e9397149e Content-Id: <15501865754810.48322422961703815@content.messagingengine.com> Content-Disposition: inline;filename="image.png" Content-Type: image/png; name="image.png" Content-Transfer-Encoding: BASE64 iVBORw0KGgoAAAANSUhEUgAAAcEAAAELCAYAAAChyD06AAAABHNCSVQICAgIfAhkiAAAIABJ REFUeF7snQdcU9cXx38qhCFgFQQZKigKLhRFsaJW1DoruHCiVtG6raOOOuuu1rrqntWq1aKt 2KG1Ki7qam2r1crfgZMKIsiWoPZ/74OEkATyAgkEcm4/qeSOc8/93pecnHPvfa/MfyyBEhEg AkSACBABIyRQ1gjHTEMmAkSACBABIiAQICNIFwIRIAJEgAgYLQEygkY79TRwIkAEiAARICNI 1wARIAJEgAgYLQEygkY79TRwIkAEiAARICNI1wARIAJEgAgYLQEygkY79TRwIkAEiAARICNI 1wARIAJEgAgYLQEygkY79TRwIkAEiAARICNI1wARIAJEgAgYLQEygkY79TRwIkAEiAARICNI 1wARIAJEgAgYLQEygkY79TRwIkAEiAARICNI1wARIAJEgAgYLQETsSPnT1xKf5mB129egx6+ JJaa+HplygDlypaDhbkZyvA3IpIwJxlsTl6/YXNScp6IxcdXrlxZWJiJH6sIHFpXMSZ+9PnV +vLQqkFBPr9adUCV9UagjJjnCfKv15TUtBL1Ras3YnoWzA2EVXlLaDKD/Estmc1JSU/WfKwi jb4ux2pM/Ojzq8srJ39ZYj+/+Uuh0qIkICoc+pJ5gCXJ0yhKgLrui3PmvDUl7gGWhlRc4yiu fnU9Z2LGQZ9fXVPPW57Yz2/eEqikqAmIMoKvXr8uar2Muj8xvF+9Kh1zwkO5xZGMiZ+Y66k4 5qC09km8S9bMijKC5AUW7aQaE29jGqs+riIx/MTU0YduxiqTeJesmRdlBEvWkEhbIkAEiAAR IALiCJARFMeJahEBIkAEiEApJEBGsBROKg2JCBABIkAExBEgIyiOE9UiAkSACBCBUkiAjGAp nFQaEhEgAkSACIgjQEZQHCeqRQSIABEgAqWQABnBUjipNCQiQASIABEQR4CMoDhOVIsIEAEi QARKIQHRN9AWNfaUe7hw8nuEHQWCNn2IJoqNYo5g8vDtiFTMM/XFtP0z8Y5EMfMedo6ahINP lHs0RfNZBzGnuXK+wvuUk5gzeD+qLtmKDzzzqScrirmILRt248T1J5BK7FGjVT9MGtEOVWX6 pETi8IaNCL0YhVRW7tlqMCaNbQUHRdH5jTnhKnau3oaj12MhLe+G1kM+xLj2Lsg1XBFqFqpK fvqJGZ+sc011Rc9voUZT9I3z48e10VRekvjlNxbR80uf36K/SKnHwhDQkRFMwO9bl2Dl0f8h U1IeqVJvBCprlRCLhPLeGDGrF2rIykwrooZai2AKl4CZmN3ZPkeKqSmsKioLLcR7aSS2zFuB Cy7DMXutNyomXMKW5WsxV+KCzSM8mKFKwe/bluDLx60wfcXHcJH+gS8/W4OFB92wrrcL61jT mGNwePESnDDtz9p7wzTyEFZtmI8tDusxroHaQRdiMOqaatJP0/gUZYqoq9X8qtM3/7w/Vgbh o/iJ+GmRH8zyr6qjUk38NJUbFr/8oYgYi1bzS5/f/HlrLr2+eTw+v/JKbUXHzjOx9J3H+HxJ KOKajcKCfrVhqrYmZYohoKNwqBTSis3xwZIvsWeqL8qr6zk1AanlXeDVoEHOy9MFVurqsjxT e2dUdXHJeTk4oKIubUfkSZyJrY/3J3aCl4sDqjYIwLjetZHw+0U85jpJ/8aJi2De22C8XYOV e3Zi5W54fOIkHgk6axjzvWM4es8NA6f1QpMaNeDV+UNMai3F2bBLzLwWRdKgn8bxKegopq6W 81sUBArXhwZ+muZfsXOD56dprGwwWs4vfX4Ld/VVaz8Eo4cOxvCh3dHYhsmq0hxDhPchGNDU ln1BmqKCpQUq2FgUriNqDR15gg54u3evLJy/q6eakvCCGUoP9QZSfZO8c6WPcWLDGuxlYcoE 2KNBu+EYN6KxPEyZcHEb5nx2CtcTgIoNOmLS1CHwUra2Lu0wbpYpGijmcyMrscr6VRX7BI+k 9uii4KpWdHFDeZb/WAoWMtUwZuGXswtc5N6rBJ6N3SDdFcmMbCuIidbmDUBMiQb9NI0PV7Ey ZA1SR6zGnBqaWLCooC7nN9fw/sKS96bgaCrPnIf2/j74+PtP0YXPm/QOflq5BjvP30E8KsG9 5WB8NLkjaunkx5IGfuxqy/ealxoKPx1cK0yETueXPr8aJ6VCTR/41uTVniLxxGFctakNX7+3 YSlv6YPhi3w0yqEKmgnoyAhq7ijhRSoyY05hWch+3OPGyaMl88KG4x0Hbb+xEnBh+SzszAzA 5BUfwT6BhSlXL8Ey+/VY2Y7pkRmLC1elzPAtxwdsBTJ09UYsWl0Dm2e3Qq5oKjPIb+datHzM 1jOj4NL6Q1Tlw0lhnisz2RLFOEN5CQuTSlm4l5VrUrt8RZRPfYxY7vbJDS1rlJrK5BpA0jQ+ K2e8HdgW0hrMr9dUlw1Ld/OrzKYhZn57GO1WDsXMlDE4PNcP1gL7eJxYMAVfxHfEzNWz4I67 2PvpIkxYIMGeRf5gv5WLN0kMhZ9uMOhufunzq5sZ+RNrR23GvwHzsLRLlSyRcSexcMZhWHbu DsvI47h6Lw2mVWrDv19X1Pz7R4RG/A//Zpqimnd3DB/WGtVk322J/8PxQ4dx/I9HSMy0hKOH D7oPYh6oXe4ga+blLzBmy01k5hqACRqPXYkJ3tl10+4hfD+XFYU41leFanXhH9ADXeuzT6SC fhUiT+HSvXiY2rrBt18Ihnhnf2JF6qIbhllSdBQO1ayS5C1nNKhRH13GzMOn80PQJPU8Vs37 GvfUNs1E1LYP0LVbYParN/qsvppV8/Ep7L3qgoETWZhRCGN2wgcBbrh37hJieA3Tt9B+xBi8 w0KtVT2Zt8c2sphePYnf841BSnHv4BrsS2iFDzrx9b78Uu5LIM+aNVqhScW/EbrrKmKY0ZQ+ PodVuy4hk4UxDDt+Lxsf93SG4B2X/Kx9Dgvt5jdPauoLmHcuEdRgP0Ky/gAe/oy9l6tg4Iwx aOVeBY7ufvhoRi9UurwfRx+qF1O0uQbETwcD125+6fOrA+QFFPEK10//BbuAcVg6NwS+uIkf V3+GbY9qY8DMT7BgWEOkXfkau04/z5KfeY85Cl9g398W8B00HlPGdUW1pAtY+9k+XFd6Zrdp /SDMmDop+zUYLbndsqiNxlWzv9G4rM9WYdcfr1AzYAAztMyQWkTh8Orl2PiHTBjX73dmqEdh 6cJJ6F7lOcI378P5RCZLC10KCEdtsyLzBB3aT8Wn7WU6eMBz2gvcmnAMJ+4NwQfynTKycuWF dVNImGfFk/QxCydm/o0tIb2xRT6kTGQyzy4BbiyHfVEqWBmJS33m2R3Co1hWpBwSzW6f8vtG LNyXifZLRquGTeV9yP4QacIkHnh/an8sYptjhh3LZLa5Pto3cIPpvfJ5qaHSU/FkiByfoFxO Xe3mt/Ajy7jzDx5a1US9agqy3JuinuQQ7jxkvzqq5We8C9+/biQUHz9t9ddufunzqy1fXdZ3 bBOEoPo8nlUVHVq4IPxboGtwRzRwZFmObdH40EWE33vK3tgi7e/jOP7IEi0njmJt+PVYG55V MvEv8yiP/x2EBs1yArCwrIKaHtzrTMP1r/bhUqILOkwKQUu7LO3T/uCybNCSGcrhHlnXtm+z 2rBbshj7jpxD97FZ5saxTX8M8BbibejQpSF+vPEX7jJ1GqdpoUtWlzr5f5EZQRVt2fpaVUkq ElhoVF3KWljPdRghp1p5X4xbEYIGit/XbFdqRVxSI0qD5/b4GBZ9dhUuY1j41FPhi5NtRS3P wqlSxeYsDipluSwqKipZefbCp191Y9FEKSQVrfB46wiccKkBTb6mKOGFraTN+LSpK9NLw/wW Vv2scLTyRPA4NZBRaOE6FmCI/Ao7RA3zS5/fwgIueHu7KjmLASzwBJjYwC7bUHGpQl52UDPx 3+fsryRcWjc517dnJl7B8RHzFhWNoKBSJh7+tA4bz6SjwQeTMMAjx0gmxjFZJlVYxE/xi5kZ zhpsZ0/EU8Rlf/Mp6gcTHhljTgz7ntVeF0GhQqciMoLMTf5oKR71Xo/JzbO/uNjGkRhpeXhq eexBwnaNOkgvsU0rDmBH7rITM05S5gEK34HsbwXDxT3HR2zzTHuF0xZyainXsW7RbqS0m4eV 7ZUMrj030odw/Z4UXZpk6RzzmJ0XdGmOfCOEKlMiYUc7WPuUqzh8MRUNhnhrXE5UEaGPDG3G p7Gu7uZX7FDNqtVBtZTTuMFCn94yb/DOX7ghrYbOhuYFGiA/sZyz6ulufunzqx15fdeuYGcr xHM6TBoFf4WFdG6ULCuorqzHXd6Oz799Cse+kzC6WYVc6gmyXj1i35mZ8M32BPnGnrv3kgC7 KlCww2qHpa0uaoUUILOI1gRroAlztc9+uREnbsUgJuY6Dq9n64H2LdFeJRSqYRQ1OiHQ4wXC lq9hsh4jhhm5n5ZPxPit15n5YynzBU5s3SCUPbp1DuvWn0Nm405orhIKjcGJz5bibMV+7OiD PdsBnsC8Uv5KyTrCIGHhy+amuLBrGy48ZjrfOoYtB9nGmXa+WRtnNKiZVSxFSsxj3Lp4DCtn rsBF1tcHrVUUESVJ55U0ji8GFw7uwhl+XkRjXR3Obx4DtbJiPyQe/oU/Hz5FMq9TrSOCGj1l m2G24RzL+/dOBNau/B7xjXoyI5iHkCLNNix+hRu6DueXPr+Fmwodt7b07gD/Kk9x/KtQhEc+ wr+PonDp0CYsXKK6Jph5NxRrd/yFTLbfoWu1dNyN/B9uRd7Dw8Qsr4PL6lA1CefXLce2ny7g 0uWz2LfqC4Tes4RvQHPwaGx+SRtd8pOjbVkReYJAjQHzMD1zLbZ8MhaxzGuz92iL6fOH5Byc F625A7rMmgds2IadM8fiBd6CW/NemDSkAfOwTjJf3xmt20mYgZuGVSzU6tKgP2ZPbK66DsfC oKFX+U7N7ZgyeLtC7/zONPvYnWkkaDJ8Hj7YsBbrJnyAF+yOMQ1afYQ5gdoEMyPx5UfzcZYd wG/QfDQ+H9JKCwMqGkgBK2oYn/QJLoT9jFT7ALY5pqJGFrqbX/XDqdWpHxqd2oCZYx5iym52 RKJSJXSZ+zmk69ZgxfD9SGFHVtxbDsfacR2Lf2coH4KB8VNPVXyu7uaXPr/iqRdBTdMaGDB1 POz47tD92/Ej29Fpx3Z0dh8XJF/rk2kRx4zeQ35+/95xtnHmuFy5mn0XYc67zGtksoLYeqAd 3x16lG124bIca6PD2CB092ZeY5yG8WihiwZJWhWX+Y8lTS2SUgxiU78mNUtVuY2V2lsOyMdY muZE01j1MbHGxK80jVUf14I+ZBbHNa2PcRiDzCIKhxoDShojESACRIAIlDQCZARL2oyRvkSA CBABIqAzAmQEdYaSBBEBIkAEiEBJI0BGsKTNGOlLBIgAESACOiNARlBnKEkQESACRIAIlDQC ZARL2oyRvkSACBABIqAzAmQEdYaSBBEBIkAEiEBJIyDKCJYpU6akjatE62tMvI1prPq4KMXw E1NHH7oZq0ziXbJmXpQRNClXrmSNqoRrK4a3iUnpmJNy5URdgjqfUWPiJ+Z60jlgIxZIvEvW 5Iv6BjI3k4B+3RTNxHLO5uZmGjuzMNNcR6MQA6hQXOMorn51jVzMOOjzq2vqecsT+/nNWwKV FDUBUbdN40rxu6ulv8zA6zev2d9FrWbp749HnMuVLQcLZgDF/uAQ5iSDzcnrN8L8lJTEx8c9 QP4FLnas+hhbfvwMmWdB+NHnVx9XUI7Mgnx+9alRcX6u9DkufcgWbQT10TnJJALFScCQDV1x cqG+SzcBMpC557fIniJRui8rGl1JIpCX8csrvySNjXQlAsoElI2e7DpXzlduZyzvyRM0lpmm caqEjNUZPXV5hI4IlFQC6gydcp7y+5I61oLqTZ5gQclRuxJFQNG45fU3HxAZwRI1raSslgS4 wVP2BPl7YzaE5AlqeRFR9ZJHQPahV2f81OXJRkgGseTNNWkMFYOmaOBkf2vKMyaOZASNabaN cKzKBlDs+7xQkWHMiwzlFwcBTR6cstET+744xlJcfZIRLC7y1K/eCeRn8HhZfuXKyikbP+X3 yvXpPRHQJwFl46f8nvedn8HjZfmV61N3Q5NNa4KGNiOkj14IKBo8mQF88ybrfKW691wJZSOp qBgZQb1MEwkVSUCs0eP1ypYtKxg82Yu/lyWex69ldfJEqlLiq5EnqIcp5BcV3VhAD2C1EKls wGSGjv/LjV95C3MtpFFVImDYBM6cOQVrm4qilWzq46NiHHljZe9QtMASXJE8QR1PHr9vS0pa Ou0y1DHXwohTNoCvX78ujDhqSwRKPAHZZ0DZKyzxAyvAAETdO7QAco22yUt2azkKlRXv9Ct7 gTJteP6rV68glUqLV0HqnQgUMwH+GeCfBeXvqrw+O8Wsrl67J09Qx3hfkZehY6KFE6fOC3z1 KrNwQqk1ETBgAjzcH3nnDp48iQZ/CJ6zkxNq13IXwp+ylJmZKbwvx54QpLgeaIxrg2QEdXwx K/+y0rF4EldAAnxe+JcDf2VmviqgFGpGBAyfwP9u38G9qCi5onfZ3/wG3x61a8vzuBE0NTUV Pg+yjTOGPzL9aEjhUP1wJakGRkBmBF+/fiWEgSgRgdJK4HF0tMrQHjGvUDHxzwB/yXZIqzQw ogwygkY02cY0VEWPXBYS5R94/tgpMoLGdCUY31gz2OPVlJNyHv8M8M0xiseEZG2MLZpFRlD5 aqH3pYaAzPjxAck8QeEDzl+UiIARE1D8YSgzeoqfF2NCI3pNcF5YMo79nYHHCdptL3epWA59 m1pgcofyxsSVxmqABPiHnP/6pSMSBjg5pFKREpB9DozN61MHWZQRnMsM4PZzaeraa8zjRvPz 4ynCL/EpHa001qcKRKAwBMR8qMXUKYwO1JYIGDoBMZ8BXscYdouKMoKhV9KFOX2ywqFAc+v8 UQy++e0lGcEC0aNGhSUgX/ynMGhhUVL7UkZAFgLlnxF+XMIYk6g1waSXhV9D0TaMiofbMNA/ EJ+cVz7Y/BeWvNcZH5/n06X4d/7Tl3xqBtr124Ab+VejUiMgwG6dbQSjpCESgbwJiPEE825d ukpEGcHiGPLtYxF4iFRcOnUFqnudikMjXfV5C2sDveDdMOvl29IffUcvw5FbSbrqoGByImaj fUgYkgvWusS04r94KREBIgBhZyglwECN4B2cPB+PZt06wOryz7icUtqmSgLXgRvw7eEw7N+w EAOdruGzQSFYe62Yzb1EAglD/dtCf/hOPFUifnyI0VUe8vnPeD70Eb9ewOmz50rEB+frA9+w w933S4SupU1JdUckStsYNY3HMI3gzeM4Gd8Qnd9/D62s/sJPBbGC8VewduJAtOvQGZ0Hz8Xe y6m5WGQ8DMfaaUPRuUN7tHtvKKasu4LnQo0UnJsdiHazw3O8opSfMaVDIJZcVg7NasKbd7nE yQ1ubuzl1RIBc3ZgVUAy9i7ag5z7POTdVm8l1tYw05vw0if4xYsXOBB6EENHjFQZXHJKChZ/ uhyBvfqgd98BWLdxU567UjXVfRoTg45dA1Reee1y/efWLWzcsg2eHll3CNEkX0V5LTKGjxqD Xy9e1KKFatWGXl5YsGgJXiQmqhZSDhHQMwGDNII3TkUgpRHzRirVRbuWVvjz2BUtw3RP8c3s uTgq9cMnGzZj7eSmePDnP5CbMOlf+GLacvxRZTjW7v4GexZ1gPTYIiw5Fs9wW6FRp4aQ/BmO P7M90OTLEbgp8UO7RtxP0kcyg09wEFyjjiFcZgUzbuHInIHo0tIHvi07YfCcMEQqOooZUQrl ARi7/Dxk94RIvvUNZvRh/FjI1bftQMwNu5Xl1SWFYWzTACwO3Y5JQrkPuoQsQ0QcG5NrJ4wM TMbcll4YcfA5pOET0bzhaBxRjtIKMjph7JwP0YPp1mP1rSwgeemT3eeM5bMxuDMbS1M/9Bi9 Hb8pys2rLZOcEXUUn40OQKumbCwts8bJ1QWuaNZVYapkayB//HkNi5csL/Qkbty8FcHvhzBv /giePo1Rkbdx0xY8evQYy5YswswZ03A+4ld8c/BblXo8Q1PdhIQESJiXvnzp4lwvxXtBygTz X/ZrvtiAkKFDUMUhayObJvlqlRKZ2SMwAO41aoqsrb5a3Tqe8PVtil2796ivQLl6JWDs64MG aARv4igLhdZt2xTWbOrrsX+t/vwZ57QJiTIvL+xOFQTOGINW7tVQq1E3zHyfGTbZpSSpiYGL NmPFOD/UqlIJjo16IbCRFHduPhJqWDfrCF+26ebkn9xsSnHz/F9AM3/ozQbyTrlnyPzA/0Vx SxeHY9ND8FmUF6ZuC8N326bBI3Ihhk8/ykp4ikP49GFYG9cWs75iIdVVwZAwozVjzxNmNZgH PGY5onzmYP9PR7H1Q2f8tmgiVshDrfdxZE8U/KduxP6v5sArei/mbbzG7rLbEkF+nbHg5Hms C7CFxH8Zzl5ejQAbocPcSRqNa1FOGLkhFOuD3fLXh7eU3sdv0V6YdSACZw8vQ4vnGzFp7tHs Hzb5j2XFmDn4zWkith0+he9WBSLjyHTMC+MUmorTVUl170ZeeO+9rsoj0vp9+fLlBQM3dfJE lbb8voznmNEbOmSQ4I019m6Ent27I/z0mQLVTWAeZ6WKFdHQq0Gul7rt65cuX0F6ejreadVS 6EsbXVSUE5HRtXMn2NtXFlEz/yo9uwfi519+QTwz+JSIQFESMDgjmPHncZxjodB2zbLPFNbt wDxCZpCYYRSdHt7FU2bovKsptJCYKryxQiX8g52zRyLwPRb6ZKHOpREKTxaQNGX9A5eY8cuQ /oNzfwK+zDvUa6jQzBoS1kEyt7tRYdgZ4YShC6fD39MZTp7M2C0Ihl3EDhzhniIr3xThhpEL Q+Dn5gy3pn0wdaAHIo+FIzojGtHJ1vDw94ObszO8Amdj1cJhaMF/UQjJFh1nz0FAU08Wig3E 0I6uSL5/K9u4smIzG5gJvxbMmD55jFhii04fTkcnLzc42bE6+enDRUmc0HFYH3jYmMGMGdsJ UzvBLOIIIrg3mF9bMw8MXcUM7bS28HC2g1PTYPT2yUDktWx3WYyuvH+WZOuC/N+GXvWycwv+ z+DgAahXt45aATx8yR9VU8PNVV5es4YbHj1+jNfCrdteY8iwETh77jw01eUCEhJeoCIzgmLS GbYO2NSnifyJAWLky+Ry48nDrge//Q4hH4zGe917YcasOYiPj8fK1WuF0O6Awe/jp2M/y1Xp 2ac/zp6PEAwvb3v05+MYNXYCAnoG4WMWjeEhY1m6e+8eJk+dLpTxEPLxEyflZQ729nCt7iow oVQ0BBQ/E0XTo2H2IuqcYNGpzrwutis0PjMBS7u1x1KFjiUsJPq8U0f2FS42ZW3yUFs75QqW TtuA570XYNOihnCUSIV1wBXyyhI0Yx4oVrKQ6E0rXJI2xUd6dQNZxxnJkDIn0JoZoIzIa7hv 7QFmY3KSpx8amO0RPMUMsHLpb1jBwos5OkshtfNCnM1oDA3ag0ljWAjVry3a+HdCp0594M/t mRCCNIO1gnGTMMPELH1OqFgtMOVMbiBz8jKi8tEHnsqNYebmBVewsbD4rX90fm1t4IFwrJg4 DeHXo5HM74nIjIt1bxWRBpWRxh6qzJOVVc7NIfjfPFT5khkL7kV26dyRrQm7QkxdHg59FvdM MBz877p16mDi+HFqPbAb//yDIcED5TzEyFeGd/HSZUydMgmpqalYsXI1ho8ai+4B3bDqMxY6 v3AB6zZsRLOmPrCzVf00hrKQ74RxY4QzZ8s/X4lvDn2LD0KGCV3Mm78Ifn5vC7KvXbuO1Wu/ QLWqVeVrlx7Ma751KxJgfVEiAkVFwLCMIFurO8o2wTQauwkfNVNYf3u4Hx8t4B5iR3SvJAJN tZqoJv0Vt58C3lWy6yvuaXl4BTdS6mBoADeAvFya5YEpiDbjIVHpcuzYIkFKszH6DYXyfqOj EAkndHPjnhXPUPbCshYE5cuC1v4sFDoNPgqYwLxJWzBPblooTgy8gvDwUzgdOg2b17BQ5Fdr ECD3BhUGqqs/89QnXG0PubYY5dU26TzmsdBuXPBq7F7dFE5mGQif6IfFaiUaTuabN6q3FuSP suHpTfaB/b5BWZacb2JRTsp17ZmXVLNGDWYbWBiXHXHc/uUuLFiyFF+s+jzXHT34TZFjY5/B zs5OLlKMLsr9vz84WG6Y/Nu8g0tXroB7vjy5ulbH/m8OIort5lRnBMeM+gCN2Fo0T23eaY3b 7LE+PHFP8VlcHJo2aQLHKlWEVzkTE5hlhR2EOk6OVXCGPEGBBaWiI2BQRjCDbUY5l9IQ4zu5 o3rOj2igGtslWmkKWyt8yn6RioBTzR+B7ruxc93P8J3hjyopf2Hnwb+YqcuOj1apiir4GWFf RqB6Jyv8e2o3Nl/JhLSjwlezhO1ObSnFRz9L0W5AUxWTJEILLaok4bcdoYh2C4I/8/7MwDyl 5GNs3Q3wkXmDt37D9Qw3wUiasX+dMk7hfoYzAuTeIvMQM1gZ20iyNtwM3Ya1RafgpuzVBzv6 BGHvz1EI0JMHZcbWM/PUR3EzTzaRjMjfmJ13xgAnPtZ82kZG4FqyF0b15gaQN85g3qAWWIup apkyWasMiuewZDerMVG6K4eYuh3atwN/yVJlZuQ+GDMODx4+ZCHE6vL81LSsWxvasF2+siRG vjImxTuHWFiYo4JNzsIw34xjxiIJ6S9fKjcT3pcvbynPtzA3F4wfTxYWFgjq1RPz2S5Q7kXy V+uWfkK+LFlaWiIttWC3Z5QLoT+IgJYEDGhNUMp2gUZAynaFtlI0gMKA+C7RSrjDyv8VNcAq 6L5oAdql7MawboHoPnE/pO512b7P7FSJbZSZ4QecWoRRY9jxiYc+GNitDipJU7KPSfB6EjTi m3LK8/VBRXdLlAIaK0nZM7+inzxB1LXzCJ0TgknHJOg9NZiZBJbcAjE6r2rsAAAgAElEQVTQ Jxo756xmu0WfIPrWKXy2KBRxPsFZRs8zCAO8nmPv9Nk4wixlNAtHhk4LQr/l7MYCkmRc2zgH i1efRySXf+UUfo02g52TaugqLyWtrbk3egW/sb5FHZ7PTx/eCdtIc2TNdkQIYzmKxctPwcw/ CH78uzW/tty4stDvwU2ncO3WFRxbPRFrf5Wy6G2OJdRa17wGrcN8Kxbu5CmFhRNlKTklWQgR cgOimLSpK2tXvXo1Jqssnj/PvU4uYQ9J5SktPceQFER+LgV1+Gb4sPexaf1a1PH0xI9s09aw EaPw778sXJOd+ON+TEwN6ne5DkdPogyVgAFdcRL4zg1DzlJ5bmT1xu2Vl8384Wh2YUPk/K2E uFJTTFi9FxMUsj9S+NuxLQsTsldO6o8+SiKe3mG7RRsNhu5toBT394ag617WIdtk4urTFlO/ +hABnrIvSDsELNuOjM8WYnGfHUg2c2IbXT7EtqmByAp0OSNo1UZg0TKsDQlkhtsWtf1DMP9D 5rHaNMWnG5Kx+LM5GLyTnXy0dYVP72WY34lZHOXjDkrjlb31CBwGn5+XY/Kg+5h1eCMCcqJr ebTIRx+ECWP0cmVGfUwf/M42drr6jMbK2W2F3b9sW2q+Y1mw8BpmLJ+GIaFmqO03DEN7Z+Bg crKwkYerpaxrN/G2Po+xFD7bkYX1zJkXxEOBfMMHT/fu3WfrXy7yDSuyXsTUnTxtBrp3ew+t s3d8xsTGCs9FVA5Hcq+KG9l4tpFGG/mFH7FmCdxr5btjhwxim5t6dkevHoEYOXY8ws+cwYB+ fQUBiYlJwi5YSkSgKAmIMoLW5mWQXMj7hzpXNCCnUxPhlKe4fTMcmw7Go9VcXYdCPTEh7Fou 46xWHRtPBC3cy15qSwEbLwQtZ+Vqiu2ahmDVNyGqJTaBWH8lMFe+27BQXMrat5CT79YH648q /yTILlYjQyjJS5/szTiugXMwdc4cVZ3ya8vKnDotwm72ykkhyNn2wXKVdDWEe2Rzj++d1q2w 66u9qFy5Ml6y0OF37O5APdgxAFniZwZbsk0iTo6OGus2btRQkGVrW4lFJqywedt21K5VC9Wq VVXhyXehKp5bFKOLihA9ZPDNQIe+O8zWMMuiw7vtEB39L+LinsOF7WCWpYePHqEG058SEShK AqKM4IhWllj5Syr40yAKmvr65MT+CyqjqNo9P78ao1Y+Qt3eszFe37tCi2pQ1E+REhg5nJ3j XL8B0z6eBROTcmjr30bwfnjiRyS+//FHODo6CEYwv7q8fj+2pstDhYuWLmebYzNQv149zJ01 Q+1jbvha28XLl9Gnd0/5eDXJLwow3GudP3cOtu34EqFsx+hbFSqwNcIecu+Wr59e//sGApnH S4kIFCWBMuysCNtvpjl9/nMKDvyWjicJ2t1/kXuA3AAay7MEk1Jy355NM9lSXoPfMabdRrhu P4apWZsG9Tpg2eWseAaK75rkh8YzMl6yjRr8lYa6bF2qNCa+A5Ovte3Yugl8A01JSfxepzu+ 3I2tm9arhIxLyhiKU88zZ07B2iYrlPyjwjlORZ26siNmssR/lPCNSDyEzkP3pmw92YTt1uU3 YJC9eF11N2QoznHqo29RniDvmBsxYzFk+gBttDLzCp8aLRD9DpwbPn4rs53MoEz7aLJ+O9OR dCn7gbLn6/0IGTaEDKCOmJIY8QRK0EKd+EFRTSJgzAT4mb7n7C4vJeXuK9xg83XPFs2bG/O0 0diLiYBoT7CY9KNuiQAR0JIAD2stmj8PSUmiDrhoKV331flNAPjheUpEoDgIkCdYHNSpTyKg ZwJ8jYfvJi0JiQxgSZil0qsjGcHSO7c0MiJABIgAEdBAgIygBkBUTASIABEgAqWXABlBHc+t MWwp1jEyEkcEiAARKDYCZAR1jF75Bsk6Fk/iiAARIAJEQIcEyAjqECYXZc4eDUPeoI6hkjgi QASIgJ4IkBHUMVhuAK0sLcA9Qtlz4XTcBYkjAkSACBABHRGgc4I6AqkohhtCS/YcNkpFTyC/ 26a9ZPfwNGHPwyuX/YDboteOeiQCRMDQCJAnaGgzQvoQASJABIhAkREgI1hkqKkjIkAEiAAR MDQCZAQNbUZIHyJABIgAESgyArQmWGSoqSNDIsAfI0OJCJRGAuZmZnjJnj+pmPjjkiipJ0Ce oHoulEsEiAARKJEEXJydVPR2dlLNU6lkpBnkCRrpxNOwiQARKJ0Earm7CwN7/CSaPxUX3ADW dq9ZOgerg1GREdQBRBJBBIgAETAUAmXZMSCP2rWFFyXNBCgcqpkR1SACRIAIEIFSSoCMYCmd WBoWESACRIAIaCZARlAzI6pBBIgAESACpZQAGcFSOrE0LCJABIgAEdBMgIygZkZUgwgQASJA BEopATKCpXRiaVhEgAgQASKgmQAZQc2MqAYRIAJEgAiUUgJkBEvpxNKwiAARIAJEQDMBMoKa GVENIkAEiAARKKUEyAiW0omlYRk3gbPnzuNk+OlSAWH3nr24ey+qVIyFBmF4BMgIGt6ckEYl hMCLFy+wZ9/X6Bc8WEXj5JQUzJ2/EO92fg9dunXHyjVr8fr1a5V6PCP22TPMnDMPnd4LRK8+ /bFz1268efNGXvffp0/Ryr+9yisveTdu3sSadRtQt46nIEOTfG10VTuAfDIHDhmKcxER+dTQ XNTY2xszZ8/Fi8REzZWpBhHQkgDdO1RLYFSdCHACa75Yj7Dvf0D58uWRlJSkAmXN2nV48OAh 1qxcgbS0NCxcshR2tnYYHDwgV11u7D6eNQcODg7YuG6NYLAWLl4KW1tbBLzXVagbHx8PiUSC FcuW5mrL7xGpnLi85StWYfTIEXCsUkUwpprki9VVuS8x7/v07sVu3lxLTNU869SvVxctWjTH 1m07MHXKpDzrUQERKAgB1U9RQaRQGyJgZASsrKwEAzf74+kqI8/MzET4mbMYOSJE8MZ8mjRG n9698cuJkyp1Hzx8iP/dvoMpEyfAzdUVvk2bouO77yLi1wvyuvEJCbCtVAnejRrmepVhTwhQ Tr9euIj09HS0bfOOUKRJvja6Kvcl5n1gt/eYgbcXUzXfOn2DeuPHo0fxnP0goEQEdEmAjKAu aZIsoyEQMnQIGtSvp3a8PHwplUrhXrOGvLwWe5TNw0eP8Jp5ZjyM2ad/MMJPn0G1qlXx0/eH Bc9PlkxMTPDy5Uv5+/j4BFRiRlBMOnkqHM19m0HmJWqSr0lXxT65ceVh2f3fhGLAoPfRtkNn TPpoGp4/f45Pl68QQr89gvriyA8/ypvxEC//QSBr+/2PP2HIsBFo36krJk+dDh5SlqXbd+5g zPgPhTIeYv7p2M/ysirMU67hVkNgRokI6JIAGUFd0iRZRIARSE1NEzhYW1vLefC/eWjyJTMk 5cqVQ0C3rqjJjCT/25p5lbLEN4AcO34cXbt0lufxcGjss1jBMHTo8h6mTJuBmJhYebniH9dv 3EC9unXkWZrka9JVXSfnI37F7JkzsGzJIkRF3cfAIcNQuXJlbFq3Ft26dsHK1WvwLC5OXVPs +/oAPhw/Fp8v/1T4UbB3/wF5vRkz58DDozZ279yGQQP6s7Du57j5zy15eR3mVd+4cVOtXMok AgUlQGuCBSVH7YhAHgTevFHdACOLXL757z+hVTD7kldMZ89HYP7CxYIH2da/DTq0bycv5uuF /EGpPXsEAqz5pq3bMGveJ9i6cT17ZmpOSPTVq1eCceQGSTnlJV+MrsqyPhg+TL7ppn27tvj1 4kVwz5gnNzdXfLX3a9y9ew+V7eyUm2LihHFo7N1IyOdtb92KFP7mniJfD23erBmcHB2Fl4mp KczNzeQynJ0ccYo8QRWmlFE4AmQEC8ePWhMBFQJlymQFWBR3eGbbPpgwz09daurTBF9u24Ko Bw/AN6rsYx7SgH59hapdOnUUXrLkYG+PQUNDcJ/V5euIspTKNuDwVMHGRp4n+yMv+QXRlXuX smRpaYG3KlSQv+dhWDMzM6QrhHMVlbGyKi9/a2FuLhg/niwsLITx8l2ybzf3FV58XZPnyxLf hJSakqoojv4mAoUmQOHQQiMkAUQgNwFZeJMfPZClpOQkIfTJDYS6xA1C1aouaN3SD4PYDtJD 3x5WV03Ic3WtzmSVxbNnuUOOEuY58ZSapmoo8pJfEF3zVKyQBXxH664dW1G/Xj2EHfke/YOH IDr6X7nUjIwM5h3S7/ZCYqbmSgTICNIlQQR0TMCJhe3MmVGLjPyfXPKdO/fgWr2afMOKrOCv a9fZmtrQXGcIuTdlKskyaLzemAkTc20IeRoTw+q/gb1S2JN7TdzIPmcbacTK10ZXHWPKJY57 tVu374CzkxP69emNzRvWwdrGGr+czNlR++JForBLlhIR0CUB+lmlS5okiwgwAtzja9fWn32p 74Q9C13ynZ6hBw8hiJ2Zk6W9bINIm3daoUYNN3bOMJkdpv9C+PLnuyX3HwhlZa3ldZuyIxZc lp2dLdtEY40vNmyEp4cHqjOjqpz4LlRF70mTfDG6Kvehj/c81Ml3nfLwbJfOHfHkSbTg6fLd rbLEDWWtWu766J5kGjEBMoJGPPk0dP0RGD9mFD5buQoTJk2BiUk5dHi3vWDkeOJHJL4LC4Oz syPatG4t7JRcv3ETQj4YDb5m9m67dhj2ftZGE15/0MAB4KHAOZ8sZP++REMvLyxeMC/XphjZ SPhaWsSFCxjYP2s9kYc7NcnPT1f9EcotmW+iWbZkMTZs2iKsh1Z86y22RtgH/tnnHfn66p9/ XUPvnj2KSiXqx0gIlPmPJSMZKw3TCAjILmf+r+zFd03yQ+HcI+MbMfgdXDw9s24pVtqQ8B2W fC3t6z27VMKlJXms/F6om7Zsw55dO1RCyiV5XLrS/ejRH1j4uKJocXbsXKqlpaWw8YiH7k3Z ejI/n8p3G8teXJi6GzKI7qSEVKQ1wRIyUaQmERBDgK8T8luVbdm6XUz1ElFHyn7A7Nz9FUaP GkEGsETMWMlSkoxgyZov0pYIaCTAz+zxw+ql5e4qm5kH6NPYG638/DSOnSoQAW0J0JqgtsSo PhEwcAI8rMVvtp2YqHpjbwNXXa16vXp2Fw7PUyIC+iBAnqA+qJJMIlDMBPgaD99NWhoSGcDS MIuGOwYygoY7N6QZESACRIAI6JkAGUE9AybxRIAIEAEiYLgEyAga7tyQZkSACBABIqBnAmQE 9QyYxBMBIkAEiIDhEiAjaLhzQ5oRASJABIiAngmQEdQzYBJPBIgAESAChkuAjKDhzg1pRgSI ABEgAnomIPKwfCaWLIvH+mfK2pTF8EmVMd9ZOb+43qvqaWNdDvU8LDC2gyX8K+U8hVsvGsan Y+AXyXjU6C0cD5TAPD4V3ZakwKZvZextqs/fG48QOnsJfnyqPKpK6DB3MQbwhw3EXcDnS0IR 12wUFvSrjZwH9Si3ye99IsKXzMAu08HYMPVtWOZXVUPZ9c3j8fmVV2prOXaeiaXvPNaBvmrF UyYRIAJEQE5ApBHMru9kgVWtFL4+TcqgXhE+3uvlHwmou/cNJk+zxTj7fGZRrud/iI2WIuxK CoL/zsDHoytinLM4Qyi6L0U1GI/K5mWQYS2uj3xGULCiqq0wvL1bTltTC1Szy37LDk9XYE8B z7TJeVJ3wTrRTatq7YdgdP1MZCIJVw8dxlXL5hjSmRtnpmdVdsjbNMag9NXNqEkKESAChkZA KyNoVlGCgKbmMDe0USjpk1tPS4zzf4mJXyRi6Z4U+E+3Rj196W9jjtXTi4+OqW1d+Po1Uu/l VfDB8EU++hq51nIr1PSBb03e7CkSTzAjaFOb6a7oXRqWvloPkBoQASJQIghoZQTVj+gNwrbG YcwDCbbPewudsh3Fl3+/gPeXUrz9vh121M8OBSZJsfWnFGz7OxPPXpVFzZrmmNLLCp14mFIW OvS3QuW7aTjy8A3MKpoiMLACPq1fDr/uj0XQb1lPfVq6PAZLrS1wZJ4NmqhXKncuM07zu6Tj yN6X+OquNT7lX7756KK+L2tU+CMF88Jf4kL0G8C8HBo3ssKngeZwlzvHLzFsRiLudLDF2bbK aN/g97NJmBEuxd3k/2BWmY2trTU+aWpaRD8q/sTaUZvxb8A8LO1ShYVHT2LhjMOw7NwdFSJP 4dK9eJjausG3XwiGeGffbivxBn786jCO//0Uaaa28GzTEdXyjaNm4t/Lh7Hv6G+49Yjdt9LC ATWbvYch/XzgmG87dZOopC+voqCzZeRxXL2XBtMqteHfrytq/v0jQiP+h2ipCap5d0fI0Fao KpuCxNs4ybzN41cfICHdFBWremDDp6XzUUrqSFIeESACeRPQbqHq1X94lvQasdmvxHRulMqi Y1szVH6Zga/+ZsZBSK9x5EIGkiqaY7hHdheZUizZloBPIssgsFdF7Hm/POolpyNkYxLC03MU PM3aVWj7Fs5Mq4jJ9q/x1Z4kfMO+T+t1eAt7/Pk3aVkE9a2II7x9TjONf1VwlqAm3uBO7GtA gy5q+0rPwOdH0pFUzQrbx1fEhrblcOdiIgaGSfFSY++swt0UhByRwtzHBntY+/nMEP/+20tc VRi7GDH51slMZzdNTpS/0tIy860OvML1078zQzgKSxdOQvcqzxG+eR/OJ7Jmmfew77N1CI0E GvQagOH93kaFv0PxI3ufZ0q7gcP7LyCtRndM+HgSRne2xb9ntuPz/fdY2FNXiev8F+wCxmHp 3BD44iZ+XP0Ztj2qjQEzP8GCYQ2RduVr7Dr9PKtDNo5D6zYg9KY5mgQNx4j328Ix9U9dKUNy iAARKOEElN2VfIeTEZmE5gsUqlSzxh8TLGFf0xJ9Kr/EtnMv8cjbElXjuccF1GWbUVpkewCJ kWnYFs0M2PC3MNOTr5lJ0ML+P9xlG0e23bKGf/UsuTXftsb8+lmNRjDjuj4yA1fZhpw+NSV4 26kMzJgRdK8uQZP81gTzHQWgSZe93ur6KoeN0yR4aVE2y3OrboKMu88w5m4mHrOxuGvoE2yt 0Az/4WXyG2SYmCKgdyX00dRGy/LMG7vx0RSFRjX6Y83M1qiQjxzHNv0xwLuqUKNDl4b48cZf uMs22DROPI7wpzZoOXEShtfP2gLj6+2AzNmbcSkveZaNMHpRbWSyh3UKM1jTBZmR07Ex8jbi UAO6eg6AY5sgBNXnOldFhxYuCP8W6BrcEQ1YB/9VaYvGhy4i/B7fJVQJaX//ghOPLPH26BAE 1HjNHqrrBKcBKXmNgPKJABEwMgJaGUFUs8SeDhI5IjNrE9gI70wxqLUpth1KR1isBfyvpOMq MwyrfHLEP2MeWAbzxI58GYsjCpAz2N81o5l3lm0Eq9qXyyllG00Ew6EDNyLxCQtDMgPah8l/ 9kCDLt7qHOTX+PVKMlZeyMSNZMCmUjnYcy/OhBk1hfHk+aezFQ6+D8w7lYoxq5KRxMKpHdva 4NO2EhTCnufurkYHTAmoLc8ztXHRuIPTrorCkwaYcTZlPht7hikS454j08QFDTwU9oBa1kYD Znsuqd/UyfpNxK2IUBw+cxsPmTdpaeeACmks2zRNh54goKgz2+/D5sCGPTEhB4WQl91j4tPn zN9NwpXNH+Pi69d4zZ4yz580H/r20Nzs6B0RIAJGSUArI2hmbYq3Pc3UrmFVbWSJNj8m4quz abhz4zUqN7JGQJaFFMBWrliOGTRg+Ii3MKhiDusM9oXKjzEgXSpyArLWBUVWzqqWlIF5P0mR UdkSg1gYsnKSBl3kwnP6ir2QiOAjr9GmVwV878H0TX6Fr8JeaBXONLO3xIYJ1jDPfI0bvyVj 4KEXmGdfGRvr62Y3qamNGzzr11O/MUYrYEAF9hge01dP8fBfwJcfsRASe88dLAWDoyg28TQL fR6IQYPgEMypz4xr4lOEH9gEtsRbbKmCrS1M2I8v/3FD0czyJV6+fMm8QV3GoIttaNQxESAC OiCglRHMSMjAN1f+UzCC7IhEfXPU47vuLcwwvBELd15MQSjKYXir3MayAgupDaqcgG0HmRvV 1hxvszY3/kzF+ltlMX9yRVGhQXObssyQsiMPp9JYCNYEbzeVsICYapLrydYwY2P5EYkMtnJk yo5IWGWtI2rShemm3FeWf8VCsU4mcGcbeWITpLgRy/q2Vu1fXU7shQQ0P/QajVtZCeukSbHc g2SerlYzoE6yfvIsvTvAv8pnOL5lFxwHdYSnTRKuH9mHcL7UlocR5GuM7CcNHKu6wNHOFInP zzIjyvLyi8fqR325VEvvd/FOlVU4+fV3yHynIaqWTcW9Kyfw9tvN9dwziScCRKAkENDuKzj6 JT4+oLgNhB2Wd2I7L4XD8mXQorUlajIj+LiaBYYrH6A3lWA+O6fnwneHhiVi/asycHGSYPJQ a/ThZw3jReCqyXZj+rzCvD+TMeOBJULzMIJQ0FM4LF/fioVxFQ7La9KFq6Lc12QbrHqShCVb n2Eb29nqwna2tmBnDi+IfHi3/dsVsCc9GfPOJSHkHDMVbOdrR+ZVzhfWRw0wmdbAgKnjUIHt Dg1dNZ/tDq3Edl22hb/HQRzPQ90KfoMx/NE+hK6ejuOZlrDz8IEnuxZu8Y02xZXYOPpNGoO3 +O7Qw3txlDmBNvbVMaq49KF+iQARMCgCZf5jyaA0ImWIQCEIyC5n/q/sxdcAM9lCpywUmpaW Bk9POiJRCMzU1MAIHD36A6xtFNaZNOhnx5YJLNkGNgsLC5ibm8OULaSbmJigTJky8hcXwd+X 9qRuB0hpHzONjwgQASJABIiAQICMIF0IRIAIEAEiYLQEyAga7dTTwIkAESACRICMIF0DRIAI EAEiYLQEyAga7dTTwIkAESACRICMIF0DRKAUEjh77jxOhp/W+8h279mLu/ei9N4PdUAE9EWA jKC+yJLcUk/gxYsX2LPva/QLHqx2rJrKZY2SU1Iwd/5CvNv5PXTp1h0r16zFa3aLN1n69+lT tPJvr/JSrKOowI2bN7GG3TS8bp2cYyBidOF30uH98PZiU2Nvb8ycPRcv2I3bKRGBkkhAu8Py JXGEpDMR0AOBNV+sR9j3P6B8+fJISlK9Y4KmckWV1qxdhwcPHmLNyhXgZxgXLlkKO1s7DA4e IFSLj4+HRCLBimVLc42kbFnV37Bv3rzB8hWrMHrkCDhWYY/MYkkbXXJ1IOJN/Xp10aJFc2zd tgNTp0wS0YKqEAHDIqD6KTIs/UgbImCQBKysrASjNfvj6Wr101Qua8QP8YefOYuRI0IEz82n SWP06d0bv5w4KZcbn5AA20qV4N2oYa6XuoPMv164KNwbtW2bd+TtxeqidiD5ZL5mBpenvkG9 8ePRo3jOjDUlIlDSCJARLGkzRvoaBIGQoUPQgN2sPK+UXzkPY/bpH4zw02fAQ51SqRTuNWvI RdVyr4mHjx5BZmTi4xNQiRlBMenkqXA0920GRS8xP13Uybz+9w0MGTYC7Tt1xeSp08FDqTzJ wqXrNmxCj6C+zPvbLuRXcXBADbcawngoEYGSRoCMYEmbMdK3xBMoV64cArp1RU1m+FJTsx6x YW2dcyd2/jcPa77MftoFD4fGPosV1h47dHkPU6bNQEwMv3u7arp+4wbq1a2jWqBFzuEj3+PD 8WPx+fJPBWO8d/+BXK35muGCeXMR1LuXPL8O82Jv3BC/lqiFOlSVCOiVgOg1wV3npPj+6isk pNKtRnUxIxXLl0FgE/YcxpbZTx3WhVCSUWIIBA/oL+iqbhOK7HaNb7Jv6+vAPK1a7u7o2SOQ PTUY2LR1G2bN+wRbN67PdW9Hfo9UbhwrV65cKA6TJoxHY+9Ggoz27dri1q3IXPJGjhiu4gU7 OzniFHmCheJOjYuHgCgjuP20FPt+1cGTbYtnjAbZK/8x8eVZKaTscU8hbXIeVGyQypJSeiNQ pkxWMIZ7frIku6W9CfMYeerSqaPwkiUHe3sMGhqC+w8ewM3VVZ6fyjbV8FTBRuFBnvJS8X9Y WZWXV7ZgN1dWfv6iqanq1wbfIJSakiq+E6pJBAyEgKhw6NG/8nyUuIEMo+SqQWxL7tzpQnNr tsGGJ35MQpaSkpPAQ6ZmZvwx1KrJ1bU6Ky+LZ8/ichVK2JMAeEpNK3pjlJGRARM1xlFVe8oh AoZFQPUnnRr9Pu/+TE0uZemKAPtBT0lHBNQ9SolvROG7MPkXNX+cEn8ZyqOUnFgYkT/KJjLy f8IGE57u3LkH1+rV5JtbxkyYiKCePeCfvePzaUwMO0f4BvZKYU/+WBxuOJ+zjTRFnV68SBR2 sFIqGQSio6OF646/+DXDH6XEf3gZ46OURBnB6tWrl4yZJS2NnoA6I6jueYLFDWrv1wfQ5p1W cHZyQru2/ti6fSfsWZiTG+jQg4dybTppyo5N8HI7O1tYW1njiw0b4enhgerMUConvrM0Ovpf 5Wy9v+eh2Vq13PXeD3WgGwJO7Lqj5wlmsRRlBHWDnaQQASLACXDP9LuwMDg7OwpGcPyYUfhs 5SpMmDSFPdi0HDq82x79+vSWwxo0cIDgxc75ZCH79yUaenlh8YJ5ah94+nZzX0RcuICB/fsW GWy+nvnnX9fQm3mrlIhASSNAT5YvaTNG+uZLQKwnaCjh0HwHU4DC2GfP0D94CL7es0slXFoA caKa8PuUbtqyDXt27ch1PlFUY6qkEwL0ZPmCYxS1Mabg4qklESACRUmArxP2Yef3tmzNOsiu 776lbK115+6vMHrUCDKA+oZN8vVCgIygXrCSUCJQfAT4HWKexcUVyR1cNjMP0KexN1r5+RXf gKlnIlAIArQmWAh41JQIGCIBExMT4WbbiYmqN/bWtb69enaHk6OjrsWSPCJQZATIEywy1NQR ESg6AnzLO99Nqu9EBlDfhEm+vgmQEdQ3YZJPBIgAESACBkuAjKDBTg0pRgSIABEgAvomQEZQ 34RJPhEgAkSACBgsATKCBjs1pBgRIAJEgAjomwAZQX0TJvlEgOLK+2AAACAASURBVAgQASJg sAREH5Hgt0ZKTUtnjzPjzxMsY7ADIsWMm0B+d4zhtxxLT+evrEcOGTcpGr0xE0hhj916zb7K X7Hvdemr18INtPnRGmO8gbYoT5A/6SxZMIA8kQE05g8PjZ0IEAEiUJoIiDKCqalpZPpK06zT WIgAESACREAgIMoIykJMxIwIEAEiQASIQGkiIMoIlqYB01iIABEgAkSACMgIkBGka4EIEAEi QASMlgAZQaOdeho4ESACRIAIkBGka4AIEAEiQASMlgAZQaOdeho4ESACRIAIkBGka4AIEAEi QASMlgAZQaOdeho4ESACRIAI6N4IxoRhyYRp2HUtUyPd9N834KNPDuF+HjXzLr+NfdMnYfu1 PBrqNfs2vvlkJrb/Trfe0itmEk4EiAARKAICOjeCTy5dQyzScevqP9BsBotghIXs4s6Bmfho 6zWFsTigcft30czVspCSqTkRIAJEgAgUNwEdG8HHuHotGZ5+vrD45yJulUpnyQbuLf3RwLa4 p476JwJEgAgQgcISEP0UCVEd3b+EP5Ld8V5nPzz4ZyMu/5OGBk0UPKakm/juywOIuJ8E00p1 0MI1PbdYTeV5KZH5GJcPHMCx64+RBBs4N+iMPn2bw9k0u0HSbZz49hDOXItBuqkNXJv1woBe XqjEijNjfscP3/6Ey7djkWlqD3ehrC6TwkOua3FZUHErpk6ogwGfjkEzS56/AekDVyHEiwvI p++0i9g0+xdU6tkcyRHh+OdJOmzcWyLo/V6oY5PXYCifCBABIkAEioqATj3B+79fQ7p7E/YF 7wbvBha4c/kfFhiVpec4s3UrLmd6YcjkGRjXty5i79zHK9HleSFJwtUv1+K7GFf0GD8bM8f3 gvOTA1j35e/MIPLE+92AM0lNMGT6bEwd/S4sru/E9iOPmQG7je827sGdSoEYN2sxZg5vjleX v8S+S7xlLQxYtAwjm1nDpMH7WPr5CGYAlXXQ1DevH4vLp2PQoOcYTJ3cF9XjT2Pf0ShlQfSe CBABIkAEioGADo1gFC5fT0L1xnVgwQbi2oT9e/sSrstCojFXEfGkEloE90IDFwc412qJAZ3d IXdFNZXnBSfmEk7+UwntBLm2qOTihT4D28D6n19wOYY1enye9euC9gPfhbuDLRxcWb89fWES H4MkU2e0Hz4DI3t6wdnWBpVqtUEL90w8uc8bsmRqyZ6zJfwBk6w/cmuhqW+htjUa9+2LZrVc WN/N0b6xPdJjnmQb6Nzi6B0RIAJEgAgULQGdhUMzucFLqoVudbLdJVdfeNqsxVVmGJv5sthf zGPEm7owQ6QwQBNZvJLlaSrPg0vm4yjEWLjAVVGuS124mp7Gk5hMZGbGIN7CmRm5HAEWXv0w iYcyWcrENXy3bSeu349HeibbyvPqFSz88uhMKVtT38z+sWQKCwUDamLBxsz6yfGAxfVFtYgA ESACRED3BHRkBDPxgO0KTX6VjH0zxmOfgp4ml24iybc5W2PjyZT9l1/SVK6mrSBQeRhZ+1I1 Gpq0m9i38VsktxmBScNroZJpJq5vnYZv1HSjNqswfasVSJlEQDcEzp47j0z2g66dfxvdCCwC Kbv37IVfixaoWcOtCHqjLohAFgFl61EwLmxt7fI/6XDvOR1BdRS9u1+w+UvuITaHnwMLB2Ze w5PngLvMK1O0UprK89DM1MENDum/g0cw5V7m49u4n+mAZg7MqLJ/K6XfQQxb5nPP3oySef88 frjvgHau/+BBuis6+XEDyDvIRLpGy5mjiKa+81CZsksJgRcvXuCHn44Kr/17dquMSlO5rEHs s2dYvXYdrv7xJ8pbWuK9rp0xZFAwypbNWq349+lT9OkfrCL/9ImfUa5cOZX8GzdvYs26DVi3 ZqW8TKwuvIHY/tLT09GhSzdsWr8W9erWVdFD24zG3t6YOXsuNm9ch7cqVNC2OdUnAgUioBMj mHn7Kq6n10KPZszQKW4ecfBDAxYSvXztOfxaNkYL559w7NuL8BzYhBmm2zh2+jYLC2bHMR00 lOc1PAdfvFPrF3y3JwwOwS3hnPkEZw5EILlWT2YEeaOW8HM+jWN7w+HA1v54v9/vOYJYrwno UYkZSFxCxNFrsPe1QPzVn/D9P6/wqlnOCUcLHr68fRt3YpxZyNVWWO+UJ019l8ojInlNhHHl r/liPcK+/wHly5dHUlLWFixFAprKZXXfvHmDj2fNgYODAzauWwNuEBcuXgpbW1sEvNdVqBYf Hw+JRIIVy5bmgiwzkoqZXN7yFasweuQIOFapIhSJ1UUmR5v+cilUyDf169VFixbNsXXbDkyd MqmQ0qg5ERBHQCdG8M5ldpicGZ0GKrsn+S5RG0SwUGk8O1vnN2IEYtkRic9mHGBHJFzh7e4K izsyRW01lOc1IBs0GzIBmd8ewDfLTrAjEJXYEYkAjGPHErIcP1u8M2IMMg8cwq5l37JydgzC 732MDHBhAl0wYOB97Pp2J1ZHmMK5zrto7/cKEewXLv9a4+2dfdmGmquHsH1lDPrMYkcksr3J LG009Z2XzpRf0glYWVlhzcoVSEtLw7SPZ6kMR1O5rMGDhw/xv9t3sHzpYsHwubm6ouO77yLi 1ws5RjAhAbaVKsG7UUOVfpQzfr1wEdxDa9vmHXmRWF1kDeK16E+5//zev2YGuly2d5tXvb5B vdFv4CAMGzpEGDMlIqBvAmX+Y0lTJ0kpqZqqUDkRMAgCssuZ/yt7vWJrY5lsM1JGxktmIPgr DT6NG+tE30uXrwhG8MzJ42rlqSt//fo1+gcPEby11q1aIo0ZLWtmVGVp4+atuBUZKRhZnrjH efTYcSHsqCnNX7gY1tbWmDxxgkpVdbqoVNKiP1k4dOzokYJ+T6Kj4dWgPubO+hhvvfWWYIx5 uJQbtpPh4cy4t8eoD0bg9p07WLXmC8H429nZYnDwQHTp1FGuyrARo9Clc0f07tlDnXqUp4bA 0aM/wNqmopoS9VnmFhawsLBkL3OYmZmzXfBsB7yJCcqUKSN/8Zb8fWlPOjwiUdpR0fiIgG4I 8HW8gG5dUbNmDWFNT9EA3r0XhWPHj6Nrl87yznh4MvZZLPoFD2ZG5T1MmTYDMTGxapW5fuMG W5+ro7ZMbKY2/XGZh498jw/Hj8Xnyz/Fw0ePsHf/gVxd8TXKBfPmIqh3LyF/xsw58PCojd07 t2HQgP4sfPs5bv5zS96mTh1P3LhxU6y6VI8IFIqATsKhhdKAGhMBIyQQzL78FdPZ8xHgXpxU KkVbtqOzQ/t28mK+XljL3R09ewQCLG6zaes2zJr3CbZuXJ/rlzr3eLlxrFy5cqGIiu1P1smk CePR2LuR8LZ9u7a4dSsyV/8jRwxHg/r1hDzuHfJ1z+bNmsHJ0VF48TO45uZm8jbOTo44dfpM Lhn0hgjoiwAZQX2RJblEQAsCTX2a4MttWxD14AHWsJ2i+5g3NaBfX0ECDxUqhgsd7O0xaGgI 7rO6fA1RllLZ+iRPFWxyLVzLy8X+IbY/mTwrq/Jy0Rbm5oKhU0ympjlfMxYsDMfHNXPOPLzd 3Fd48fVLni9LfLNRKi3BiJ0uqldIAhQOLSRAak4EdEGAG4+qVV3QuqUfBgUPwKFvD+cp1tW1 OgujlsWzZ3G56kiyb8qQmqbbNfy8+stTQQ0FfC10146tqF+vHsJYKJWvj0ZH/ytvlZGRwbxD +n2uASMV64gAGUEdgSQxRKAgBP66dh0DhwwF3ywjS/zog6kk57ztmAkTEa4QHnwaE8Pqv4G9 UtiTe1NmZmZ4Hp9QEFXkbcT2V5BOuPe6dfsOODs5oV+f3ti8YR3b0GGNX06elIt78SKRdoYW BC61KRAB+rlVIGzUiAgUjsDerw+gzTutUIPdHSUpKRkr2W5JbhT4ofb9B0JZWWt5B02bNGaG Y6ewk9LayhpfbNgITw8PVK9eTUWJWu41c3lVKhXUZBw89B282Zqe7E4t2vSnRly+WTzUuf+b ULaWWVbYAfrkSbTg0VarWlXejhvKWrXc85VDhURAVwTICOqKJMkhAiIJcK/vu7AwODs7ok3r 1sKuyvUbNyHkg9Hg62vvtmuHYe8PkUsbNHAAO96RgTmfLBSOeTT08sLiBfPUbl/na2wRFy5g YP+s9UQxKvHdnRIzidwIatOfGPmKdSrb2WHZksXYsGmLsO5ZkR2lGNCvD/yzzzXyw/5//nWN jkdoC5bqF5gAnRMsMDpqaIgEivqcoKEx4Dsv+Rrb13t2qYRLDU1Xdfrwe55u2rINe3btkN82 Tl09ystNgM4JFvyKoDXBgrOjlkTA4AjwdcI+7Dzelq3bDU43TQpJ2Q0Ndu7+CqNHjSADqAkW leuMABlBnaEkQUTAMAiEsFuOPYuLy7WZxjA0y1+LzcwD9GnsjVZ+Ip9llr84KiUCogiIWhPk t84RcXc1UR1SJSJABPRLgN/+it9sOzFR9cbe+u25cNJ79ewuHJ6nRASKkoAoT7A8u7+cxhuM FqXW1BcRIAL5EuD3guS7SUtSIgNYkmar9Ogqygjyc0vWlhbIupUqmcPSM/00EiJABIiAcRMQ FQ7liARDqHB7JOPGRqM3VAL57Q59aVIOJuw6Llf6b4xvqNNDehkIASv28GZL9uI3WDBndyui p0gYyMSQGkSACBABIkAEipKAqHBoUSpEfREBIkAEiAARKCoCZASLijT1QwSIABEgAgZHgIyg wU0JKUQEiAARIAJFRYCMYFGRpn6IABEgAkTA4AiQETS4KSGFiAARIAJEoKgIkBEsKtLUDxEg AkSACBgcAdHnBPn5q/SXGXj95jW7hZrBjYMUMjAC7E57KFe2HCzMzdQ+8sfA1CV1iAARMFIC ojxBbvNS0tLxij0HjQygkV4pWg6bXyf8euHXDf1m0hIeVScCRKDICIgygi+ZB0g30C6yOSlV HfHrhl8/lIgAESAChkhAlBHkv+gpEYGCEqDrp6DkqB0RIAL6JiDKCJIXqO9pKN3y6fop3fNL oyMCJZmAKCNYkgdIuhMBIkAEiAARyIsAGcG8yFA+ESACRIAIlHoCZARL/RTTAIkAESACRCAv AmQE8yJD+USACBABIlDqCZARLPVTTAMkAkSACBCBvAiQEcyLDOUTASJABIhAqSdARrDUTzEN kAgQASJABPIioHsjGLUaPRr6YcYpzXcJST42Gr6dl+FaHtppKs+jmQ6y4xCxfBi6tPRBq+A9 iNKBRN2IuILFnf0x6ViSbsSRFCJABIiAkRMQfQNtsZwiw07hPpIRdywCGW3bwkxsQwOqlxGx GjNC49Bp4Q709nCCk8Ho5oaOw0KQ3MDGYDQiRYgAESACJZmAjj3BW/g5/Dla9A6A9a9h+LWE OizJ0dGQOrVF705e8HCzMyBDbgefoGD4O5fkS450LwoCZ8+dx8nw00XRVZ597N6zF3fvGU4c JU9FqcCoCejWCF4Lw7HnPug2ug/8rX/DEWUrGHcen4V0gm9TFmYM/BA7I5SspKZyxamKu4Id 04LQnsnybdkJw5efQrSsPOMWjswZKIQzedngOWGIlEVnk8IwtmkAFodux6Q+/vBt6IMuIcsQ EZfV+LeF/nh30W+Q3t+Bfg29MJx5hELKiFKQGYCxy89n9SfI64Sxcz5ED9Zfj9W3RNTPu3+h cZ5ju4K5rI9Jp1gdDeMQ5Dw5lYv3jtUfolXbhXmGn7MUp/+LJfDixQvs2fc1+gUPVmkSExOL WXPmoUtAD3Tv1Qdr1q2HNDNTpR7PSE5Jwdz5C/Fu5/fQpVt3rFyzFq8V7tf779OnaOXfXuWl WEdR8I2bN1l/G1C3jqeQLVaX9PR0oQ/eXhepsbc3Zs6eixeJiboQRzKIgF4I6DQceu1YOJJ9 PoSfnRec/K0xNiwCyZ06w1pQ/Qn2TpyIIwjCp1/1gVPyFWyauwhSeGUPTFO54vh53dHYZzYa n37TCbbJEVg7fRomSfbgwEQ7HJsegs/iArBg23J4IBI7507D8OkSfLe6M+wEMfdxZE8UZs3e iAlmkdg8fQ7mbeyME3O84DPnGH50G4YeoV7Y+tVEeNjwgG4cwqcPw9qMYMz/ajmc4lh/cydi hlMYdgewYmk0rkX5Y9aGUHg58eCphvr59J/FKa+xKTLIfxxgK5l7GRNF3jsZ7xTGX/v0ApE/ H8Nfca/wSqWxCUzs6qNDx/p4S6Ws9Gas+WI9wr7/AeXLl0dSUu4fc9w4Tft4FpydnfDFqs/x PD4eC5d8yp6taIEPhg9TgbJm7To8ePAQa1auQFpaGqu7FHa2dhgcPECoG8/aSyQSrFi2NFfb smVVf8O+efMGy1eswuiRI+BYpYpgTLXRRUW5QmTUr1cXLVo0x9ZtOzB1yqRCSKKmREB/BFQ/ RQXu6xq+D4+DVyc/wegJ//52BOGy74eoYzgY6YSghdPh7+kGj6Z9sGCUDySy/jSVK+p1K5TJ 8sDQBSHwcXOGmxeTNTUQZtFRiIsKYx6mE4YK/TjDybMtZi0Ihl3EDhyRR2Zs0XH2HAQ09WRt AzG0oyuS799iposnM0jMuOEzgxkzgMKaJpO5KcINIxeGwI/3x3SfOpCZV2b0Be9TYotOH05H Jy83ONmxFprqI5/+8xuboJ9iykcO0+FgpFs2hyzes0b55fBWFpXv+7fg4VsfJnF3ce+u0ivO BPVYmTEZQI7KyspKMFqzP56uQu6fW5G4FxWFj6dPRc2aNdCMRSuCevXErxcuqNTNZN5h+Jmz GDkiRPDcfJo0Rp/evfHLiZPyuvEJCbCtVAnejRrmepXhTy5WSr9euAju0bVt845Qoo0uyrI0 vX/NDK6m1DeoN348elT4IUCJCBgiAZ0ZwYwrYQiPa4qOLbI3bTDj4md3ha0RZocToyIRbeaJ Jm4KGARjk500lSs0y7gfhWhrT3gorI1Zt52D3cuZ1xl5DfetPcDsUU7y9EMDsyj8L0oWEzWD tULfEu7tZUiZV6o+ZUQxmdLfsKIzC6/y8Ct79VhzHdLnTxQMZ05bMfXz6j+/sWV5sYo65jOO qGjG24OtaebUlyjgVj/SfHLfqo+eQ3qhbgWFOhXqoceQ3qhnbBaQIQgZOgQN6tdTC8y+sh0W L/gE1sxQypK5uRlMTLICL9w769M/GOGnz4CHOqVSKdyZsZSlWu418fDRI8iMTHx8AioxIygm nTwVjua+zSDzEjXpok7m9b9vYMiwEWjfqSsmT50OHvblSRYuXbdhE3oE9WUe3nYh//adOxgz /kOhPg8N/3TsZ7nYKg4OqOFWQxgrJSJgiAR0FA7NwPUjp/Bc+hzzWnlhnsJIJUciEBcYmB2G lGjYZKKpXARCwbVU/rbPMn6aD23kI9+ahTu/mgYfuevKu7FmPl24+kba1lcvpeC5yggKLimn pWAI2dtdh3ATxmsANaG0t7cHf8kSD1Ee/+UE3mndSsgqV64cArp1FbzE1NQ0Ic/aOmvRQPY3 b/OSeXQ83MrDobHPYgUDw/9uUL8+pk2ZDAeHnD5kfV2/cQMjhg2VvRX0yE8XeUWFPw4f+V6Q z/Xkodm9+w9g7KiR8hp8zXDBvLlwcnIU8mbMnIPWrVti9swZ+OOPP1k49nO4Vq8uX5Oswzzc GzduonfPHuq6ozwiUKwEdGMEM67gSEQymkz9BrP8FL277Rg7nXuIgQhy84BrxilEPgF8ZB6c olXSVK6AycyVhR3ZmmIUczJ9st2jjGvfYO01Fv7z84Jr8jG2RsfKZF7Qrd9wPcMN3dwKZhnM nFh/TPf7Gc4IkHtWGcjIYOFSNZZV2/qKV0C+YwvW4lpx4ryPIZJx8MvWWapGVy0kZlXlhjDk LTSDC1xyHB2txRhTgz379gubQ3qzkKgsBQ/oL/ypbhOKLMr55r//hDoOzJuq5e6Onj0CAZa1 aes2zJr3CbZuXA/FkOirV6+ETTCVK1eW96P8hzpdlOtMmjAejb0bCdnt27XFLRbeVUwjRwyX e8HcO4x99gzNmzWDk6Oj8DIxNQX3fGXJmRnLU+QJ/r+9a42NqojCp62wtBQEWU0MEWgiAUFr NK2PIGIRpaCCCK2VIiRSIxAFDWqMUCuKJoCPigLlUWoFBKnG1JhIjIaYiIm2Jj4SFf+AJF0k YHiUQtv4Ot/dTju93e3O9rF7d+dMcrN7XzNnvplzvzlnztzrhln2PYJAn7hDW+oP0MHGXJo1 i+fYsrI6tqkcJerHXCEzX1Y+r7njIJUNtXTkHBNIw9dUsaeuwwUZ6bwO2PgCJ6+tpbup/kgD BTgqtaz0Lao/NYT8WbOpOCdAVaXldBDnfuMIybU1dCpngUZgUaLP5c3P/osDTVbTJ8yuAXaP 1nBkatH6OgrJK9Feb1q3aMR28DwSxOG3I3S4bj+9UHEorMs3mqwpUwjQFK9vv6uj6l272XIq 5cCYQV1uS0kJqiAsP5XauI8uYUsMaWb+dFr36lp2w+fSzTflUtmq5+nw4d/p6B9/dMqviYNq kC4dGnodaSRZVGaZmYPb84XMIDo9DRjQMXZOT0+n+UUP0vMcCbu6bA3P/x2g22+bxC7QDj88 rNmm802d8pAdQcArCPQBCbZQfe1Bas3Jp7wuupdN0/P8dJjPB2gkFZSX0/TGLVQ0eRJNK9lJ reOyqcOYiHReh2wkFZdvofm+WnqucAbNWVZJjXnraNOTCAn306x1lbQ8i9+ugnMl6+nnrBW0 Y51yyfYEepbtzS30NJPKxsWz6Z7CFfQhFdKaFbldHK/B3KO93rRu0cgexHOW7wA992ABlaw9 RFk51/UwMCaacuVahQDm9cpeWksrn1rBrsFrQgKj5g2xTEKlc43nHFekT58z1+4eM2Y0n0+l kyfb5tvbzg1kCwyp6UJXwjGRJaSABgcRiVq9cztdO3Ei1bIr9aEFiygQON5+Z0tLC1uHfeN0 MhBHLhEEokIg5T9Oke44J6O4SBAlxPnAzgKacyCf9u1fTFq8TExkH6pZF/1ZoOrO+FUb3ISI wmxubnasGixDGD8+uIaut7LAusIShK++/LxTViC1x5Y+TpPZKgJJhEsIksm/d7YTZarmDPfs /YCjQ7+gdyu3O7ctW/4kFfB8Wl5bxOefJ05QQVEx7aqqJBCinhCcsorzyptye/thU1mAzd0z 76OKTRtp4oQJzv2wYhFxunXzOw527vOwRhHJWsLzkHDNAvOFj5TQtKl5tOjhoP9+Gy+R+OXX X6n89Q2dZJWdvkPgs88+pSFDhxtn6B8xgjIyMgiW/CC29gfwAAqBW2hDtSGzUBHIxoUkyIUy PEuQhopezAaqWbyUvsl7lpbn8QM/UEuv8drIMQumxpwAo5c9se9AVGcZL36/7LLhztIIfXkA LD+s+QPR3TFlMo3kdaV3MmFsr6xyAlhA1DUffkQF8+a2g5DLyyZw3u8fwRGnQ+jtzVto/Lhx NHr0qC5AIbJUt8JMZOmSSRQH4Orct7+GH5apNHPGdGpoCDgW6qirrmrPBUQ5duzVUeQqlwoC sUNASDB2WMe4pJGU/8xi+n3Delr41lFq9Y2hnHnltOmRWNuAMa62B4o7duwY1dV/70iCpQR6 Kitd5VhpH9fW8mL6Kx0SfGLZEtrwxpu0/KmVPBpPo7vvmkZFhfPab3u4eD4HYbVQ6Ysv828z XZ+dzUswykKO0m+95WY6xOsRix8KlhtJFlhsvUmX+/08X/kKba7YRu9zFOnwYcN4jpBjAdqs Vsx1/vDjTxIZ2huQ5d5+RUDcof0Kr2SuEIi3OxQuUeUObWpq6jN3qNdaGJGamJPbu7uarugm SjRWcuMdphXbdtDu6p3taxdjVbZN5fTEHQorXrlD4Qq11R3aB4ExNnU1qasg4G0EQHyF7Erd tj24kD2e0uJdqVXv7aKlSx4VAoxnQ0jZ3SIgJNgtPHIyWRCwYYJftRXeZnPyFL+/Ns5r87ay BZhz4w00edKkZOlGSVkPm3QjVAPKnGAoVOSYIJDACMCthZdtnz0b32+ZzX3gfmfxvCRBwMsI iCXo5dYR2foUAZtGvAh5RzRpPJMQYDzRNyvbJp0Ih4iQYDhk5HhSIiBKn5TNKpXqAQKiC0HQ jEhQwOpBD5Nb2hHwWv/xmjzSVQSBWCMgOtCBuBEJqncYxrqhpLzkQCDe/UcUPjn6kdSi/xCw WUeMSHCQb2DIhbn91ySSc7IgAOXSvyjQ3/WyWZn7G1vJ3y4EbNElIxIEGJkZ6c5b7fmvJEEg IgLoJ+gv6Dde6TLox7YodsQGkgusR0D0IdgFjJdIALCM9K6fgrG+JwkAnkVAER5+8aV1fd+z QotggkAMEAilG7aSopElGIM2kSIEgT5FQLf4dIXHJ4pAiJIEAZsRgA5AF0INDHXdsQEjeRrY 0MpSR0fZ9U0gEQRsRkD0oaP1hQRt1gRL6q4UXrlEMQI2+IymJehINW1EQFmBSidss/70NhcS tFEDLKqze8QLpcd2+vRpIUKL+oFUtTMCSg/c+mEjTsaBMTaCI3VOTASg2LD01K+qBfYxAsa7 Nc+cOUPHjx93vpbe2trqfHkeX3nXv0yPb+FJEgQSAYG0tIF0gT8RhuQOAkOfx2v08DFnfDoJ G3RAnxPUdQT/bbIMhQQToYeLjL1CQI12ofSKBPFQUCSHY3hA6CSoCgznNg13vFeCys2CgCEC 4UjKfVwN/FQf9/l8DiEqElRE6L7PUIykuExIMCmaUSrhRkBZgfqviogD4SkSwzHswxLEMWyK HHWr0J2/7AsCXkNAEZn61ef7QHy6RYg+j3231Yg62UaIxiSIB8LF5hb651+4jLzW/PbJg8Xo aalplD7IZ9xpbWpD4JOakurgoxQbyo0RsE6AeDjgq/MYIYP8Llxspn/p77Y+HuzoyMtt+bn3 7euBwRo7OHM/lLdKxbYHuIlK39fJUJEcfpX1pyxB/UvysZXeW6WlsDJHpDRccL7pQpcHgbeq Yqc06PCZgzMivpXF5jYEPmA1dHW4PEF2+FWbs89b4/nzwDyTjwAAAQtJREFUfK57dVDqYqA2 VnVI9MPBHno7ULKDrxNdd3XFdSoIRnlC1LSA2sc1pvl1V1ainjOyBJvZAhSl92YTo13QPsri CSelzW2o46O7iNRDABjCAvT5Ot6IhGPdBsZEHjuGa4okPh7b98QmMZARq6Zbfu6LdRcnzimS cxOiflxd587Lhn0jEvybR82SvIuASfuYXOPdGvZOMlh5SFB6jIJBbuqBgP8gvJS2uUGd+GTg Fx3uwBRuZUnxRUAnSBCiSqrPK/Jzn4uv1PEr3YgE5WEQvwYyKdmkfUyuMSkrEa9xSI4f0AoD KD/+q+OoE8gRSUiwdy2MeSZJ8UUgHAlCKkWA+jX6//hKHp/S/wfqzyKGSTV2RwAAAABJRU5E rkJggg== --88bd74d5948c45abab56160e9397149e-- --29d010928c0b4a278eb48edebcab1530-- From nobody Thu Feb 14 16:08:31 2019 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 0C5EF12F1A6 for ; Thu, 14 Feb 2019 16:08:29 -0800 (PST) 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=yN1bfaRa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hshakXOY 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 57RkwKWrO1PX for ; Thu, 14 Feb 2019 16:08:27 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A503C128B36 for ; Thu, 14 Feb 2019 16:08:27 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8C6E822075 for ; Thu, 14 Feb 2019 19:08:26 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Thu, 14 Feb 2019 19:08:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=1iv9u4etrso4uom+k0oXK1Yl3pTq w8us3v9YXCo/kF4=; b=yN1bfaRazPt60oEYyrtBpOjFKpjNop2329GLTP/u/qqp OAf5W14fhVyyEbvFPAFt/Z7n0O9viM4Fdegr3N9CPnNM9HoFjnDOp8kHhdJFrTIU WdeSELiqt5SciGxMxahDJCT49RNhbiuqIt3Z0y4x3ySvApilII4JhqlAz22OQIwO Z9DDLfVd8US3emajEZ1SpA40A3CchxFs2DUxpErIknBsrDinCvxUe/p/4xj/YRT9 BApkbGvcGJziBBqs1tHnO97nXBydnL7mpBJXyrLMbLrHMaEo14sGJT2qtAiaYRhs QuGrL0Pj0haDXVh2jjL+UGVz0hMi5r6vvx1UxHwkZQ== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=1iv9u4etrso4uom+k 0oXK1Yl3pTqw8us3v9YXCo/kF4=; b=hshakXOYkNKr8Va79kbpGt3O14o6wUbW7 gZQ/u+WWmsbSRjbIuwVW3spPyskhDWgK6p0hRBqhX9NAQVebkbrcBvzVOuW2/YsE ALM+reexfGkaFXBwJugxVwm3Yjy/GFT07V48eNUVhGH5ixsgQZNVA9mCK9N0Axka QWH1UdTgFGQULuMbEYnu0Ml41Crlr7hSBnBMA+85Bmy/Q6zFPi8ABDlKQ8LuwhYV +xAfW4hn60blDy08/aCtQDio3FwpVq3rdcyKTR9y15AqMPBZYEuPnevtb3XgFgph xSjpfdrF2eM9jsHD1NILkRdLKfrtH5AD9MPfhek2ktQMxSl6fR5eg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtiedgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecunecujfgurhepofgfkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpe dfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdr tghomheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A6C2A20250; Thu, 14 Feb 2019 19:08:25 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 64588216 Message-Id: In-Reply-To: <61f84257-4e52-5bea-d51d-29048cc2d90f@dmfs.org> References: <1550161342.3633293.1658022312.2075C011@webmail.messagingengine.com> <61f84257-4e52-5bea-d51d-29048cc2d90f@dmfs.org> Date: Thu, 14 Feb 2019 19:08:18 -0500 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=cd2f9581366f4c27a01bb32828827635 Archived-At: Subject: Re: [calsify] JSCalendar recurrenceRule until vs. before 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, 15 Feb 2019 00:08:29 -0000 --cd2f9581366f4c27a01bb32828827635 Content-Type: text/plain On Fri, 15 Feb 2019, at 04:12, Marten Gajda wrote: > I've never understood why iCalendar specified until to be inclusive in the first place. However, I also don't see much of a problem either. Yes. My view is BEFORE is better than UNTIL, but possibly not enough better to justify deviating from iCalendar here (even if the two are trivially mapped between). > If this is really a concern for some of us, there might be another solution to this approach: Just allow until to have a non-zero time component, even if all-day is true. This way "until=2019-02-14T23:59:59" could be used for all-day and non-all-day events. > Conversion to iCalendar RRULE is trivial: just remove the time component > Conversion from iCalendar is trivial too: just append "T23:59:59" to the until date. I'd be perfectly happy with this (indeed, this is what my implementation initially presumed). Neil. --cd2f9581366f4c27a01bb32828827635 Content-Type: text/html
    On Fri, 15 Feb 2019, at 04:12, Marten Gajda wrote:

    I've never understood why iCalendar specified until to be inclusive in the first place. However, I also don't see much of a problem either.


    Yes. My view is BEFORE is better than UNTIL, but possibly not enough better to justify deviating from iCalendar here (even if the two are trivially mapped between).

    If this is really a concern for some of us, there might be another solution to this approach: Just allow until to have a non-zero time component, even if all-day is true. This way "until=2019-02-14T23:59:59" could be used for all-day and non-all-day events.

    Conversion to iCalendar RRULE is trivial: just remove the time component

    Conversion from iCalendar is trivial too: just append "T23:59:59" to the until date.


    I'd be perfectly happy with this (indeed, this is what my implementation initially presumed).

    Neil.
    --cd2f9581366f4c27a01bb32828827635-- From nobody Thu Feb 14 23:09:23 2019 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 5FDE112008F for ; Thu, 14 Feb 2019 23:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 UpuvZd_zqVYD for ; Thu, 14 Feb 2019 23:09:18 -0800 (PST) Received: from dd40210.kasserver.com (dd40210.kasserver.com [85.13.156.70]) (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 C718F1200B3 for ; Thu, 14 Feb 2019 23:09:17 -0800 (PST) Received: from nbnimm (178.165.129.3.wireless.dyn.drei.com [178.165.129.3]) by dd40210.kasserver.com (Postfix) with ESMTPSA id 9F10063A0697 for ; Fri, 15 Feb 2019 08:09:14 +0100 (CET) From: "Alexander Nimmervoll" To: References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> In-Reply-To: Date: Fri, 15 Feb 2019 08:09:17 +0100 Message-ID: <029301d4c4fd$5eaca610$1c05f230$@caldavsynchronizer.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0294_01D4C505.C0710E10" X-Mailer: Microsoft Outlook 16.0 Content-Language: de-at Thread-Index: AQOLZthb+8PHggH5/l2b8JGbRR609QKonOjiol3hCEA= Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time 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, 15 Feb 2019 07:09:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0294_01D4C505.C0710E10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sounds reasonable. I like the idea of the extra property indication "wall-time" for duration to handle the fixed end time special case during DST shifts, discussed in the nightclub example. So why do you stick to due instead of start+duration for JSTasks? For the airline example with start and end time and fixed scheduled duration an idea would also be to use the estimatedDuration property for the scheduled flight-time or something similar. Cheers, Alex Von: calsify Im Auftrag von Neil Jenkins Gesendet: Freitag, 15. Februar 2019 00:20 An: calsify@ietf.org Betreff: Re: [calsify] JSCalendar duration vs. end time On Fri, 15 Feb 2019, at 03:03, Robert Stepanek wrote: Two arguments were raised in favor of adding an end time * It simplifies translation of VEVENTs with DTSTART/DTEND from iCalendar. Every client/server will need to be able to translate between duration and end already, so this is unlikely to be a significant hurdle to anyone. * It allows to specify recurring events with a fixed end time even in case of time gaps (e.g. a recurring night club that has to close at a fixed time for legal reasons). You kind-of mention this below, but I think it's important to note that this argument is false.. You cannot do this with recurrences as they exist right now in iCalendar. On Fri, 15 Feb 2019, at 05:25, Alexander Nimmervoll wrote: But looking into it also from client UI perspective almost every client allows you to choose start and end time and not start time and duration for an event. The UI is independent of the underlying data format; as mentioned above you need to be able to translate between the two anyway. Is there a reason you choose start time and duration vs start time and end time? Yes.. There are many reasons why I strongly believe duration is preferable to end: 1. Having two representations for the same thing requires more code complexity, as there are two code paths to deal with. 2. Recurrences always operate with duration regardless of whether it's actually specified as "end time", which is very confusing. With duration, it's very clean: you expand the start time according to the recurrence rule and then just inherit every other property (duration is just another property you inherit). 3. There is no extra expressivity adding "end time". You can always convert from end time to duration. The one exception is if the time zone data changed so that an offset transition now happened in the middle of the event AND in such a case you wanted the event to maintain its original end time rather than its original duration. I contend that: 1. This case is exceedingly rare, and not important enough to make the common case more complex. 2. No UI will ever be built to offer the user a choice for how to handle this situation, so it's even less important to handle. 3. A better way to handle it would be to add an extra property that could be used to indicate the duration should be done in "wall clock" time; this would then also work for recurrences, which there is no solution for in iCalendar. 4. Duration is guaranteed to be zero or positive, making it harder to create an invalid event and easier to check that an event object is valid. If you move the start of a series of events you don't need to make sure to keep the end in sync. 5. Should time zone definitions change, it is more likely the duration should remain fixed and the end should shift (e.g. for flights). Using start and end time allows also an easier specification of different start and end timezones This is modelled differently in JSCalendar: there is a single time zone for the event, which is what it is scheduled in, but you can associate time zones with locations and mark that a location is where the event finishes, which is equivalent to the end time zone in iCalendar. This again is clearer, as it more closely matches the semantics of iCalendar (the "end" time zone is not used for scheduling/recurrences, it is only used for displaying in the UI after the necessary date arithmetic). And if time zone definitions change, again it's more likely the duration should stay constant rather than the end time (the example everyone uses for a different end time zone is flights: flying from Melbourne to LA is not going to get an hour shorter if California suddenly changes its daylight saving rules). Neil. ------=_NextPart_000_0294_01D4C505.C0710E10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Sounds = reasonable.

     

    I like the idea of the extra = property indication “wall-time” for duration to handle the = fixed end time special case during DST shifts, discussed in the = nightclub example.

     

    So why do you stick to due instead = of start+duration for JSTasks?

     

    For the airline example with start = and end time and fixed scheduled duration an idea would also be to use = the estimatedDuration property for the scheduled flight-time or = something similar.

     

    Cheers,

    Alex

     

    Von: calsify <calsify-bounces@ietf.org> Im Auftrag von = Neil Jenkins
    Gesendet: Freitag, 15.     Februar 2019 00:20
    An: = calsify@ietf.org
    Betreff: Re: [calsify] JSCalendar duration = vs. end time

     

    On Fri, 15 Feb 2019, at 03:03, Robert Stepanek = wrote:

    Two = arguments were raised in favor of adding an end = time

    • It simplifies translation of VEVENTs = with DTSTART/DTEND from = iCalendar.

     

    Every client/server will need to be = able to translate between duration and end already, so this is unlikely = to be a significant hurdle to anyone.

     

    • It allows to specify recurring events = with a fixed end time even in case of time gaps (e.g. a recurring night = club that has to close at a fixed time for legal = reasons).

     

    You kind-of mention this below, but = I think it's important to note that this argument is false.. You = cannot do this with recurrences as they exist right now in = iCalendar. 

     

    On Fri, 15 Feb 2019, at 05:25, = Alexander Nimmervoll wrote:

    But looking into it also from = client UI perspective almost every client allows you to choose start and = end time and not start time and duration for an = event.

     

    The UI is independent of the = underlying data format; as mentioned above you need to be able to = translate between the two anyway.

     

    Is there a reason you choose start = time and duration vs start time and end = time?

     

    Yes.. There are many reasons why I = strongly believe duration is preferable to = end:

    1. Having two representations for the same = thing requires more code complexity, as there are two code paths to deal = with.
    2. Recurrences always operate with duration = regardless of whether it's actually specified as "end time", = which is very confusing. With duration, it's very clean: you expand the = start time according to the recurrence rule and then just inherit every = other property (duration is just another property you = inherit).
    3. There is no extra expressivity adding = "end time". You can always convert from end time to duration. = The one exception is if the time zone data changed so that = an offset transition now happened in the middle of the event AND in such = a case you wanted the event to maintain its original end time rather = than its original duration. I contend that:
      1. This case is exceedingly rare, and not = important enough to make the common case more = complex.
      2. No UI will ever be built to offer the = user a choice for how to handle this situation, so it's even less = important to handle.
      3. A better way to handle it would be to = add an extra property that could be used to indicate the duration should = be done in "wall clock" time; this would then also work for = recurrences, which there is no solution for in = iCalendar.
    4. Duration is guaranteed to be zero or = positive, making it harder to create an invalid event and easier to = check that an event object is valid. If you move the start of a series = of events you don't need to make sure to keep the end in = sync.
    5. Should time zone definitions change, it = is more likely the duration should remain fixed and the end should shift = (e.g. for flights).

     

    Using start and end time allows = also an easier specification of different start and end = timezones

     

    This is modelled differently in = JSCalendar: there is a single time zone for the event, which is what it = is scheduled in, but you can associate time zones with locations and = mark that a location is where the event finishes, which is equivalent to = the end time zone in iCalendar. This again is clearer, as it more = closely matches the semantics of iCalendar (the "end" time = zone is not used for scheduling/recurrences, it is only used for = displaying in the UI after the necessary date arithmetic). And if time = zone definitions change, again it's more likely the duration should stay = constant rather than the end time (the example everyone uses for a = different end time zone is flights: flying from Melbourne to LA is not = going to get an hour shorter if California suddenly changes its daylight = saving rules).

     

    Neil.

    ------=_NextPart_000_0294_01D4C505.C0710E10-- From nobody Fri Feb 15 00:20:12 2019 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 A40E3130E7E for ; Fri, 15 Feb 2019 00:20:10 -0800 (PST) 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=fTPoN0mW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cV+vkEyc 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 HYQM2fnJIf6e for ; Fri, 15 Feb 2019 00:20:09 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24825129A87 for ; Fri, 15 Feb 2019 00:20:09 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id F167122694 for ; Fri, 15 Feb 2019 03:20:07 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Fri, 15 Feb 2019 03:20:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=YwJF7jNA6cP6c7s1g+RI6um2jy6/ YirdIfH7KYZdCno=; b=fTPoN0mWFBkO2RZsonm71k5NXc1iZb/0HQMILRJMXtpV Oe7Aq83OCJ4hgXMPQxODiRPlKzliqrUgOw6jZzi8vACwYIEGBk1YeGHpmYSA0bXY E4yhpB9paVTSR9NACqTZtUR1OMbqbM3HlZEM3wLCpLCqjCwidk+FxJ3eJj3VaLgP xe7NduWkvtdstkTBbS6zJWMY9IbGDBgmoNyJb1am8L/D069hJiBWco4NPLh/LaJY f+vFVf6F+5TZaI+hRgcC2HwCQW7e5Bv7eye6CFw7Bv0E8LgmVznRUmVvHEcE3eSe 1WobxWZYtN9fv3SKHPiq4NHbZDDiOXnDkGpSX66FVw== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=YwJF7jNA6cP6c7s1g +RI6um2jy6/YirdIfH7KYZdCno=; b=cV+vkEycXk4uWiDfyza8NsyDQizjmWsLs T427G3HJLuWo0CRgLQzk3T3A2k5sl+NdDeYc83II+3OF8YhHonjiPllLnaLs9U/y vpxM1p/Q6ksCQP/itrLJW5EosVdzXpIHG+bh2RiB7Iaw0o1Q0krQiQ0xfBgmHILR d0przzMeKzl9cBhKY9GzucV0P+r6DF36CeA2QoIu1Jd5e4HwA1Xv6KNL5zXDX3Ig s05D3FAF+kW9VV7UG+I16nL4kuEk3mjTMzjaeFJw+LVvexf665bynIQpvc+3Sqmu 2EDmXLRaBh/lzQ6bTmNKJ7Yc5ZCQNbjQF5M/RHwoP4zrRHmL2FXBQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtiedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecu fedttdenucenucfjughrpefofgfkjghffffhvffutgesrgdtreerreertdenucfhrhhomh epfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohesfhgrshhtmhgrihhlthgv rghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrg hilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 34C7620250; Fri, 15 Feb 2019 03:20:07 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 91525120 Message-Id: <392569fa-f464-4e8a-9c7a-f2e3401c30af@www.fastmail.com> In-Reply-To: <029301d4c4fd$5eaca610$1c05f230$@caldavsynchronizer.org> References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> <029301d4c4fd$5eaca610$1c05f230$@caldavsynchronizer.org> Date: Fri, 15 Feb 2019 03:20:06 -0500 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=eeac7526c13f4afe9b9cd6d50f3e7b5e Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time 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, 15 Feb 2019 08:20:11 -0000 --eeac7526c13f4afe9b9cd6d50f3e7b5e Content-Type: text/plain On Fri, Feb 15, 2019, at 8:09 AM, Alexander Nimmervoll wrote: > So why do you stick to due instead of start+duration for JSTasks? There is no duration for tasks, the time properties of JSEvent and JSTask differ (see section 5 in the spec). For events, a start is mandatory, optionally defining a duration. For tasks, all time properties are optional. It can be defined to start at a certain time, be due at a certain time and have an estimated duration, but none of these are mandatory. We got asked to allow estimatedDuration and the time span between start and due to not match, which can be useful to highlight resource issues in project planning. Admittly, implementations still need to handle due-before-start issues for JSTask. > For the airline example with start and end time and fixed scheduled duration an idea would also be to use the estimatedDuration property for the scheduled flight-time or something similar. The estimatedDuration property is not defined for events. Cheers, Robert --eeac7526c13f4afe9b9cd6d50f3e7b5e Content-Type: text/html Content-Transfer-Encoding: quoted-printable
    On Fri, Fe= b 15, 2019, at 8:09 AM, Alexander Nimmervoll wrote:

    So why do you stick to due instead of start+duration for JSTasks= ?


    There is no durat= ion for tasks, the time properties of JSEvent and JSTask differ (see sec= tion 5 in the spec).

    For events, a start is= mandatory, optionally defining a duration.

    For tasks, all time properties are optional. It can be defined to start= at a certain time, be due at a certain time and have an estimated durat= ion, but none of these are mandatory. We got asked to allow estimatedDur= ation and the time span between start and due to not match, which can be= useful to highlight resource issues in project planning. Admittly, impl= ementations still need to handle due-before-start issues for JSTask.
    =

    For the airline example with st= art and end time and fixed scheduled duration an idea would also be to u= se the estimatedDuration property for the scheduled flight-time or somet= hing similar.


    The e= stimatedDuration property is not defined for events.

    <= /div>
    Cheers,
    Robert
    --eeac7526c13f4afe9b9cd6d50f3e7b5e-- From nobody Fri Feb 15 00:30:09 2019 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 A1994130E7E for ; Fri, 15 Feb 2019 00:30:07 -0800 (PST) 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=fq2doxd6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=vdTlkCyb 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 Axq7KphwFS3y for ; Fri, 15 Feb 2019 00:30:06 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850D3129A87 for ; Fri, 15 Feb 2019 00:30:06 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 934E022A0B for ; Fri, 15 Feb 2019 03:30:05 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Fri, 15 Feb 2019 03:30:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm1; bh=IzJULdj3BnUSBZwt2j0fG7qSdaag 4NRABqgdXvewTWw=; b=fq2doxd6myESAuhvDWmu2PBZ0moNRw3gNyudzJRkQj8D yc1S/NS3eayizzcebNRjaYxxZm8jQHJ7cFV4LDJg+X2LkmdxuKWjxRf/pE0Pttfz T2gavl9xfavVsliDHVqfx5nsV57PsRboB3oIRGQrQ6JrtktxKYR6nOvM/u/9PCgz zb0co2FvrLhtoS+1HzTie2bHOLq/BRfbd8DwUhD5lUinrhrmMQYT5cyXVhqFOZUE LnyegFhSbTRt/xzuLbNV+i0sEjSI/C1L3xsuxtwG0rePKG9scLSkoG3LQA7Ib6uR ssftrQ1+whsy7oB8+2IT+akFsUPmIXG5jucXxHkf9Q== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=IzJULdj3BnUSBZwt2 j0fG7qSdaag4NRABqgdXvewTWw=; b=vdTlkCybEd8j3RbT7oXEPDUPKg5WbDvQd QwBqL6xdL0RQ9JGnQ41Fujnt6E7Mk32EHAgWjKCFKXZPrLIucs3Q+LXHJGkJcvtB DNNQQ3HuS7Q+poqAN5XFYJUzsMKqHNUw6ppJdTosA71iQ67QE19s+pcNRxoJqb3C BxCVmvAiXX/bm7pnLnqIh1tHUIT99i/CAWpPr/7SHLBVMyndTX1GcjYBq+xwJ9g5 K0rD3fif0uHS8VdG7oCEz8A3SpaifzZTuD3NTTxmRjNGMSAq4FHXR6CUnG0tmsjM rkxSl9ZsHWqXdA+0wMpJGscI2L+UX+BT5l+ek6UIwZRNiwjklxung== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledruddtiedguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecu fedttdenucenucfjughrpefofgfkjghffffhvffutgesrgdtreerreertdenucfhrhhomh epfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohesfhgrshhtmhgrihhlthgv rghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrg hilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2989320250; Fri, 15 Feb 2019 03:30:05 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-832-gba113d7-fmstable-20190201v1 X-Me-Personality: 91525120 Message-Id: In-Reply-To: References: <1550161342.3633293.1658022312.2075C011@webmail.messagingengine.com> <61f84257-4e52-5bea-d51d-29048cc2d90f@dmfs.org> Date: Fri, 15 Feb 2019 03:30:04 -0500 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=23a1bcb8158042e4b0d81ebff1a03f63 Archived-At: Subject: Re: [calsify] JSCalendar recurrenceRule until vs. before 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, 15 Feb 2019 08:30:08 -0000 --23a1bcb8158042e4b0d81ebff1a03f63 Content-Type: text/plain On Fri, Feb 15, 2019, at 1:08 AM, Neil Jenkins wrote: >> If this is really a concern for some of us, there might be another solution to this approach: Just allow until to have a non-zero time component, even if all-day is true. This way "until=2019-02-14T23:59:59" could be used for all-day and non-all-day events. > I'd be perfectly happy with this (indeed, this is what my implementation initially presumed). Sounds good to me. Let's do this. --23a1bcb8158042e4b0d81ebff1a03f63 Content-Type: text/html
    On Fri, Feb 15, 2019, at 1:08 AM, Neil Jenkins wrote:

    If this is really a concern for some of us, there might be another solution to this approach: Just allow until to have a non-zero time component, even if all-day is true. This way "until=2019-02-14T23:59:59" could be used for all-day and non-all-day events.

    I'd be perfectly happy with this (indeed, this is what my implementation initially presumed).

    Sounds good to me. Let's do this.

    --23a1bcb8158042e4b0d81ebff1a03f63-- From nobody Fri Feb 15 01:08:12 2019 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 BC046130F28 for ; Fri, 15 Feb 2019 01:08:10 -0800 (PST) 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 qr0wJ_SdCSwG for ; Fri, 15 Feb 2019 01:08:08 -0800 (PST) Received: from mailrelay2-1.pub.mailoutpod1-cph3.one.com (mailrelay2-1.pub.mailoutpod1-cph3.one.com [46.30.210.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75837130E7E for ; Fri, 15 Feb 2019 01:08:06 -0800 (PST) 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=a1O8OwmJVR9tiRhIHdNbHbFa3oSUjEYqUJRTZOW4oN4=; b=gsXU1sDlOGAJw54kYIDn0VFv7cbqZ4BCDNh8sl7c8LbZ6TNDLAITc0kJxzNJsCjfWVsgZijyeEB29 63AhcUCqBzbqZQuY2dcerGR8PdWDehlvU5NN2sRAFNMr6smU8iFORN9JX8sdcZ42v9AcHnfE3JQn+x nunrhBLCDuyZLdUE= X-HalOne-Cookie: 979db6cfa2bb1ae127414adcadde9f180f0f9417 X-HalOne-ID: 330174b1-3101-11e9-a4c0-d0431ea8a290 Received: from smtp.dmfs.org (unknown [62.224.76.2]) by mailrelay2.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id 330174b1-3101-11e9-a4c0-d0431ea8a290; Fri, 15 Feb 2019 09:08:03 +0000 (UTC) Received: from boss.localdomain (p3EE04C02.dip0.t-ipconnect.de [62.224.76.2]) by smtp.dmfs.org (Postfix) with ESMTPSA id 10C173FA for ; Fri, 15 Feb 2019 10:08:03 +0100 (CET) To: calsify@ietf.org References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> <029301d4c4fd$5eaca610$1c05f230$@caldavsynchronizer.org> From: Marten Gajda Message-ID: Date: Fri, 15 Feb 2019 10:08:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <029301d4c4fd$5eaca610$1c05f230$@caldavsynchronizer.org> Content-Type: multipart/alternative; boundary="------------D3041D601C720390839E46C4" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time 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, 15 Feb 2019 09:08:11 -0000 This is a multi-part message in MIME format. --------------D3041D601C720390839E46C4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Am 15.02.19 um 08:09 schrieb Alexander Nimmervoll: > > So why do you stick to due instead of start+duration for JSTasks? > In contrast to events where the start is usually the more important date, the due date of a task is usually far more important than its start. So if you move a task in your calendar you usually mean to move the due date. In addition, in order to apply a duration you would always need a start, but iCalendar and most implementations allow tasks to have a due date only. And that's mostly what an average user cares about. There is an iCalendar extension which adds an estimatedDuration property to VTODO. Its meant to express that the actual execution time of a task is usually shorter than the execution window (i.e. the time between start and the due date). >   > > For the airline example with start and end time and fixed scheduled > duration an idea would also be to use the estimatedDuration property > for the scheduled flight-time or something similar. > Where would be the difference to the duration we already have for events? I think it might make sense to add a parameter which expresses that the duration is only an estimate or may be subject to change. We could, for instance, add a margin of error. For example: a concert starts at 20:30 and is scheduled for 2 hours. It may be delayed and the band may play a few more extra songs, but due to local regulations there is a hard stop at 23:00. I'd leave that to an extension of the current spec though. Cheers, Marten >   > > Cheers, > > Alex > >   > > *Von:*calsify *Im Auftrag von *Neil Jenkins > *Gesendet:* Freitag, 15. Februar 2019 00:20 > *An:* calsify@ietf.org > *Betreff:* Re: [calsify] JSCalendar duration vs. end time > >   > > On Fri, 15 Feb 2019, at 03:03, Robert Stepanek wrote: > > Two arguments were raised in favor of adding an end time > > * It simplifies translation of VEVENTs with DTSTART/DTEND from > iCalendar. > >   > > Every client/server will need to be able to translate between duration > and end already, so this is unlikely to be a significant hurdle to anyone. > >   > > * It allows to specify recurring events with a fixed end time > even in case of time gaps (e.g. a recurring night club that > has to close at a fixed time for legal reasons). > >   > > You kind-of mention this below, but I think it's important to note > that *this argument is false*.. You cannot do this with recurrences as > they exist right now in iCalendar.  > >   > > On Fri, 15 Feb 2019, at 05:25, Alexander Nimmervoll wrote: > > But looking into it also from client UI perspective almost every > client allows you to choose start and end time and not start time > and duration for an event. > >   > > The UI is independent of the underlying data format; as mentioned > above you need to be able to translate between the two anyway. > >   > > Is there a reason you choose start time and duration vs start time > and end time? > >   > > Yes.. There are many reasons why I strongly believe duration is > preferable to end: > > 1. Having two representations for the same thing requires more code > complexity, as there are two code paths to deal with. > 2. Recurrences always operate with duration regardless of whether > it's actually specified as "end time", which is very confusing. > With duration, it's very clean: you expand the start time > according to the recurrence rule and then just inherit every other > property (duration is just another property you inherit). > 3. There is no extra expressivity adding "end time". You can always > convert from end time to duration. The /one/ exception is if the > time zone data changed so that an offset transition now happened > in the middle of the event AND in such a case you wanted the event > to maintain its original end time rather than its original > duration. I contend that: > 1. This case is exceedingly rare, and not important enough to > make the common case more complex. > 2. No UI will ever be built to offer the user a choice for how to > handle this situation, so it's even less important to handle. > 3. A better way to handle it would be to add an extra property > that could be used to indicate the duration should be done in > "wall clock" time; this would then also work for recurrences, > which there is no solution for in iCalendar. > 4. Duration is guaranteed to be zero or positive, making it harder to > create an invalid event and easier to check that an event object > is valid. If you move the start of a series of events you don't > need to make sure to keep the end in sync. > 5. Should time zone definitions change, it is more likely the > duration should remain fixed and the end should shift (e.g. for > flights). > >   > > Using start and end time allows also an easier specification of > different start and end timezones > >   > > This is modelled differently in JSCalendar: there is a single time > zone for the event, which is what it is scheduled in, but you can > associate time zones with locations and mark that a location is where > the event finishes, which is equivalent to the end time zone in > iCalendar. This again is clearer, as it more closely matches the > semantics of iCalendar (the "end" time zone is not used for > scheduling/recurrences, it is only used for displaying in the UI after > the necessary date arithmetic). And if time zone definitions change, > again it's more likely the duration should stay constant rather than > the end time (the example everyone uses for a different end time zone > is flights: flying from Melbourne to LA is not going to get an hour > shorter if California suddenly changes its daylight saving rules). > >   > > Neil. > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 --------------D3041D601C720390839E46C4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
    Am 15.02.19 um 08:09 schrieb Alexander Nimmervoll:

    So why do you stick to due instead of start+duration for JSTasks?

    In contrast to events where the start is usually the more important date, the due date of a task is usually far more important than its start. So if you move a task in your calendar you usually mean to move the due date.

    In addition, in order to apply a duration you would always need a start, but iCalendar and most implementations allow tasks to have a due date only. And that's mostly what an average user cares about.

    There is an iCalendar extension which adds an estimatedDuration property to VTODO. Its meant to express that the actual execution time of a task is usually shorter than the execution window (i.e. the time between start and the due date).

     

    For the airline example with start and end time and fixed scheduled duration an idea would also be to use the estimatedDuration property for the scheduled flight-time or something similar.

    Where would be the difference to the duration we already have for events? I think it might make sense to add a parameter which expresses that the duration is only an estimate or may be subject to change. We could, for instance, add a margin of error. For example: a concert starts at 20:30 and is scheduled for 2 hours. It may be delayed and the band may play a few more extra songs, but due to local regulations there is a hard stop at 23:00.

    I'd leave that to an extension of the current spec though.

    Cheers,

    Marten

     

    Cheers,

    Alex

     

    Von: calsify <calsify-bounces@ietf.org> Im Auftrag von Neil Jenkins
    Gesendet: Freitag, 15.     Februar 2019 00:20
    An: calsify@ietf.org
    Betreff: Re: [calsify] JSCalendar duration vs. end time

     

    On Fri, 15 Feb 2019, at 03:03, Robert Stepanek wrote:

    Two arguments were raised in favor of adding an end time

    • It simplifies translation of VEVENTs with DTSTART/DTEND from iCalendar.

     

    Every client/server will need to be able to translate between duration and end already, so this is unlikely to be a significant hurdle to anyone.

     

    • It allows to specify recurring events with a fixed end time even in case of time gaps (e.g. a recurring night club that has to close at a fixed time for legal reasons).

     

    You kind-of mention this below, but I think it's important to note that this argument is false.. You cannot do this with recurrences as they exist right now in iCalendar. 

     

    On Fri, 15 Feb 2019, at 05:25, Alexander Nimmervoll wrote:

    But looking into it also from client UI perspective almost every client allows you to choose start and end time and not start time and duration for an event.

     

    The UI is independent of the underlying data format; as mentioned above you need to be able to translate between the two anyway.

     

    Is there a reason you choose start time and duration vs start time and end time?

     

    Yes.. There are many reasons why I strongly believe duration is preferable to end:

    1. Having two representations for the same thing requires more code complexity, as there are two code paths to deal with.
    2. Recurrences always operate with duration regardless of whether it's actually specified as "end time", which is very confusing. With duration, it's very clean: you expand the start time according to the recurrence rule and then just inherit every other property (duration is just another property you inherit).
    3. There is no extra expressivity adding "end time". You can always convert from end time to duration. The one exception is if the time zone data changed so that an offset transition now happened in the middle of the event AND in such a case you wanted the event to maintain its original end time rather than its original duration. I contend that:
      1. This case is exceedingly rare, and not important enough to make the common case more complex.
      2. No UI will ever be built to offer the user a choice for how to handle this situation, so it's even less important to handle.
      3. A better way to handle it would be to add an extra property that could be used to indicate the duration should be done in "wall clock" time; this would then also work for recurrences, which there is no solution for in iCalendar.
    4. Duration is guaranteed to be zero or positive, making it harder to create an invalid event and easier to check that an event object is valid. If you move the start of a series of events you don't need to make sure to keep the end in sync.
    5. Should time zone definitions change, it is more likely the duration should remain fixed and the end should shift (e.g. for flights).

     

    Using start and end time allows also an easier specification of different start and end timezones

     

    This is modelled differently in JSCalendar: there is a single time zone for the event, which is what it is scheduled in, but you can associate time zones with locations and mark that a location is where the event finishes, which is equivalent to the end time zone in iCalendar. This again is clearer, as it more closely matches the semantics of iCalendar (the "end" time zone is not used for scheduling/recurrences, it is only used for displaying in the UI after the necessary date arithmetic). And if time zone definitions change, again it's more likely the duration should stay constant rather than the end time (the example everyone uses for a different end time zone is flights: flying from Melbourne to LA is not going to get an hour shorter if California suddenly changes its daylight saving rules).

     

    Neil.


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

    -- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

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

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
    --------------D3041D601C720390839E46C4-- From nobody Fri Feb 15 01:45:10 2019 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 0ECE1130F9F for ; Fri, 15 Feb 2019 01:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cronofy.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f5ubP3keTFd for ; Fri, 15 Feb 2019 01:45:01 -0800 (PST) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 E769D130F9A for ; Fri, 15 Feb 2019 01:45:00 -0800 (PST) Received: by mail-ua1-x930.google.com with SMTP id c5so1105366uaq.7 for ; Fri, 15 Feb 2019 01:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cronofy.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=mhh2jnqJCl4kGVfzxQ+1m1tTZfW+rXulPl7C1ibtDeA=; b=LVfRMDD2OlIbGxQ1Yuw2BzhGWk7z5NBziTUEyYm5yhZkXVqa/5dAg3U6TxDFcr/u61 x5+srmRFQhrdcyf7zLqvwO19XZW+HYOeHQaVPj+POA3w5kJgMUYbfm3LA/QVG16mpB6I WHWkVU4YkxGnSB4kRRjn5zPC+LIBmR1mghI/Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=mhh2jnqJCl4kGVfzxQ+1m1tTZfW+rXulPl7C1ibtDeA=; b=mhU8uO5JZ9sSBBtkg0BFXcbHHvmqMOjTDHZ9+8IaFjgHbFXzp1tmg1qN9tI+N+eeB7 QCym6eCrOz5ibZC5kjSuX+Uc+4YHg9uQq+ShIhg9Qpvr0ywJvJsKbOg2fEpLbx3eQv9C e/UnOO6XIbndYsgb8RWUwu467C66ISasBY3aXk5iB0eBs3LYruxfSk366dY1ythJTsgV MIV16YpgUfkYlvDT8qu+sudzC9pSz4hQK7Ce4be6/cXbyYd2MmY2ZSIJUT7yVZh9oWJ+ Hza84aqYJVc76P2s3yGPxMt0yp/uHcmz0yvGTzw+ejk6hq5hTF7FqX1NqVZJrowPffJY IoWA== X-Gm-Message-State: AHQUAuZ8rpzRBVDZqyzlpsKeyRI/u6YNcaPk9iELjv5CbTPpBKqdeBtD vJ4i1tXTldL6y9TxoUmtoODS2mAwvXE2FnwgiPtdrcxdFNg= X-Google-Smtp-Source: AHgI3IaCuI2QVMRfM8Wma/Gwfkanv9hz136mAzNOVj32Um+07EE8F6dZq2Y20DxJvP2oyV6lwFMlolbbC976elJvF+E= X-Received: by 2002:ab0:13ed:: with SMTP id n42mr152798uae.49.1550223899338; Fri, 15 Feb 2019 01:44:59 -0800 (PST) MIME-Version: 1.0 References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> <029301d4c4fd$5eaca610$1c05f230$@caldavsynchronizer.org> In-Reply-To: From: Garry Shutler Date: Fri, 15 Feb 2019 09:44:47 +0000 Message-ID: To: calsify@ietf.org Content-Type: multipart/alternative; boundary="000000000000d7c9a00581eba0d8" Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time 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, 15 Feb 2019 09:45:07 -0000 --000000000000d7c9a00581eba0d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As the intended usage is so different, the similarity in naming can only lead to confusion, which has been demonstrated here. If tasks were to have due and estimatedDuration (and perhaps something like commencement rather than start), and events have start and duration it would be more clear that they are different to each other. - *Garry Shutler* CTO & Co-founder, Cronofy Scheduling Everything for Everyone On Fri, 15 Feb 2019 at 09:08, Marten Gajda wrote: > Am 15.02.19 um 08:09 schrieb Alexander Nimmervoll: > > > So why do you stick to due instead of start+duration for JSTasks? > > In contrast to events where the start is usually the more important date, > the due date of a task is usually far more important than its start. So i= f > you move a task in your calendar you usually mean to move the due date. > > In addition, in order to apply a duration you would always need a start, > but iCalendar and most implementations allow tasks to have a due date onl= y. > And that's mostly what an average user cares about. > > There is an iCalendar extension which adds an estimatedDuration property > to VTODO. Its meant to express that the actual execution time of a task i= s > usually shorter than the execution window (i.e. the time between start an= d > the due date). > > > > For the airline example with start and end time and fixed scheduled > duration an idea would also be to use the estimatedDuration property for > the scheduled flight-time or something similar. > > Where would be the difference to the duration we already have for events? > I think it might make sense to add a parameter which expresses that the > duration is only an estimate or may be subject to change. We could, for > instance, add a margin of error. For example: a concert starts at 20:30 a= nd > is scheduled for 2 hours. It may be delayed and the band may play a few > more extra songs, but due to local regulations there is a hard stop at > 23:00. > > I'd leave that to an extension of the current spec though. > > Cheers, > > Marten > > > > Cheers, > > Alex > > > > *Von:* calsify *Im > Auftrag von *Neil Jenkins > *Gesendet:* Freitag, 15. Februar 2019 00:20 > *An:* calsify@ietf.org > *Betreff:* Re: [calsify] JSCalendar duration vs. end time > > > > On Fri, 15 Feb 2019, at 03:03, Robert Stepanek wrote: > > Two arguments were raised in favor of adding an end time > > - It simplifies translation of VEVENTs with DTSTART/DTEND from > iCalendar. > > > > Every client/server will need to be able to translate between duration an= d > end already, so this is unlikely to be a significant hurdle to anyone. > > > > > - It allows to specify recurring events with a fixed end time even in > case of time gaps (e.g. a recurring night club that has to close at a = fixed > time for legal reasons). > > > > You kind-of mention this below, but I think it's important to note that *= this > argument is false*.. You cannot do this with recurrences as they exist > right now in iCalendar. > > > > On Fri, 15 Feb 2019, at 05:25, Alexander Nimmervoll wrote: > > But looking into it also from client UI perspective almost every client > allows you to choose start and end time and not start time and duration f= or > an event. > > > > The UI is independent of the underlying data format; as mentioned above > you need to be able to translate between the two anyway. > > > > Is there a reason you choose start time and duration vs start time and en= d > time? > > > > Yes.. There are many reasons why I strongly believe duration is preferabl= e > to end: > > 1. Having two representations for the same thing requires more code > complexity, as there are two code paths to deal with. > 2. Recurrences always operate with duration regardless of whether it's > actually specified as "end time", which is very confusing. With durati= on, > it's very clean: you expand the start time according to the recurrence= rule > and then just inherit every other property (duration is just another > property you inherit). > 3. There is no extra expressivity adding "end time". You can always > convert from end time to duration. The *one* exception is if the time > zone data changed so that an offset transition now happened in the mid= dle > of the event AND in such a case you wanted the event to maintain its > original end time rather than its original duration. I contend that: > 1. This case is exceedingly rare, and not important enough to make > the common case more complex. > 2. No UI will ever be built to offer the user a choice for how to > handle this situation, so it's even less important to handle. > 3. A better way to handle it would be to add an extra property that > could be used to indicate the duration should be done in "wall cloc= k" time; > this would then also work for recurrences, which there is no soluti= on for > in iCalendar. > 4. Duration is guaranteed to be zero or positive, making it harder to > create an invalid event and easier to check that an event object is va= lid. > If you move the start of a series of events you don't need to make sur= e to > keep the end in sync. > 5. Should time zone definitions change, it is more likely the duration > should remain fixed and the end should shift (e.g. for flights). > > > > Using start and end time allows also an easier specification of different > start and end timezones > > > > This is modelled differently in JSCalendar: there is a single time zone > for the event, which is what it is scheduled in, but you can associate ti= me > zones with locations and mark that a location is where the event finishes= , > which is equivalent to the end time zone in iCalendar. This again is > clearer, as it more closely matches the semantics of iCalendar (the "end" > time zone is not used for scheduling/recurrences, it is only used for > displaying in the UI after the necessary date arithmetic). And if time zo= ne > definitions change, again it's more likely the duration should stay > constant rather than the end time (the example everyone uses for a > different end time zone is flights: flying from Melbourne to LA is not > going to get an hour shorter if California suddenly changes its daylight > saving rules). > > > > Neil. > > _______________________________________________ > calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo= /calsify > > -- > Marten Gajda > CEO > > dmfs GmbH > Schandauer Stra=C3=9Fe 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 > --000000000000d7c9a00581eba0d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    As the intended usage is so different, the similarity= in naming can only lead to confusion, which has been demonstrated here.

    If tasks were to have due and estimatedDuration (and= perhaps something like commencement rather than start), and events have st= art and duration it would be more clear that they are different to each oth= er.

    -
    Garry Shutler
    CTO & Co-founder, Cronofy
    Scheduling Everything for Everyone<= /div>


    On Fri, 15 Feb 2019 at 0= 9:08, Marten Gajda <marten@dmfs.org> wrote:
    =20 =20 =20
    Am 15.02.19 u= m 08:09 schrieb Alexander Nimmervoll:
    =20 =20

    So why do you stick to = due instead of start+duration for JSTasks?

    In contrast to events where the start is usually the more important date, the due date of a task is usually far more important than its start. So if you move a task in your calendar you usually mean to move the due date.

    In addition, in order to apply a duration you would always need a start, but iCalendar and most implementations allow tasks to have a due date only. And that's mostly what an average user cares about.

    There is an iCalendar extension which adds an estimatedDuration property to VTODO. Its meant to express that the actual execution time of a task is usually shorter than the execution window (i.e. the time between start and the due date).

    =C2=A0

    For the airline example= with start and end time and fixed scheduled duration an idea would also be to use the estimatedDuration property for the scheduled flight-time or something similar.

    Where would be the difference to the duration we already have for events? I think it might make sense to add a parameter which expresses that the duration is only an estimate or may be subject to change. We could, for instance, add a margin of error. For example: a concert starts at 20:30 and is scheduled for 2 hours. It may be delayed and the band may play a few more extra songs, but due to local regulations there is a hard stop at 23:00.

    I'd leave that to an extension of the current spec though.

    Cheers,

    Marten

    =C2=A0

    Cheers,

    Alex

    =C2=A0

    Von: calsify <ca= lsify-bounces@ietf.org> Im Auftrag von Neil Jenkins
    Gesendet: Freitag, 15. F= ebruar 2019 00:20
    An: calsify= @ietf.org
    Betreff: Re: [calsify] JSCalendar duration vs. end time

    =C2=A0

    On Fri, 15 Feb 2019, at 03:03, Robert Stepanek wrote:

    Two arguments were raised in favor of adding an end time<= /p>

    • It simplifies translation of VEVENTs with DTSTART/DTEND from iCalendar.

    =C2=A0<= /span>

    Every client/server will need to be able to translate between duration and end already, so this is unlikely to be a significant hurdle to anyone.

    =C2=A0<= /span>

    • It allows to spe= cify recurring events with a fixed end time even in case of time gaps (e.g. a recurring night club that has to close at a fixed time for legal reasons).

    =C2=A0<= /span>

    You kind-of mention this below, but I think it's important to note that th= is argument is false.. You cannot do this with recurrences as they exist right now in iCalendar.=C2=A0

    =C2=A0<= /span>

    On Fri, 15 Feb 2019, at 05:25, Alexander Nimmervoll wrote:

    But looking into it also from client UI perspective almost every client allows you to choose start and end time and not start time and duration for an event.

    =C2=A0<= /span>

    The UI is independent of the underlying data format; as mentioned above you need to be able to translate between the two anyway.=

    =C2=A0<= /span>

    Is there a reason you choose start time and duration vs start time and end time?

    =C2=A0<= /span>

    Yes.. There are many reasons why I strongly believe duration is preferable to end:

    1. Having two represent= ations for the same thing requires more code complexity, as there are two code paths to deal with.
    2. Recurrences always o= perate with duration regardless of whether it's actually specified as "end time", which is very confusing. W= ith duration, it's very clean: you expand the start time according to the recurrence rule and then just inherit every other property (duration is just another property you inherit).
    3. There is no extra expressivity adding "end time". You can always conv= ert from end time to duration. The one=C2=A0exception is i= f the time zone data changed so that an offset transition now happened in the middle of the event AND in such a case you wanted the event to maintain its original end time rather than its original duration. I contend that:<= /u>
      1. This case is excee= dingly rare, and not important enough to make the common case more complex.
      2. No UI will ever be= built to offer the user a choice for how to handle this situation, so it's even less important to handle.
      3. A better way to ha= ndle it would be to add an extra property that could be used to indicate the duration should be done in "wall clock&qu= ot; time; this would then also work for recurrences, which there is no solution for in iCalendar.=
    4. Duration is guarante= ed to be zero or positive, making it harder to create an invalid event and easier to check that an event object is valid. If you move the start of a series of events you don't nee= d to make sure to keep the end in sync.
    5. Should time zone def= initions change, it is more likely the duration should remain fixed and the end should shift (e.g. for flights).

    =C2=A0<= /span>

    Using start and end time allows also an easier specification of different start and end timezones

    =C2=A0

    This is modelled differently in JSCalendar: there is a single time zone for the event, which is what it is scheduled in, but you can associate time zones with locations and mark that a location is where the event finishes, which is equivalent to the end time zone in iCalendar. This again is clearer, as it more closely matches the semantics of iCalendar (the "end" time zone is not used for scheduling/recurrences, it is only used for displaying in the UI after the necessary date arithmetic). And if time zone definitions change, again it's more likely th= e duration should stay constant rather than the end time (the example everyone uses for a different end time zone is flights: flying from Melbourne to LA is not going to get an hour shorter if California suddenly changes its daylight saving rules).

    =C2=A0

    Neil.


    <= /fieldset> 
    _____________=
__________________________________
calsify mailing list
calsify@ietf.org
https://www.iet=
f.org/mailman/listinfo/calsify

    --=
=20
Marten Gajda
CEO

dmfs GmbH
Schandauer Stra=C3=9Fe 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<= br> https://www.ietf.org/mailman/listinfo/calsify
    --000000000000d7c9a00581eba0d8-- From nobody Fri Feb 15 04:56:18 2019 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 E1EE7130E73 for ; Fri, 15 Feb 2019 04:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 1hzYGXkrDIXr for ; Fri, 15 Feb 2019 04:56:14 -0800 (PST) Received: from dd40210.kasserver.com (dd40210.kasserver.com [85.13.156.70]) (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 BE66E1275F3 for ; Fri, 15 Feb 2019 04:56:14 -0800 (PST) Received: from nbnimm (80-110-99-159.cgn.dynamic.surfer.at [80.110.99.159]) by dd40210.kasserver.com (Postfix) with ESMTPSA id 6B48863A0401 for ; Fri, 15 Feb 2019 13:56:12 +0100 (CET) From: "Alexander Nimmervoll" To: References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> <029301d4c4fd$5eaca610$1c05f230$@caldavsynchronizer.org> In-Reply-To: Date: Fri, 15 Feb 2019 13:56:16 +0100 Message-ID: <03a501d4c52d$d6d2b3c0$84781b40$@caldavsynchronizer.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03A6_01D4C536.38971BC0" X-Mailer: Microsoft Outlook 16.0 Content-Language: de-at Thread-Index: AQOLZthb+8PHggH5/l2b8JGbRR609QKonOjiAalRB5ABc14FEgFqbvNuojoNk6A= Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time 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, 15 Feb 2019 12:56:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03A6_01D4C536.38971BC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Are the use cases really so different between events, meetings and tasks = regarding time? Meetings, flights, concerts and various events also can = have an estimated/scheduled duration different to actual duration. = Similar for start and end time. So a data model which implements a standard property/parameter to = distinguish between estimated/scheduled and actual start/end/duration = could be useful for events and tasks in my opinion. =20 Cheers, Alex =20 =20 Von: calsify Im Auftrag von Garry Shutler Gesendet: Freitag, 15. Februar 2019 10:45 An: calsify@ietf.org Betreff: Re: [calsify] JSCalendar duration vs. end time =20 As the intended usage is so different, the similarity in naming can only = lead to confusion, which has been demonstrated here. =20 If tasks were to have due and estimatedDuration (and perhaps something = like commencement rather than start), and events have start and duration = it would be more clear that they are different to each other. =20 - Garry Shutler CTO & Co-founder, Cronofy Scheduling Everything for Everyone =20 =20 ------=_NextPart_000_03A6_01D4C536.38971BC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    Are the use cases = really so different between events, meetings and tasks regarding time? = Meetings, flights, concerts and various events also can have an = estimated/scheduled duration different to actual duration. Similar for = start and end time.

    So a data model which = implements a standard property/parameter to distinguish between = estimated/scheduled and actual start/end/duration could be useful for = events and tasks in my opinion.

     

    Cheers,
    Alex

     

     

    Von: = calsify <calsify-bounces@ietf.org> Im Auftrag von Garry = Shutler
    Gesendet: Freitag, 15.     Februar 2019 10:45
    An: = calsify@ietf.org
    Betreff: Re: [calsify] JSCalendar duration = vs. end time

     

    As the intended usage is so = different, the similarity in naming can only lead to confusion, which = has been demonstrated here.

     

    If tasks were to have due and = estimatedDuration (and perhaps something like commencement rather than = start), and events have start and duration it would be more clear that = they are different to each = other.

     

    -

    Garry Shutler

    CTO & Co-founder, Cronofy
    Scheduling Everything for = Everyone

    <= p class=3DMsoNormal> 

     

    ------=_NextPart_000_03A6_01D4C536.38971BC0-- From nobody Fri Feb 15 08:11:28 2019 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 EFBB4128BCC for ; Fri, 15 Feb 2019 08:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvwtIalE0iSA for ; Fri, 15 Feb 2019 08:11:22 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A33E127598 for ; Fri, 15 Feb 2019 08:11:21 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id d18so1370894qtg.12 for ; Fri, 15 Feb 2019 08:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=loXT2sEwiQHailo3f3xuh7xTmhSDldcjeO/28QDeCFE=; b=K6X5MYyDfZL88SIedZSfgBdJqg/usckL3+mGaz7nbgpdKQS9bJXVRPKwSp/Whazu9K oU1+KoEjTZGZDYiKk8h9qr4RNnNX6NyWX9BTlUV/1Pe7rwQBshUF1A9ebRGbRbQF/aKL QjP3y5hXfU1LcOcQJYAOCFzzfqHOCF5kCqva3CD24IBGr0oZPQCzRBw4cazfKrhwXM5Z BUkkeupAU8VCwcTQ6bjVqTjZlU41S5HhiBQvByBOvhSES8E4Q3GXoAIF9XHDG/uNWNYp /CclquKPW8m6sF9pQX9wh1Xofo4Sz8I+rnYGvHZo9bh5CmQR7wJb65JyrhSf5LquC3Ly tDnw== 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=loXT2sEwiQHailo3f3xuh7xTmhSDldcjeO/28QDeCFE=; b=IVUUftkSq7euP8ZbCcj+YeQaBz8R5o6KBAjZAXhCX/pgaSKAUe52G/XbLrFnO950rw UsNk15wPrgRIR1xpOqCsG7QU1/0uUHWRRVhQgwsCGBGi3iK1AuTCxgYRNQTk5/s+L29w n5hq2t02YmHebBrnhgRWkQhwXU+U5dYQn8TgWmYrpq4vTtBt81iARDSSnMfuDW21c7/e JD1pO/PlcZSzJZf3V3JWHNg5XF5TiOu4n/YFz5MD/gcywaGIppkQH+PCRo9y7gyhQD3b oWWupcRBpy1guHiftemf0MVXt7qus8zrlgQ2ka1YsjI87EgjmYle8X20pH7RBtc3u3CJ 7yGQ== X-Gm-Message-State: AHQUAuZv6734364LLaURiBZHxl7dBMNbHITRc58y78zWmX+1CTJmoxY5 xhiPZY53obbjRMhpABF9DXO/2z7X X-Google-Smtp-Source: AHgI3IZb46o/ltvDENMAdaUwueYFqqI8amJlObvTthEFh587nRzya94SbQg1ohHV/YRQKpkcZAJRqw== X-Received: by 2002:aed:35c6:: with SMTP id d6mr8364347qte.320.1550247080235; Fri, 15 Feb 2019 08:11:20 -0800 (PST) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id f7sm3386165qkb.33.2019.02.15.08.11.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Feb 2019 08:11:18 -0800 (PST) To: calsify@ietf.org References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> <029301d4c4fd$5eaca610$1c05f230$@caldavsynchronizer.org> From: Michael Douglass Message-ID: <33c0b886-1136-715e-be56-10d342e2522c@gmail.com> Date: Fri, 15 Feb 2019 11:11:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D90B6518430982319477A5D7" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time 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, 15 Feb 2019 16:11:26 -0000 This is a multi-part message in MIME format. --------------D90B6518430982319477A5D7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 2/15/19 04:44, Garry Shutler wrote: > As the intended usage is so different, the similarity in naming can > only lead to confusion, which has been demonstrated here. > > If tasks were to have due and estimatedDuration (and perhaps something > like commencement rather than start), and events have start and > duration it would be more clear that they are different to each other. The tasks extension (draft) already does that. - > *Garry Shutler* > CTO & Co-founder, Cronofy > Scheduling Everything for Everyone > > > On Fri, 15 Feb 2019 at 09:08, Marten Gajda > wrote: > > Am 15.02.19 um 08:09 schrieb Alexander Nimmervoll: >> >> So why do you stick to due instead of start+duration for JSTasks? >> > In contrast to events where the start is usually the more > important date, the due date of a task is usually far more > important than its start. So if you move a task in your calendar > you usually mean to move the due date. > > In addition, in order to apply a duration you would always need a > start, but iCalendar and most implementations allow tasks to have > a due date only. And that's mostly what an average user cares about. > > There is an iCalendar extension which adds an estimatedDuration > property to VTODO. Its meant to express that the actual execution > time of a task is usually shorter than the execution window (i.e. > the time between start and the due date). > >> For the airline example with start and end time and fixed >> scheduled duration an idea would also be to use the >> estimatedDuration property for the scheduled flight-time or >> something similar. >> > Where would be the difference to the duration we already have for > events? I think it might make sense to add a parameter which > expresses that the duration is only an estimate or may be subject > to change. We could, for instance, add a margin of error. For > example: a concert starts at 20:30 and is scheduled for 2 hours. > It may be delayed and the band may play a few more extra songs, > but due to local regulations there is a hard stop at 23:00. > > I'd leave that to an extension of the current spec though. > > Cheers, > > Marten > >> Cheers, >> >> Alex >> >> *Von:*calsify >> *Im Auftrag von *Neil Jenkins >> *Gesendet:* Freitag, 15. Februar 2019 00:20 >> *An:* calsify@ietf.org >> *Betreff:* Re: [calsify] JSCalendar duration vs. end time >> >> On Fri, 15 Feb 2019, at 03:03, Robert Stepanek wrote: >> >> Two arguments were raised in favor of adding an end time >> >> * It simplifies translation of VEVENTs with DTSTART/DTEND >> from iCalendar. >> >> Every client/server will need to be able to translate between >> duration and end already, so this is unlikely to be a significant >> hurdle to anyone. >> >> * It allows to specify recurring events with a fixed end >> time even in case of time gaps (e.g. a recurring night >> club that has to close at a fixed time for legal reasons). >> >> You kind-of mention this below, but I think it's important to >> note that *this argument is false*.. You cannot do this with >> recurrences as they exist right now in iCalendar. >> >> On Fri, 15 Feb 2019, at 05:25, Alexander Nimmervoll wrote: >> >> But looking into it also from client UI perspective almost >> every client allows you to choose start and end time and not >> start time and duration for an event. >> >> The UI is independent of the underlying data format; as mentioned >> above you need to be able to translate between the two anyway. >> >> Is there a reason you choose start time and duration vs start >> time and end time? >> >> Yes.. There are many reasons why I strongly believe duration is >> preferable to end: >> >> 1. Having two representations for the same thing requires more >> code complexity, as there are two code paths to deal with. >> 2. Recurrences always operate with duration regardless of >> whether it's actually specified as "end time", which is very >> confusing. With duration, it's very clean: you expand the >> start time according to the recurrence rule and then just >> inherit every other property (duration is just another >> property you inherit). >> 3. There is no extra expressivity adding "end time". You can >> always convert from end time to duration. The /one/ exception >> is if the time zone data changed so that an offset transition >> now happened in the middle of the event AND in such a case >> you wanted the event to maintain its original end time rather >> than its original duration. I contend that: >> 1. This case is exceedingly rare, and not important enough >> to make the common case more complex. >> 2. No UI will ever be built to offer the user a choice for >> how to handle this situation, so it's even less important >> to handle. >> 3. A better way to handle it would be to add an extra >> property that could be used to indicate the duration >> should be done in "wall clock" time; this would then also >> work for recurrences, which there is no solution for in >> iCalendar. >> 4. Duration is guaranteed to be zero or positive, making it >> harder to create an invalid event and easier to check that an >> event object is valid. If you move the start of a series of >> events you don't need to make sure to keep the end in sync. >> 5. Should time zone definitions change, it is more likely the >> duration should remain fixed and the end should shift (e.g. >> for flights). >> >> Using start and end time allows also an easier specification >> of different start and end timezones >> >> This is modelled differently in JSCalendar: there is a single >> time zone for the event, which is what it is scheduled in, but >> you can associate time zones with locations and mark that a >> location is where the event finishes, which is equivalent to the >> end time zone in iCalendar. This again is clearer, as it more >> closely matches the semantics of iCalendar (the "end" time zone >> is not used for scheduling/recurrences, it is only used for >> displaying in the UI after the necessary date arithmetic). And if >> time zone definitions change, again it's more likely the duration >> should stay constant rather than the end time (the example >> everyone uses for a different end time zone is flights: flying >> from Melbourne to LA is not going to get an hour shorter if >> California suddenly changes its daylight saving rules). >> >> Neil. >> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > > -- > Marten Gajda > CEO > > dmfs GmbH > Schandauer Straße 34 > 01309 Dresden > GERMANY > > phone: +49 177 4427167 > email:marten@dmfs.org > > Managing Director: Marten Gajda > Registered address: Dresden > Registered No.: AG Dresden HRB 34881 > VAT Reg. No.: DE303248743 > > _______________________________________________ > 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 --------------D90B6518430982319477A5D7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 2/15/19 04:44, Garry Shutler wrote:
    As the intended usage is so different, the similarity in naming can only lead to confusion, which has been demonstrated here.

    If tasks were to have due and estimatedDuration (and perhaps something like commencement rather than start), and events have start and duration it would be more clear that they are different to each other.

    The tasks extension (draft) already does that.

    -
    Garry Shutler
    CTO & Co-founder, Cronofy
    Scheduling Everything for Everyone


    On Fri, 15 Feb 2019 at 09:08, Marten Gajda <marten@dmfs.org> wrote:
    Am 15.02.19 um 08:09 schrieb Alexander Nimmervoll:

    So why do you stick to due instead of start+duration for JSTasks?

    In contrast to events where the start is usually the more important date, the due date of a task is usually far more important than its start. So if you move a task in your calendar you usually mean to move the due date.

    In addition, in order to apply a duration you would always need a start, but iCalendar and most implementations allow tasks to have a due date only. And that's mostly what an average user cares about.

    There is an iCalendar extension which adds an estimatedDuration property to VTODO. Its meant to express that the actual execution time of a task is usually shorter than the execution window (i.e. the time between start and the due date).

     

    For the airline example with start and end time and fixed scheduled duration an idea would also be to use the estimatedDuration property for the scheduled flight-time or something similar.

    Where would be the difference to the duration we already have for events? I think it might make sense to add a parameter which expresses that the duration is only an estimate or may be subject to change. We could, for instance, add a margin of error. For example: a concert starts at 20:30 and is scheduled for 2 hours. It may be delayed and the band may play a few more extra songs, but due to local regulations there is a hard stop at 23:00.

    I'd leave that to an extension of the current spec though.

    Cheers,

    Marten

     

    Cheers,

    Alex

     

    Von: calsify <calsify-bounces@ietf.org> Im Auftrag von Neil Jenkins
    Gesendet: Freitag, 15.     Februar 2019 00:20
    An: calsify@ietf.org
    Betreff: Re: [calsify] JSCalendar duration vs. end time

     

    On Fri, 15 Feb 2019, at 03:03, Robert Stepanek wrote:

    Two arguments were raised in favor of adding an end time

    • It simplifies translation of VEVENTs with DTSTART/DTEND from iCalendar.

     

    Every client/server will need to be able to translate between duration and end already, so this is unlikely to be a significant hurdle to anyone.

     

    • It allows to specify recurring events with a fixed end time even in case of time gaps (e.g. a recurring night club that has to close at a fixed time for legal reasons).

     

    You kind-of mention this below, but I think it's important to note that this argument is false.. You cannot do this with recurrences as they exist right now in iCalendar. 

     

    On Fri, 15 Feb 2019, at 05:25, Alexander Nimmervoll wrote:

    But looking into it also from client UI perspective almost every client allows you to choose start and end time and not start time and duration for an event.

     

    The UI is independent of the underlying data format; as mentioned above you need to be able to translate between the two anyway.

     

    Is there a reason you choose start time and duration vs start time and end time?

     

    Yes.. There are many reasons why I strongly believe duration is preferable to end:

    1. Having two representations for the same thing requires more code complexity, as there are two code paths to deal with.
    2. Recurrences always operate with duration regardless of whether it's actually specified as "end time", which is very confusing. With duration, it's very clean: you expand the start time according to the recurrence rule and then just inherit every other property (duration is just another property you inherit).
    3. There is no extra expressivity adding "end time". You can always convert from end time to duration. The one exception is if the time zone data changed so that an offset transition now happened in the middle of the event AND in such a case you wanted the event to maintain its original end time rather than its original duration. I contend that:
      1. This case is exceedingly rare, and not important enough to make the common case more complex.
      2. No UI will ever be built to offer the user a choice for how to handle this situation, so it's even less important to handle.
      3. A better way to handle it would be to add an extra property that could be used to indicate the duration should be done in "wall clock" time; this would then also work for recurrences, which there is no solution for in iCalendar.
    4. Duration is guaranteed to be zero or positive, making it harder to create an invalid event and easier to check that an event object is valid. If you move the start of a series of events you don't need to make sure to keep the end in sync.
    5. Should time zone definitions change, it is more likely the duration should remain fixed and the end should shift (e.g. for flights).

     

    Using start and end time allows also an easier specification of different start and end timezones

     

    This is modelled differently in JSCalendar: there is a single time zone for the event, which is what it is scheduled in, but you can associate time zones with locations and mark that a location is where the event finishes, which is equivalent to the end time zone in iCalendar. This again is clearer, as it more closely matches the semantics of iCalendar (the "end" time zone is not used for scheduling/recurrences, it is only used for displaying in the UI after the necessary date arithmetic). And if time zone definitions change, again it's more likely the duration should stay constant rather than the end time (the example everyone uses for a different end time zone is flights: flying from Melbourne to LA is not going to get an hour shorter if California suddenly changes its daylight saving rules).

     

    Neil.


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

    -- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

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

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743
    _______________________________________________
    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
    --------------D90B6518430982319477A5D7-- From nobody Mon Feb 18 14:59:14 2019 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 8840E1310AE for ; Mon, 18 Feb 2019 14:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=comcast.net 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 W3p4XpImrh7Q for ; Mon, 18 Feb 2019 14:59:10 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (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 823951310A9 for ; Mon, 18 Feb 2019 14:59:10 -0800 (PST) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-03v.sys.comcast.net with ESMTP id vnf0goNCiZgSGvrsTgqMgY; Mon, 18 Feb 2019 22:59:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1550530749; bh=5G1nqvaYBcMu5Zq052l3XTNrfgp7XD8RGnhxNClJPN8=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=YoqC1fVAgYkEkWTRQzV4abyo36/3qMZd8g8nUWLojfwJGLghNFT53HlChDa5TmEpy JeJ1uNlpab035YKD1+1O8n9jO/SEcpZQU9cDgghRwPtZ/QQiL9YXN1Ti+VEJc8VcIO PLRte50PtoqA5dqhKKI8bmdgEiGjOqDAa/lOk+BR1flBQGRxUGx7bFFHaPrXnslFiV LgsJR8WRO5dR2CLjIIan3cGgsI2Tcw4XSA02vmzqxqUVNaYEXamW50ZB4y+r8Mldpr ZQ6Evwlom71MKAC0d4/o2gCN5+EZJkxe5j85QEEDe1/tHn+Slyo05rGEX8MT8idwn9 IwoizlhB8oEig== Received: from THARE ([98.192.130.240]) by resomta-po-10v.sys.comcast.net with ESMTPA id vrsSgbMB9FKT9vrsTgXVFO; Mon, 18 Feb 2019 22:59:09 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedutddrtddvgddtgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfhfjgfufffkgggtofhtsegrtdhgpedvtdejnecuhfhrohhmpedfvfhimhcujfgrrhgvfdcuoefvihhmjfgrrhgvsegtohhmtggrshhtrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeelkedrudelvddrudeftddrvdegtdenucfrrghrrghmpehhvghlohepvffjteftgfdpihhnvghtpeelkedrudelvddrudeftddrvdegtddpmhgrihhlfhhrohhmpehtihhmhhgrrhgvsegtohhmtggrshhtrdhnvghtpdhrtghpthhtoheptggrlhhsihhfhiesihgvthhfrdhorhhgpdhrtghpthhtohepmhhikhgvrgguohhughhlrghsshesghhmrghilhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-Xfinity-VMeta: sc=??;st=legit From: "Tim Hare" To: "'Michael Douglass'" , References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> <029301d4c4fd$5eaca610$1c05f230$@caldavsynchronizer.org> <33c0b886-1136-715e-be56-10d342e2522c@gmail.com> In-Reply-To: <33c0b886-1136-715e-be56-10d342e2522c@gmail.com> Date: Mon, 18 Feb 2019 17:59:06 -0500 Message-ID: <025301d4c7dd$8da7c7f0$a8f757d0$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0254_01D4C7B3.A4D409E0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQOLZthb+8PHggH5/l2b8JGbRR609QKonOjiAalRB5ABc14FEgFqbvNuAugSKpyiKCygkA== Content-Language: en-us Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2019 22:59:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0254_01D4C7B3.A4D409E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I am not a developer at the moment, but an interested party. = I=E2=80=99m more interested, for my part, in enabling people and = organizations to publish calendar information easily. =20 That said, in my opinion anything that causes divergence between RFC = 5545 and representations in other ways (XML, JS) can be problematic. = I=E2=80=99m on record as wondering why property parameters = didn=E2=80=99t become XML attributes, because that representation seemed = to match the text-only representation better; I believe JSCalendar = should make it easy to go from DTSTART/DTEND to a start time and end = time and from DTSTART/DURATION to start time and duration. There may = be non-user-facing instances where translating between one = representation and another is useful, and being able to =E2=80=98round = trip=E2=80=99 it makes development of such things a little less = bug-prone. Tim Hare Interested Bystander, Non-Inc. =20 From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of Michael = Douglass Sent: Friday, February 15, 2019 11:11 AM To: calsify@ietf.org Subject: Re: [calsify] JSCalendar duration vs. end time =20 On 2/15/19 04:44, Garry Shutler wrote: As the intended usage is so different, the similarity in naming can only = lead to confusion, which has been demonstrated here. =20 If tasks were to have due and estimatedDuration (and perhaps something = like commencement rather than start), and events have start and duration = it would be more clear that they are different to each other. The tasks extension (draft) already does that.=20 - Garry Shutler CTO & Co-founder, Cronofy Scheduling Everything for Everyone =20 =20 On Fri, 15 Feb 2019 at 09:08, Marten Gajda > wrote: Am 15.02.19 um 08:09 schrieb Alexander Nimmervoll: =20 So why do you stick to due instead of start+duration for JSTasks? In contrast to events where the start is usually the more important = date, the due date of a task is usually far more important than its = start. So if you move a task in your calendar you usually mean to move = the due date. In addition, in order to apply a duration you would always need a start, = but iCalendar and most implementations allow tasks to have a due date = only. And that's mostly what an average user cares about. There is an iCalendar extension which adds an estimatedDuration property = to VTODO. Its meant to express that the actual execution time of a task = is usually shorter than the execution window (i.e. the time between = start and the due date). =20 For the airline example with start and end time and fixed scheduled = duration an idea would also be to use the estimatedDuration property for = the scheduled flight-time or something similar. Where would be the difference to the duration we already have for = events? I think it might make sense to add a parameter which expresses = that the duration is only an estimate or may be subject to change. We = could, for instance, add a margin of error. For example: a concert = starts at 20:30 and is scheduled for 2 hours. It may be delayed and the = band may play a few more extra songs, but due to local regulations there = is a hard stop at 23:00. I'd leave that to an extension of the current spec though. Cheers, Marten =20 Cheers, Alex =20 Von: calsify = Im Auftrag von Neil Jenkins Gesendet: Freitag, 15. Februar 2019 00:20 An: calsify@ietf.org =20 Betreff: Re: [calsify] JSCalendar duration vs. end time =20 On Fri, 15 Feb 2019, at 03:03, Robert Stepanek wrote: Two arguments were raised in favor of adding an end time * It simplifies translation of VEVENTs with DTSTART/DTEND from = iCalendar. =20 Every client/server will need to be able to translate between duration = and end already, so this is unlikely to be a significant hurdle to = anyone. =20 * It allows to specify recurring events with a fixed end time even in = case of time gaps (e.g. a recurring night club that has to close at a = fixed time for legal reasons). =20 You kind-of mention this below, but I think it's important to note that = this argument is false.. You cannot do this with recurrences as they = exist right now in iCalendar.=20 =20 On Fri, 15 Feb 2019, at 05:25, Alexander Nimmervoll wrote: But looking into it also from client UI perspective almost every client = allows you to choose start and end time and not start time and duration = for an event. =20 The UI is independent of the underlying data format; as mentioned above = you need to be able to translate between the two anyway. =20 Is there a reason you choose start time and duration vs start time and = end time? =20 Yes.. There are many reasons why I strongly believe duration is = preferable to end: 1. Having two representations for the same thing requires more code = complexity, as there are two code paths to deal with. 2. Recurrences always operate with duration regardless of whether it's = actually specified as "end time", which is very confusing. With = duration, it's very clean: you expand the start time according to the = recurrence rule and then just inherit every other property (duration is = just another property you inherit). 3. There is no extra expressivity adding "end time". You can always = convert from end time to duration. The one exception is if the time zone = data changed so that an offset transition now happened in the middle of = the event AND in such a case you wanted the event to maintain its = original end time rather than its original duration. I contend that: 1. This case is exceedingly rare, and not important enough to make the = common case more complex. 2. No UI will ever be built to offer the user a choice for how to handle = this situation, so it's even less important to handle. 3. A better way to handle it would be to add an extra property that = could be used to indicate the duration should be done in "wall clock" = time; this would then also work for recurrences, which there is no = solution for in iCalendar. 4. Duration is guaranteed to be zero or positive, making it harder to = create an invalid event and easier to check that an event object is = valid. If you move the start of a series of events you don't need to = make sure to keep the end in sync. 5. Should time zone definitions change, it is more likely the duration = should remain fixed and the end should shift (e.g. for flights). =20 Using start and end time allows also an easier specification of = different start and end timezones =20 This is modelled differently in JSCalendar: there is a single time zone = for the event, which is what it is scheduled in, but you can associate = time zones with locations and mark that a location is where the event = finishes, which is equivalent to the end time zone in iCalendar. This = again is clearer, as it more closely matches the semantics of iCalendar = (the "end" time zone is not used for scheduling/recurrences, it is only = used for displaying in the UI after the necessary date arithmetic). And = if time zone definitions change, again it's more likely the duration = should stay constant rather than the end time (the example everyone uses = for a different end time zone is flights: flying from Melbourne to LA is = not going to get an hour shorter if California suddenly changes its = daylight saving rules). =20 Neil. _______________________________________________ calsify mailing list calsify@ietf.org =20 https://www.ietf.org/mailman/listinfo/calsify --=20 Marten Gajda CEO =20 dmfs GmbH Schandauer Stra=C3=9Fe 34 01309 Dresden GERMANY =20 phone: +49 177 4427167 email: marten@dmfs.org =20 =20 Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743 _______________________________________________ calsify mailing list calsify@ietf.org =20 https://www.ietf.org/mailman/listinfo/calsify _______________________________________________ calsify mailing list calsify@ietf.org =20 https://www.ietf.org/mailman/listinfo/calsify ------=_NextPart_000_0254_01D4C7B3.A4D409E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    I am not a developer at the moment, but an interested party.=C2=A0 = I=E2=80=99m more interested, for my part, in enabling people and = organizations to publish calendar information easily.=C2=A0

    That = said, in my opinion anything that causes divergence between RFC 5545 and = representations in other ways (XML, JS) can be problematic.=C2=A0 = I=E2=80=99m on record as wondering why property parameters = didn=E2=80=99t become XML attributes, because that representation seemed = to match the text-only representation better;=C2=A0=C2=A0 I believe = JSCalendar should make it easy to go from DTSTART/DTEND to a start time = and end time=C2=A0 and from DTSTART/DURATION to start time and = duration.=C2=A0 =C2=A0There may be non-user-facing instances where = translating between one representation and another is useful, and being = able to =E2=80=98round trip=E2=80=99 it makes development of such things = a little less bug-prone.

    Tim Hare
    Interested Bystander, = Non-Inc.

     

    From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of = Michael Douglass
    Sent: Friday, February 15, 2019 11:11 = AM
    To: calsify@ietf.org
    Subject: Re: [calsify] = JSCalendar duration vs. end time

     

    On 2/15/19 = 04:44, Garry Shutler wrote:

    As the intended usage is so different, the similarity = in naming can only lead to confusion, which has been demonstrated = here.

     

    If tasks were to have due and estimatedDuration (and = perhaps something like commencement rather than start), and events have = start and duration it would be more clear that they are different to = each other.

    The tasks = extension (draft) already does that.

    -

    <= div>

    Garry = Shutler

    CTO & = Co-founder, Cronofy
    Scheduling Everything for = Everyone

     

     

    On = Fri, 15 Feb 2019 at 09:08, Marten Gajda <marten@dmfs.org> = wrote:

    Am 15.02.19 um 08:09 schrieb Alexander = Nimmervoll:

     

    So why do = you stick to due instead of start+duration for = JSTasks?

    In contrast to events where = the start is usually the more important date, the due date of a task is = usually far more important than its start. So if you move a task in your = calendar you usually mean to move the due date.

    In = addition, in order to apply a duration you would always need a start, = but iCalendar and most implementations allow tasks to have a due date = only. And that's mostly what an average user cares = about.

    There is an iCalendar extension which adds an = estimatedDuration property to VTODO. Its meant to express that the = actual execution time of a task is usually shorter than the execution = window (i.e. the time between start and the due = date).

     <= /o:p>

    For the = airline example with start and end time and fixed scheduled duration an = idea would also be to use the estimatedDuration property for the = scheduled flight-time or something = similar.

    Where would be the = difference to the duration we already have for events? I think it might = make sense to add a parameter which expresses that the duration is only = an estimate or may be subject to change. We could, for instance, add a = margin of error. For example: a concert starts at 20:30 and is scheduled = for 2 hours. It may be delayed and the band may play a few more extra = songs, but due to local regulations there is a hard stop at = 23:00.

    I'd leave that to an extension of the current = spec = though.

    Cheers,

    Marten

     <= /o:p>

    Cheers,=

    Alex

     <= /o:p>

    Von: calsify <calsify-bounces@ietf.org> Im Auftrag von = Neil Jenkins
    Gesendet: Freitag, 15.     Februar 2019 = 00:20
    An: calsify@ietf.org
    Betreff: Re: [calsify] = JSCalendar duration vs. end time

     <= /o:p>

    On Fri, 15 = Feb 2019, at 03:03, Robert Stepanek = wrote:

    Two = arguments were raised in favor of adding an end = time

    • It simplifies translation of VEVENTs with DTSTART/DTEND = from iCalendar.

     <= /o:p>

    Every = client/server will need to be able to translate between duration and end = already, so this is unlikely to be a significant hurdle to = anyone.

     <= /o:p>

    • It allows to specify recurring events with a fixed end time = even in case of time gaps (e.g. a recurring night club that has to close = at a fixed time for legal = reasons).

     <= /o:p>

    You kind-of = mention this below, but I think it's important to note that this = argument is false.. You cannot do this with recurrences as they = exist right now in iCalendar. 

     <= /o:p>

    On Fri, 15 = Feb 2019, at 05:25, Alexander Nimmervoll = wrote:

    But looking = into it also from client UI perspective almost every client allows you = to choose start and end time and not start time and duration for an = event.

     <= /o:p>

    The UI is = independent of the underlying data format; as mentioned above you need = to be able to translate between the two = anyway.

     <= /o:p>

    Is there a = reason you choose start time and duration vs start time and end = time?

     <= /o:p>

    Yes.. There = are many reasons why I strongly believe duration is preferable to = end:

    1. Having two representations for the same thing requires more = code complexity, as there are two code paths to deal = with.
    2. Recurrences always operate with duration regardless of = whether it's actually specified as "end time", which is very = confusing. With duration, it's very clean: you expand the start time = according to the recurrence rule and then just inherit every other = property (duration is just another property you = inherit).
    3. There is no extra expressivity adding "end time". = You can always convert from end time to duration. The = one exception is if the time zone data changed so that an = offset transition now happened in the middle of the event AND in such a = case you wanted the event to maintain its original end time rather than = its original duration. I contend that:
      1. This case is exceedingly rare, and not important enough to = make the common case more complex.
      2. No UI will ever be built to offer the user a choice for how = to handle this situation, so it's even less important to = handle.
      3. A better way to handle it would be to add an extra property = that could be used to indicate the duration should be done in "wall = clock" time; this would then also work for recurrences, which there = is no solution for in iCalendar.
    1. Duration is guaranteed to be zero or positive, making it = harder to create an invalid event and easier to check that an event = object is valid. If you move the start of a series of events you don't = need to make sure to keep the end in sync.
    2. Should time zone definitions change, it is more likely the = duration should remain fixed and the end should shift (e.g. for = flights).

     <= /o:p>

    Using start = and end time allows also an easier specification of different start and = end timezones

     <= /o:p>

    This is = modelled differently in JSCalendar: there is a single time zone for the = event, which is what it is scheduled in, but you can associate time = zones with locations and mark that a location is where the event = finishes, which is equivalent to the end time zone in iCalendar. This = again is clearer, as it more closely matches the semantics of iCalendar = (the "end" time zone is not used for scheduling/recurrences, = it is only used for displaying in the UI after the necessary date = arithmetic). And if time zone definitions change, again it's more likely = the duration should stay constant rather than the end time (the example = everyone uses for a different end time zone is flights: flying from = Melbourne to LA is not going to get an hour shorter if California = suddenly changes its daylight saving rules).

     <= /o:p>

    Neil.



    ___________________________=
____________________
    calsify mailing =
list
    calsify@ietf.org
    https://www.ietf.org/mailman/listinfo/calsify<=
/o:p>
    -- 
    Marten =
Gajda
    CEO
     
    dmfs GmbH
    Schandauer Stra=C3=9Fe =
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

    _______________________________________________
    cals= ify mailing list
    calsify@ietf.org
    https://www.ietf.org/mailman/listinfo/calsify<= /o:p>



    ___________________________=
____________________
    calsify mailing =
list
    calsify@ietf.org
    https://www.ietf.o= rg/mailman/listinfo/calsify
    ------=_NextPart_000_0254_01D4C7B3.A4D409E0-- From nobody Thu Feb 21 22:46:26 2019 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 02499130D7A for ; Thu, 21 Feb 2019 22:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAFMGtZlt--1 for ; Thu, 21 Feb 2019 22:46:23 -0800 (PST) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 CF67912E04D for ; Thu, 21 Feb 2019 22:46:22 -0800 (PST) Received: by mail-qt1-x833.google.com with SMTP id y4so1367548qtc.10 for ; Thu, 21 Feb 2019 22:46:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=+WZv9uzHCLLAQde+N1I2BDWBSIVvt5y28PpA3Z4yFWM=; b=nmGUoy9cg5jW/AGn6UVAsPujBXVwmFxdocDKgeTCuVhNniN3xvoM+QsNJ4EmQJkG58 0nF4llLlF7vZc5Dc3XhBqDpeS0LDjdi4CFEO+kpQyrnS+44abaeCeFKBTc/2PbdEB2DX YDITH0QNaRkS+kJUvDqgMRPbm1QZiY/MwTITBwLHqJPfQFgZivo5JxV8WSeV5E/TGglI 4hjYZU002WkoVozsohK5sFm9jGg4XKjHhTlDoWWHCbaavMxq1TWevadHamoNnvrVd2l7 UFn+9QudHZk0kjeGR89+zIyXBVr69g0dVjrkfFlqmkAHW01nrqWiABsFxgOSnvsxOl5c liqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=+WZv9uzHCLLAQde+N1I2BDWBSIVvt5y28PpA3Z4yFWM=; b=eZMXSE1XgpFBr+pU7LxFFDaJvEG46NwQMCgJ8i2JcUIso76FSak6Q72ZLGgsym4ldf iIRgMXrxtJxLevr1et4Lm1M9omom1zaOJPuOPOhod9hNGw/YkA4wtqBjYxsyBmNAJ7A2 xqEo2g5HGBK297dqzyUiwgyFvzzifEfKD6X3BiX+9f6c/FgIWzkfIbS+r43PzA3q38H2 vF1tpzBCztIUhIwI6q2Kvkgnq9TfCIuiE+5+q/9odRWUvO7Auq4v+Z46TpOn7S6eR8X9 b3SQNfeg1TnyUdzsJ4oJiWKRjrV2UO+giDIsS0wlFxJq55MhowPpxItWC0ZW1s/Wnpnx xgtQ== X-Gm-Message-State: AHQUAubf52rG8zhDzuAyYd/HMoqvN366NE7VfSXWE8gewU+CIX+ZjW/g R1cLvo93tgxa00n8dEpnVL1ezJk3 X-Google-Smtp-Source: AHgI3IaIcUErqvX4NkarAcA9pZ8uGd8DE2sFamAbfq5nRtLIecwLhv7iC4IvAYrsSCc5Vo/5e1Dvkw== X-Received: by 2002:ac8:2e19:: with SMTP id r25mr1926402qta.0.1550817981608; Thu, 21 Feb 2019 22:46:21 -0800 (PST) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id h58sm400849qtb.89.2019.02.21.22.46.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 22:46:21 -0800 (PST) To: Calsify From: Michael Douglass Message-ID: Date: Fri, 22 Feb 2019 01:46:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [calsify] draft-ietf-calext-eventpub-extensions - styled-description X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 06:46:25 -0000 There has been a sudden upsurge of interest in rich text in calendar items and this has resulted in a need to make some changes to the styled-description specification. Given the late stage of the process for this spec I'm not sure how to proceed - should I just post a version 11 draft? To summarize - the changes are: Add a new parameter: DERIVED=TRUE/FALSE This will be used on the DESCRIPTION and STYLED-DESCRIPTION properties to indicate that the value is derived from a 'master' STYLED-DESCRIPTION, i.e one without that parameter or with DERIVED=FALSE Only one such 'master' will be allowed. This gives us the option of providing alternative representations of the rich text in some other format. In the case of the DESCRIPTION only plain text is allowed. Need to remove text suggesting this property be used for language variants. Another approach is being considered for that. I also need to add some text in the security section stating that rich text needs to be filtered for malevolent or dubious content. From nobody Fri Feb 22 05:02:26 2019 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 B4BD412EB11 for ; Fri, 22 Feb 2019 05:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=LxqkrotU; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZDSwW5HJ 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 7KPl8i1YaVsx for ; Fri, 22 Feb 2019 05:02:22 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 71491129619 for ; Fri, 22 Feb 2019 05:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1550840540; x=1553432540; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=cfiuVJl3Vll7IjGc17PqM72CHYYc5GYl3FI7HM0q2Vg=; b=LxqkrotU/nZdZJMp3+EZSvWJjhAbJYr5OGk+3/odqio0IN6t7IMeevjkQ12jKse3 NgN77rVzoBuTV0glPwqrcRXlc9fce0YvULmpTAH80B/jSZwq1iWxby+GhTQpSult mokI40nSlV4cex1XRYjvlFxmYbtXtp3Te5vY8gFGpZ8=; X-AuditID: c1b4fb25-da1ff70000005ff7-10-5c6ff2dc91f9 Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 93.8D.24567.CD2FF6C5; Fri, 22 Feb 2019 14:02:20 +0100 (CET) Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 22 Feb 2019 14:02:20 +0100 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 22 Feb 2019 14:02:19 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cfiuVJl3Vll7IjGc17PqM72CHYYc5GYl3FI7HM0q2Vg=; b=ZDSwW5HJ1ATjm139TKe6O+8JEdTLaHg6TmnXOvt9zdquL/cssobjCuWn23911doIQsqf/YFBO4iBclmUFgFVit+As3+6SdngHOSC0Un8L+FdSu55Ben8gL3lAP0OzuhJ+6wpdVRc0hocCBw78dH8yVBt7p4UXe5/68OwdzBbjw0= Received: from BN8PR15MB3090.namprd15.prod.outlook.com (20.178.221.213) by BN8PR15MB3217.namprd15.prod.outlook.com (20.179.73.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.18; Fri, 22 Feb 2019 13:02:10 +0000 Received: from BN8PR15MB3090.namprd15.prod.outlook.com ([fe80::25d5:ef39:7f8e:66b1]) by BN8PR15MB3090.namprd15.prod.outlook.com ([fe80::25d5:ef39:7f8e:66b1%4]) with mapi id 15.20.1643.018; Fri, 22 Feb 2019 13:02:10 +0000 From: Daniel Migault To: Michael Douglass , Calsify Thread-Topic: [calsify] draft-ietf-calext-eventpub-extensions - styled-description Thread-Index: AQHUynpfGNLMunBhw0yJRE5smc1IcqXrxETQ Date: Fri, 22 Feb 2019 13:02:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; x-originating-ip: [70.80.131.240] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 80c2eecf-cd3a-4199-69e7-08d698c5f4af x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN8PR15MB3217; x-ms-traffictypediagnostic: BN8PR15MB3217: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; BN8PR15MB3217; 23:Uj6ftgvxvf+H+Uc4zBEcRFeEf6JtDZHJp7+WS/iIq?= =?us-ascii?Q?XvrOJqoaJQn7Ix2wAiGETCJm0zREuiQ7JAwy9SaOdCYAYlqVKeGnbHr7jtrH?= =?us-ascii?Q?CR6v76mfFKkCMDXZCcBnrjBK8X1dq5KaEqB3WUadJ6+/DzMzeDVd55FP2dvf?= =?us-ascii?Q?MuWytAtdqY6JeIcX5L+ldVyA+5XI5qe0+T/YHGycuWfJKfnOHrIwOktD4awL?= =?us-ascii?Q?0w8LptVLkl+4LNjea5WgCsXM3RAPSSvbnIr8/0A/gtvAQRUNJYIVSLZ3xVLF?= =?us-ascii?Q?QEhW1tuh5R8L6QWw65cWZ+zheH4Nt+9op3nS7hM+33JmQdRuuhR4rxi5Nf3Y?= =?us-ascii?Q?eYyBNO1LLafi3Ee7ad7VB/9R/8FQzweb0aeZgp5Etqh5hrVNshJwilUfm+5P?= =?us-ascii?Q?lCq7M6jW0AVTcrpGghf72Nu2UzT6VWEnZjWCRO/wCzSVktQtD4EGX1NqGMV0?= =?us-ascii?Q?bmN1YQYfMwQC8deqpjVnpWJQ1n5P5Y8cunF832CX7crNOSKcREK/ilbMj+Mg?= =?us-ascii?Q?0AxokZdbXxKz0c1YVjoqq4vX3T+x8/3uD2WrVN1ekS2qHR7iWp5kkZmo5rcW?= =?us-ascii?Q?Q83lJJPr05LOPTmJ78kQB+0sbAEa/Mg4LdxKv3pPc3gDBZDOi0hidIVsZDQv?= =?us-ascii?Q?d/PNaIc5yNJU9i00AONHSp/eD4S8o5OAYG10hdHhKAPkSVR8a5oGCovZzgW1?= =?us-ascii?Q?DY/Yp/sh7nr5yqcbCCAW2kFXARflJd2bxae2NAzv+mHzSsyyTzWR4QD0yjXC?= =?us-ascii?Q?vINiqdsh//aSlRoT1r4BxJ5V4AYLeycyxyhPfeguGxYqmX6E6zQwGHIEZtQm?= =?us-ascii?Q?irPaMe0s5qfDtMbHtYwK4bg3TJQT1PEF7A8Q2Uyvs5b7q9Tqz0VKf2p18yRI?= =?us-ascii?Q?a1/JLRNsk+n664f7xosbhH5zqwwYZSULG4MNOEcLgLKIYXU/MHdqHFSP4pOx?= =?us-ascii?Q?+eMoQM7bCSB1uY+9oEXKRoMKKgqpAjj1YlY1tvqLdUsqGZMH7RBg1GCHk1WY?= =?us-ascii?Q?kNj92S55jbl8pSqLnjIoM7iykL3bJJur0mMUVOz5ZE2UnMUtPAeI0HFrSZ6s?= =?us-ascii?Q?LywNw+Ys9Uccyapc49rKcDQLUztZ6MOewsrI1ikjbKHDaR2JreUGm03Oe53L?= =?us-ascii?Q?mKnOGKvBgD1mmqYdRZAuEkhocBi5jzuoeJSNanqx1irtTgqpO37nd/UaQ91c?= =?us-ascii?Q?D5u49eHT0WMfBKZl2cP4Fz/AZGuAKQXR8b3fz8wcBr8CMuxboVCixyO94Rfa?= =?us-ascii?Q?zvCUGRWW7HqF/s75rWUbhPXCRLrbNPzsbzePSkr?= x-microsoft-antispam-prvs: x-forefront-prvs: 09565527D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(396003)(366004)(376002)(39860400002)(13464003)(189003)(199004)(476003)(11346002)(446003)(6246003)(74316002)(9686003)(5660300002)(8676002)(6306002)(55016002)(6436002)(68736007)(8936002)(81166006)(81156014)(229853002)(966005)(66066001)(256004)(14454004)(71190400001)(71200400001)(86362001)(14444005)(102836004)(26005)(53936002)(6116002)(186003)(3846002)(486006)(44832011)(2906002)(97736004)(7696005)(105586002)(305945005)(7736002)(25786009)(6506007)(53546011)(478600001)(106356001)(33656002)(99286004)(76176011)(316002)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR15MB3217; H:BN8PR15MB3090.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: SqyIhgyke5yoGsTP81rLONCmfcsAeuWxoNBuNikAcA2jK602I/oxoI6hwGIIV7tJiw8mhjrs9npAoiS3pfBej2tdfhugkjQtyd+0qWtFZSdn6/I9tRdwH6P2MEtgWZnvuvl41WIZipV+qzvGZpTLNpU8imPvi7Cy0/8vXIbj6aL1JvUPPhZTXqp+nh8m/Fp+QoeXRaNzvbVU9pYTjynAfMuLqhWBZLE//N3qxY9lAH1DbP8PAeeLkqwfKSm8kJkDTZ94pRUIxQ4zg01z4TFAkfyrMDu1JReG4zQFFMAJCIe+jVIuA0vCpb02+jGvpgq7QZGANcmvpixzXgoJqJx4jYCGHNCNViu0SmYUfsqot2jKdhgfJOu7oLQMVZjQdYGOks9oOCVWT9ppXcSbCf72BpI7KqDtnpcm8LphG0m4J0Y= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 80c2eecf-cd3a-4199-69e7-08d698c5f4af X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2019 13:02:09.5466 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR15MB3217 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42KZGbG9WPfOp/wYg/WPpS02vWhmtZiy7AGb A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXR1vCTqWAVf8WOn3fZGhh38HQxcnJICJhI HD43m62LkYtDSOAIo8Sdz1uYIZxvjBIXdi5mh3CWMEmsv/8KzGERmMAs0bJ6IgtEZjKTxJUH 66CcR4wSmw7NYgWZzCZgJNF2qJ8dxBYR8JLoW7gJqIiDQ1ggWOLxET6IcIjEpIm32CBsI4l7 e24xgdgsAqoSL88cAGvlFYiROHXqApgtJGAjcePQRRYQm1PAVuL87U5GEJtRQEzi+6k1YL3M AuISt57MZ4J4TkBiyZ7zzBC2qMTLx/9YIerjJL597IGKK0q82bmGFcKWlbg0v5sRwvaVmPNl CSvIXxICNxklzsz4xgKR0JI497ARaoGUxImLR6GK9vFK/FoygxHkSQmBbIklNy0hamQkpjWd ZoOwb7NKPPysB/FMqsTyta2MExh1ZyG5G8LWkViw+xMbhK0tsWzha+ZZ4LAQlDg58wnLAkaW VYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiBiePglt+qOxgvv3E8xCjAwajEwxt1Iz9GiDWx rLgy9xCjBAezkgiv3QegEG9KYmVValF+fFFpTmrxIUZpDhYlcd4/QoIxQgLpiSWp2ampBalF MFkmDk6pBkaT+Dm/NSdfW3xE45/NlPUz2MV7j5/o+uAtsD5pKetOiS/np5vXTDny9UzvhPa7 FzjjORf+ez67Tkvq9iJltzrFh6YNt3QD6t4s+nlbwOm598Z6+y1WZusuZL9V2n/z8BefbbVz dWetdbg7/+jjlcftFm5t3yHkv1F1UZKg5/OpX5bPMklYpnV8gRJLcUaioRZzUXEiALBN5QQY AwAA Archived-At: Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions - styled-description X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2019 13:02:25 -0000 Hi,=20 Update the draft. The draft has been sent to the IESG and its current state= is AD Evaluation which means that an IETF Last Call has not be sent. Unles= s Alexey thinks otherwise, I think you can update the draft, changes could = have come during the IETF Last Call.=20 I understand the changes are refinements, but the question I have for the W= G is whether the document needs more discussions in which case we may bring= it back to the WG. Yours,=20 Daniel =20 -----Original Message----- From: calsify On Behalf Of Michael Douglass Sent: Friday, February 22, 2019 1:46 AM To: Calsify Subject: [calsify] draft-ietf-calext-eventpub-extensions - styled-descripti= on There has been a sudden upsurge of interest in rich text in calendar items = and this has resulted in a need to make some changes to the styled-descript= ion specification. Given the late stage of the process for this spec I'm not sure how to proce= ed - should I just post a version 11 draft? To summarize - the changes are: Add a new parameter: DERIVED=3DTRUE/FALSE This will be used on the DESCRIPTION and STYLED-DESCRIPTION properties to i= ndicate that the value is derived from a 'master'=20 STYLED-DESCRIPTION, i.e one without that parameter or with DERIVED=3DFALSE Only one such 'master' will be allowed. This gives us the option of providi= ng alternative representations of the rich text in some other format. In th= e case of the DESCRIPTION only plain text is allowed. Need to remove text suggesting this property be used for language variants.= Another approach is being considered for that. I also need to add some text in the security section stating that rich text= needs to be filtered for malevolent or dubious content. _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From nobody Mon Feb 25 13:37:12 2019 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 B10721310CC for ; Mon, 25 Feb 2019 13:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drfGb9vWEhAD for ; Mon, 25 Feb 2019 13:37:03 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 47BD5131101 for ; Mon, 25 Feb 2019 13:37:01 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id u7so3240165qtg.9 for ; Mon, 25 Feb 2019 13:37:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=mhTBpWtiulkzPpH5YWhIdfEwXgqAXb3B7nXAHMUkWK4=; b=mj/Bg1u/RZ2poWrAGWmNv2wYtXY8dA9PKOh0VrN9gwYos2MSJz4WuA3l4MP7YbTrUK S6MHyjB4PE5yovCWxGTHbjqtKvmDj7UOXpc47T5DYrt9NYFy/skydJXy6MMj+I8RIY/m LA74M1kmoh5It3By6fusKo4z7PRiET5o81yshcHzP//WKDoxkZtFRTMYN3EWmAfp7d5d 9jMIPdJ0Y7HJyCMIvEyjqvfFMXn997FnnTlCBp9NQpljQY/f3wqV17aj4DxlDUdm+fnO Jhm8RJP3ZauBROv5k0qxQr9YGCIRfKSkCxy8uEe527XCqqbHe89a8JKpRS/ca5bhnx6I xHyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=mhTBpWtiulkzPpH5YWhIdfEwXgqAXb3B7nXAHMUkWK4=; b=nEDJSWazZ8xtYGEGxrI7qwMBxpQwTr5gkuB5/ZHpFThdUkkgBTkkuI3BSsDyriKfSz ypdtJr9dSUe4qJjDnQHbJljaaiCBGcsVJybJs9qCQ4Bi5C4PaM1jRv0c9wb6XtOeOue7 Db8JqfGm1S4wV7Rl7+XyuCmOLOp1W5kS3mQ1zf1Wcyp+dzXXjQSK9pk2EHZvMNS55fDE OGqbVIaPRiG1PMs6lGZSmFfGTxgU2Nnowz1PFdAVFoU9BHCREy0k5E20B3s4PLUgOkjt Vv+MgMLJncu9JW/SK7jT2zFO3MYVBXL5/ct3KW29MpW1UQ03tudlqZ792rECnPO7KRF5 6YKg== X-Gm-Message-State: AHQUAubFoyANw0i1UqggCrzi0BH7iBEwLlV4ayiRklsyv/6PL3LMJ8fm NtHHl+LEIRZzRs9IyvOvDCHaj/dQ X-Google-Smtp-Source: AHgI3IYB6fyBHIjY9sitY1gLkxS8dpoAU8FMB0kZOrjMwLMWnUNoyELRrLJKPmbubMbSdUKDksGWcg== X-Received: by 2002:a0c:891a:: with SMTP id 26mr15673565qvp.163.1551130620213; Mon, 25 Feb 2019 13:37:00 -0800 (PST) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id j139sm6212423qke.26.2019.02.25.13.36.59 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Feb 2019 13:36:59 -0800 (PST) To: Calsify From: Michael Douglass Message-ID: <7cb84a61-45ef-8aa2-12c5-10a9ca854bed@gmail.com> Date: Mon, 25 Feb 2019 16:36:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [calsify] Location for start/end. Eventpub and jscalendar X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 21:37:11 -0000 One of the topics that came up at the Zurich CalConnect meeting was the issue of specifying timezones. The new jscalendar spec allows the flagging of a location with an indication that the location is the start/end location for the event. As an outcome of the discussion I agreed to add such a flag to the eventpub extensions spec. Looking at 5545 we already have the RELATED parameter defined for alarms. It seems that would be appropriate for this use. In jscalendar it is defined as "rel". I'll post another comment/question on "related" on jscalendar alarms Names aside, I think the usage is statement is missing something in  jscalendar. For eventpub  would describe the usage of RELATED on structured-location as something like: RELATED=START the calendar object starts at this location RELATED=END the calendar object ends at this location If there is a RELATED=START but no RELATED=END then the event is assumed to start and end at the same location. (Obvious I guess but not stated in jscalendar?) From nobody Mon Feb 25 13:50:21 2019 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 82DC91310CA for ; Mon, 25 Feb 2019 13:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fFW-kKlPsv8 for ; Mon, 25 Feb 2019 13:50:19 -0800 (PST) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 403421310A1 for ; Mon, 25 Feb 2019 13:50:19 -0800 (PST) Received: by mail-it1-x133.google.com with SMTP id l15so840760iti.4 for ; Mon, 25 Feb 2019 13:50:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=MWfrQsa4FtZMqM6b6K7PTpkp+3mIDA0Dnc0gmAtmZeY=; b=E88p92UOC/XqQWXxZUkTpyOW8OOYm37Dl4/T6lAv5YK4fJhgZ/LzPWbVTf2sMDb3Ri L4IWBR5EcqhDEAT7Eeuer9X21cBgyJGthHaYcN6tv7pSOGed+hfNwv8NShmsBOxxJXY1 SLNl1hXBnYbWujUd0MqrVA6MQg+acDdQEJaGpINSmzCNww1fK8bQawHtMbHAp462npD4 p8oDANSl1GkFJlyvJlBU71T7AlT0sTAe0i6zJYQDcZEuXs3fUFORbrUmoR/Mb+iphGgr JScRMgL29CTR+2UJlkLp3fEhyNnCiuP0fUtWpXWSopSK/IJUx9Mums6RWVefp187Sjb5 c/6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=MWfrQsa4FtZMqM6b6K7PTpkp+3mIDA0Dnc0gmAtmZeY=; b=UyxfhdUy8SruHASrviLyAKdPkbxIF0EdRcoXGfjILOryjFzMXTWaKYcOQQkw/DUtp2 E0t/Loh5Vk8e4tTbPpZOIRE1f1BxkCUczfvY/l7KqyKooCMpsbDvI0S9XVApPJbv0wN9 YsSnC0gTl3epFRYKC8Ws2LLMcZ/pJHooy24AD6D7rIwNKlQLpz8RkzYt7YGdilhtHyH1 aXgrrs4kMCQGaasFVENLNHcx3JPblHgKIqedeCVQj+5d9Y57q6eHpYL3Qme0RtQVui2k uTBg6dksbPFWpheq71nl3/ft5bvZpguXSpaE4ACZpUKLWcy6gK7gBSHUUf1pfPtVU6pU qZdA== X-Gm-Message-State: APjAAAWgPPunQYHZUa+dRNHwX0KjI/eJeoZXTqtz+xMhEcamQlkNxyqe vua/nDfMBi1WfgPVYfqXcu+PyMZ1 X-Google-Smtp-Source: AHgI3IY3DbZ1eHalhvagJDFVjYLjMK8fQ6WNpI+W3FQnbVp+5lOQ3WpHKONPkECDPa4RyUvftI1r3w== X-Received: by 2002:a24:7d88:: with SMTP id b130mr614076itc.163.1551131418273; Mon, 25 Feb 2019 13:50:18 -0800 (PST) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id 14sm5573492ity.24.2019.02.25.13.50.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Feb 2019 13:50:17 -0800 (PST) To: Calsify From: Michael Douglass Message-ID: Date: Mon, 25 Feb 2019 16:50:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [calsify] jscalendar, alarm and related X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2019 21:50:20 -0000 Why was it decided to have relatedTo = before/afterXXX and presumably have offset be positive only (as defined but not explicit I think) This seems more cumbersome than the current related = start|end and a positive or negative duration for trigger. I assume the idea was to disallow negative durations for events - which don't make sense but a negative duration for offset makes sense. From nobody Mon Feb 25 16:21:46 2019 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 7C3F8130EEF for ; Mon, 25 Feb 2019 16:21:45 -0800 (PST) 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=iw0vGkWj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kOTgvFRj 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 gCG5Wt44oYYl for ; Mon, 25 Feb 2019 16:21:42 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D44712D84C for ; Mon, 25 Feb 2019 16:21:42 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 495C8329A for ; Mon, 25 Feb 2019 19:21:41 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 25 Feb 2019 19:21:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm2; bh=4EhxcbiMKZr9VV4/obaImCkLdHwJ ZyjDDi2PtreEgMU=; b=iw0vGkWjJgbSjGmDrBYGMAFLCiLwiQfAl75tSiESnRtN ZE/HEH6CAxuXsWdxwSzQNM6jEE+v7NZ0GuVv1GNyO8yiuF7O4YNPZPokFns5+T4e Iv8vazvjUjVQ+/e1VCE1H0TLX2XtiVc/5D39x7Xt8cxWxc74hi/IsJfjljRsf5SW tG4W21uTefQ0ej+aUd+S4fWGf0iHFoOZeTiEmzs8/KlWweYCNjpnRqFhmB/FUaRx 2DjlcPp0Hu/yxD+Va5RSNBcHyG7RtevrhXmmPpzFOvojZCsSqwqYQoVtFG1WC1OL rgDpu/TqtIUtIkCQ4aM4hZnzVumdpAis0+RYMn43Lg== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=4EhxcbiMKZr9VV4/o baImCkLdHwJZyjDDi2PtreEgMU=; b=kOTgvFRjog/Q3fAKI1OyU2peiaVaPUmw/ U25mrCNe9CfY6fCCIO0pCSx558J/3S17vZST/6hcFqPLzuD3W/1PIxGqkomaPGIR z5By0SVWgHzmAca+cPs5n0rgp2ycBFqVRAF1Xo9AJMCkT10MGfqwaXPZWgCNA2AY OFr1I5Egnk7lhPltheT5d8dloOl9xawaBrdChITdL9qz6Q0gffCUmXlTxxBnI9dV 16Ef3kgJIl5M7t/QrhKaxsCuBmIDhIrVx8aQvyET7ICJfOgv9K507HnWyWP5zX8u j5LGH5YVgcskGfY1OAeODlkqAPPJDcVAcCWPuza5r2wetPBjHQSlw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrudekgddvudculddtuddrgedtledrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurf grrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtgho mhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 269D920320; Mon, 25 Feb 2019 19:21:40 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-895-g0d23ba6-fmstable-20190213v1 X-Me-Personality: 64588216 Message-Id: <6909f082-e5c2-4cc5-afb8-c1096f1ce574@beta.fastmail.com> In-Reply-To: References: Date: Mon, 25 Feb 2019 19:21:39 -0500 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=44ac23331c424eb984f846ed20b90efd Archived-At: Subject: Re: [calsify] jscalendar, alarm and related 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, 26 Feb 2019 00:21:46 -0000 --44ac23331c424eb984f846ed20b90efd Content-Type: text/plain On Tue, 26 Feb 2019, at 08:50, Michael Douglass wrote: > Why was it decided to have relatedTo = before/afterXXX and presumably > have offset be positive only (as defined but not explicit I think) Because RFC3339 only includes a definition for positive durations, so if we had negative ones we would have to define our own syntax (and may lose compatibility with parsers that have already been implemented following this specification). Neil. --44ac23331c424eb984f846ed20b90efd Content-Type: text/html
    On Tue, 26 Feb 2019, at 08:50, Michael Douglass wrote:
    Why was it decided to have relatedTo = before/afterXXX and presumably 
    have offset be positive only (as defined but not explicit I think)

    Because RFC3339 only includes a definition for positive durations, so if we had negative ones we would have to define our own syntax (and may lose compatibility with parsers that have already been implemented following this specification).

    Neil.
    --44ac23331c424eb984f846ed20b90efd-- From nobody Mon Feb 25 19:12:08 2019 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 9750A130E62 for ; Mon, 25 Feb 2019 19:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 TFfy7vysgMOx for ; Mon, 25 Feb 2019 19:12:03 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 EEDB5130E67 for ; Mon, 25 Feb 2019 19:12:02 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id m9so6759108qkl.4 for ; Mon, 25 Feb 2019 19:12:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=p4iBQ6EBs+dc2xJyAJmsNegnKvEUIDly8bveOw+mPLA=; b=OuxDCGduRcvjJ3Oj4lmeJVj0coF3VeggGw7hwRpGEk+EI8gosBQ4/mzel5G6flnE93 plWsEHUpZyltwBClQGSBXe9xpEA/+LON2tWfIzB3BBUZ5z2xMtPpJvFOYossxWAGMZEO +wp1tmtly/geJCWaXwHp/tQLBBXRjVZzqsGK14hq8v0pm9C8rKJPUV7u8uEU1oeR6yJC WxUdLq0i7TE1vjXc67TOR5Qv8uH8Opb/mRH95SIUP8KAO4bUm5DSpI8P3eKv3164mP3g iX41sFds29MguL1XKeYYBjPP+GV4rmHfeYu7fY4IRizTJC1QIarQAV3KiX06YcePVp26 IBcA== 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=p4iBQ6EBs+dc2xJyAJmsNegnKvEUIDly8bveOw+mPLA=; b=VI/2qaIVH4wgZi89MmpPyCa0ezHn7joyIMH+nVp5oe0txx1rtLuxK/7nat4o/vCSzn WP6LLo/2BNjvVFdsAie7cFBnEXeAGvPT4v9NJvkoXd2ZEz3ZCZVlVVsvxfMVeZUvIqLj 8pFHGzYbCRyoPcsh/1eVVLm+eb2qPUVWpgqWv4mXmkQP8DtrewXjZbxlKwYLZw55+0AV bujbvfXTOq5x+xXbXcESx3H3otXhr46R9SDz8dmKiTNbOwRAmBWl+PCqRWE40wS3COsF XkSVRlD4a161j6OppWea00rUxLOBP/AU6OdIOj8HIse/7wgKKrgXM1wtRYYtnyYZwQ/H +p4w== X-Gm-Message-State: AHQUAuY8UBJjfg2W5zby67iGeXtKQsK5mUJl+fmss7AJq8oD3aoHuldF Xf33f4XL7ebsr7cNVh9/5SGIdPYl X-Google-Smtp-Source: AHgI3IZTrgz5hkNYI1XzsPn2P+fSnuWq4XD5BSPUKj87PqSI7pjs3VcjCQOk53HPSeTD5nKMVct8yA== X-Received: by 2002:ae9:f101:: with SMTP id k1mr15800839qkg.111.1551150721804; Mon, 25 Feb 2019 19:12:01 -0800 (PST) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id r47sm6406115qtc.48.2019.02.25.19.12.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Feb 2019 19:12:01 -0800 (PST) To: calsify@ietf.org References: <6909f082-e5c2-4cc5-afb8-c1096f1ce574@beta.fastmail.com> From: Michael Douglass Message-ID: <033621e8-bc55-84ce-c973-994b18468fc1@gmail.com> Date: Mon, 25 Feb 2019 22:12:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <6909f082-e5c2-4cc5-afb8-c1096f1ce574@beta.fastmail.com> Content-Type: multipart/alternative; boundary="------------19E93CB6E4686E1312FCB224" Content-Language: en-US Archived-At: Subject: Re: [calsify] jscalendar, alarm and related 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, 26 Feb 2019 03:12:07 -0000 This is a multi-part message in MIME format. --------------19E93CB6E4686E1312FCB224 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/25/19 19:21, Neil Jenkins wrote: > On Tue, 26 Feb 2019, at 08:50, Michael Douglass wrote: >> Why was it decided to have relatedTo = before/afterXXX and presumably >> have offset be positive only (as defined but not explicit I think) > > Because RFC3339 only includes a > definition for positive durations, so if we had negative ones we would > have to define our own syntax (and may lose compatibility with parsers > that have already been implemented following this specification). I don't think it needs a new syntax - it's (["+"] | "-") followed by duration. > > Neil. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------19E93CB6E4686E1312FCB224 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


    On 2/25/19 19:21, Neil Jenkins wrote:
    On Tue, 26 Feb 2019, at 08:50, Michael Douglass wrote:
    Why was it decided to have relatedTo = before/afterXXX and presumably 
    have offset be positive only (as defined but not explicit I think)

    Because RFC3339 only includes a definition for positive durations, so if we had negative ones we would have to define our own syntax (and may lose compatibility with parsers that have already been implemented following this specification).
    I don't think it needs a new syntax - it's (["+"] | "-") followed by duration.

    Neil.

    _______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
    --------------19E93CB6E4686E1312FCB224-- From nobody Mon Feb 25 19:14:38 2019 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 D327D130E68 for ; Mon, 25 Feb 2019 19:14:36 -0800 (PST) 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=hNAluebK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jITTyk2j 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 v9sEmN4uDpqz for ; Mon, 25 Feb 2019 19:14:36 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC24A130E67 for ; Mon, 25 Feb 2019 19:14:35 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id E0E8D2D31 for ; Mon, 25 Feb 2019 22:14:34 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Mon, 25 Feb 2019 22:14:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm2; bh=AD3jCtZZH2rseYX82bVx8t1XJu3v mGTHuXhYqrh/6PQ=; b=hNAluebK0ZnK0kCHLnE7Ow8jlnemdAh+dXDlxNa8ODmb B/Y4YV8Gnz4anuw5c5WV8sQ+WwXFd/kvvglS6U3Tk1aYdpiEgKaaC9htAsWilqKc ILn2W5NfG8FnODmOYXhxcS3ClFCDF+z0DvaLGKBFVoQM15g+eUitbA9y+V2/WV2L 2Gy1dIcko3DbIW2SQhpuLT2LhNdHJ5UAPaAs4/UpSa+Kkfkv8sZx3lICDD4GaTFv p4zP3je016m3BcWoINTwTNW+qzhBHcPrdxu7vyivPH1hVyXnTrh/eBtxdV5t5bt+ S7u4lQX4imfAjdjJczoNQkB35e0HuyVu1E2O/889hw== 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-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=AD3jCtZZH2rseYX82 bVx8t1XJu3vmGTHuXhYqrh/6PQ=; b=jITTyk2jKeIfF33EmIjgXvqH5fLai/h7U 52gFjjaLewwiqq8bI/+2KrYB0mA5E35a3RAzLQMckqseaUze2HYuo4yfryx2ZGGu Pq55iC6QiObUousueHmc+Rh1gPsr0wQcA4Zz8wOu/kFoFzuFJoIhapZ44R9IW2Os 0H5V1lxEDIqe4MGL1CouQPKU1R3jsbu1wOINn0bs3G6yCqj/K/srQzYOSKwjYYxo UEHjnDofVdr2i1ViaG3z8OT95spLVo0gr8MKEZk4uIeIBg9kfmb4b6o8ju5nVe4K mJlyjeLhQJ+4+t7Aq8VZ0P4SF2Lm62HqF4GSySXV4tkSi5yCYEjOQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrudekgdehkeculddtuddrgedtledrtddtmd cutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepnhgvih hljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0E03520320; Mon, 25 Feb 2019 22:14:34 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-895-g0d23ba6-fmstable-20190213v1 X-Me-Personality: 64588216 Message-Id: In-Reply-To: <033621e8-bc55-84ce-c973-994b18468fc1@gmail.com> References: <6909f082-e5c2-4cc5-afb8-c1096f1ce574@beta.fastmail.com> <033621e8-bc55-84ce-c973-994b18468fc1@gmail.com> Date: Mon, 25 Feb 2019 22:14:33 -0500 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=be51eb0e28b142b8902c103ddd231cbc Archived-At: Subject: Re: [calsify] jscalendar, alarm and related 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, 26 Feb 2019 03:14:37 -0000 --be51eb0e28b142b8902c103ddd231cbc Content-Type: text/plain On Tue, 26 Feb 2019, at 14:12, Michael Douglass wrote: > I don't think it needs a new syntax - it's (["+"] | "-") followed by duration. That's a new syntax by definition. And that doesn't go in to the point of existing object interpretations may not support negative durations (e.g. may use an unsigned int for the internal representation); the point is you may now have compatibility issues with existing code and whether this is sufficiently better to be worth that tradeoff. Neil. --be51eb0e28b142b8902c103ddd231cbc Content-Type: text/html
    On Tue, 26 Feb 2019, at 14:12, Michael Douglass wrote:
    I don't think it needs a new syntax - it's (["+"] | "-") followed by duration.

    That's a new syntax by definition. And that doesn't go in to the point of existing object interpretations may not support negative durations (e.g. may use an unsigned int for the internal representation); the point is you may now have compatibility issues with existing code and whether this is sufficiently better to be worth that tradeoff.

    Neil.
    --be51eb0e28b142b8902c103ddd231cbc-- From nobody Mon Feb 25 19:19:34 2019 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 28843130E6B for ; Mon, 25 Feb 2019 19:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 kzaDnIS8kzH0 for ; Mon, 25 Feb 2019 19:19:29 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 50C87130E69 for ; Mon, 25 Feb 2019 19:19:29 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id f196so6746889qke.10 for ; Mon, 25 Feb 2019 19:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=1OyfpUGK42Y0eMOWK5SjsreX7wV7D8LX146yUY3PdMs=; b=fMaL892f/AMfH8IjXKBNkCoQnFOZs7rKm2t8AQjadWb5RmBRlxsR4gvMzt233eIJxq xqv5CepgWA2wtARBjCrRqPKR8JaotKnZ7N+4El6IwBLjYoRfWnK2asOsLzPpE7rbpiJq fQb613BlcxyWsj49zlCEVzteWwNXC5AxkNf9CZYkgs1d1N0XiQNGm7guya7zgdspT7cq 8Et6jhFIqYTWB/d6aPNZ5HjT2dhDGfxbyQN5Z02bY7UGPLQsjACF0MQK+3HufCeUcYwb ch5NrGawmiY2kUuFuwXkdS37qoJ9U6uBlQmIgbsfNGnAsOMZD05/TnTAx5QTVLTb7gly IbbQ== 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=1OyfpUGK42Y0eMOWK5SjsreX7wV7D8LX146yUY3PdMs=; b=AZ7b1C1+q3aex7Jj7RdAjsWPOhhakLjatooGjuYBYxlvGnJZYcqJIhGWwnxXkeM0Q9 8IJX+qxz1daayel7Xtz3fYi/FoYV0p6/lCobKG/H90TVi+xTTq07rs8eZvkloT2Up75E cr3/Y9Xz7LDRj/Rn9AVYLulrQ9Ezu00Tu0/AEW14L5T9xkzf/9wBhofPDi2kXMwGxBNW agCuRrMKlM1plxcJ34tGtsuALXk8Qj3QlQDVZ09ILlKR7QOxVlaK20h952dkaTQYOMnr x1psLShO7rZcJO5GLiywqfO5IcP6Dox2Ez9aUNih3olWZFEKnma5aMK3UDnFpOsA6el3 3ZeA== X-Gm-Message-State: AHQUAubYbsIKIzlQ5t0uVaMYhv6cqB+ZqwJ3kfYcxVfOuY2WlnM+TvzY SSuAc+P6KMoubderdcmnHC75xWQC X-Google-Smtp-Source: AHgI3IbrIJBRGU+tZb5DTo2WnO1hLMQAKtaeb6RUSpzKi4TSaIDFfLJpkCdGuzvjaM7g+AbP4RBuiQ== X-Received: by 2002:a05:620a:123b:: with SMTP id v27mr14440393qkj.29.1551151168201; Mon, 25 Feb 2019 19:19:28 -0800 (PST) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id y21sm7941018qth.90.2019.02.25.19.19.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Feb 2019 19:19:27 -0800 (PST) To: calsify@ietf.org References: <6909f082-e5c2-4cc5-afb8-c1096f1ce574@beta.fastmail.com> <033621e8-bc55-84ce-c973-994b18468fc1@gmail.com> From: Michael Douglass Message-ID: Date: Mon, 25 Feb 2019 22:19:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------69DE646E391C2B7E87CB501D" Content-Language: en-US Archived-At: Subject: Re: [calsify] jscalendar, alarm and related 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, 26 Feb 2019 03:19:32 -0000 This is a multi-part message in MIME format. --------------69DE646E391C2B7E87CB501D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/25/19 22:14, Neil Jenkins wrote: > On Tue, 26 Feb 2019, at 14:12, Michael Douglass wrote: >> I don't think it needs a new syntax - it's (["+"] | "-") followed by >> duration. > > That's a new syntax by definition. And that doesn't go in to the point > of existing object interpretations may not support negative durations > (e.g. may use an unsigned int for the internal representation); the > point is you may now have compatibility issues with existing code and > whether this is sufficiently better to be worth that tradeoff. What existing code? This is in reference to alarms which in icalendar are specified by negative or positive trigger values. Any reimplementation of alarm code for jscalendar will have to take account of the difference. From icalendar 3.3.6 dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) I already have a parser which handles negative durations. I already check for and disallow negative durations for events. > Neil. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------69DE646E391C2B7E87CB501D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


    On 2/25/19 22:14, Neil Jenkins wrote:
    On Tue, 26 Feb 2019, at 14:12, Michael Douglass wrote:
    I don't think it needs a new syntax - it's (["+"] | "-") followed by duration.

    That's a new syntax by definition. And that doesn't go in to the point of existing object interpretations may not support negative durations (e.g. may use an unsigned int for the internal representation); the point is you may now have compatibility issues with existing code and whether this is sufficiently better to be worth that tradeoff.

    What existing code? This is in reference to alarms which in icalendar are specified by negative or positive trigger values. Any reimplementation of alarm code for jscalendar will have to take account of the difference.

    From icalendar 3.3.6

           dur-value  = (["+"] / "-") "P" (dur-date / dur-time / dur-week)
    I already have a parser which handles negative durations. I already check for and disallow negative durations for events.
    Neil.

    _______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
    --------------69DE646E391C2B7E87CB501D-- From nobody Mon Feb 25 23:34:46 2019 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 46CCE130E86 for ; Mon, 25 Feb 2019 23:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] 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 usUueqKdV9Fr for ; Mon, 25 Feb 2019 23:34:41 -0800 (PST) Received: from dd40210.kasserver.com (dd40210.kasserver.com [85.13.156.70]) (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 B6948128B33 for ; Mon, 25 Feb 2019 23:34:41 -0800 (PST) Received: from nbnimm (91.141.1.119.wireless.dyn.drei.com [91.141.1.119]) by dd40210.kasserver.com (Postfix) with ESMTPSA id DFBF463A1247 for ; Tue, 26 Feb 2019 08:34:38 +0100 (CET) From: "Alexander Nimmervoll" To: References: <6909f082-e5c2-4cc5-afb8-c1096f1ce574@beta.fastmail.com> <033621e8-bc55-84ce-c973-994b18468fc1@gmail.com> In-Reply-To: Date: Tue, 26 Feb 2019 08:34:37 +0100 Message-ID: <02f401d4cda5$bb372bc0$31a58340$@caldavsynchronizer.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F5_01D4CDAE.1CFB93C0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGmrCMzDJdgWPjmujNtvBZViA3KigJArCnZAOOJ+U0B5zEEpwFdPYiKphqrIbA= Content-Language: de-at Archived-At: Subject: Re: [calsify] jscalendar, alarm and related 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, 26 Feb 2019 07:34:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02F5_01D4CDAE.1CFB93C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I also think it should allow the same syntax as alarm trigger values and = every iCalendar parser understands positive and negative durations for = that.=20 =20 Another question is about the subset of the duration definition for = JSCalendar. Why was the dur-date removed? This also leads to necessary = conversions from alarm triggers. =20 Cheers, Alex =20 On 2/25/19 22:14, Neil Jenkins wrote: On Tue, 26 Feb 2019, at 14:12, Michael Douglass wrote: I don't think it needs a new syntax - it's (["+"] | "-") followed by = duration. =20 That's a new syntax by definition. And that doesn't go in to the point = of existing object interpretations may not support negative durations = (e.g. may use an unsigned int for the internal representation); the = point is you may now have compatibility issues with existing code and = whether this is sufficiently better to be worth that tradeoff. What existing code? This is in reference to alarms which in icalendar = are specified by negative or positive trigger values. Any = reimplementation of alarm code for jscalendar will have to take account = of the difference. >From icalendar 3.3.6 dur-value =3D (["+"] / "-") "P" (dur-date / dur-time / dur-week) I already have a parser which handles negative durations. I already = check for and disallow negative durations for events. Neil. _______________________________________________ calsify mailing list calsify@ietf.org =20 https://www.ietf.org/mailman/listinfo/calsify ------=_NextPart_000_02F5_01D4CDAE.1CFB93C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    I also think it = should allow the same syntax as alarm trigger values and every iCalendar = parser understands positive and negative durations for that. =

     

    Another question = is about the subset of the duration definition for JSCalendar. Why was = the dur-date removed? This also leads to necessary conversions from = alarm triggers.

     

    Cheers,<= /span>

    Alex

     

    On 2/25/19 22:14, Neil Jenkins = wrote:

    On Tue, 26 Feb 2019, at 14:12, Michael Douglass = wrote:

    I don't think it needs a = new syntax - it's (["+"] | "-") followed by = duration.

     

    That's a new syntax by definition. And that doesn't go = in to the point of existing object interpretations may not support = negative durations (e.g. may use an unsigned int for the internal = representation); the point is you may now have compatibility issues with = existing code and whether this is sufficiently better to be worth that = tradeoff.

    What existing code? This = is in reference to alarms which in icalendar are specified by negative = or positive trigger values. Any reimplementation of alarm code for = jscalendar will have to take account of the = difference.

    From icalendar = 3.3.6

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
dur-value=C2=A0 =3D (["+"] / "-") "P" =
(dur-date / dur-time / dur-week)

    I = already have a parser which handles negative durations. I already check = for and disallow negative durations for = events.

    Neil.



    ___________________________=
____________________
    calsify mailing =
list
    calsify@ietf.org
    https://www.ietf.o= rg/mailman/listinfo/calsify
    ------=_NextPart_000_02F5_01D4CDAE.1CFB93C0-- From nobody Wed Feb 27 20:29:53 2019 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 DC1CE12950A; Wed, 27 Feb 2019 20:29:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <155132819085.14099.13670351254661088738@ietfa.amsl.com> Date: Wed, 27 Feb 2019 20:29:50 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-11.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, 28 Feb 2019 04:29:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : Event Publishing Extensions to iCalendar Author : Michael Douglass Filename : draft-ietf-calext-eventpub-extensions-11.txt Pages : 33 Date : 2019-02-27 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-11 https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 27 20:47:10 2019 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 CEB3C130DD6 for ; Wed, 27 Feb 2019 20:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1vVkL3E-rWA for ; Wed, 27 Feb 2019 20:47:06 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 19572130DC0 for ; Wed, 27 Feb 2019 20:47:06 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id w4so22154811qtc.1 for ; Wed, 27 Feb 2019 20:47:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=n+UTVsOBXwkPlbOye0dOpy1bUepwsFK6NvRFMVebBO0=; b=UJfiC/Geop7QdKClhQc2GaOCItVsHOmaO+TV3sXj1CIDNBR0m2zPCRy0gl8NKIx9sp H+HwzPhP0IXN5D/ekKf2a7Cc9hkTOG1u2eLFSk3wn7SMA9RTaT+bPrg5YsET9Wnk5TLQ ZNak4PlJTgM/4R2FgXimBkrE6MR19J5+RJlLlV5h/E4VaawwnA18+P8CMl1IBGZOr6xj GRn6MxYBHaOttVgTaKEd9o5F8mKSAGaeftoNTi55elousoL91OyRqjtDGs0kJ7Cfys7b 2BeaqTmkG9dPHHozc9Qo2VsvIiQxOEcEmNKXzd7YB0rMs00GvmeYwl9bo8gd3yKFxWsS 8D6Q== 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=n+UTVsOBXwkPlbOye0dOpy1bUepwsFK6NvRFMVebBO0=; b=IUKZHr9PPFBXKKz24coce2AlZt4auhq6vQ7kXxesG9xZZko/SdxGfUwNP4KdY6VGOr t9vXb4QSsO8gk10LYYz6uMDF557Q5L9qLgzDe7H2NzMu/FJ4EHpVc/Rt2VpDrCx0r5Ob /8LOKEuCyCPADEy9CDabbt0oVn/5E5drCU7BIYg6934NL8sEtTtOopk7k7NeUBkVG8wf M6qmP/gc/3BrI6Npl+qZtDv/i1ecALC+gI44CGzFnimSZRGAE6U7wRA19zcTFsEOXnLl RwpGbgLClwtySLs1Lo2HblXEe4p32eSC+G6Dh+R4TCcPd9y0OAO9gNiojYTuLHJPgtEL TQNA== X-Gm-Message-State: AHQUAuZYETXu2JIcWhcCpBkg4p7d8LZRLSD3aLrAlNum2tKvDqttq6Ay JiR9MXgN5K3L1HHRnVV4fsOtRBOg X-Google-Smtp-Source: AHgI3IYdZTVRxmK9JUFiKJttCSzZ/t/E63Eq8c9lMUiVU+NoJgipmMcWNAW389hdZDIauLszIkGyCQ== X-Received: by 2002:aed:384a:: with SMTP id j68mr4627575qte.171.1551329224850; Wed, 27 Feb 2019 20:47:04 -0800 (PST) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id i33sm13308285qti.74.2019.02.27.20.47.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Feb 2019 20:47:04 -0800 (PST) To: Daniel Migault , Calsify References: From: Michael Douglass Message-ID: Date: Wed, 27 Feb 2019 23:47:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [calsify] draft-ietf-calext-eventpub-extensions - styled-description 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, 28 Feb 2019 04:47:09 -0000 I've submitted draft 11. In addition to the interest in rich text there was interest in adding a parameter to the new structured-location to allow it to be used to specify the star and/or end location of the component. Coincidentally there has been similar interest on the IANA timezone list. While that change seems relatively small it may warrant further discussion as it has implications on the speicifcation of start and end. A summary of the changes: Some minor typos The DERIVED parameter to indicate a property is derived from some other property and should not be modified. Changes to STYLED-DESCRIPTION to use that property and to clarify and state that only one (master) description should exist. Text on the use of the RELATED parameter for locations. On 2/22/19 08:02, Daniel Migault wrote: > Hi, > > Update the draft. The draft has been sent to the IESG and its current state is AD Evaluation which means that an IETF Last Call has not be sent. Unless Alexey thinks otherwise, I think you can update the draft, changes could have come during the IETF Last Call. > > I understand the changes are refinements, but the question I have for the WG is whether the document needs more discussions in which case we may bring it back to the WG. > > Yours, > Daniel > > > > -----Original Message----- > From: calsify On Behalf Of Michael Douglass > Sent: Friday, February 22, 2019 1:46 AM > To: Calsify > Subject: [calsify] draft-ietf-calext-eventpub-extensions - styled-description > > There has been a sudden upsurge of interest in rich text in calendar items and this has resulted in a need to make some changes to the styled-description specification. > > Given the late stage of the process for this spec I'm not sure how to proceed - should I just post a version 11 draft? > > To summarize - the changes are: > > Add a new parameter: DERIVED=TRUE/FALSE > > This will be used on the DESCRIPTION and STYLED-DESCRIPTION properties to indicate that the value is derived from a 'master' > STYLED-DESCRIPTION, i.e one without that parameter or with DERIVED=FALSE > > Only one such 'master' will be allowed. This gives us the option of providing alternative representations of the rich text in some other format. In the case of the DESCRIPTION only plain text is allowed. > > Need to remove text suggesting this property be used for language variants. Another approach is being considered for that. > > I also need to add some text in the security section stating that rich text needs to be filtered for malevolent or dubious content. > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Thu Feb 28 04:08:17 2019 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 3081612894E for ; Thu, 28 Feb 2019 04:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=vdix+loL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yLjEQTrz 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 8xuTngI21k1Q for ; Thu, 28 Feb 2019 04:08:14 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C479F128CF3 for ; Thu, 28 Feb 2019 04:08:13 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id D442A22738 for ; Thu, 28 Feb 2019 07:08:12 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 28 Feb 2019 07:08:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm2; bh=SZuHOrTqilEhlC1h97O/euQ8loI DRtmfzVU1TYSWUEo=; b=vdix+loLb4ftEnJKlJ3yTx6EsyrBjGJnNJE724FZ25C kCRie1HZD+JoQQvG/N/yfl4LVYdWPomBt2AMoZGre5FYz29SeCMT3kKuUxJID56Q ysxIJmZkw075PjRrE+2ZlGGgsHaLcNJSshryGw0+TxRuECQ3TnXTA0LwqSqJ7oAJ 7UIn6S25iGdrKH8BtQom3/KvkvOOi9z/vDMs3NLJACWCa9HYR4fpagwRqw3oEqwE EBctod1gc51D1cQLghjrX9yPGhbP/hCwekq68L6RWSDE6JPdD6ev22sQPcpOmdhv OTx4G9AsDOFvlUys1QD3dRFKWLt1oA+C6crtnG8H7XQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=SZuHOr TqilEhlC1h97O/euQ8loIDRtmfzVU1TYSWUEo=; b=yLjEQTrztgb+IWWravqUq5 JFv5psqi+vXt7AW1/ck2S/qAJud8qd7KZfEhuPjr7x5FEQ1qT0zstrPhiOWgJHAA OnfXcPmlQOVN0g4qTKdv4iD8Disq60ZHv20hxmhrybkZbjpwWiv51F9NIYVtvQXh x+3Mo4sGiuc1ZhB24ybVO/2Gu5WwIqHKzz1+zYEdktCucITheseirA/G+bCGi8WJ AjgOIGQlhx68F4+vzExppjlui4L3zNlRkejDmHeeFnuWt7Rg1ZmMKBH4vGCE2PE4 TsR2ndej7Gc0DTK+AGQ2utICGSJazUNib8yzSZzDRa4A023/zxp22glBAY2+/rDA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrvdefgdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhohfkffgfgggjtgesmhdtre ertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehfrghs thhmrghilhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepjeegrd ejjedrkeehrddvhedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghs thhmrghilhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 1FDCAE4582 for ; Thu, 28 Feb 2019 07:08:12 -0500 (EST) To: calsify@ietf.org References: <6909f082-e5c2-4cc5-afb8-c1096f1ce574@beta.fastmail.com> <033621e8-bc55-84ce-c973-994b18468fc1@gmail.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <79518eee-1c66-0c1d-0e76-fb53afdadb0a@fastmail.com> Date: Thu, 28 Feb 2019 07:08:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------3D358B89A40828345B3E9B64" Content-Language: en-US Archived-At: Subject: Re: [calsify] jscalendar, alarm and related 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, 28 Feb 2019 12:08:16 -0000 This is a multi-part message in MIME format. --------------3D358B89A40828345B3E9B64 Content-Type: multipart/alternative; boundary="------------B371D3721DC78E5D62EF982A" --------------B371D3721DC78E5D62EF982A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I'm in agreement with Mike and Alexander in that we should allow negative durations in jcalendar in the same fashion as iCalendar. On 2/25/19 10:19 PM, Michael Douglass wrote: > > > On 2/25/19 22:14, Neil Jenkins wrote: >> On Tue, 26 Feb 2019, at 14:12, Michael Douglass wrote: >>> I don't think it needs a new syntax - it's (["+"] | "-") followed by >>> duration. >> >> That's a new syntax by definition. And that doesn't go in to the >> point of existing object interpretations may not support negative >> durations (e.g. may use an unsigned int for the internal >> representation); the point is you may now have compatibility issues >> with existing code and whether this is sufficiently better to be >> worth that tradeoff. > > What existing code? This is in reference to alarms which in icalendar > are specified by negative or positive trigger values. Any > reimplementation of alarm code for jscalendar will have to take > account of the difference. > > From icalendar 3.3.6 > > dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) > I already have a parser which handles negative durations. I already > check for and disallow negative durations for events. >> 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 -- Ken Murchison Cyrus Development Team FastMail US LLC --------------B371D3721DC78E5D62EF982A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

    I'm in agreement with Mike and Alexander in that we should allow negative durations in jcalendar in the same fashion as iCalendar.


    On 2/25/19 10:19 PM, Michael Douglass wrote:


    On 2/25/19 22:14, Neil Jenkins wrote:
    On Tue, 26 Feb 2019, at 14:12, Michael Douglass wrote:
    I don't think it needs a new syntax - it's (["+"] | "-") followed by duration.

    That's a new syntax by definition. And that doesn't go in to the point of existing object interpretations may not support negative durations (e.g. may use an unsigned int for the internal representation); the point is you may now have compatibility issues with existing code and whether this is sufficiently better to be worth that tradeoff.

    What existing code? This is in reference to alarms which in icalendar are specified by negative or positive trigger values. Any reimplementation of alarm code for jscalendar will have to take account of the difference.

    From icalendar 3.3.6

           dur-value  = (["+"] / "-") "P" (dur-date / dur-time / dur-week)
    I already have a parser which handles negative durations. I already check for and disallow negative durations for events.
    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

    -- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
    --------------B371D3721DC78E5D62EF982A-- --------------3D358B89A40828345B3E9B64 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------3D358B89A40828345B3E9B64-- From nobody Thu Feb 28 12:06:34 2019 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 5E29612F1AB for ; Thu, 28 Feb 2019 12:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 RY85HQ8b4tpn for ; Thu, 28 Feb 2019 12:06:31 -0800 (PST) Received: from mr85p00im-ztdg06021101.me.com (mr85p00im-ztdg06021101.me.com [17.58.23.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F402124BF6 for ; Thu, 28 Feb 2019 12:06:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=04042017; t=1551384390; bh=5nvCGDVI6/1/r3dh8Tv/5Tk2XohDjpqsxDarzfMLYXY=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=q6ddRUJKOhibgq2fdstVTeZmzo9CVq2y2AZ1wNf4OvgAnkPpNbVYsM+YiPRcZDeqx vdfKr1H6W8QVWm457QWwp0NWRt1IizZn1H5DQyPX+l3CtMln/i6G1jz9RYyYStpNZ8 lwS1HQ9PZ5oDfRiCEMGUYbGTlMMSsCS9edhPyY0Kdccaz4Gvk+s0sHOlPwFYFGr1SC 9Bg+xlz2kzCZAm5uQ3aVx/038WEAZpBs11GDGfflpVBGCFczYq89aCwFrrCF4wNHDp us3/alYrUMi2XSlUCl1La3eJh7FvACMdMaQvFnnVctdglbcVLOA6OYoeuen5tl+GHK UlKyifYTiTNjg== Received: from jungleland.nac.uci.edu (jungleland.nac.uci.edu [128.195.168.56]) by mr85p00im-ztdg06021101.me.com (Postfix) with ESMTPSA id 6BF67A600C1; Thu, 28 Feb 2019 20:06:30 +0000 (UTC) From: Andrew Laurence Message-Id: <297FECCD-0F2E-44D4-BD39-5FBC9D596C30@me.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B3E5DAE5-7DDE-45D6-9813-89F1E005A922" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 28 Feb 2019 12:06:29 -0800 In-Reply-To: <79518eee-1c66-0c1d-0e76-fb53afdadb0a@fastmail.com> Cc: calsify@ietf.org To: Ken Murchison References: <6909f082-e5c2-4cc5-afb8-c1096f1ce574@beta.fastmail.com> <033621e8-bc55-84ce-c973-994b18468fc1@gmail.com> <79518eee-1c66-0c1d-0e76-fb53afdadb0a@fastmail.com> X-Mailer: Apple Mail (2.3445.102.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-02-28_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=965 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1812120000 definitions=main-1902280135 Archived-At: Subject: Re: [calsify] jscalendar, alarm and related 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, 28 Feb 2019 20:06:33 -0000 --Apple-Mail=_B3E5DAE5-7DDE-45D6-9813-89F1E005A922 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii IIRC, negative durations are in the 8601-2 draft. -Andrew > On Feb 28, 2019, at 4:08 AM, Ken Murchison wrote: >=20 > I'm in agreement with Mike and Alexander in that we should allow = negative durations in jcalendar in the same fashion as iCalendar. >=20 >=20 >=20 > On 2/25/19 10:19 PM, Michael Douglass wrote: >>=20 >> On 2/25/19 22:14, Neil Jenkins wrote: >>> On Tue, 26 Feb 2019, at 14:12, Michael Douglass wrote: >>>> I don't think it needs a new syntax - it's (["+"] | "-") followed = by duration. >>>=20 >>> That's a new syntax by definition. And that doesn't go in to the = point of existing object interpretations may not support negative = durations (e.g. may use an unsigned int for the internal = representation); the point is you may now have compatibility issues with = existing code and whether this is sufficiently better to be worth that = tradeoff. >> What existing code? This is in reference to alarms which in icalendar = are specified by negative or positive trigger values. Any = reimplementation of alarm code for jscalendar will have to take account = of the difference. >>=20 >> =46rom icalendar 3.3.6 >>=20 >> dur-value =3D (["+"] / "-") "P" (dur-date / dur-time / = dur-week) >> I already have a parser which handles negative durations. I already = check for and disallow negative durations for events. >>> Neil. >>>=20 >>>=20 >>> _______________________________________________ >>> calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify = >>=20 >>=20 >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify = > --=20 > Ken Murchison > Cyrus Development Team > FastMail US LLC > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --Apple-Mail=_B3E5DAE5-7DDE-45D6-9813-89F1E005A922 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii IIRC, negative durations are in the 8601-2 draft.

    -Andrew

    On Feb 28, 2019, at 4:08 AM, Ken Murchison <murch@fastmail.com> wrote:

    I'm in agreement with Mike and Alexander in that we should allow negative durations in jcalendar in the same fashion as iCalendar.


    On 2/25/19 10:19 PM, Michael Douglass wrote:


    On 2/25/19 22:14, Neil Jenkins wrote:
    On Tue, 26 Feb 2019, at 14:12, Michael Douglass wrote:
    I don't think it needs a new syntax - it's (["+"] | "-") followed by duration.

    That's a new syntax by definition. And that doesn't go in to the point of existing object interpretations may not support negative durations (e.g. may use an unsigned int for the internal representation); the point is you may now have compatibility issues with existing code and whether this is sufficiently better to be worth that tradeoff.

    What existing code? This is in reference to alarms which in icalendar are specified by negative or positive trigger values. Any reimplementation of alarm code for jscalendar will have to take account of the difference.

    From icalendar 3.3.6

           dur-value  = (["+"] / "-") "P" (dur-date / dur-time / dur-week)
    I already have a parser which handles negative durations. I already check for and disallow negative durations for events.
    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

    -- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
    <murch.vcf>_______________________________________________
    calsify mailing list
    calsify@ietf.org
    https://www.ietf.org/mailman/listinfo/calsify

    --Apple-Mail=_B3E5DAE5-7DDE-45D6-9813-89F1E005A922--