IETF Logo Mail Archive

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

Ken Murchison <murch@andrew.cmu.edu> Wed, 15 March 2017 15:01 UTC

Return-Path: <murch@andrew.cmu.edu>
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DCC1315F8 for <calsify@ietfa.amsl.com>; Wed, 15 Mar 2017 08:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 6YcvMCnXTSRG for <calsify@ietfa.amsl.com>; Wed, 15 Mar 2017 08:01:48 -0700 (PDT)
Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.157.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B68131610 for <calsify@ietf.org>; Wed, 15 Mar 2017 08:01:30 -0700 (PDT)
Received: from [172.31.24.160] (VPN-172-31-24-160.VPN.CMU.LOCAL [172.31.24.160]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.15.2/8.15.2) with ESMTPSA id v2FF1Rlj025315 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 Mar 2017 11:01:28 -0400
To: Tobias Friedrich <tf@ox.io>, calsify@ietf.org
References: <148943479822.20333.15175294910025553176@ietfa.amsl.com> <154978740.4223.1489587436644@app.ox.io>
From: Ken Murchison <murch@andrew.cmu.edu>
Organization: Carnegie Mellon University
Message-ID: <aac42a6d-c508-09b3-4202-fe0e7d22495f@andrew.cmu.edu>
Date: Wed, 15 Mar 2017 11:01:27 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <154978740.4223.1489587436644@app.ox.io>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-PMX-Version: 6.3.0.2556906, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.3.15.145415
X-SMTP-Spam-Clean: 10% ( TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1300_1399 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, REFERENCES 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_VERSION 0, __MOZILLA_USER_AGENT 0, __NO_HTML_TAG_RAW 0, __PHISH_SPEAR_STRUCTURE_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT2 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __USER_AGENT 0)
X-SMTP-Spam-Score: 10%
X-Scanned-By: MIMEDefang 2.78 on 128.2.157.38
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/emkeHNqwyrI8ZI1Wk7OTEyu4j-Y>
Subject: Re: [calsify] I-D Action: draft-ietf-calext-caldav-attachments-02.txt
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Mar 2017 15:01:50 -0000

Hi Tobias,


On 03/15/2017 10:17 AM, Tobias Friedrich wrote:
> 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?

I will add a reference to Section 3.9 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.

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

v2.23.0 | Report a Bug | By Email