Re: [calsify] I-D Action: draft-ietf-calext-caldav-attachments-02.txt
Gren Elliot <gren.elliot@synacor.com> Wed, 29 March 2017 15:12 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 160BB12954C for <calsify@ietfa.amsl.com>; Wed, 29 Mar 2017 08:12:46 -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 oGicD3u2Bau2 for <calsify@ietfa.amsl.com>; Wed, 29 Mar 2017 08:12:43 -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 76C36127599 for <calsify@ietf.org>; Wed, 29 Mar 2017 08:12:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; d=synacor.com; s=S201606; c=relaxed/simple; q=dns/txt; i=@synacor.com; t=1490800362; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=gV/s7XJbl/KQCi29Uj5/VjxYg0c=; b=ko2icBbgQGtx7lhLHs3AdLpdUkv8CuXxlLA7pjCiddilOv/B0te5ijo8ZfRYfWjq i7AT/QxgWy/vje/VrOo3+ipBs3Oe64ZHbasGR8Mo1HeubsyyTt6AnGm3dN86D1P/ C7H1ZvG/4LRcNF6RSiefrupQK6QlacWgKpkpjy4IQz1DJIt8IiDz0hqb3Uvu+iFC waYhu3q6b6yJiQAXQleS1MN+H2IDgfiKDuowgvOsHDz7mP7nvEjz0H9hLf5zQNyN PjCFLzYMTDUCZS0hNDrOYH7gpbW8QHK0OG+PC9xHfjBHLuh+/Gaq80v520el39tk AcqLdbKK7yJfB3nhTjHwBQ==;
X_CMAE_Category: , ,
X-CNFS-Analysis: v=2.2 cv=fo6eXxwf c=1 sm=1 tr=0 a=pqTuOV7obtYyuMchBlrC0Q==:117 a=pqTuOV7obtYyuMchBlrC0Q==:17 a=48vgC7mUAAAA:8 a=fMwQw_I6VK1IENayruwA:9 a=QEXdDO2ut3YA:10 a=Q0jImbJWXe5Z-ODh6U0A:9 a=ppnwKAlkqZV3_-5q: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: smtp01.corp.aga.synacor.com header.from=gren.elliot@synacor.com; sender-id=pass
Authentication-Results: smtp01.corp.aga.synacor.com smtp.mail=gren.elliot@synacor.com; spf=pass; sender-id=pass
Authentication-Results: smtp01.corp.aga.synacor.com smtp.user=gren.elliot@synacor.com; auth=pass (LOGIN)
Received-SPF: pass (smtp01.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:19075] 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 81/02-25240-9EECBD85; Wed, 29 Mar 2017 11:12:42 -0400
Date: Wed, 29 Mar 2017 16:12:42 +0100
From: Gren Elliot <gren.elliot@synacor.com>
To: calsify@ietf.org, Ken Murchison <murch@andrew.cmu.edu>
Message-ID: <etPan.58dbceea.78dc43e6.460@synacor.com>
In-Reply-To: <148943479822.20333.15175294910025553176@ietfa.amsl.com>
References: <148943479822.20333.15175294910025553176@ietfa.amsl.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="58dbceea_d73544_460"
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/eAmbUW0R7bceV6jUMegVfZIGyXk>
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, 29 Mar 2017 15:12:46 -0000
Hi, Here some more review comments after reading through the whole document: Reviewing https://tools.ietf.org/html/draft-ietf-calext-caldav-attachments-02 1. Not sure if this is a bug in the tools used to create the draft but just before the table of contents, the text "as described in Section 4.e of" actually has a hyper link to Section 4 of this document rather than the "Trust Legal Provisions" document. 2. In the introduction, would benefit from a link to RFC4791 similar to the one for RFC7230 on the following line. 3. In the introduction, should the description of RFC4791 be the same as the one used in that RFC: "Calendaring Extensions to WebDAV (CalDAV)" rather than: "the CalDAV Calendar Access protocol" 4. Minor nit. In the Introduction there is a space before the full stop after "managing access privileges". 5. Section 3.3.2 rid= parameter. I was initially thinking about how we would deal with RECURRENCE-ID properties which reference TZID values with commas in them. I now think that is a misunderstanding on my part - as TZID references would be in parameters and we only use the value of RECURRENCE-ID. I think this section would benefit from an example. e.g. to reference: 'RECURRENCE-ID;TZID=America/Montreal:20120220T100000' use: 'rid=20120220T100000' As a side question. Are we comfortable that values will be unique? Theoretically, I could imagine if 2 instances used different TZID parameters, they could have the same value. We could choose to ignore this on the basis that you shouldn't mix different TZID parameters in the same item? 6. Section 3.3.3 managed-id query parameter Would benefit from a "(see Section 4.3) after: "the "MANAGED-ID" property parameter value" 7. Section 3.4 Adding attachments. 2.A Would be good to explicitly state how servers should respond to an invalid "rid" query parameter. I imagine this would be done by enhancing section 3.11 to document a precondition for a valid "rid" and providing a link to that from here. 8. Section 3.5 Updating attachments. 2.A Would be good to explicitly reference section 3.11 on Error handling for how servers should respond to an invalid "managed-id" query parameter. 9. Section 3.6. Removing Attachments via POST. 2.A Would be good to explicitly state how servers should respond to an invalid "rid" query parameter. I imagine this would be done by enhancing section 3.11 to document a precondition for a valid "rid" and providing a link to that from here. 10. Section 3.6. Removing Attachments via POST. 2.B Would be good to explicitly reference section 3.11 on Error handling for how servers should respond to an invalid "managed-id" query parameter. 11. Section 3.7 Adding Existing Managed Attachments via PUT This suggests that servers SHOULD NOT change either tha MANAGED-ID or ATTACH property for any managed attachments. Speaking for our server, the safest way to implement managed attachments would be to only allow attachment sharing within one calendar item, thus it is likely that we, and potentially others in the same situation would not follow this "SHOULD NOT" advice. Perhaps some text that clients should not assume this would be wise. 12. Section 3.11 Error Handling Need to document a precondition for POST that all RECURRENCE-IDs referenced in the "rid" query parameter must be valid. e.g. (CALDAV:valid-rid): The rid query parameter in the POST request MUST only contain values corresponding to valid "RECURRENCE-ID" properties in the iCalendar data targeted by the request. 13. Section 3.11 Error Handling How should servers respond if an unknown value for the action= query parameter is specified? Perhaps: (CALDAV:valid-action): The value for the action query parameter in the POST request is not supported by this server. 14. Section 4.3 MANAGED-ID Property Parameter This documents a new ICALENDAR property. Should there be some linkage to say this updates RFC5545? 15. Section 6. Additional WebDAV properties Should there be some linkage in this document to say this updates the CalDAV RFC4791? Regards, Gren Elliot of Synacor Zimbra. 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.
- Re: [calsify] Apologies re re-post of Review of d… Gren Elliot
- Re: [calsify] Review of draft-ietf-calext-caldav-… Gren Elliot
- [calsify] I-D Action: draft-ietf-calext-caldav-at… internet-drafts
- Re: [calsify] I-D Action: draft-ietf-calext-calda… Gren Elliot
- Re: [calsify] I-D Action: draft-ietf-calext-calda… Ronald Tse
- Re: [calsify] I-D Action: draft-ietf-calext-calda… Tobias Friedrich
- Re: [calsify] I-D Action: draft-ietf-calext-calda… Daniel Migault
- Re: [calsify] I-D Action: draft-ietf-calext-calda… Ken Murchison
- Re: [calsify] I-D Action: draft-ietf-calext-calda… Gren Elliot
- Re: [calsify] I-D Action: draft-ietf-calext-calda… Tobias Friedrich
- Re: [calsify] I-D Action: draft-ietf-calext-calda… Gren Elliot