Subject: [calsify] Updated JSCalendar draft version 08

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 08 Oct 2018 05:56:07 -0400

All, 
 
I have just uploaded version 08 <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-08> of the JSCalendar RFC draft. This draft is in WG last call and we'd like to send it to the IESG soon. 
 
The draft update includes your feedback on the mailing list and verbal discussion of some mailing list members at CalConnect XLIII:  
 
*Main changes**:* 
 * *Non-mailto URI*: To support all allowed values of iCalendar ORGANIZER and ATTENDEEs, the calendar object's replyTo property now supports non-mailto: URIs. URI templates are not supported anymore. A new Participant.sendTo property using the same value type as replyTo got defined. The email property of a Participant is optional. Participant ids must adhere to the generic id requirements, that is: only contain characters of the "URL and Filename safe" Base64 Alphabet. 
 * *Durations*: the JSEvent duration property got redefined in accordance with iCalendar. The computation of the duration must take time discontinuities in the event's start time-zone into account. The default value got changed from PT0D to PT0S. 
 * *JSON array to JSON set*: to better support partial updates, the type definitions of most multi-valued properties have been changed from JSON arrays to JSON sets. This includes the Participant roles, delegates, memberOf and linkIds properties, as well as the relatedTo property. Recurrence rules are expected to be updated as a single value, and the byXxx properties are still defined as JSON arrays. 
 
*Minor changes:* 
 * *Renamed Participant properties*: the following Participant properties got renamed to avoid ambiguity: participation to attendance, rsvpResponse to participationStatus, rsvpWanted to expectReply. 
 * *Locations*: a location with unspecified time-zone is not required to be in the calendar object's start time-zone. 
 * *Typos*: Fixed a typo in the recurrence rule definition. 
 
*Open points:* 
 * None. A "web" replyTo/sendTo method may be defined, but is not required for submission of the core spec. 
 
Cheers, 
Robert

---

From: Marten Gajda <[email-masked]>
Date: Mon, 8 Oct 2018 13:46:10 +0200

>   * *Durations*: the JSEvent duration property got redefined in
>     accordance with iCalendar. The computation of the duration must
>     take time discontinuities in the event's start time-zone into
>     account. The default value got changed from PT0D to PT0S.
>
Doesn't that conflict with the isAllDay requirement:
>    If *isAllDay* is true, then the following restrictions apply:
>
>    …
>
>    o  the *duration* property MUST only include a day component.
I mean, the default now contains a time component. Strictly spoken, this
means, you can't create all-day events with the default duration because
they would be invalid.

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743

---

From: Andri Möll <[email-masked]>
Date: Mon, 8 Oct 2018 11:51:00 +0000

On 10/8/18 11:46 AM, Marten Gajda wrote:
> I mean, the default now contains a time component. Strictly spoken, 
> this means, you can't create all-day events with the default duration 
> because they would be invalid.
How were you able to create all-day events before with P0D which also 
contains no day component? P0D = PT0S, after all.

---

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 08 Oct 2018 08:20:00 -0400

…

>> I mean, the default now contains a time component. Strictly spoken, this means, you can't create all-day events with the default duration because they would be invalid. 
>>   
> How were you able to create all-day events before with P0D which also contains no day component? P0D = PT0S, after all.  
 
The duration requirements for isAllDay are incomplete anyways: it can include day or week components. I'll update that. 
 
On P0D vs PT0S: I don't see a reason why a zero duration sub-field would signify anything but the absence of the according time unit, and vice versa. We do the same for the start LocalDate-property, which also is required to have a zero time component if isAllDay is true (as opposed to omitting the time fields). If we'd have gone with normalized durations, it might have made sense to require all zero duration fields to be omitted from the string representation, but the current spec doesn't require normalized durations. 
 
 I do agree that the spec should be more clear on that zero duration components are equivalent to their absence, and I'll take note to update the Duration type description and isAllDay restrictions accordingly. Any objections to that? 
 
 Note: in my opinion even P0W1D should be legit, but it's forbidden by the ABNF in iCalendar, so we might want to keep it at that. 
 
Cheers, 
Robert

---

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 08 Oct 2018 08:25:03 -0400

Addendum: I'm not fundamentally opposed to setting the default duration to P0D, if you think that's less ambiguous or cleaner.  
 
Changing it to P0S just was the attempt to define it in terms of the smallest allowable unit of a duration, and be more aligned with the recurrence rule expansion rules also using seconds as the smallest expandable unit.

---

From: Marten Gajda <[email-masked]>
Date: Mon, 8 Oct 2018 14:48:11 +0200

