Subject: [calsify] Updated JSCalendar draft calext-01

From: Robert Stepanek <[email-masked]>
Date: Fri, 02 Mar 2018 10:38:35 +0100

Hi all,

right before the IETF-101 draft submission deadline, I've uploaded
version 01[1] of the JSCalendar draft.
There has only been one change to the document:
 * *bySetPosition* *property*: The recurrenceRule type mistakenly did
   not include the BYSETPOS parameter of the RFC5545 RRULE. It now
   defines the bySetPosition property (see section 4.3.1[2]).
As always, please let me know of any feedback.

Cheers,
Robert

Links:

  1. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-01
  2. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-01#section-4.3.1

---

From: Adrian Apthorp <[email-masked]>
Date: Sat, 3 Mar 2018 18:56:12 +0800

Robert,

I just noticed that the description of 5.2.8 status is incorrect.

> The scheduling status (Section 4.4 
> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-01#section-4.4>) of a JSTask defaults to "needs-
>     action" if omitted.

Given the possible values it should actually be the overall progress 
status of a JSTask. Of course the distinction with "5.2.7 progress" 
needs to be clear as the individual participants progress.

With this is there the opportunity to include the two new task status 
values as per draft-apthorp-ical-tasks-01.txt and also revise 
"completed" to be a general purpose status change timestamp.

Cheers

Adrian

On 02/03/18 17:38, Robert Stepanek wrote:
> version 01 
> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-01> of the 
> JSCalendar draft.
>
>     defines the bySetPosition property (see section4.3.1
>     <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-01#section-4.3.1>).
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Robert Stepanek <[email-masked]>
Date: Mon, 05 Mar 2018 11:51:17 +0100

Hi Adrian,

I just uploaded a new draft.

>  I just noticed that the description of 5.2.8 status is incorrect.

It was defined to be backwards-compatible with iCalendar RFC 5545.
Considering the RFC updates in draft-apthorp-ical-tasks I agree it makes
sense to redefine them also in JSCalendar.
>> The scheduling status (Section 4.4[1]) of a JSTask defaults to "needs-
>> action" if omitted.> 
Done. Please note that my changes are more a basis for discussion than a
final decision, considering the deadline for IETF 101 today.
>  "completed" to be a general purpose status change timestamp.
I'm not sure what change you have in mind for the COMPLETED property? I
could imagine it to be confusing to track general update time-stamps
given the property name?
Cheers,
Robert

Links:

  1. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-01#section-4.4

---

From: Adrian Apthorp <[email-masked]>
Date: Tue, 6 Mar 2018 21:09:41 +0800

Robert,

Thanks - a couple of comments below:

> On 5 Mar 2018, at 6:51 PM, Robert Stepanek <[email-masked]> wrote:
> 
> Hi Adrian,
> 
> It was defined to be backwards-compatible with iCalendar RFC 5545. Considering the RFC updates in draft-apthorp-ical-tasks I agree it makes sense to redefine them also in JSCalendar.

Understood. However, 5545 does not describe the purpose to indicate the scheduling status of a task. I was suggesting to reword the purpose.

> 
>>> The scheduling status (Section 4.4) of a JSTask defaults to "needs-
>>>    action" if omitted.
>> 
>> Given the possible values it should actually be the overall progress status of a JSTask. Of course the distinction with "5.2.7 progress" needs to be clear as the individual participants progress.
> 
> Done. Please note that my changes are more a basis for discussion than a final decision, considering the deadline for IETF 101 today.

I think the only comment I have is not to define the rules for how a participant progress propagates to the task status. These are likely to be business rules that are determined by the organiser or defined for a specific type of task. They can be manually applied or automated.

> 
>> With this is there the opportunity to include the two new task status values as per draft-apthorp-ical-tasks-01.txt and also revise "completed" to be a general purpose status change timestamp. 
> 
> I'm not sure what change you have in mind for the COMPLETED property? I could imagine it to be confusing to track general update time-stamps given the property name?

Yes, I didn’t complete the thought in my original message. What I was thinking was to rename this property (status-changed) and then it becomes applicable to all status changes. Presumably it can still be mapped to 5545 COMPLETED when that status is achieved.

Cheers

Adrian