CalDAV Managed Attachments
Summary: Needs a YES. Has a DISCUSS.
Alexey Melnikov (was Yes) Discuss
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?).
Deborah Brungard No Objection
Ben Campbell No Objection
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?
Suresh Krishnan No Objection
Warren Kumari No Objection
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...
Mirja Kühlewind No Objection
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.
Kathleen Moriarty No Objection
I also agree with Mirja on the document status.
Adam Roach No Objection
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.