Re: [calsify] JSCalendar duration vs. end time

Doug Royer <douglasroyer@gmail.com> Sat, 09 March 2019 02:30 UTC

Return-Path: <douglasroyer@gmail.com>
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 E5AFF12796B for <calsify@ietfa.amsl.com>; Fri, 8 Mar 2019 18:30:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 cSZd_FDVatGt for <calsify@ietfa.amsl.com>; Fri, 8 Mar 2019 18:30:58 -0800 (PST)
Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 19930126C15 for <calsify@ietf.org>; Fri, 8 Mar 2019 18:30:58 -0800 (PST)
Received: by mail-ot1-x333.google.com with SMTP id v20so19086951otk.7 for <calsify@ietf.org>; Fri, 08 Mar 2019 18:30:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=/MrujCp1OOtkkZfBtlk0XjNkhbU58WFkJXaw7cmMhpg=; b=NLceqQ9pagtkiT8rsr/RXuQPSK/pbGor8dhd43xObX1kYCjobbGJgieNQzpZT+hr6m xzF5T6FvRY6Xfd30Z66f577GGfsUDMTmlSkbLp34dkfXoQQSG5PLx9tI3zE/JRicAe6o cUiY/dSl8Pjv5Poz8NDNb8bB8e9YenbcC82FEHFoiUT58MsnZmW9FpZcdXOlvr6rsaJQ A/o+iMXI3N5tqozaQpGUhuEggYxc/VI5YpliwPjnrvwcWoO/JCnWNY19BySjTTBURngT tBYRXkpAA2Uds67rJGKeQMjMRGJvlmyqJPTT2Bjo/nJ3B+dbwugVhY2JgZf4RLVSm36X t+7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=/MrujCp1OOtkkZfBtlk0XjNkhbU58WFkJXaw7cmMhpg=; b=P+TnV+0qf/KM+tq9SBSBxE9eEWZEJQMzBFubr3s72JQwqhYVAJrS0JXUlMaPSGFg/1 D/5LeS/wTdlzVRzIBFN5f0kRp3KiXQ5uPJX+LEmHQIK6AMh+mPt3WPBs0s3RbTrsvZh3 FzeMAFEk5HoHLcrbSM3c1p7ON+6aZXOETmgPYCmCHRlKzmGqol/BKsuQahOM1nujDz0f +GkbbnH9D1l56YG6qOA5VikwS/X89B/VRmbpH4x1giJvPumf9mT2bRTeGcw3XQY8Zse/ nGGy7qaTOiK0b8MrClHK1pixAjiHCkErhlYAH1LPAvEsc/WmSmtjeAg/Ke09Tp58Bm4M Bynw==
X-Gm-Message-State: APjAAAW2qJrJH4Cf/4YHdvzj5dusWdh7P1U7DiAObor3J6EvKkdIWLkt qxU53WrHJKp9rSPZ0xQj2z4NiJ0rZ0M8
X-Google-Smtp-Source: APXvYqzZ1jc8buFRqgB1X58ir8yLay7VWGw1f2aRVaztRgWc5Q6CkvEXOr3wK+eAitIm3U6dBHqWBQ==
X-Received: by 2002:a9d:73c2:: with SMTP id m2mr13706808otk.91.1552098656849; Fri, 08 Mar 2019 18:30:56 -0800 (PST)
Received: from [192.168.1.7] (75-174-58-238.boid.qwest.net. [75.174.58.238]) by smtp.googlemail.com with ESMTPSA id e24sm3778811otl.2.2019.03.08.18.30.55 for <calsify@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 18:30:55 -0800 (PST)
From: Doug Royer <douglasroyer@gmail.com>
X-Google-Original-From: Doug Royer <DouglasRoyer@gmail.com>
To: calsify@ietf.org
References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> <53c5912a8b973aeb0ab67a0d8b7ed0072c5f23b7.camel@aegee.org>
Organization: http://SoftwareAndServices.NET
Message-ID: <e8b254ac-4ff9-f889-5338-fb4fa124eab1@gmail.com>
Date: Fri, 08 Mar 2019 19:30:54 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <53c5912a8b973aeb0ab67a0d8b7ed0072c5f23b7.camel@aegee.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms020801010101050801070507"
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/CrUwL_51zsygHTZBIJ9vaJdtW-g>
Subject: Re: [calsify] JSCalendar duration vs. end time
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Mar 2019 02:31:00 -0000

On 3/8/19 12:37 PM, Дилян 
Палаузов [Masked] wrote:
> 
> 
> Hello,
> 
> imagine you book a room for 3:45 hours, and want to have there a session “Topic A” for one hour, a 0:15 hours for
> coffee-break and then a session “Topic B” for two hours.  You map this in iCalendar/CalDAV as (imprecise syntax):
> 
> --
> DTSTART: 8am
> DTEND: 9am (or if you prefer DURATION: 1h)
> SUMMARY: Topic A
> UID: 1
> --
> DTSTART;RELTYPE=FINISHTOSTART;REL-TO=UID:1 (per https://tools.ietf.org/html/draft-ietf-calext-ical-relations - the start
> is defined as the end of the other event)
> DURATION: 15minutes
> SUMMARY: Tee time
> UID: 2
> --
> DTSTART:RELTYPE=FINISHTOSTAR;REL-TO=UID:2
> DTEND: 11:45am
> SUMMARY: Topic B
> UID: 3
> --
> 
> So far so good.
> 
> Now, imagine the first session get longer as expected, e.g. 75 minutes.  The last session has to end in 11:45am, because
> the room is booked only until then.  Under circumstances, the only event that needs to be updated is the first one, and
> the rest of the agenda will magically align, provided draft-ietf-calext-ical-relations makes progress.
> 
> In this case, for UID:2 you have to use DURATION and for UID:3 you have to use DTEND → Both are needed.

So your choice is to make the calendar not match reality, or reissue 
some new instances with the corrected values. When you re-issue new 
instances, simply adjust them to be correct.

If you do not re-issue instances, the calendar does not match reality 
anyway - so the point is really not relevant. Your simply picking which 
properties in which components are incorrect.

If you reissue, simply set the 1st session end time to an accurate limit 
(or ignore it is wrong). Set the break time to the correct start time 
and 15 minute duration (or ignore it is wrong). And set the 2nd session 
time to the correct values.

There is no one way to solve these issues. I think that makes it 
ambiguous and poorly designed. There is no wrong way to get it done. The 
meetings over times zone changes is a pain when implementations change 
everything to DTEND, and relative entries are kind of correct in the 
example you provide - or you have to reissue them anyway to make them 
correct.

In both ways of thinking, the changed VEVENT components need to be 
updated. It is just a matter of one of several ways of getting it done.
Which is why I say it is ambiguous. There should be one way to get it 
done recognized by all implementations.

I assert that all VEVENTs have some kind of duration, even when zero, 
and can never be negative. However DTEND when not in UTC, is not always 
obvious and a real pain over time zone changes.

I have found that developers will push for the method that makes any 
changes to their current implementation easier. And sometimes, that 
makes for ambiguous or difficult to understand specifications.

-- 

Doug Royer - (http://DougRoyer.US)
Douglas.Royer@gmail.com
714-989-6135