Re: [calsify] WGLC feedback for draft-ietf-calext-ical-tasks-05

On 12/1/22 07:02, Robert Stepanek wrote:
> First, my apologies for waiting until last call for a thorough re-read 
> of the document.

And mine  for taking so long to address these comments.

My intent is to first address the corrections and detail comments in 
this and other responses.

After communications with Adrian we both feel that the sections on 
architecture and terminology do belong in a separate document. Once 
we've dealt with the other issues I'll move them elsewhere and adjust 
accordingly. I'm holding off on this mostly to maintain the current 
section numbering for the time being.

I'll also reply in chunks as I think there might be some discussion 
needed on a couple of points.

>
> I support the proposals in this RFC.
>
> I have a few remarks about its definitions.I think the RFC 
> presentation could be improved. For details, see below.
>
> *Feedback on definitions:*
>
>   * Section 7.2: the REL parameter in the example is not defined, it
>     should read LINKREL as defined in RFC 9253.
>
Fixed
>
>   * Section 7.3: it's unclear why LINK is the better choice over
>     ATTACH in these examples. Even the text in this section talks
>     about "attachments".
>
LINK provides typed references to associated data and services which is 
really what's intended here. I'll change the text to remove the 
attachment related text:

------- OLD -------

The LINK property can be used to 'attach' the domain specific data to
the task.  For example, it might be a URI pointing to a web page
where the status of the task can be directly manipulated.

LINK;REL="vacation-system";VALUE=URI:http://example.com/
vacation-approval?id=1234

Or it might be used for attachments specific to the task, for example
an electronic copy of a signature taken to confirm delivery of a
package.

LINK;REL="electronic-signature";VALUE=URI:http://example.com/
delivery/sig1234.jpg

------- NEW -------

The LINK property can be used to relate a domain specific service to the 
task. For example, it might be a URI pointing to a web page where the 
status of the task can be directly manipulated.

LINK;LINKREL="vacation-system";VALUE=URI:http://example.com/
vacation-approval?id=1234

Additionally, it might be used to link data specific to the task, for 
example an electronic copy of a signature taken to confirm delivery of a 
package.

LINK;LINKREL="electronic-signature";VALUE=URI:http://example.com/
delivery/sig1234.jpg

--------END -------

>   * Section 12.3: The examples for SUBSTATE confused me:
>       o First example: What does SUBSTATE:ERROR tell more than
>         STATUS:FAILED?
>       o Second example: Wouldn't a SUSPENDED value for STATUS be more
>         appropriate?
>
I'm not sure where the examples originally came from but the second 
aligns almost exactly with what's described here: 
https://blogs.sap.com/2020/10/26/sap-s-4hana-cfin-sub-statuses-for-in-process-documents-in-sap-aif-error-monitor/

Note they added substatus in 2020

I think the point of a less detailed status is that it triggers the same 
response for all sub-statuses, e.g. for IN-PROCESS the assumption is 
that wait long enough and it will complete. You only look at the 
sub-status if you want to know why it's taking so long.

I guess the first doesn't seem to add much more but again STATUS:FAILED 
say's it's not going to complete. SUBSTATUS:ERROR is the catch-all 
substatus. We could define more - if we do what I suggest below then 
SUBSTATUS:/eg/nobody-home might be better

However - it does seem that the values for substatus (and perhaps 
status) can be very domain specific. I'm not sure that opening up a 
registry necessarily helps here. It's probably good to define a bunch of 
fairly generic values but some may be very specific to a service.

The usual way out of that is to specify the value as a uri, e.g.

SUBSTATUS;VALUE=URI:https://mydomain.org/substatus-defs/waiting-for-process

On the other hand is it possible to perhaps define a prefixed text string

So looking back at the blog post above we could have

SUBSTATUS:/SAP/Blocked by predecessor

On the other hand we could just specify this as a free form string that 
SHOULD have some definition as to its meaning?

Thoughts on this one?

>
>
>
> _______________________________________________
> calsify mailing list
> calsify@ietf.org
> https://www.ietf.org/mailman/listinfo/calsify