Re: [calsify] Review of draft-ietf-calext-caldav-attachments-02.txt

[Gren Elliot <[e-mail]>]

Hi,

I’m re-submitting this as I did not notice any responses to the original from 23rd March.
The subject of the previous one had ID-Action in it - perhaps that is why?

Here some more review comments after reading through the whole document:

Reviewing https://tools.ietf.org/html/draft-ietf-calext-caldav-attachments-02

1.   Not sure if this is a bug in the tools used to create the draft but
     just before the table of contents, the text
          "as described in Section 4.e of"
     actually has a hyper link to Section 4 of this document rather
     than the "Trust Legal Provisions" document.

2.   In the introduction, would benefit from a link to RFC4791 similar to
     the one for RFC7230 on the following line.

3.   In the introduction, should the description of RFC4791 be the same as
     the one used in that RFC:
         "Calendaring Extensions to WebDAV (CalDAV)"
     rather than:
         "the CalDAV Calendar Access protocol"

4.   Minor nit.  In the Introduction there is a space before the full
     stop after "managing access privileges".

5.   Section 3.3.2 rid= parameter.
     I was initially thinking about how we would deal with RECURRENCE-ID
     properties which reference TZID values with commas in them.  I now
     think that is a misunderstanding on my part - as TZID references
     would be in parameters and we only use the value of
     RECURRENCE-ID.  I think this section would benefit from an example.
     e.g.  to reference:
               'RECURRENCE-ID;TZID=America/Montreal:20120220T100000'
           use:
               'rid=20120220T100000'
     As a side question.  Are we comfortable that values will be
     unique?  Theoretically, I could imagine if 2 instances used
     different TZID parameters, they could have the same value.
     We could choose to ignore this on the basis that you shouldn't
     mix different TZID parameters in the same item?

6.   Section 3.3.3 managed-id query parameter
     Would benefit from a "(see Section 4.3) after:
     "the "MANAGED-ID" property parameter value"

7.   Section 3.4 Adding attachments. 2.A

     Would be good to explicitly state how servers should respond to
     an invalid "rid" query parameter.  I imagine this would be done
     by enhancing section 3.11 to document a precondition for a
     valid "rid" and providing a link to that from here.

8.   Section 3.5 Updating attachments. 2.A

     Would be good to explicitly reference section 3.11 on Error handling
     for how servers should respond to an invalid "managed-id" query
     parameter.

9.   Section 3.6. Removing Attachments via POST. 2.A

     Would be good to explicitly state how servers should respond to
     an invalid "rid" query parameter.  I imagine this would be done
     by enhancing section 3.11 to document a precondition for a
     valid "rid" and providing a link to that from here.

10.  Section 3.6. Removing Attachments via POST. 2.B

     Would be good to explicitly reference section 3.11 on Error handling
     for how servers should respond to an invalid "managed-id" query
     parameter.

11.  Section 3.7 Adding Existing Managed Attachments via PUT

     This suggests that servers SHOULD NOT change either tha MANAGED-ID
     or ATTACH property for any managed attachments.  Speaking for our
     server, the safest way to implement managed attachments
     would be to only allow attachment sharing within one calendar item,
     thus it is likely that we, and potentially others in the same
     situation would not follow this "SHOULD NOT" advice.  Perhaps some
     text that clients should not assume this would be wise.

12.  Section 3.11 Error Handling

     Need to document a precondition for POST that all RECURRENCE-IDs
     referenced in the "rid" query parameter must be valid.
     e.g.

     (CALDAV:valid-rid): The rid query parameter in the
      POST request MUST only contain values corresponding to valid
      "RECURRENCE-ID" properties in the iCalendar data targeted by the
      request.

13.  Section 3.11 Error Handling

     How should servers respond if an unknown value for the action= query
     parameter is specified?  Perhaps:

     (CALDAV:valid-action): The value for the action query parameter in the
     POST request is not supported by this server.

14.  Section 4.3 MANAGED-ID Property Parameter
     This documents a new ICALENDAR property.  Should there be some
     linkage to say this updates RFC5545?

15.  Section 6.  Additional WebDAV properties

     Should there be some linkage in this document to say this updates
     the CalDAV RFC4791?

Regards,
Gren Elliot of Synacor Zimbra.

This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.