[calsify] Re: Short re-WGLC for draft-ietf-calext-ical-tasks

[Michael Douglass <[e-mail]>]

On 10/23/24 16:19, Bron Gondwana wrote:
> Thankfully I haven't submitted this yet!  Should we add it on the 
> agenda for CALEXT at IETF in 2 weeks' time?
>
> Mike - if you can merge in this and any other suggestions you've seen, 
> we can hopefully get this thing done this year!

I shall do that.

Also we had a chat this morning and came up with some agenda items:

1. the iTip with participants spec

2a. Vpoll

2b. jsCalendar <-> iCalendar

The second 2 can be any order but it seemed to make sense to do #1 first 
as the other 2 now depend on it to some extent.

>
> Bron.
>
> On Wed, Oct 23, 2024, at 08:40, Robert Stepanek wrote:
>> If there is still a chance, I would prefer for this RFC to update its 
>> modification of the PARTICIPANT property in section 10:
>>
>> Currently, the PARTICIPANT component definition in RFC 9073, section 
>> 7.1. does not explicitly mention the PERCENT-COMPLETE property (RFC 
>> 5545, 3.8.1.8). As a consequence, a PARTICIPANT component may include 
>> multiple PERCENT-COMPLETE properties. I think this is an oversight. 
>> Just as the PARTICIPANT already is restricted to only have at most 
>> one DTSTAMP property, it should also just allow one PERCENT-COMPLETE 
>> property.
>>
>> As draft-ietf-calext-ical-tasks updates the VTODO-related semantics 
>> of iCalendar and already includes a section that updates the 
>> PARTICIPANT component definition, it looks to be the best place to 
>> also add this requirement.
>>
>> On Thu, Oct 3, 2024, at 12:44 PM, Robert Stepanek wrote:
>>> The IANA registry item in section 17.1.6. 
>>> <https://www.ietf.org/archive/id/draft-ietf-calext-ical-tasks-10.html#name-properties-registry> 
>>> for the ESTIMATED-DURATION property is wrong:
>>>
>>> It registers "ESTIMATED_DURATION" but the name is 
>>> "ESTIMATED-DURATION" (underscore vs hyphen).
>>>
>>> Cheers,
>>> Robert
>>>
>>> On Wed, Jul 31, 2024, at 5:07 AM, Michael Douglass wrote:
>>>>
>>>> Finally got round to this. Individual responses below and I've just 
>>>> posted version 10
>>>>
>>>> Thank you.
>>>>
>>>> On 6/20/24 03:35, Robert Stepanek wrote:
>>>>> Overall critique:
>>>>>
>>>>> I stand by my critique that I also raised in my review of version 
>>>>> 05 
>>>>> <https://mailarchive.ietf.org/arch/msg/calsify/c48tM54VQvY5sOh-DToregJ01gk/>: 
>>>>> I not only find the Architecture sections 2. to 4. unnecessary but 
>>>>> even detrimental for this specification.  The functional 
>>>>> architecture for task management systems might better be defined 
>>>>> in a separate document.
>>>>>
>>>>> I think that this specification would be simpler to read if it 
>>>>> gets condensed to the actual changes it brings to iCalendar. It 
>>>>> would benefit from being more in line with other RFCs that define 
>>>>> iCalendar extensions, such as RFC 9073 
>>>>> <https://www.rfc-editor.org/info/rfc9073>, RFC 9253 
>>>>> <https://www.rfc-editor.org/info/rfc9253> or RFC 7953 
>>>>> <https://www.rfc-editor.org/info/rfc7953> (all by the same authors 
>>>>> as draft-ietf-calext-ical-tasks). These RFCs all define their 
>>>>> content in terms of iCalendar, rather than introducing a new 
>>>>> document structure, terminology and process model.
>>>>>
>>>>> This critique is not a veto, but rather a call for caution.
>>>>
>>>> Obviously I disagree. For newcomers to these specifications or to 
>>>> those who view VTODO as only useful for reminders etc, these 
>>>> sections show how the tasks component can be used.
>>>>
>>>>>
>>>>> -- Details and Nits:
>>>>>
>>>>> Abstract
>>>>>
>>>>> "Task" is used in the Abstract and Introduction before it is 
>>>>> introduced as 'A "task" is a representation of an item of work 
>>>>> assigned to an individual or organization'. The Abstract would be 
>>>>> clearer if it already defines what kind of "tasks" this 
>>>>> specification is all about.
>>>>
>>>> I sort of agree but I'm not sure I can get away without using the 
>>>> word "task"
>>>>
>>>> I've replaced this:
>>>>
>>>> ----------------------- OLD
>>>>
>>>> This document updates and defines extensions to the Internet
>>>> Calendaring and Scheduling Core Object Specification (iCalendar)
>>>> (RFC5545) to provide improved status tracking, scheduling and
>>>> specification of tasks.
>>>>
>>>>
>>>> ----------------------------
>>>>
>>>> with this
>>>>
>>>> ----------------------- NEW
>>>>
>>>> The Internet Calendaring and Scheduling Core Object Specification 
>>>> (iCalendar) (RFC5545) VTODO calendar component has been seen as the 
>>>> poor relation of VEVENT - useful only for personal reminders and 
>>>> to-do lists.
>>>>
>>>> This document updates and defines extensions to VTODO to provide 
>>>> improved status tracking, scheduling and specification of tasks to 
>>>> allow its use in pther contexts, such as process control and 
>>>> project management.
>>>>
>>>>
>>>> -----------------------------
>>>>
>>>>
>>>>>
>>>>> Introduction
>>>>> Make "ad-hoc tasks in personal to-do- lists" also a bullet?
>>>>
>>>> I don't think so - the text reads
>>>>
>>>> Tasks can be identified in a number of situations, either informally as ad-hoc tasks in personal "to-do" lists or more formally in:
>>>>
>>>>
>>>> I think the point here is that ad-hoc tasks is th einformal 
>>>> accepted usage and the others are example sof what we'd like to see.
>>>>
>>>>>
>>>>> 1.1 Terms and Definitions
>>>>> "All calendar components start with the letter "V"." Disputable, 
>>>>> because the "PARTICIPANT" component  of RFC 9073 does not start 
>>>>> with "V".
>>>> True - we also have the AVAILABLE component. I made a significant 
>>>> number of changes to try to make naming more consistent
>>>>>
>>>>> Properties defined by [RFC5545]: nit - this doesn't like look a 
>>>>> properly formatted reference.
>>>> It wasn't - fixed
>>>>>
>>>>> "Resources can be of "Location", "Equipment", or "Role" type." 
>>>>> Where is this enumeration defined? If it isn't defined in this 
>>>>> specification, then restricting it to these three values might be 
>>>>> incorrect now or in the future.
>>>> This was intended to point out that a resource may be of many 
>>>> different types. Genrealised and removed some quotes.
>>>>>
>>>>> Section 9.1 and 9.2:
>>>>> Could the VSTATUS example be moved to section 9.1? Are both 
>>>>> VSTATUS and PARTICIPANT/ATTENDEE necessary to be in the same 
>>>>> example in section 9.2?
>>>> Split them up - was not intentional
>>>>>
>>>>> Section 9.1:
>>>>> "Note that while VSTATUS is intended to allow multiple 
>>>>> date-stamped status changes to be stored it is not intended to be 
>>>>> used as a history of changes to a tasks properties".
>>>>>
>>>>> I had to pause when I read this and its meaning only become more 
>>>>> clear to me after having read section 9.2 to 9.3 and their 
>>>>> examples. Maybe something like "instead, the purpose of VSTATUS is 
>>>>> to document changes related to fulfilling the tasks" could help?
>>>>
>>>> I moved 9.2 to after the following subsection which I think helps 
>>>> and moved the above modified  text to the end of  the "Comments 
>>>> associated to reasons and status changes" section.
>>>>
>>>> ----------------------- OLD
>>>>
>>>> Note that while VSTATUS is intended to allow multiple date-stamped 
>>>> status changes to be stored it is not intended to be used as a 
>>>> history of changes to a tasks properties.
>>>>
>>>> ----------------------------
>>>>
>>>> ----------------------- NEW
>>>>
>>>>
>>>> Note that the "VSTATUS" calendar component not intended to be used 
>>>> as a history of changes to a tasks properties. The purpose of 
>>>> "VSTATUS" calendar component is only to document changes related to 
>>>> fulfilling the tasks
>>>> ---------------------------
>>>>
>>>>
>>>>>
>>>>> Section 9.4:
>>>>> This section feels out of place, as it seems to be more related to 
>>>>> the architecture than actual iCalendar changes. If I read this 
>>>>> section correctly, it seems to say: "Everything that's required 
>>>>> from iCalendar implementations already is supported (alarms, 
>>>>> notifications) and the rest is out of scope (escalations)."
>>>> I'm not sure. Notifications and escalations are tightly related to 
>>>> status changes and this section points out that some calendar 
>>>> constructs (e.g. alarms) may not work as expected.
>>>>>
>>>>> Section 10:
>>>>> Maybe also mention RFC 9073 here, as it had added the 
>>>>> "participantc *locationc *resourcec" components?
>>>> Done
>>>>>
>>>>> Section 12.1:
>>>>> Maybe explicitly require in Description that the duration MUST be 
>>>>> zero or positive.
>>>>
>>>> We already have this:
>>>>
>>>> Purpose  This property specifies the estimated positive duration of
>>>>     time the corresponding task will take to complete.
>>>>
>>>>
>>>>>
>>>>> Section 12.3:
>>>>> Does SUBSTATE require a STATUS property to be present in the same 
>>>>> component? I guess it should?
>>>> The VSTATUS definition in section 14.1 requires STATUS
>>>>>
>>>>> Section 12.4.:
>>>>> The line ";if all attendees have completed" in the ABNF seems out 
>>>>> of place? Is it actually supposed to visually separate 
>>>>> AUTOMATIC-COMPLETION from the rest of enumeration values?
>>>> Fixed
>>>>>
>>>>> The Examples section should go at the end of this section, not 
>>>>> separate the paragraph introducing the enumeration values from 
>>>>> their definitions.
>>>> Fixed
>>>>>
>>>>> What's supposed to happen if TASK-MODE is "CLIENT,SERVER"? Also, 
>>>>> does "SERVER" have precedence over the "AUTOMATIC" values?
>>>>
>>>> Changed this. Property can only appear zero or once in VTODO. Only 
>>>> a single value allowed. Added an extra value of "AUTOMATIC" which 
>>>> does both completion and failure. Completion and failure imply CLIENT.
>>>>
>>>>
>>>> ----------------------- OLD
>>>>
>>>> Conformance  This property can be specified zero or more times in a
>>>>     "VTODO" calendar component.
>>>>
>>>> Format Definition  This property is defined by the following
>>>>     notation:
>>>>
>>>> task-mode   = "TASK-MODE taskmodeparam ":" taskvalue
>>>>                *("," taskvalue) CRLF
>>>>
>>>> taskvalue   = "AUTOMATIC-COMPLETION" ; set STATUS completed
>>>>                  ;if all attendees have completed
>>>>                  / "AUTOMATIC-FAILURE"
>>>>                  / "SERVER"
>>>>                  / "CLIENT"
>>>>                  / iana-token
>>>>                  / x-name
>>>>
>>>> taskmodeparam      = *(";" other-param)
>>>>
>>>>
>>>> -----------------------
>>>>
>>>> ----------------------- NEW
>>>>
>>>>
>>>> -----------------------
>>>>
>>>> Additionally this text has been removed
>>>>
>>>> -----------------------
>>>>
>>>> The server can add this property to a "VTODO" calendar component to indicate to
>>>> the client that it will be managing the status.
>>>>
>>>>
>>>> -----------------------
>>>>
>>>> and a statement that the default mode is "CLIENT" added. This 
>>>> preserves the current state.
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Section 13.1:
>>>>> The first sentence and probably also the title should make clear 
>>>>> this change only relates to VTODO.
>>>> Done
>>>>>
>>>>> _______________________________________________
>>>>> calsify mailing list [e-mail] <mailto:[e-mail]>
>>>>> To unsubscribe send an email [e-mail] <mailto:[e-mail]>
>>>>>
>>>
>>> _______________________________________________
>>> calsify mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>
>> _______________________________________________
>> calsify mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>
> --
>   Bron Gondwana, CEO, Fastmail Pty Ltd
> [e-mail]
>
>