[caldav] Comments on draft-desruisseaux-caldav-sched-09
Keith Jay Gillis <kjgillis@coalesco.org> Sun, 23 January 2011 06:01 UTC
Return-Path: <kjgillis@coalesco.org>
X-Original-To: caldav@core3.amsl.com
Delivered-To: caldav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAA813A68AF for <caldav@core3.amsl.com>; Sat, 22 Jan 2011 22:01:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.988
X-Spam-Level:
X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_MISMATCH_ORG=0.611]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKyNC-vvwx5t for <caldav@core3.amsl.com>; Sat, 22 Jan 2011 22:01:37 -0800 (PST)
Received: from coalesco.org (kjgillis.name [64.27.57.71]) by core3.amsl.com (Postfix) with ESMTP id D70083A6BF0 for <caldav@ietf.org>; Sat, 22 Jan 2011 22:01:36 -0800 (PST)
Received: from [192.168.1.3] (seadsl-d-207-244-147-47.dsl.w-link.net [207.244.147.47]) by coalesco.org (Postfix) with ESMTPSA id C48CF707BC for <caldav@ietf.org>; Sat, 22 Jan 2011 22:04:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=coalesco.org; s=K000001; t=1295762664; bh=9lct7LXdnqTaL+mi6Pzx2elC7amRlLAEX/swzlSTOP4=; h=Subject:From:To:Content-Type:Date:Message-ID:Mime-Version; b=RhoQFGYosxx4tRiXiSXogi++8Z01KyTkmwVV3xF5Hf9RI2LyMM52JF4m/cnyz3PQE uI+gkpYH8kqkOu/LaJx3VNJiuVG/mFDm3UXq7XRETZkLLpZTcYsPUEdYTOZH6+Jnxl BPe/Tirz3MoXQ7O9RzGRID/BWgy0hUF0rvZIVRDc=
From: Keith Jay Gillis <kjgillis@coalesco.org>
To: caldav@ietf.org
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Wp2rnA4jHU8zPECbnPGX"
Date: Sat, 22 Jan 2011 22:04:26 -0800
Message-ID: <1295762666.18243.259.camel@kjgillis1.coalesco.org>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Subject: [caldav] Comments on draft-desruisseaux-caldav-sched-09
X-BeenThere: caldav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <caldav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/caldav>
List-Post: <mailto:caldav@ietf.org>
List-Help: <mailto:caldav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/caldav>, <mailto:caldav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Jan 2011 06:01:39 -0000
Hi, If I'm reading the draft correctly, the server automatically adds scheduling objects to the default calendar in response to scheduling requests without giving the user an opportunity to review them. I might be misunderstanding parts of the draft, but this behavior seems like it could cause problems. In draft-desruisseaux-caldav-sched-09 §B.3 the notification has TRANSP set to OPAQUE. Would the TRANSP property of the scheduling object added to the default calendar be set the same way? If freebusy altering events are added to the calendar without confirmation, someone could make you appear busy when you are actually free. If the incorrect information isn't removed quickly, it could make planning a meeting difficult for someone using the freebusy information. This might not be an issue if events with the attendee's PARTSTAT set to anything other than CONFIRMED are excluded from freebusy and if the server only automatically adds events with PARTSTAT set to NEEDS-ACTION. RFC 4791 §7.10 specifies something similar to using PARTSTAT where freebusy is derived from TRANSP and STATUS. Would unconfirmed events be treated as though CLASS was set to PRIVATE? Could an automatically added event be used to make someone believe you are attending an event you are not actually attending? I know ACLs could be used to prevent the malicious addition of events to the default calendar. What if you want to receive events from someone you do not completely trust? Would you have to choose between blocking them, and not receiving any invitations from them, or allowing them, and risking abuse? Would requests from blocked users be dropped without alerting the recipient? I'm also curious about how the management of ACLs would work. Would these ACLs typically be set to deny by default? If so, would an organizer of an event that involved people from multiple organizations, who might not have added the organizer to their ACLs, need to contact the potential attendees through some out-of-band means to request that the organizer be added to the attendees ACLs before the organizer could send invitations? That would be cumbersome. The draft does not make the relationship between server-to-server delivery of invitations and the features described in the draft clear. Draft 04 made it clear in §4.2 ¶4 with "note that remote delivery mechanisms are not defined in this specification". A similar sentence in draft 09 might help. Thanks, Keith
- [caldav] Comments on draft-desruisseaux-caldav-sc… Keith Jay Gillis