Re: [calsify] Shepherd Review of draft-ietf-calext-caldav-attachments

Cyrus Daboo <cyrus@daboo.name> Fri, 14 April 2017 15:12 UTC

Return-Path: <cyrus@daboo.name>
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 0D27F13010C; Fri, 14 Apr 2017 08:12:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 tTPptVjUUsru; Fri, 14 Apr 2017 08:11:58 -0700 (PDT)
Received: from daboo.name (daboo.name [173.13.55.49]) (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 B78B7131101; Fri, 14 Apr 2017 08:11:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id D07F169D9C06; Fri, 14 Apr 2017 11:11:55 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGmZ94-dc0jI; Fri, 14 Apr 2017 11:11:55 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.44.178.52]) by daboo.name (Postfix) with ESMTPSA id 9F8BE69D9BFA; Fri, 14 Apr 2017 11:11:54 -0400 (EDT)
Date: Fri, 14 Apr 2017 11:11:47 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Philipp Kewisch <mozilla@kewis.ch>, Calsify <calsify@ietf.org>
cc: draft-ietf-calext-caldav-attachments.authors@ietf.org
Message-ID: <542BFDD77B44AB53C66FB48E@caldav.corp.apple.com>
In-Reply-To: <95b28712-5d79-4eca-ca35-a127ae30fb9c@kewis.ch>
References: <95b28712-5d79-4eca-ca35-a127ae30fb9c@kewis.ch>
X-Mailer: Mulberry/4.1.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="2118"
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/JsZsfoYCrorN5pLRZcGlht2KdNI>
Subject: Re: [calsify] Shepherd Review of draft-ietf-calext-caldav-attachments
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: Fri, 14 Apr 2017 15:12:02 -0000

Hi Philipp,
Thanks for you review.

--On April 13, 2017 at 12:05:55 PM +0200 Philipp Kewisch <mozilla@kewis.ch> 
wrote:

>>    Specific instance  A specific iCalendar instance is targeted by using
>>       its "RECURRENCE-ID" value as the item value.  That value MUST
>>       correspond to the RECURRENCE-ID value as stored in the calendar
>>       object resource (i.e. without any conversion to UTC).  If multiple
>>       items of this form are used, they MUST be unique values.
> Can you clarify why you chose to not allow specifying this value in any
> form, so that the server does timezone translation if needed?

I think we wanted to avoid the need for the server or client to have to do 
any conversions, which could prove problematic particularly if the time 
zone definitions the client and server have differ (which was something 
that could happen at the time we wrote the initial spec, but is now less 
likely to happen with the time zones by reference feature).

>>        D.  Upon successful creation of the attachment resource, and
>>            modification of the targeted calendar object resource, the
>>            server MUST return an appropriate HTTP success status
>>            response and include a "Cal-Managed-ID" header field
>>            containing the "MANAGED-ID" parameter value of the newly
>>            created "ATTACH" property.
> Any specific reason to shorten "Calendar" to "Cal" here?

I don't recall any specific version for that choice. However, it would be 
best not to change that given that existing deployments do make use of it.

>>  Malicious content could be introduced into the Calendar Server by way
>>    of a managed attachment, and propagated to many end users via
>>    scheduling.  Servers SHOULD check managed attachments for malicious
>>    or inappropriate content.  Upon detecting of such content, servers
>>    SHOULD remove the attachment, following the rules described in
>>    Section 3.12.5.
> "Calendar Server" should probably be lowercase here, as you are not
> referring to a specific product.

Agreed. Ken can make that change.

-- 
Cyrus Daboo