IETF Logo Mail Archive

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

Gren Elliot <gren.elliot@synacor.com> Wed, 15 March 2017 15:16 UTC

Return-Path: <gren.elliot@synacor.com>
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 D92D913166C for <calsify@ietfa.amsl.com>; Wed, 15 Mar 2017 08:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=synacor.com
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 Rvf6QO4AZUGc for <calsify@ietfa.amsl.com>; Wed, 15 Mar 2017 08:16:34 -0700 (PDT)
Received: from smtp.corp.synacor.com (smtp.corp.synacor.com [69.168.102.214]) (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 D8D9A13166B for <calsify@ietf.org>; Wed, 15 Mar 2017 08:16:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; d=synacor.com; s=S201606; c=relaxed/simple; q=dns/txt; i=@synacor.com; t=1489590993; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=H0ErCGSADpSG4dGTnbelUYsynPA=; b=Ko2CapeXQOfO07GDajc/vE7Rc50QmINiiz76Y1t9ZrhTS8mNr5rS/vCJHAehiP9t C+urXmJ+QiRvja0oaNu3crgMnB2ZhFcLcrUitqsRS341Fgp/Y04+sWrLcjUzj79s 8gy4OWnFU1FzhMFW6+tbZqs3sba43NGT1toB2O5CQaxeMvkfHjcBw/yMbGfSz63d aLJvB/8dxoKfRw1rINMOgscjBAlnPh9ZUhBzAYaOKxfX6HjH9cvpYaWC9GdWRIQC 6X3H94HvSET5h5dmnx4mg+7eQAV2T4de+2kbH30Or5HyaRwhd09nFEV4JN20TnS5 ixaEpHuhpwnjHZu99W021w==;
X_CMAE_Category: , ,
X-CNFS-Analysis: v=2.2 cv=FZ51/926 c=1 sm=1 tr=0 a=pqTuOV7obtYyuMchBlrC0Q==:117 a=pqTuOV7obtYyuMchBlrC0Q==:17 a=48vgC7mUAAAA:8 a=WyBZRdBUlbr8mXKOQscA:9 a=QEXdDO2ut3YA:10 a=NzvyGvoxNGUA:10 a=D931NDuKWPgRrH-b:21 a=_W_S_7VecoQA:10 a=w1C3t2QeGrPiZgrLijVG:22
X-CM-Score: 0
X-Scanned-by: Cloudmark Authority Engine
X-Authed-Username: Z3Jlbi5lbGxpb3RAc3luYWNvci5jb20=
Authentication-Results: smtp02.corp.aga.synacor.com smtp.mail=gren.elliot@synacor.com; spf=pass; sender-id=pass
Authentication-Results: smtp02.corp.aga.synacor.com header.from=gren.elliot@synacor.com; sender-id=pass
Authentication-Results: smtp02.corp.aga.synacor.com smtp.user=gren.elliot@synacor.com; auth=pass (LOGIN)
Received-SPF: pass (smtp02.corp.aga.synacor.com: domain synacor.com designates 38.97.88.241 as permitted sender)
Received: from [38.97.88.241] ([38.97.88.241:17807] helo=pan.local.mail) by smtp.corp.synacor.com (envelope-from <gren.elliot@synacor.com>) (ecelerity 3.6.23.54417 r(Core:3.6.23.0)) with ESMTPA id 89/C5-03087-0DA59C85; Wed, 15 Mar 2017 11:16:32 -0400
Date: Wed, 15 Mar 2017 15:16:32 +0000
From: Gren Elliot <gren.elliot@synacor.com>
To: Ken Murchison <murch@andrew.cmu.edu>, Tobias Friedrich <tf@ox.io>, calsify@ietf.org
Message-ID: <etPan.58c95ad0.7026534d.58c@synacor.com>
In-Reply-To: <aac42a6d-c508-09b3-4202-fe0e7d22495f@andrew.cmu.edu>
References: <148943479822.20333.15175294910025553176@ietfa.amsl.com> <154978740.4223.1489587436644@app.ox.io> <aac42a6d-c508-09b3-4202-fe0e7d22495f@andrew.cmu.edu>
X-Mailer: Airmail (397)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="58c95ad0_6b8fb9b1_58c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/ZWwJxpZs9qrfeoeRxvycOaATSxQ>
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:16:36 -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 <murch@andrew.cmu.edu>
Reply: Ken Murchison <murch@andrew.cmu.edu>
Date: 15 March 2017 at 15:01:54
To: Tobias Friedrich <tf@ox.io>, calsify@ietf.org <calsify@ietf.org>
Subject:  Re: [calsify] I-D Action: draft-ietf-calext-caldav-attachments-02.txt  

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  

_______________________________________________  
calsify mailing list  
calsify@ietf.org  
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.

v2.23.0 | Report a Bug | By Email