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

[Joris Baum <[e-mail]>]

Hi Mike,

no worries. Thanks for addressing my comments :) .

Replied inline for some of the the potentially discussion-worthy points.


On 20.02.23 05:23, Michael Douglass wrote:
>>
>> 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.
>
My main concern here was that the definitions did not entirely match the 
"Task architecture diagram". Since you are moving that to a separate 
document, adding that text should cover it all.
>
>> 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...
>
I think both approaches sound sane. However, changing the value type to 
"text" sounds like a less disruptive approach, so I would vote for that one.


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
--------------------------------------------------------------------------