Am 08.10.2018 um 14:20 schrieb Robert Stepanek:
> The duration requirements for isAllDay are incomplete anyways: it can
> include day or week components. I'll update that.
>
> On P0D vs PT0S: I don't see a reason why a zero duration sub-field
> would signify anything but the absence of the according time unit, and
> vice versa. We do the same for the start LocalDate-property, which
> also is required to have a zero time component if isAllDay is true (as
> opposed to omitting the time fields). If we'd have gone with
> normalized durations, it might have made sense to require all zero
> duration fields to be omitted from the string representation, but the
> current spec doesn't require normalized durations.
>
> I do agree that the spec should be more clear on that zero duration
> components are equivalent to their absence, and I'll take note to
> update the Duration type description and isAllDay restrictions
> accordingly. Any objections to that?
No objections. If we're clear on what a "component" is and what it means
if it has a 0 coefficient vs. being absent I'm fine with it.

For me it would preferable to only allow a notation which contains no
"T" though. Allowing something like PT0H0M0S is just an additional
source for errors. People could come up the idea of specifying PT86400S
and argue that this equals 24 hours, "which is a day". After all, one of
the objectives of this new format is to "make it hard to get it wrong."

Having a format which is strict in cases like this makes it much easier
to argue about that.

>
> Note: in my opinion even P0W1D should be legit, but it's forbidden by
> the ABNF in iCalendar, so we might want to keep it at that.
>
> Cheers,
> Robert
>
>
>
>
>
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

---

From: Andri Möll <[email-masked]>
Date: Mon, 8 Oct 2018 13:03:51 +0000

On 10/8/18 12:48 PM, Marten Gajda wrote:
> source for errors. People could come up the idea of specifying 
> PT86400S and argue that this equals 24 hours, "which is a day". After 
> all, one of the objectives of this new format is to "make it hard to 
> get it wrong."
>
> Having a format which is strict in cases like this makes it much 
> easier to argue about that.

We're talking about a dozen and a half character regular expression here 
that covers all combinations of nominal and accurate components without 
problems. What additional errors? :P

Let people specify PT86400S as an "alias" for PT24H or PT1440M. I've 
brought up three atoms in the ISO 8601 duration specification before --- 
months, days and seconds. It's very likely a duration parser internally 
decomposes those three. Whether it chooses to round to hours and minutes 
when serializing is its thing. And I doubt most distinguish between 
nominal and accurate durations at the type level anyway, thereby if all 
three atoms are zero in the input, whether the output serializes to PT0S 
or P0D is anyone's guess and shouldn't be relied on.

---

From: Marten Gajda <[email-masked]>
Date: Mon, 8 Oct 2018 15:21:56 +0200

Am 08.10.2018 um 15:03 schrieb Andri Möll:
> Let people specify PT86400S as an "alias" for PT24H or PT1440M.
I'm not concerned about having these as aliases. That's totally fine by me.

I'm talking about people coming up with the idea to use PT86400S as an
alias for P1D for an all-day event.

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

---

From: "Neil Jenkins" <[email-masked]>
Date: Tue, 09 Oct 2018 05:46:07 -0400

I agree we need to change the spec, as it's currently inconsistent. I would propose changing 
 
If *isAllDay* is true, then the following restrictions apply:
   o  the *start* property MUST have a time component of "T00:00:00".
   o * the *duration* property MUST only include a day component.*
to this: 
If *isAllDay* is true, then the following restrictions apply:
   o  the *start* property MUST have a time component of "T00:00:00".
   o  *the *duration* property MUST not include non-zero time components (hours, minutes, or seconds).*
 
Then the default of `PT0S` is valid regardless of `isAllDay` and it mirrors the way `start` is specified. I get Marten's point that just saying only day/week components is slightly less likelihood of people making errors, but I think the difference is minimal and as Andri says, it's just as easy to verify that any time components are zero if given. 
 
Neil.

---

From: Marten Gajda <[email-masked]>
Date: Tue, 9 Oct 2018 13:54:34 +0200

Sounds reasonable to me.

Am 09.10.2018 um 11:46 schrieb Neil Jenkins:
>    o *the *duration* property MUST only include a day component.*
> to this:
> Then the default of |PT0S| is valid regardless of |isAllDay| and it
> mirrors the way |start| is specified. I get Marten's point that just
> saying only day/week components is slightly less likelihood of people
> making errors, but I think the difference is minimal and as Andri
> says, it's just as easy to verify that any time components are zero if
> given.
>
> Neil.
>
>

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]