[art] ART Area Review for draft-ietf-calext-caldav-attachments-02
Julian Reschke <julian.reschke@gmx.de> Sun, 14 May 2017 14:24 UTC
Return-Path: <julian.reschke@gmx.de>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4618812932A; Sun, 14 May 2017 07:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.899
X-Spam-Level:
X-Spam-Status: No, score=-4.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDFZQ9KGF3LD; Sun, 14 May 2017 07:24:42 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79F961201FA; Sun, 14 May 2017 07:23:57 -0700 (PDT)
Received: from [192.168.178.20] ([93.217.100.51]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M8eAd-1dxDjM0yvL-00wB2G; Sun, 14 May 2017 16:23:55 +0200
To: IETF Discussion <ietf@ietf.org>, art@ietf.org
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <c04f39e2-79d2-ab9d-59ab-26e51d7ab5fc@gmx.de>
Date: Sun, 14 May 2017 16:23:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:q1Dk5fbzBRKSa9CB+rFw6/JTwk9Td0BAfmilJFWL9t0cQG4wHhQ M2uOx/6K+uglFCdsSehCJlH/DbScGIQzuJ02GFSDME7GURy7GGFYnTMORio+UoegdupLieJ PWOP5gunn5l0pg7oB7UJnUldjxVcSyjSjFF3R34wZ6j6wy6vdWGoenWVJgaKb3iZTZKe5zv MAjwQUbqlA8j0Pdmyb0Zw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:Mz0PWO78b0g=:0uvJQyjeK6lyx65QF3x9gl BOhjR7pNQOUlJ5lhj7aBHdaTvv8m8sqotLS2hKNrMhjtu8leeBlBxOJzcXnUNdmKByCx7FLsb 6xaXJWukjylIn5fp7H3qaELAaknOKeg1JgmsRHVVxMe5PkNibsOPXtMXkt/rZmBGEoWweQjc4 XgnbDwtcSTTh/52NyPMSBWEmeqcL+5pOKdPCo8zfY9ersQSdgrP/EbnrqwSL8NMAWoPPEgkH3 VN9jsZno4uM5U67OulUWzWmyJEOMuH6Bo5XVGEZEkkcRS3ywwHNdi3pPg19xbzxq2I9UhvnKv et5VkE1V1eEEmLFffJlmIRVOty2BJOuIhke1lW0siHi0POBiu7ByLQ2L/xAtPeoUB/1++P/iJ fWpJy1tJMSqemxgkMF2wDlRh6VDEHEUZzkjNF5Z+qqrSl5V/6Nl2IvXUP3HVisIuZmLrJaLO+ T/vS9303LK9mW9TFMcZW1Pz5ooKJ8QHbrMg5DTCpN7PGi1ByzLgJkvlMabAWqar2JKaL1/PDe pED2HF7hv828e1Wjo1T4G8oTyvSdzrtHsoxFw64J4kxY2MtsUCq+00s3v8xJNi3knirMPC1cb W3022/gsOgLF76bAgm6E8+SjFkCO2yooc0ui97h8mLRTtUAQ2WRXyumYQTnPwUMs2ebNuu+kk 0j0IRjKANIX1QB534edHfk26JrRCsl5KyaZn2/jfDsYonhnh9zOWadduBSxhkkmrbgG4R0a3x QTuSgrFgHFufUOhhuAvBJOs7y1rOqMjjGn/rI91GTSc7v+lJxBG14gngJKGhoQ3+09qQWo6Ow DOy/R2X
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/dz43MoKDOwAKnn1vfN9kXF2DO-A>
Subject: [art] ART Area Review for draft-ietf-calext-caldav-attachments-02
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 14 May 2017 14:24:44 -0000
Reviewer: Julian Reschke Review result: Not Ready Document: draft-ietf-calext-caldav-attachments-02 IETF LC End Date: 2017-05-14 IESG Telechat date: 2017-05-25 This document describes attachment handling in CalDAV (WebDAV based calendaring). The mechanism described by this document is essential RPCish, using HTTP POST for tunneling. It will work in practice, but it definitively isn't state of the art in IETF protocols, in particular in an otherwise WebDAV/CalDAV-based ecosystem. Major issues: The main issue with this specification is that it 1) models operations on attachments as POST operations, where the actual type of operation is specified using a query parameter, instead of using the HTTP methods POST, PUT, and DELETE. 2) hardwires specific query strings into the protocol, violating a MUST level requirement in BCP 190 (see https://tools.ietf.org/html/rfc7320#section-2.4): Applications MUST NOT directly specify the syntax of queries, as this can cause operational difficulties for deployments that do not support a particular form of a query. For example, a site may wish to support an application using "static" files that do not support query parameters. Re 1) this is even called out specifically in Sections 3.8 (update) and 3.9 (remove), but it's not clear at all why that is the case. Re 2) Part of the hard-wiring could be avoided by using different HTTP methods for the different actions. The other parameters could be made discoverable using URIs / URI templates, exposed as WebDAV properties, as is the case in RFC 5995. 5.1. Cal-Managed-ID Response Header Field This doesn't seem to address the points listed in <https://greenbytes.de/tech/webdav/rfc7231.html#considerations.for.new.header.fields> (and it wouldn't be needed if the attachment would be modeled as an HTTP resource whose values could be reported back in a Location header field upon creation). Minor issues: 3.12.4. Processing Time Clients can expect servers to take a while to respond to POST requests that include large attachment bodies. Servers SHOULD use the "102 (Processing)" interim response defined in Section 10.1 of [RFC2518] to keep the client connection alive if the POST request will take significant time to complete. While discussing the new code 103 in the HTTP WG, we considered interop problems with existing code that doesn't handle 1xx status codes at all, or had problems with status codes other than 100. I personally support use of new 1xx status codes, but it would be good to hear whether the WG considered deployment problems when making this a SHOULD-level requirement. 3.12.5. Automatic Clean-up by servers Servers MAY automatically remove attachment data, for example to regain the storage taken by unused attachments, or as the result of a virus scanning. When doing so they SHOULD NOT modify calendar data referencing those attachments. Instead they SHOULD respond with "410 (Gone)" to any request on the removed attachment URI. This essentially requires servers to distinguish between resources that never have been there, and those which have been there but were removed. It's definitively additional work for the server, where it's not clear what the benefit for clients is. 6.1. CALDAV:managed-attachments-server-URL property This mechanism is really funky. Depending on the presence of this property, the authority part of attachment URIs is rewritten or not. Depending on its contents, the rewrite is based on yet another default or the given value. It's not clear why all this can't be replaced by a mechanism where attachment URIs can be relative references to be resolved against a base URI. Nits/editorial comments: In addition, such a server MUST support the "return=representation" Prefer header field value [RFC7240] on successful HTTP PUT and POST requests targeting existing calendar object resources, by returning the new representation of that calendar resource (including its new ETag header field value) in the response. (not specific to this spec, but to the CalDAV ecosystem: the specs rely a lot on DAV feature names, but there's no registry - I believe it would be good if we added one in a separate spec) 1. Introduction The iCalendar [RFC5545] data format is used to represent calendar data and is used with iTIP [RFC5546] to handle scheduling operations between calendar users. [RFC4791] defines the CalDAV Calendar Access protocol, based on HTTP [RFC7230], for accessing calendar data stored on a server. Maybe also mention RFC 4918 here. RFC 4918 currently isn't referenced at all, despite the fact that the specification relies on stuff defined over there, such as the "DAV" response header field.
- [art] ART Area Review for draft-ietf-calext-calda… Julian Reschke
- Re: [art] ART Area Review for draft-ietf-calext-c… Ken Murchison
- Re: [art] ART Area Review for draft-ietf-calext-c… Julian Reschke
- Re: [art] ART Area Review for draft-ietf-calext-c… Ken Murchison
- Re: [art] ART Area Review for draft-ietf-calext-c… Cyrus Daboo
- Re: [art] ART Area Review for draft-ietf-calext-c… Cyrus Daboo
- Re: [art] ART Area Review for draft-ietf-calext-c… Julian Reschke
- Re: [art] ART Area Review for draft-ietf-calext-c… Julian Reschke
- Re: [art] ART Area Review for draft-ietf-calext-c… Ken Murchison
- Re: [art] ART Area Review for draft-ietf-calext-c… Roy T. Fielding
- Re: [art] ART Area Review for draft-ietf-calext-c… Julian Reschke
- Re: [art] ART Area Review for draft-ietf-calext-c… Julian Reschke