Re: [calsify] draft-ietf-calext-ical-tasks-03 Review

[Michael Douglass <[e-mail]>]

Sorry for missing this.

I've just published a new draft (06) with just these points covered to 
try to preserve section numbering as much as possible.

After that I'll publish a version which removes most of the sections 
which we feel are more appropriate elsewhere as a model definition.

  See changes below.

On 3/29/22 08:08, Joris Baum wrote:
>
> Hi,
>
>
> I just had a look at the draft-ietf-calext-ical-tasks-03 spec. In 
> general, it looks good to me. Most of my comments are small things 
> which might or might not require some more clarification.
>
> General note: Typically, collaborative software development tools 
> allow tracking the changes to any task property. Such a 
> "history"-feature is most likely out of scope for that draft, but it 
> looks like `VSTATUS` could be used (to some extent) for that feature. 
> Maybe it would make sense to state in the draft that tracking history 
> of all properties is not covered by the spec?
>
Text added to section 10.1

---- Begin

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 propertie

---- End

> Section 4:
>
>   * Task Actors mentions "Organizer" as an actor. In the picture, it
>     is not part of that group. I suggest to either leave it out in the
>     text or change the group name in the picture (probably the latter).
>   * The Task Actors roles seem to be purely informational. Maybe it
>     would make sense to specify how they are supposed to be mapped to
>     an iCalendar equivalent, like `ORGANIZER`?
>
I think they are defined in terms and definitions? I've added the text "

Often represented as an attendee with ROLE=NON-PARTICIPANT.

to the Observer definition.

> Section 12.2:
>
>   * A "name-space" is mentioned, but it seems to be not defined what a
>     "name-space" should look like.
>   * When using IANA registered values for `REASON` as done in one of
>     the examples (`REASON:out-of-office`) do not seem to be of `URI`
>     type. I guess that is not in line with its definition?
>
I think I would be inclined to change the text

----- OLD -----

Typically, reasons are defined within the
context of the task type and therefore SHOULD include the name-space
of the authority defining the task. Common reason codes are IANA
registered and do not have a name-space prefix.

----- NEW -----

Often, reasons are defined within the context of the task type and therefore SHOULD
specify the authority defining the task either with a urn namespace or a URL referencing
the domain of the authority.

-------------

Or something of that kind. However as it stands this definition is just 
wrong as you suggest - it doesn't allow for a simple text value.

I thought maybe the best fix for the values would be to specify the 
registered values as a urn - however that got me into reading rfcs 2648 
and 6924 at least which leads me to believe there is no registered urn 
namespace for values such as this.

Perhaps change the value type to text and use the opposite of the 
approach defined for TZID, i,e

REASON: out-of-office

references a value defined in the IANA registry

REASON:/example.org/sprung-a-leak

uses a value defined at example.org

I think this needs further discussion...

>
> The following are probably merely minor notes (about spelling, style 
> and copy+paste errors). You would probably have found them yourself 
> before a WGLC, but I think it does not hurt to include them:
>
> Section 7.2:
>
>   * "See section 3.1.3 Task Domain Data Handling." You probably meant
>     section 7.3 ?
>
Yes - fixed the reference
>
>   * "Extensions [Doug114] to the RELATED-TO" Reference not included.
>     You probably meant draft-ietf-calext-ical-relations ?
>
Fixed
>
>   * REL is used as a param in the examples, e.g.
>     `LINK;REL="vacation-system";VALUE=URI:http://example.com/vacation-approval?id=1234`.
>     But it is not part of draft-ietf-calext-ical-relations. I guess it
>     comes from an earlier version of the spec?
>
Fixed - it became LINKREL
>
> Section 9: "In addition a number of different patterns of resource or 
> assignee identification are anticipated." - "In addition, a number of 
> different patterns of resource or assignee identification are 
> anticipated." (very minor, but it confused me for a short while)
>
Was removed as a result of other changes.
>
> Section 10.3: "As situations chnage further VSTATUS components" → "As 
> situations change further VSTATUS components"
>
Fixed
>
> Section 10.4:
>
>   * "Alarms (VLARM components)" → "Alarms (VALARM components)"
>
Fixed
>
>   * "Task Generating System, e.g., a BPMS" → Maybe specify what a BPMS
>     is. However, Wikipedia seems to understand it.
>
Done
>
> Section 19: I am unable to open or find the [TARCH] reference?
>
The intent was to create such a document. I will create one using the 
sections which will be removed from this document and then update the 
reference.
>
>
> Regards,
>
> Joris
>
>
> -- 
> Joris Baum
> Tel: [phone]
> Fax: [phone]
>
> http://www.audriga.com  |http://www.twitter.com/audriga
>
> --------------------------------------------------------------------------
> audriga GmbH | Alter Schlachthof 57 | 76137 Karlsruhe
> Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
> Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
> --------------------------------------------------------------------------
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify