Subject: [calsify] I-D Action: draft-ietf-calext-caldav-attachments-02.txt

From: [email-masked]
Date: Mon, 13 Mar 2017 12:53:18 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Calendaring Extensions of the IETF.

        Title           : CalDAV Managed Attachments
        Authors         : Cyrus Daboo
                          Arnaud Quillaud
                          Kenneth Murchison
	Filename        : draft-ietf-calext-caldav-attachments-02.txt
	Pages           : 33
	Date            : 2017-03-13

Abstract:
   This specification defines an extension to the calendar access
   protocol (CalDAV) to allow attachments associated with iCalendar data
   to be stored and managed on the server.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-calext-caldav-attachments/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-calext-caldav-attachments-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-caldav-attachments-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Gren Elliot <[email-masked]>
Date: Tue, 14 Mar 2017 11:15:55 +0000

The changes in the last draft look good to me.

Gren Elliot
Synacor Zimbra

From: [email-masked] <[email-masked]>
Reply: [email-masked] <[email-masked]>
Date: 13 March 2017 at 19:53:41
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject:  [calsify] I-D Action: draft-ietf-calext-caldav-attachments-02.txt  

Abstract:  

_______________________________________________  
calsify mailing list  
[email-masked]  
https://www.ietf.org/mailman/listinfo/calsify  

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.

---

From: Tobias Friedrich <[email-masked]>
Date: Wed, 15 Mar 2017 15:17:16 +0100 (CET)

We at Open-Xchange are supporting "calendar-managed-attachments", too.

Two smaller issues in the draft I stumbled across:

3. Overview: 
> In the case of the remove operation, the client can alternatively directly update the calendar object resource and remove the relevant "ATTACH" properties.

Guess a reference to the other alternative (action=attachment-remove) is missing here?

3.1 Requirements / 3.4., 3.5, 3.6 Adding, Updating, Removing Attachments
> ... such a server MUST support the "return=representation" Prefer header field value...
vs.
> ... If the client included a Prefer header field with the "return=representation" preference in the request, the server SHOULD return ... 

MUST or SHOULD?

Apart from that, the spec appears to be in a final state.

Tobias 

> [email-masked] hat am 13. März 2017 um 20:53 geschrieben:
> 
> 
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 15 Mar 2017 14:45:54 +0000

Hi, 

Thanks for the feed back. Given the feed back we received, I believe we can start a WGLC. 

That said it would be helpful that people provide feedbacks / reviews or show support individually. We try to avoid the representation of organizations as every voice counts the same in the consensus.

Yours,
Daniel   

-----Original Message-----
From: calsify [mailto:[email-masked]] On Behalf Of Tobias Friedrich
Sent: Wednesday, March 15, 2017 10:17 AM
To: [email-masked]
Subject: Re: [calsify] I-D Action: draft-ietf-calext-caldav-attachments-02.txt

vs.

MUST or SHOULD?

Tobias 

> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
>

---

From: Ken Murchison <[email-masked]>
Date: Wed, 15 Mar 2017 11:01:27 -0400

Hi Tobias,

> Guess a reference to the other alternative (action=attachment-remove) is missing here?

I will add a reference to Section 3.9 here.

> Apart from that, the spec appears to be in a final state.

Good catch.  My current thinking is that the MUST is a bit too strong 
since the protocol can be used successfully (albeit less efficiently) 
without it.  Also, preferences are just that, and a server is not 
obligated to honor it.

I'm interested in opinions on whether server support for 
Prefer:return=representation should be a MUST or SHOULD.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Gren Elliot <[email-masked]>
Date: Wed, 15 Mar 2017 15:16:32 +0000

I’m guessing that earlier drafts/implementations of this feature occurred before “return=representation” was introduced?  If so, there may be implementations in the wild which don’t honour this preference but otherwise are fully compliant with this spec (including already advertising "calendar-managed-attachments” support).
If I’m correct in this guess, then I think sticking with SHOULD is a good idea - otherwise we should probably change how the feature is advertised.

Regards,
Gren

From: Ken Murchison <[email-masked]>
Reply: Ken Murchison <[email-masked]>
Date: 15 March 2017 at 15:01:54
To: Tobias Friedrich <[email-masked]>, [email-masked] <[email-masked]>
Subject:  Re: [calsify] I-D Action: draft-ietf-calext-caldav-attachments-02.txt  

Hi Tobias,

---

From: Tobias Friedrich <[email-masked]>
Date: Tue, 21 Mar 2017 12:41:31 +0100 (CET)

> Ken Murchison <[email-masked]> hat am 15. März 2017 um 16:01 geschrieben:
> 

I'd also go for the SHOULD.

Tobias

---

From: Gren Elliot <[email-masked]>
Date: Wed, 29 Mar 2017 16:12:42 +0100

Hi,

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.