Skip to main content

Calendaring Extensions to WebDAV (CalDAV): Managed Attachments
draft-ietf-calext-caldav-attachments-04

Yes


No Objection

(Deborah Brungard)
(Suresh Krishnan)

Note: This ballot was opened for revision 03 and is now closed.

Warren Kumari
No Objection
Comment (2017-08-15 for -03) Unknown
I agree with Mirja's concerns / confusion on the change from PS to Informational. I read the background / shepherds write-up with explains this, but am still not hugely comfortable with the situation -- if it is PS material, and is implemented by a number of folk, PS seems acceptable -- but then again, I fully get the desire to just get it shipped and done.

I had thought that I'd made some notes somewhere on an earlier version, but can no longer find them. I'm fairly sure that they were written on a plane heading somewhere, and were only minor nits, so...
Alexey Melnikov Former IESG member
(was Discuss, Yes) Yes
Yes (2019-03-25) Not sent
My former DISCUSS text:

IANA Considerations need to mention that this document allows for Content-Disposition header field to be used in HTTP requests. RFC 6266 only defined its use for HTTP responses.

Also, the IANA Expert Reviewer has mentioned:

I would like section 4.3. MANAGED-ID Property Parameter to clarify the scope of uniqueness of the MANAGED-ID values (e.g., globally unique like UID, unique per iCalendar component? unique per VEVENT?).
Adam Roach Former IESG member
No Objection
No Objection (2017-08-16 for -03) Unknown
Regarding concerns from others on the topic of document status: even without the ARTART review, I would have DISCUSSed the top-level issues identified by Julian, and in particular the hardcoding of query strings. I would be quite uncomfortable with the precedent of a PS document going out in that form. I'm a little squeamish about having it in an Informational document, but given the apparently pervasive deployment indicated by section 7, I suppose it's better to have it documented than not.

Section 3.2 is ambiguous about whether the use of "calendar-managed-attachments-no-recurrance" is in addition to or instead of "calendar-managed-attachments." In this sentence, please replace "the server MUST include" with "the server MUST also include" or "the server MUST instead include", depending on what is intended here.

I'd be happy if section 3.12.3 indicated that such redirects are performed with 307 or 308 responses, as other redirect codes change the method from POST to GET.

Presumably, when section 7 is removed, section 11.3 is to also be removed? The document should indicate this.

Please expand iTIP (iCalendar Transport-independent Interoperability Protocol) on first use.
Ben Campbell Former IESG member
No Objection
No Objection (2017-08-16 for -03) Unknown
Loosely related to Mirja's comment:

The abstract mentions why this is informational. That information should be repeated in the Introduction. It would be helpful to see that expanded (in the introduction) to explain what the non-standard bits are, and if there are preferred approaches (whether standards or potential standards.)

- 3.12.2: "Access to the managed attachments store in a calendar object resource
   SHOULD be restricted to only those calendar users who have access to
   that calendar object either directly, or indirectly (via being an
   attendee who would receive a scheduling message)."

Why not MUST? When might it make sense to allow others to access attachments?
Deborah Brungard Former IESG member
No Objection
No Objection (for -03) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2017-08-16 for -03) Unknown
I also agree with Mirja on the document status.
Mirja Kühlewind Former IESG member
No Objection
No Objection (2017-08-14 for -03) Unknown
To be honest I find the solution to publish this as informational a bit strange given it is implemeted and deployed. However, this is really not my expetise.
Suresh Krishnan Former IESG member
No Objection
No Objection (for -03) Unknown